RE: [rohc] ROHC context reuse & mode

[zhigang.c.liu at nokia.com]

Hi,

Just throw in some of my thoughts. 

For U-mode, I have the same view with Carsten. It's not going to be 
efficient anyway due to the reason we have it in the first place.

RE O- and R-mode, there are three cases when the compressor sends an IR.

Case 1: same flow but received STATIC-NACK from the decompressor. In 
this case, each STATIC-NACK (as any feedback) carries the current 
mode as seen by the decompressor. So, there is no ambiguity to the 
compressor. If the mode in STATIC-NACK is the same as that of the 
compressor, the compressor will (as it should) stay in the same mode 
and send IR packets carrying the mode value as in the STATIC-NACK. 
If it is different, the compressor will treat it as a mode transition
and act accordingly. In either case, the IR packets must carry all the
context information that is needed by the decompressor to re-establish
context (since the decompressor may have lost them in the worst case).

(I think this also answers the question from Kristofer why we have
mode field in IR packets. In other words, the mode is handled
specially in RFC 3095 so that the synchronization of mode can run
in parallel with ROHC states.)

Case 2: start a new flow with a CID that hasn't been used. Simple.
Start in U-mode as it should be.

Case 3: start a new flow but reuse CID. This is the sticky case.
Two subcases. 

3a) If the new flow belongs to a different profile, the compressor
should start in U-mode as discussed. 

3b) If same profile, this is actually similar to Case 1 (if you think 
hard about it). The only difference is that the decompressor didn't
send STATIC-NACK. The compressor can stay in the same mode for the 
CID (before the new flow), and send all context info in IR (see Case 1 
above).

There may be other details to check, e.g., whether we have race condition
caused by decompressor sending STATIC-NACK while compressor starts a
new flow? But later ...

BR,
Zhigang


> -----Original Message-----
> From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext
> Carsten Bormann
> Sent: 12 February, 2004 02:56 AM
> To: Kristofer Sandlund
> Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); rohc@ietf.org
> Subject: Re: [rohc] ROHC context reuse & mode
> 
> 
> 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
> 

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