RE: [rohc] ROHC context reuse & mode

[zhigang.c.liu at nokia.com]

Hi Kristofer,

> So what are you saying should happen here? Should every 
> periodic refresh flush the entire context every time? Including 
> list compression tables?

Yes. This is simply a risk management in U-mode. You never know
if the decompressor has received a particular packet. However, 
the compressor can choose the frequency of IRs, and IR-DYNAMIC
and other context update packets for that matter.

> It seems like we're throwing away a bit more than we'd need 
> to, but I can agree to that as long as it is clarified if the 
> compressor is allowed to use any "old information" after sending
> a periodic refresh

Sorry, I'm not sure I follow you. Anyway, the reason that the compressor
sends an IR packet is that it fears the decompressor may not has a 
certain context (see above). And the decompressor will assume the IR 
packet means to re-establish context from clean slate. For partial
context refresh, other packets (e.g. IR-DYNAMIC) can be used.

> One ambiguity is profiles 2 & 3 which do not have mode 
> information in the IR packets, so the IR cannot say which 
> mode it is meant for. 

This is true. It would be cleaner if we had put the mode outside of 
RTP dynamic chain ...

> So the decompressor probably must stay in its current mode 
> when this happens? Can this cause any problems?

If the previous profile for this CID is different from what is 
received in an IR packet, the decompressor should start in 
U-mode since this clearly indicates a new packet flow.

Else, the decompressor cannot tell if it is a context refresh 
of the same packet flow or initialization of a new flow. Staying
in its current mode seems OK to me, because:
- if it is the former case, the compressor should not have switched
mode (it's always the decompressor that controls mode).
- if it is the latter case, the compressor is in U-mode and 
decompressor is in same or "higher" mode (in terms of expectation 
of feedback). For the "higher" case, the feedback from decompressor
will trigger the compressor to switch mode to the current mode
of the decompressor. I don't have time to think all the details, but
it seems to be harmless though the decompressor is unaware it 
actually triggered a mode transition.

> If the compressor has confidence that these were "accepted" last 
> time they were present in the packet (could have been ACKed), 
> then most likely they are still ok in the decompresor context. 

Then, the compressor should not send IR.

> It of course depends on exactly how to interpret the static-nack. 
> What do you guys think?

STATIC-NACK means the decompressor believes its static context has 
been corrupted. Since there is no way to indicate "partial" context
corruption, the compressor has to assume the worst. Anyway, STATIC-NACK
should be a rare condition after the first ACK, so the effect on
efficiency should be quite small.

> I agree that there might be some pitfalls here that are hard 
> to predict, so we probably need to think about it for a bit.
> Whatever we decide, I think there needs to be some text to go 
> into the implementer's guide. This discussion proves that it is not 
> fully clear from 3095.

Agree.

BR,
Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc