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

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 03 May 2002 17:58:33 +0100

Hi Hongbin, Qian,

Thanks for picking this discussion up.  Let me throw in a few more 
questions and observations based on my initial thoughts...

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. 
Also, for a very short-lived connection we probably wouldn't need to do 
this, and so we wouldn't lose any efficiency.  The question, I suppose, 
is how much efficiency could be gained (and at what cost in robustness) 
if we were to use context replication for periodic refreshes.

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.

More specifically regarding your proposal, I'm not quite sure why 
picking a context in FO/SO state helps particularly...
Naively I would expect that a state is most likely to be correct at the 
decompressor immediately after sending a bunch of IR/IR-DYN packets.

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.

In B-mode, the decompressor has the ability to send feedback indicating 
that the context replication failed.  In U-mode we may still be able to 
take advantage of some implicit 'hints'.  For example, if a SYN packet 
is sent with context replication, then the receipt of a data packet for 
this flow suggests (even if it doesn't guarantee) that the context was 
correctly initialised.
Likewise, in a more general U-mode case, retransmissions (specifically 
packets that have been seen at the compressor before, rather than just 
backward jumps in sequence number) can be seen as indicative of 
potential decompressor problems.  (Naturally they could also indicate 
losses on the link.  However a 'k out of n' strategy, or something, may 
be a way of making use of this...)

As ever, comments welcome...

Cheers,

Mark.

Hongbin Liao (Intl Staffing) wrote:

> Dear ROHC-TCPers
> 	In this mail, the second, context updating issues in U-mode.
> 
> Hongbin & Qian Zhang
> 04/30/2002
> 
> 
> Context updating issues, especially in U-mode
> 
> 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.) 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. If the context being selected as the base context is invalid, the context newly being created is also invalid. This issue can be solved by giving a general principle on how to select the base context. This principle is listed as follows:
> 	Only context in FO/SO states should be selected as the base.
> 
> 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. If the base is not valid, the compressor how to re-select another valid context as the base and sent CONTEXT-UPDATE. If the compressor can not find any valid context, it need send IR/IR-DYN packet.
> 
> As to handover, the compressor and decompressor MUST re-initialize the context when receiving signal CONTEXT_REINITIALIZATION.
> 
> 
> 
>>-----Original Message-----
>>From: Qian Zhang [mailto:[email-masked]] 
>>Sent: Tuesday, April 30, 2002 12:27 PM
>>To: [email-masked]
>>Subject: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN
>>
>>
>>Dear ROHC-TCPers,
>> 
>>We are working on updating the ROHC-TCP draft according to 
>>what was discussed at the Minneapolis meeting. 
>>We would like to discuss the following issues in separate 
>>email thread. 1. U/B mode, mode transition, and MSN issues 2. 
>>Context replication/updating issue, especially in U-mode
>>
>>
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Tue, 14 May 2002 00:21:40 +0800

Hi, Mark
	Comments inline...

Cheers

Hongbin and Qian
05/13/2002

> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Sunday, May 12, 2002 5:48 PM
> To: Hongbin Liao (Intl Staffing)
> Cc: [email-masked]
> Subject: Re: [rohc] ROHC-TCP issue: context updating in U-mode
> 
> 
> 
> Hi Hongbin,
> 
> A couple more comments...
> 
> Cheers,
> 
> Mark.
> 
>   >
>   >> More specifically regarding your proposal, I'm not quite
> sure why picking
>   >>  a context in FO/SO state helps particularly... Naively I would
>   >> expect that a state is most likely to be  correct at the 
>  decompressor
>   >>  immediately after sending a bunch of IR/IR-DYN packets.
>   >>
>   >
>   > The reason why only contexts in FO/SO state are elected 
> as the base
>   > context is that, we have to ensure the base context at the
>   > decompressor side is valid. For a connection, only when the
>   > compressor can make sure the context of the connection at
>   > decompressor is valid (at a great probability), the context at the
>   > compressor side jumps into FO/SO state. So, if a context is in
>   > FO/SO state, we can know the context at the decompressor is valid
>   > (at a great probability). In your suggestion, you assume 
> that after
>   >  a bunch of IR/IR-DYN packets, the decompressor's context tends to
>   > be valid. This seems ok. However, an intuition concern is that, in
>   > this case, the compressor's context can jump into FO/SO state.
>   >
> 
> I think that what I'm trying to say is that the point at
> which I *most* trust the context is the point at which I 
> transit to FO/SO state (in other words, I largely agree with 
> you).  However, as soon as I am in FO/SO state, my confidence 
> in the context will start to degrade.
> 
> And I think that we have to be aware that we cannot *ensure*
> that the base context at the decopmressor is correct.  But we 
> need to maximise the probability that it is correct and, if 
> possible, think of ways of detecting problems (in U-mode this 
> really means making use of implicit hints).
> 

Yeah, we do agree that when the compressor jumps into the FO/SO state,
then the confidence about the correct context will start to degrade.
However, as long as it is in the FO/SO state, the compressor had enough
confidence that the compressor and decompressor had synchronized context
information. That is why only contexts in FO/SO state are used as the
base contexts, that means their corresponding context at the
decompressor are more likely to be valid.

>   >
>   >> 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.
>   >>
>   >
>   > 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.
>   >
> 
> I'm really just concerned that we strike the right balance 
> between performance (efficiency) and robustness.
> 
> 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.
> 

Agree.

>   >
>   >>Also, for a very short-lived connection we probably 
> wouldn't need to
>   >>do this, and so we wouldn't lose any efficiency.  The question,
>   >>I suppose,
>   > 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.
> 
> 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.
> 

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.

> Now, if it is only possible for flow B to transit to FO/SO 
> state through 
> sufficient implicit hints that we can be 'certain' that the flow is 
> being correctly decompressed, then there is much less of a concern.
> 
> However, if flow B could get to FO/SO state (in U-mode) 
> simply through 
> some count of the number of packets sent, then I think that 
> this is a risk.

That is a different story. That is the issue related to the state
transition. In U-mode, we have several explicit and implicit ways to
know that whether B should jump into FO/SO or not. For example, we can
use congestion window tracking algorithm as an optimization scheme to
improve this, etc.

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

---

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

Some more thoughts inline...

BR,
/L-E

>>>> LEJ:
>>>> 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 etablished. 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.
>>>
>>> MW: 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.
>>
>> HL: However, as stated by Mark "I am not sure that such a thing
>> exists" too.
>
> MW: 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.

LEJ: To be honest, I did not see a way to get that either, but
wanted it to be stated by others. In my opinion, this really means
I think we should only replicate based on Bi-directional contexts,
and nothing else. Context replication is a new concept we are
introducing to improve performance, and I think we should be really
careful when doing this. If we do context replication on non-stable
contexts, the whole concept becomes much more complicated and
unreliable, and would be more like "context sharing", since the
contexts become dependent on each other. Further, the motive of
improving compression efficiency indicates that one want optimal
performance, which is something one can not get in Unidirectional
operation anyway.

>> HL: 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.
> 
> MW: But I think that it can be argued that the effects of
> context replication failing are more serious / add more
> complexity.
> 
> MW: 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: Yes, optimistic approaches without confirmation (either acks
or lack of nacks) would always require fall-back to "no assumption
on reception". Further, we should note that there is a significant
difference between optimistic state transitions in Unidirectional
operation (with fall-back to IR) and optimistic context replication.
If an optimistic state transition in U-operation fails, that would 
result in additional losses, but only if data for that stream has already been lost. An optimistic approach should not cause losses
for a stream that would not had experienced any losses without header
compression. If we replicate a context that has not been established
at the decompressor, the new packet stream would see packets being
lost even if all packets from that stream are correctly transferred.

The principle of doing periodic fall-back in Unidirectional operation
has been established because one can never trust the context in such
cases. Therefore, I feel uncomfortable with the idea of replicating
contexts established in a Unidirectional manner.

> MW: 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. So, if I initialise
> context C from context B, I'm now down to just under 86% chance
> of C being right...
> 
> MW: (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)

LEJ: I think this rough example shows that even if one do context
replication, one would have to send the same number of IR's to
keep the same confidence level as without replication. Does not that
mean context replication from Unidirectional contexts would be
useless from an efficiency point of view? The original idea of
context replication was to avoid sending information that we know
is available, which is not the case here, but would require Bi-
directional operation.

---

From: "Qian Zhang" <[email-masked]>
Date: Thu, 30 May 2002 19:20:29 +0800

Lars-Erik and Mark,

Thanks for all the comments.

It seems that the key issue for context replication is whether we should
support replication in U-mode.

We all agree that in B-mode we can easily make sure the correctness of
the base context by using feedback. However, in U-mode, it is hard to
verify the correctness of the base context, at least in a timely way.

Let us try to summarize the Pro & Con for supporting context replication
in U-mode.
Pro:
Averagely increase the compression efficiency, although in some cases,
it may not detect the inconsistent of the context timely.

Con:
Need rather complicated control on the compressor side.

So maybe we can simply make a basic principle that we will not support
context replication in U-mode, which will make the whole scheme maintain
simplicity.

Regards,

Qian

> From: Lars-Erik Jonsson (EPL)
[mailto:[email-masked]]
> Sent: Wednesday, May 29, 2002 8:27 PM
> To: [email-masked]
> Subject: RE: [rohc] ROHC-TCP issue: context updating in U-mode
> 
> result in additional losses, but only if data for that stream has
already
> been lost. An optimistic approach should not cause losses