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

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 10 Feb 2004 11:34:26 +0100

Kristofer,

These are good questions, let's see if we can figure out 
answers to them, it might be necessary to clarify some of
these in the implementer's guide.

> Example 1:
> A ROHC compressor is running in O-mode on context #1 (say for
> example IPv4/UDP/RTP, profile 1), when it decides to reuse
> this this context for a  completely different flow (say
> IPv6/UDP/RTP, profile 1). The compressor will of course have
> to send an IR packet to the decompressor, but what mode must
> it set in the IR packet? Do I inherit the mode of the old
> flow or do I go back to U-mode?

My spontaneous answer would be, "it's a new stream, and a new
context, you must start in U-mode". Does this answer fly?
Let's see...

> RFC3095 Section 4.4.1.  "Unidirectional mode -- U-mode" says:
>     Compression with ROHC MUST start in the Unidirectional mode.
> 
> Does this mean that the compressor starts in U-mode "when the 
> channel is set-up" or "whenever the compressor re-initializes
> a context"?
> If I interpret it as the latter, then the decompressor will 
> see an IR with U-mode while being in O-mode, i.e. a mode
> change occurs without the 3-way handshake.

Yes, but this should work when it is initiated by the compressor,
right? The 3-way handshake is there in **->U-mode because one
must ensure that the compressor will not continue to rely on
feedback.
 
> Example 2:
> The compressor has received the CONTEXT_REINITIALIZATION 
> signal (section 6.3.1), but the channel is kept up and
> running. Then it seems most likely that compression must
> start in U-mode since you are supposed to re-establish 
> everything (true?). The decompressor is in O-mode in this 
> example as well. So it seems we cannot completely avoid
> a situation where the compressor could be forced to send
> U-mode IRs to an O-mode decompressor.

True, but that should not be risky, as long as it is done
on initiative by the compressor (i.e. the compressor knows
it is operating in U-mode), as all U-mode packets have a
CRC, errors can thus be avoided and would be resolved.

> "Bonus questions":
> * How does this work in profiles 2 & 3 where there is
> no mode parameter to send in the IR packets? Do I
> inherit "current mode" or do I inherit "initial mode"?

In the same way, I think it should be "initial mode", but
a compressor implementation that does this must of course
be very careful ensuring the decompressor will interpret
the packets correctly.

> * If I reuse a profile 1 context in R-mode and make it a 
> profile 0 or TCP profile context (these do not have R-mode),
> what does my compressor send? I cannot inherit
> "current mode" (R-mode), since it does not exist, and it
> seems like inheriting "initial mode" for the selected
> profile would be the only choice here.

Yes!
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. At the
end of this message, my employer might have automatically inserted
a stupid disclaimer. This nonsense is out of my control and should
simply be ignored.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Tue, 10 Feb 2004 13:33:58 +0100

Hi L-E,

Thank you for your reply.
I agree with you that "initial mode" (U-mode) seems like the best solution. That 
should probably go into the implementer's guide.

<snip>
 > be very careful ensuring the decompressor will interpret

CAN the compressor "ensure that the decompressor will interpret the packets 
correctly"? As it is currently specified, the decompressor is not forced to have 
any kind of detection that this is a new flow. To me it seems like it should be 
the responsibility of the decompressor to be able to detect when the flow has 
changed. I think we should say in the implementer's guide something like:
  "The decompressor must be able to detect when an IR packet is used to 
reinitialize a context with a different flow than the current flow in that 
context. When such an IR packet is received, the decompressor should start in 
its initial mode if no mode parameter was included in the IR packet. At this 
time, the decompressor may also discard all information stored in the old context."

Exactly how decompressor detects that it is a new flow can be an implementation 
detail, but it could for example "diff" all the STATIC-DEF fields of the new IR 
with the old context to see if it is a new flow.

Rgds,
	Kristofer Sandlund, Effnet AB

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Feb 2004 21:15:10 +0100

>> channel is set-up" or "whenever the compressor re-initializes

I believe the intention has been all the time that initializing a 
context using an IR packet would start with a clean slate, as if the 
channel was just created.  I.e., this is a new context, even when a CID 
is being reused.

I'm too busy to do the analysis (read: dusting off brain cells) right 
now:
Do we have any case where we need to maintain previous state beyond an 
IR packet?

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 11 Feb 2004 08:35:34 +0100

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?

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.

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?

Rgds,

Carsten Bormann wrote:
> I'm too busy to do the analysis (read: dusting off brain cells) right now: