Subject: [rohc] ROHC context reuse & mode

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 06 Feb 2004 09:02:52 +0100

Hi all!

I think I have found an ambiguity in RFC3095 that I would like to have 
clarified. I will explain the situation with examples.

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?

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.

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.

"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"?
* 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.

So, this might seem like a pure implementation choice at first, but I think this 
needs to be clarified, since the questions posed above seem pretty unclear to me.

Regards,
     Kristofer Sandlund, Effnet AB

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 11 Feb 2004 09:51:31 +0100

Kristofer,

> 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."

This looks ok, I'll add a new section on aspects of
"context re-use" and include this text. I think we
should also say something about the compressor, like:
  "When a ROHC compressor runs out of available 
   context identifiers or context memory resources,
   it can re-use an already established context and
   re-initialize it with IR for the new packet stream.
   The context must then be handled as a new context,
   which means compression must be carried out according
   to the initial mode of operation (U-mode)."

It is probably also useful to spell out what you said
in your previous mail. 
  "Exactly how a decompressor detects that a context
   is being re-initialized for a new flow is an
   implementation detail, but one possible approach
   could be to make a "diff" between all the STATIC-DEF
   fields of the new IR and the old context."

/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.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 16 Feb 2004 10:04:39 +0100

> 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).

One question is whether this is ok according to 3095? Personally, I
agree with Carsten that when a new context is initialized, it must
start in U-mode, and that would also apply to the CID reuse case.

/L-E

---

From: [email-masked]
Date: Mon, 16 Feb 2004 18:02:35 -0500

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

---

From: [email-masked]
Date: Tue, 17 Feb 2004 13:30:44 -0500

Lars-Erik,

Technically, I don't seen any interoperability problem for the
compressor to stay in current mode (see my email to Kristofer). 
Do you?

BTW, could you please copy me in the To or CC list when commenting
on my emails? That makes it easier for me to know you have comments.
Thanks.

Zhigang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Lars-Erik Jonsson (LU/EAB)
> Sent: 16 February, 2004 03:05 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [rohc] ROHC context reuse & mode
> 
> 
> 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.
> 
>

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Wed, 18 Feb 2004 09:44:01 +0100

Zhigang,

I am not sure there would be any technical problems
with it, but it is indeed a change in principle from
what is stated by 3095, as 3095 clearly says new
contexts must start in U-mode.

Either way, we should put some clarifying text in the
impl. guide, we just have to agree on what (I'll have
to think some more about this, or let others convince
me on which approach makes most sense).

/L-E

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 17 februari 2004 19:31
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]
> Cc: [email-masked]

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Wed, 18 Feb 2004 09:44:01 +0100

Zhigang,

/L-E

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Wed, 18 Feb 2004 14:31:41 +0100

OK,

I can buy that argumentation. So, what we should clarify then is that:
1) This is what happens when a context is re-used 
   for a new flow, compressed with the same profile.
2) If a context is re-used for compression of a new
   flow using a different profile, compression is
   obviously restarted in U-mode, independent of 
   previous mode

Would that be it?
/L-E

Zhigang/L-E,

I think that Zhigang's scheme of letting mode be inherited when we have the same 
profile seems like the best choice to me. I think this approach will be more 
consistent with the mode transition logic.
If we choose the "always U-mode when new flow" approach, and a new flow appears 
in the middle of a pending mode transition, we would probably have to specify 
that the decompressor must detect that it is a new flow (for example 
static-def-diffing as I suggested earlier) and also it should set D_TRANS=done & 
D_MODE=U-mode when we have a new flow (i.e. mode trans must be restarted). The 
inheritance scheme will just complete the mode transition without having to 
understand that it is a new flow.

I can agree that this is slightly inconsistent with the spec, but I don't think 
it "clearly says new contexts must start in U-mode". All it says is "Compression 
with ROHC MUST start in the Unidirectional mode" (sec. 4.4.1), which _could_ be 
interpreted as being on a per-channel basis. If so, mode inheritance is 
completely ok.

Rgds,

---

From: [email-masked]
Date: Wed, 18 Feb 2004 12:33:09 -0500

Lars-Erik,

It looks there are 4 aspects of this issue (or any other
issues for that matter), the last one being the most important.

1) What does the RFC 3095 text say?

section 4.4.1: "Compression with ROHC MUST start in the 
Unidirectional mode."

The text is a bit ambiguous, as Kristofer raised the question: does 
it mean per ROHC context, or per ROHC channel? But I also think
our *intension* was "per context", considering we could have different
modes for different contexts (may or may not make sense in practice, but 
the flexibility is good). On the other hand, this looks unnecessary 
to me (see below).

2) What's the principle/reason behind the text?

If I remember correctly, the main reason to have U-mode was because
we might have to run ROHC over links where feedback is not possible.

Clearly, this is not the case we are discussing here. We know there
are feedback channel if we have already been in bi-directional mode.

3) What's benefit of staying in the same mode?

Avoid the overhead of switching from U-mode to Bi-mode for every packet
flow. U-mode is not desirable due to its lower compression efficiency 
and higher chance of loss propagation. So, I expect bi-mode will be
mostly used in practice. In fact, I've seen contributions in 3GPP 
related to concerns about U-mode. 

4) Does the approach of staying in same mode interoperate?

All being said, we still have to make sure the approach interoperates
with implementations that assume every context starts from U-mode. If
it does not, the story will end here. If it does, I don't see why
we cannot clarify the approach in the implementation I-D. So far,
I haven't seen it's a problem by my own analysis.

BR,
Zhigang

> From: ext Lars-Erik Jonsson [mailto:[email-masked]]
> Sent: 18 February, 2004 02:44 AM
> To: [email-masked]
> Cc: Liu Zhigang.C (Nokia-NRC/Dallas)

---

From: [email-masked]
Date: Wed, 18 Feb 2004 12:59:26 -0500

To be accurate, we should say context ID is reused, not the context
(e.g. header field values, parameters, etc).

In addition, we can also make a clarification related to this: an IR 
packet will flush out the decompressor context that exists before 
receipt of the IR packet. (Note: mode is treated differently than
the "normal" context which can be in different states.)

BR,
Zhigang

> Sent: 18 February, 2004 07:32 AM
> Cc: [email-masked]; Liu Zhigang.C (Nokia-NRC/Dallas)
> Subject: Re: Re: [rohc] ROHC context reuse & mode
> 
> 
> 
> OK,
>