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

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Fri, 10 May 2002 21:51:11 +0800

Hi, Mark
	Comments inline...

Cheers
Hongbin L.
05/10/2002

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Saturday, May 04, 2002 12:59 AM
> To: Hongbin Liao (Intl Staffing)
> Cc: [email-masked]
> Subject: Re: [rohc] ROHC-TCP issue: context updating in U-mode
> 

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

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

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.

Here, to avoid the overhead of find the valid base context, the compressor may add a pointer to the base context. Then, the compressor first checks whether the base context is still valid. If not, it should find another valid one as the base; otherwise, IR/IR-DYN is needed and the pointer is set to nil. Remember, the base context should be in FO/SO state as we mention above, there will not exist a chain of dependencies.

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

Agree.

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

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 12 May 2002 10:47:58 +0100

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

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

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

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.