Subject: [seamoby] Header compression context extablishment

From: [email-masked]
Date: Thu, 22 Mar 2001 12:25:43 -0700 (MST)

To: [email-masked], [email-masked], [email-masked]

Re: Header compression state establishment
==========================================

Folks, 

It has come to my attention that some more or less
informed statements have been made regarding header
compression and how efficient/inefficient (re)establishment
of header compression state might be. 

In particular, the statements made in 

draft-ietf-seamoby-context-transfer-problem-stat-00.txt

are not completely accurate. This is an attempt to clarify the
situation for the header compression methodology developed in the 
ROHC WG.

The typical startup scenario for the ROHC header compression
schemes for telephony streams is as follows:

1) send a small number of IR packets with a header size roughly similar
to the header size of uncompressed headers. I expect that most
implementations will send roughly 3 IR packets.

If operating in U-mode or O-mode, this completes the context
initialization, and minimal packets will be sent henceforth.
U-mode can do an exponential backoff when sending IR packets, 
but the typical transition to O-mode or R-mode will prevent 
those IR packets from being sent. 

If operation in R-mode is desired, the minimal packets will be
sent until an acknowledgment (containing a mode transition request)
reaches the compressor. Then, 

2) during an additional roundtrip, non-minimal headers are sent during
transition to R-mode. 

Some parameters are as follows:

link roundtrip for cellular: 120-200 milliseconds.
(6-10 packets at 50 packets per second).

Minimal headers are 1 byte. 

Header size in 2) is rougly 4 bytes.

The header sizes indicated above do not include context identifiers,
which can be omitted completely for context identifier zero. 
Nor do they include the two-byte UDP checksum, which will not be sent at
all if disabled. Nor do they include the two byte IPv4 Identifier, 
which will be sent as-is if it changes randomly. Reasonable IP stacks
will have it change in increments of one, and then it will be 
completely removed. 

Hope this has helped to clarify the situation with regards to header
compression and its context (re) initialization. 

Mikael Degermark
Co-chair, ROHC WG

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 23 Mar 2001 19:04:46 -0800

Hello Mikael,

thanks for your e-mail. The text proposed in the CT problem statement draft,
which I contributed to, may not be complete. I think it was considered
adequate for -00.txt version of the draft. We could always use help from rohc
experts like yourself to improve upon.

Having said this, I don't agree with your overall characterization of the text
that it is not completely accurate. It perhaps needs to be elaborated for
U-mode and O-mode.  Even for these modes, I have questions for you to explain
why my text does not sufficiently capture the motivation needed for a CT
problem statement, which was its purpose to begin with!

I think it is pretty accurate for R-mode.

Regards,

-Rajeev

ps. there is a summary at the end of this e-mail :-)

> Re: Header compression state establishment

Reading your description below, it appears to me that the proposed text is
accurate for the R-mode, with the exception that the FO packet size would be 4
bytes. So, instead of characterizing the text as "not completely accurate", I
hope you would agree if it instead said "it is applicable to R-mode" (using
rohc terms). I appreciate your input so that we could cover all rohc cases
when we take up detailed work.

> implementations will send roughly 3 IR packets.

If I have voice packets to send at 20 ms intervals, and the link latency is 60
ms one-way, how is it that 3 IR packets are sufficient before I can receive an
Ack ?
Assuming that one of the 3 IR packets establishes "Static Context" at the
decompressor, that would take 3 IR packets worth of time. In order for the Ack
to reach the compressor, that would be another 3 IR packets worth of time. So
the total number of packets is 6 when link RTT is 120 ms, and 10 when link RTT
is 200 ms.  Isn't this correct ?

> those IR packets from being sent.

What do you mean by saying that after sending 3 IR packets, context
initialization is completed ? Do you mean that the decompressor can transition
from

     No Context -> Static Context -> Full Context

in 3 IR packets ?

For U-mode, this is what the rohc draft says:

5.3.1.1.1
"The compressor normally obtains its confidence about decompressor
   status by sending several packets with the same information according
   to the lower compression state. If the decompressor receives any of
   these packets, it will be in sync with the compressor. The number of
   consecutive packets to send for confidence is not defined in this
   document."

I assume that you think sending 3 IR packets is sufficient for the compressor
to gain confidence to transition all the way to SO state. I cannot comment on
this in U-mode, however, I do have some input for the O-mode later.

Simply for everyone's convenience, I include the paragraph from the rohc draft
for U-mode, in which feedback channel from the decompressor to compressor is
not available.

5.3.1.1.2
"When the optimistic approach is taken as described above, there will
   always be a possibility of failure since the decompressor may not
   have received sufficient information for correct decompression.
   Therefore, the compressor MUST periodically transit to lower
   compression states. Periodic transition to the IR state SHOULD be
   carried out less often than transition to the FO state. Two different
   timeouts SHOULD therefore be used for these transitions. For an
   example of how to implement periodic refreshes, see [IPHC] chapters
   3.3.1-3.3.2."

Reading the above, it appears to me that in the U-mode, the compressor ends up
(re)initializing the context several times according to the period chosen. I
suppose it is ok to say that this does not favor better compression
efficiency, e.g., in cellular links.

Now to the O-mode. You mention that 3 IR packets are sufficient for the
compressor to ascertain that the decompressor has transitioned from "No
Context" to "Static Context" to "Full Context". When I read Section 5.4.2.2
(Feedback Logic (O-mode)), I observed that when the decompressor receives an
IR packet, it always sends an ACK.

"State Actions

   NC:  - When an IR packet passes the CRC check, send an ACK(O).
   ...

 SC:  - When an IR packet is correctly decompressed, send an ACK(O).
 ....

 FC:  - When an IR packet is correctly decompressed, send an ACK(O)."

What would be the purpose of sending this ACK for IR packets ? Perhaps to help
the compressor positively determine that the decompressor has received and
processed the IR packet ? If that is the case, then the compressor has to
obtain the ACK before transitioning to better state. Going with 120 ms RTT, in
order for this ACK to come back, it would take _6_ packets (IR). Isn't this
right ?
Also, I don't know if the ACK gives sufficient confidence for the compressor
to jump from IR state directly to SO state without going through the FO
state..

> 2) during an additional roundtrip, non-minimal headers are sent during

The R-mode works in lockstep with ACKs. So, the text in the CT problem
statement is right.

> Header size in 2) is rougly 4 bytes.

Thanks for clarifying that size in 2) is 4 bytes. Thanks also for pointing out
the higher link latency (200 ms).

> Co-chair, ROHC WG

In summary,

1. I think that given the intent of the problem statement for HC context
relocation, the text served the purpose. It may not have been perfect,
however.

2. Context initialization is expensive in unreliable links. Since this has to
be done for _each_ packet stream individually, it gets worse with multiple
packets streams (such as with multimedia streams). It further exacerbates with
frequent handovers.

3. Context relocation, typically performed over high-speed wireline links,
provides a feasible alternative to context re-establishment during handovers.
It provides a mechanism to _seamlessly_ continue _all_ the compression
contexts belonging to the MN, along with performance benefits. I think this is
just right for seamoby to tackle!