Re: [rohc] ROHC context reuse & mode

[Carsten Bormann <cabo at tzi.org>]

On Feb 11 2004, at 08:35 Uhr, Kristofer Sandlund wrote:

> Hi Carsten,
>
> Are you saying that every IR packet (regardless of it being for a new 
> flow or not) should flush the ENTIRE decompressor context?
Not quite (but see below).
What I was trying to say is that a compressor must be prepared to deal 
with a decompressor that does exactly this.

> One case where some state probably should be kept is for the list 
> compression. Just because an extension header (or CSRC identifier) is 
> not present in the current IR packet does not mean that it's not 
> present in the context and could reappear in a later packet. If I 
> flush the list compression tables every time I get an IR packet, I 
> will have to re-establish every item once again. This does not seem to 
> be very efficient, especially in U-mode where I should periodically 
> refresh the context with IRs.
Well, U-mode is the simple example: We are sending IR-packets because 
we don't know whether the decompressor got enough of the previous 
packets to have set up state yet.  So the compressor must be prepared 
to deal with a decompressor that has a clean slate immediately after 
the IR.

> Also, if every IR would mean the same as establishing a new context, 
> wouldn't that mean that all IR:s would need to carry U-mode? (since 
> all compression should start in U-mode). Why then a mode parameter in 
> the profile 1 IR packet?
That is the interesting part.  Given that the compressor knows (R-mode) 
or is likely to be correct (O-mode) about the state at the 
decompressor, the U-mode argument above does not apply.  But then, we 
are sending an IR packet because something isn't right, so the 
assumptions that can be made about the state are probably limited.  It 
seems to me some serious analysis is required, which I can't do at the 
moment.

The questions I have in my mind:

1) Can it be dangerous for a decompressor to retain state beyond an IR?

2) Do we have an interoperability problem?
2a) Would your compressor have problems with a decompressor that starts 
with a clean slate after each IR packet?
2b) Would your decompressor have problems with a compressor that 
assumes this?  (Related to 1 above.)

Gruesse, Carsten


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