Subject: RE: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 17 May 2002 17:12:09 +0200

Qian and Mark,

I've finally been able to catch up on these discussions, and
commented on some of your discussions.

Cheers,
/L-E

>>> QZ: Transition from U-mode to B-mode
>>>  
>>> When there is feedback channel available, the decompressor 
>>> may at any moment decide to initiate transition from U-mode 
>>> to B-mode. Any feedback packet carrying a CRC can be used 
>>> with the mode parameter set to B. The decompressor can then 
>>> directly start working in B-mode. The compressor transits 
>>> from U-mode to B-mode as soon as it receive any feedback 
>>> packet that has the mode parameter set to B and that passes 
>>> the CRC check. 

LEJ: Explicit mode information is really not needed for this.
The decompressor can just start to send feedback, and continue
to do so. Whenever the compressor receives a feedback message,
it can disable periodical updates.

>>> QZ:Transition from B-mode to U-mode
>>> 
>>> The decompressor can force a transition back to U-mode if it 
>>> desires to do so. Any feedback packet carrying a CRC can be 
>>> used with the mode parameter set to U. The decompressor can 
>>> then directly start working in U-mode. The compressor 
>>> transits from B-mode to U-mode:
>>> 1) as soon as it receive any feedback packet that has the 
>>> mode parameter set to U and passes the CRC check, or 
>>> 2) for an enough long time period (TIMEOUT), it hasn't 
>>> received any feedback with the mode parameter set to B.

LEJ: This indicates that, as for ROHC RTP, one would really need
at least a 2-way handshake if one wants to go back to U-mode,
since the compressor must know when to stop expecting negative
acks, before the decompressor stops sending them. In ROHC RTP
we already had the mechanisms for mode transfer, so we added
the ability to go back to U-mode, but I am not sure we really
must support that.

>> MW: Qian and Hongbin have identified the aspect of TCP
>> compression that makes this an interesting challenge:
>> there is nothing obvious in the TCP/IP header that can be
>> easily used as an identifier for acknowledgements.
>>
>> We seem, therefore, to come to 3 or so choices:
>> 1/ Have 2 different packet formats for U and B mode (The B
>>    mode packets containing some kind of sequence identifier)
>> 2/ Have only 1 set of packet formats.
>>    This format set supports an explicit identifier, and:
>>       2a/ We keep the U/B mode distinction
>>       2b/ There is only one mode

LEJ: If we could avoid, or at least softening up the concept of,
different modes, that would absolutely simplify things.

>> 3/ Make use of TCP/IP header fields to construct an identifier
>>    for acks (Avoiding any need for explciit identifier)
>>
>> Taking these in reverse order, it seems natural to view the 
>> feedback as an optimisation (short-circuiting U-mode repeated
>> transmission and allowing failure reporting through negative acks).
>> In which case, it is not clear that to me that there is any need
>> to explicitly identify a U and a B mode...

LEJ: I totally agree, one mode with improved performance if feedback
can be used would be a nice solution. We should try to avoid
creating a complex mode concept, if not needed. 

>> MW: The advantage of (2) is that the identification is readily 
>> available for the decompressor to use for an acknowledgement
>> (and is small).  
> 
> QZ: If option (2) includes MSN in the uniform packet format, we 
> have to give the probability whether MSN is present or not
> (otherwise the MSN has to be always present, that is just no
> point.) Then the key issue is the probability for MSN in the packet. 

LEJ: I was about to say that this is a problem we never had before,
and that is in some way true. Just because we now might use mechanisms
to encode the compressed headers in a theoretically optimal way if
we can guess the right probabilities does not mean it is a big
problem if that can not be done. 50/50 would always work, or 
optimize for the more efficient case, i.e. when feedback is
available.

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Tue, 21 May 2002 23:35:16 +0100

Hi all,

Thanks for the feedback -- I shall now switch to bi-directional mode...

So it looks like we can probably go with a fairly loose separation 
between 'U' and 'B' mode?  (i.e. The very existence of feedback is 
sufficient to indicate the presence (and use of) a feedback channel). 
This means that we only need to convey MSN information on some packets 
and, although it may be hard to determine the probability for this, a 
fairly arbitrary choice is probably a workable 'engineering solution'!

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)