Subject: RE: [rohc] ROHC context reuse & mode

From: [email-masked]
Date: Fri, 13 Feb 2004 17:26:12 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Carsten Bormann
> Sent: 12 February, 2004 02:56 AM
> To: Kristofer Sandlund
> Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Kristofer Sandlund <[email-masked]>
Date: Sun, 15 Feb 2004 11:45:59 +0100

Hi Zhigang,

Thanks for your analysis. My comments inlined.

> efficient anyway due to the reason we have it in the first place.

So what are you saying should happen here? Should every periodic refresh flush 
the entire context every time? Including list compression tables?
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

> context (since the decompressor may have lost them in the worst case).

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. So the decompressor 
probably must stay in its current mode when this happens? Can this cause any 
problems?

I agree that the IR must carry everything needed to re-establish context, but 
what assumptions can be made regarding things that are not present in the 
current packet (e.g. List compression items that are known, are currently not 
present in the list, but might re-appear). 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. It of 
course depends on exactly how to interpret the static-nack. What do you guys think?

> Start in U-mode as it should be.

Agreed.
> should start in U-mode as discussed. 
Agreed.

> CID (before the new flow), and send all context info in IR (see Case 1 

Sure, works for me.

> caused by decompressor sending STATIC-NACK while compressor starts a

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.

Rgds,
	Kristofer Sandlund, Effnet AB