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

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Thu, 23 May 2002 20:39:57 +0800

Hi, Lars-Erik
	Comments inline...

Cheers
Hongbin
05/23/2002

> -----Original Message-----
> From: Lars-Erik Jonsson (EPL) 
> [mailto:[email-masked]] 
> Sent: Wednesday, May 22, 2002 8:46 PM
> To: Hongbin Liao (Intl Staffing); West, Mark (ITN)
> Cc: [email-masked]
> Subject: RE: [rohc] ROHC-TCP issue: context updating in U-mode
> 
> 
> 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.
> 

Totally agree.

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

Here, I agree with Mark that the main question is that "what is the level of confidence that is required in order to  replicate a context?" The same question can be also asked for transitions among IR/FO/SO states of contexts. In U-mode, context jumps into FO/SO from IR only when "it is fairly confident that the decompressor has received enough information to correctly decompress packets according to the higher compression state". IMHO, such a confidence should be enough for context replication in U-mode and I can avoid errors at a high probability.

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

However, the compressor can know the base context is 'fairly' valid after sending a bunch of IR/IR-DYN packets of that (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.
> 

Ok.

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

However, as stated by Mark "I am not sure that such a thing exists" too.

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

As stated above, the compressor need to choose an apposite context as base each time an IR/IR-DYN need transmitting. If such a base context is available, a context-replication packet is sent; otherwise, the IR/IR-DYN is sent instead. Also, at any time, a context can only be in one of the following two states: it's confident enough to be used as base or not. This kind of state doesn't depend on other contexts. We note the context-replication packet as CR(c,t) where 'c' is the base context and 't' is the time at which the context-replication packet is sent. Only CR(c,t) depend the enough confidence of context 'c' at time 't'. The context being established on base context 'c' doesn't depend context 'c' since it may send context-replication context based on a different context.

For example, at time t0, context A is confident enough to be selected as base. At the same time, context B wanna establish context at the decompressor and wanna sent IR/IR-DYN packet, it will found A and choose it as the base. A context-replication packet, CR(A,t0), is sent over the link to the decompressor. After that, at time t1, B is are also confident enough (A is still confident enough now) and context C wanna establish its own context. C can choose A or B as the base. Suppose C choose B as the context and send CR(B,t1) context-replication packet. Then, at time t2, context A is not confident enough due to whatever reasons, however context B is still confident enough. Context C is trying to establish or update the context at time t2. This time, context C can still choose B as the base regardless of A. However, if B is also not confident enough at time t2 and there is no other contexts confident enough, then context C can only send IR/IR-DYN packets. Whatever happens, there!
 will not be a chain of dependencies among them.

> 
> >>>> 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: Thu, 23 May 2002 16:57:23 +0100

Hi all,

A couple of comments...

Cheers,

Mark.

 >
 > Here, I agree with Mark that the main question is that "what is the
 > level of confidence that is required in order to  replicate a
 > context?" The same question can be also asked for transitions among
 >  IR/FO/SO states of contexts. In U-mode, context jumps into FO/SO
 > from IR only when "it is fairly confident that the decompressor has
 >  received enough information to correctly decompress packets
 > according to the higher compression state". IMHO, such a confidence
 >  should be enough for context replication in U-mode and I can avoid
 >  errors at a high probability.
 >

But I think that it can be argued that the effects of context 
replication failing are more serious / add more complexity.

Specifically, one of our reasons for doing context replication is to 
improve compression of short-lived connections.  As a user, if I end up 
waiting for multiple TCP retransmissions of the SYN packet because of 
this, I won't feel that my user experience has been improved by the 
compression.

If context-replication fails we have to be able to detect this and send 
a full IR packet.  It's not clear how we would do this in a timely fashion.

(An optimistic transition is always accompanied by the need to fall-back 
to a lower level.  The only 'lower level' than context replication is 
full IR)

 >> 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.
 >>
 > However, the compressor can know the base context is 'fairly' valid
 > after sending a bunch of IR/IR-DYN packets of that (base) context.
 >

How 'fairly' does it need to be?
;-)

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

So, if we agree that there is no reliable implicit ack, then we just 
need to agree the confidence level that is required to make use of 
context replication.

[Lots of stuff about chains of dependencies removed]

 > As stated above, the compressor need to choose an apposite context as
 > base each time an IR/IR-DYN need transmitting. If such a base context
 > is available, a context-replication packet is sent; otherwise, the
 > IR/IR-DYN is sent instead. Also, at any time, a context can only be in
 > one of the following two states: it's confident enough to be used as
 > base or not. This kind of state doesn't depend on other contexts. We
 > note the context-replication packet as CR(c,t) where 'c' is the base
 > context and 't' is the time at which the context-replication packet is
 > sent. Only CR(c,t) depend the enough confidence of context 'c' at time
 > 't'. The context being established on base context 'c' doesn't depend
 > context 'c' since it may send context-replication context based on a
 > different context.
 >
 > For example, at time t0, context A is confident enough to be selected
 > as base. At the same time, context B wanna establish context at the
 > decompressor and wanna sent IR/IR-DYN packet, it will found A and
 > choose it as the base. A context-replication packet, CR(A,t0), is sent
 > over the link to the decompressor. After that, at time t1, B is are
 > also confident enough (A is still confident enough now) and context C
 > wanna establish its own context. C can choose A or B as the base.
 > Suppose C choose B as the context and send CR(B,t1)
 > context-replication packet. Then, at time t2, context A is not
 > confident enough due to whatever reasons, however context B is still
 > confident enough. Context C is trying to establish or update the
 > context at time t2. This time, context C can still choose B as the
 > base regardless of A. However, if B is also not confident enough at
 >
 > time t2 and there is no other contexts confident enough, then context
 > C can only send IR/IR-DYN packets. Whatever happens, there will not be
 > a chain of dependencies among them.
 >
 >

So, earlier we agreed that there are no reliable implicit acks.  And, as 
you point out, the IR/FO/SO transitions are based on a 'reliable enough' 
concept.  Let's say (to give a probably specious argument), that I'm 95% 
sure that if I send 3 IR(-DYN)s, one of them gets through and 
initialises the context.

Then, if I initialise a new context (A) with IR packets, I'm 95% sure 
that it is correct.

Now, I initialise B from A, using CR packets.  I'm 95% sure that one of 
these will get through correctly, but I'm also only 95% sure that 
context A is correct.  So, context B is only correct with just over 90% 
probability.

(If I were to send a batch of IR packets at some point, I could bring B 
up to 95% confidence, but I am assuming that only IR-DYNs or CRs have 
been used.)

So, if I initialise context C from context B, I'm now down to just under 
86% hance of C being right...

(Yes, I know that this is a very simple argument, and ignores things 
such as the confidence level that I can get from implicit acks.  But I 
think that it makes my point)

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