Subject: [seamoby] [Fwd: Revised HC Relocation statement]

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Mar 2001 16:37:20 -0800

Hello James,

here is the posting to CT list that might be of interest to you. 

A deduction from this analysis is that header compression context
initialization is an expensive process in certain links. Thus, there is
a trade-off between the benefit it offers versus how long-lived the flow
is. If you have to do it for web traffic for example, some flow may live
as long as only 20 packets. So, you would have to weigh the overhead
versus the longevity of the flow.

Best Regards,

-Rajeev

Subject: Revised HC Relocation statement
From: Rajeev Koodli <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 25 Jan 2001 12:32:28 -0800

Hello folks,

following is a revised version. 

PatC, the co-chair: I wish to register a complaint that I can post
messages to this group, but I cannot see them myself! Any positive
action would be appreciated.

Regards,

-Rajeev

Header Compression (HC) Context Relocation
------------------------------------------

Compression of IP and transport layer headers is crucial over
low-bandwidth links in order to achieve efficient utilization of the
link capacity to deliver useful payload to applications. This header
compression involves maintaining state (context) information on the
network
periphery and the terminal and operating according to well-defined
protocol. When terminal mobility is involved, relocation of the
compression context(s) is needed in order to avoid surges in bandwidth
consumption associated with compression context re-establishment, which
causes interruptions to the smooth delivery real-time packets. This
overhead can be avoided, and thus the seamless operation of header
compression facilitated, by a simple transfer of context variables
from an access router's compression engine to that of the terminal's
new access router. 

The following terminology is used in describing the need for header
compression context relocation.

Full Header (FH) packet: Contains the full IP and transport protocol
headers,
plus the HC-specific fields

First Order (FO) [packet]: Contains only those fields that change from
packet to packet (e.g. RTP timestamp), and does not contain fields
that do not change at all.

Second Order (SO): Contains HC-specific header and sequence number. The
rest of the fields are constructed from the sequence number info and
the information maintained by the decompressor.

Problem Statement
-----------------
The motivation for HC context relocation is best understood by
examining the typical header compression operation.

A compressor starts by sending Full Header (FH) packets with HC-specific
headers in them and waits for few of the FHs to be reliably propagated
(e.g., ACK-based or 'n' number of headers transmitted). Note that in
bandwidth-constrained links, the link latency as well as higher error
probabilities could force the transmission of many FHs before confirming
reliable propagation of header information. Similarly, many FO packets
are sent before confirming that transition to the SO state is possible.
This process of "reference state" establishment is expensive. E.g., on a
60 ms cellular link and with 20 ms packetization for voice, it would
take 6 FHs (assuming no errors and dropped packets) to establish the FH
state
that allows transition to FO, and 6 more FOs to establish the
FH+FO reference state that allows transition to SO state. The total
overhead is thus 240 ms plus the processing overhead associated with
the header compression operation. Perhaps a value of 300 ms may be
deemed typical. Since this context establishment needs to be
done for each unidirectional packet stream, the overhead gets
worse with multiple packets streams belonging to the same mobile node
(approximately 600 ms for bidirectional voice).
When Mobile IPv6 is used with Home Address option, FH = 84 bytes
(excluding HC-specific fields) for a payload of about 20-30 bytes, and
FO could be 8 bytes. In comparison, the overhead is 1 byte when
operating in the SO state. 

The expensive overheads associated with context re-establishment can be
avoided by relocating the appropriate context between access routers.
For each type of compression mechanism used (e.g.,IPv6/UDP/RTP, IPv6
only, IPv6/TCP wtc), a Compression Profile Type (CPT) identifies the
particular type, and defines the state variables. Thus, the combination
of CPT, and the associated state variables (along with a suitable
identifier) constitutes the context for transfer purpose. This transfer
(presumably) occurs synchronously with handover signaling associated
with terminal mobility.