Subject: RE: [rohc] ROHC-TCP issue: context updating in U-mode

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 22 May 2002 14:46:22 +0200

Hongbin, Mark and others,

I've been following these discussions and will try to provide some
comments on the issues being discussed. First a few summarizing
observations and opinions:

1) The issue being discussed is mainly "how to do context
   replication in case or Unidirectional operation". In ROHC, and
   header compression discussions in general, the term "context
   update" has been used, and is already confusing and unclear
   enough. We should thus stick to the notion of "context
   replication", as previously agreed on this list.

2) When it comes to Unidirectional operation, I am not sure we
   should at all allow replication of contexts that have not been
   reliably established. Allowing that basically goes against the
   established practices of Unidirectional operation, where one
   periodically transit back to IR since one can never ensure that
   the context has ever been established. I think we should only
   allow context replication based on contexts for which
   bi-directional operation has been establish, or based on contexts
   that we, by RELIABLE implicit means, know have been established.

I have also commented on some core parts of the discussions. These
comments can be found below, where the number of ">"´s indicate which
message in the thread the text is taken from. MW stands for Mark West,
and HL for Hongbin Liao.

>>>>> HL: Context updating issues, especially in U-mode
>>>>> 
>>>>> HL: Content updating can be considered as the mechanism
>>>>> which establishes a context based on another valid context
>>>>> already created (we will refer this context as base context.)

LEJ: Let us use the notion of Context Replication, as we have
     previously agreed on this list. Context updating is an old term
     used with a different meaning.

>>>>> HL: This mechanism will reduce the overhead of context building
>>>>> significantly, especially for short-lived TCP connections.
>>>>> However, in U-mode, the compressor knows which one of existing
>>>>> contexts is valid without the feedback from the decompressor.

LEJ: One could basically say the compressor do not know.

>>>>> HL: When a context is being created, the compressor will select
>>>>> a valid state as the base and send a CONTEXT-UPDATE packet
>>>>> instead of IR/IR-DYN packet. Each time the compressor send a
>>>>> CONTEXT-UPDATE packet, it will check the base context is still
>>>>> in FO/SO state.

LEJ: In Unidirectional operation, this is timer-controlled. There is
thus no way of knowing that the context is established at the
decompressor, so there is no "valid" base context. 

>>>>> HL: As to handover, the compressor and decompressor MUST re-
>>>>> initialize the context when receiving signal
>>>>> CONTEXT_REINITIALIZATION.

LEJ: Handover considerations is left as an implementation issue
for ROHC RTP, since it depends on the link technology. Let's keep
it out of our work also for ROHC TCP.

>>>> MW: I assume that, for a U-mode flow, the compressor will 
>>>> periodically transit back to the IR state. Could/should this 
>>>> make use of the context updating concept, or must
>>>> 'traditional' IR/IR-DYN packets be used? Falling back to
>>>> sending regular IR/IR-DYN packets is obviously robust.
>>>
>>> HL: First we would like to clarify one thing for ROHC-TCP,
>>> the compressor will not periodically jump back to IR state
>>> even in U-mode. As stated above, we have the criterion how to
>>> select the base context, only context in FO/SO state can be
>>> chosen as the base. Even when the context has to jump back
>>> to IR state, we can still send context updating packet to
>>> achieve good performance.
>> 
>> MW: I'm really just concerned that we strike the right balance 
>> between performance (efficiency) and robustness.
>> 
>> MW: If we transit to IR state because of some suspicion that
>> we should refresh the context, we need to try and ensure that 
>> using context replication is actually doing the right thing 
>> and, if not, send a full IR packet.
> 
> HL: Agree.

LEJ: I think this means we can not use context replication if we
do not have knowledge of context establishment, either through a
bi-directional compression communication or by implicit knowledge, 
and then I mean reliable implicit knowledge, not just guesses. 

>>>> MW: A follow-on from this is -- should a context which has 
>>>> been created by context replication be used itself to create
>>>> a new context? Allowing this increases the flexibility that
>>>> we have to re-use contexts, but it also starts creating a
>>>> chain of dependencies.

LEJ: Even if a context is created through replication, it should
be useful for further replication IF it can be ensured it has been
correctly established at the decompressor. Of course, that excludes
contexts in Unidirectional operation from being replicated.

>>> HL: I am not sure why there will exist a chain of dependencies.
>>> Context-updating packet has the same functionality as IR/IR-DYN
>>> packet, instead it creates the context based on an already valid
>>> context. Each time an IR/IR-DYN need transmitting, the
>>> compressor can sent a context-updating packet in an efficient
>>> way. The context-updating packet only depends on the validity of
>>> the base context at the moment when it will be delivered. After
>>> that, such a dependency is removed automatically. When an
>>> context-updating needed, the compressor will check whether there
>>> is a valid context as the base. If there is one, then a context-
>>> updating packet is generated based on this base context and is
>>> transmitted; otherwise, an IR/IR-DYN packet is sent.
>> 
>> MW: What I was concerned about was that we take a flow, 'A' and 
>> use context replication to initialise the context for a new 
>> flow 'B'. The context for flow B will only be correct if the 
>> context replication from flow A succeeds. Now, say, that 
>> flow C starts.  If I initialise this from the context of flow 
>> B it is dependent upon the correctness of the context of flow 
>> B, which is itself dependent upon the context of flow A. 
> 
> HL: Maybe I had not explained clearly enough. According to our
> criterion, only contexts in FO/SO state can be used as the base 
> contexts, if A and B both use context updating to initialize the
> context, they can not rely on each other. However, if context A
> was in FO/SO state, B can use it as the base context. Until
> context B jump into FO/SO state, i.e. the context has been
> established at the decompressor, context C can use B as the base
> context. Otherwise, C cannot rely on B. To summary, only contexts
> with enough confidence that they are valid at the decompressor
> can be selected as the base. A simple criterion of this confidence
> is that the context is in FO/SO state.

LEJ: FO/SO is only an implicit (but less clear) way of saying about
the same as RFC 3095 says about transition to FO/SO: "the compressor
transits to a higher compression state when it is fairly confident
that the decompressor has received enough information to correctly
decompress packets according to the higher compression state". 
However, using the same criteria when using a context for replication
is not an obvious approach. When doing it in state transfer, one
assumes the compressor will periodically transit back to IR, or get
error messages if in Bi-directional operation. I agree with Mark that
one would create a chain of dependencies. 

>>>> MW: A random note: unlike a regular IR/IR-DYN packet, I think 
>>>> that the CRC protection needs to cover the state which is to be
>>>> created (rather than the state that is sent). It is important
>>>> that we protect against creating incorrect packets/context.
>>>
>>> HL: Agree.

LEJ: Spontaneous, I agree.

Cheers,
/L-E

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 22 May 2002 22:43:56 +0100

Hi Lars-Erik, all...

Comments upon comments!

>    replication", as previously agreed on this list.

I'll agree with that ;-)

>    that we, by RELIABLE implicit means, know have been established.

Whilst carefully side-stepping the issue of which contexts should be 
replicateable (if that is a word?), let me make a brief observation on 
'reliable implicit acks':

Basically, I am not sure that such a thing exists... (at least, not if 
we assume topological independence)  In this case, a retransmission can 
always be assumed to bypass the compressor and, therefore, we cannot 
assume that any subsequent packet implies that a previous packet has 
been received by the decompressor.

That is, either we assume topological restrictions, or we accept that 
implicit acks in U mode are 'strong hints'...

> it out of our work also for ROHC TCP.

Agreed...

So, the main question regarding context replication seems to be:

'what is the level of confidence that is required in order to replicate 
a context?'

Hongbin suggests the same level of confidence as is required to make an 
optimistic mode transition.  Lars-Erik suggest 'certainty' (i.e. 
bi-directional mode, or equivalent).  I am abstaining while I think 
about this a bit more...

Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)