Network Working Group Ghyslain Pelletier, Editor, Ericsson
INTERNET-DRAFT Qian Zhang, Microsoft Research Asia
Expires: May 2003 Lars-Erik Jonsson, Ericsson
HongBin Liao, Microsoft Research Asia
Mark A West, Siemens/Roke Manor
November 1, 2002
RObust Header Compression (ROHC):
TCP/IP Profile (ROHC-TCP)
<draft-ietf-rohc-tcp-03.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document specifies a ROHC (Robust Header Compression) profile
for compression of TCP/IP packets. The profile, called ROHC-TCP, is
a robust header compression scheme for TCP/IP that provides improved
compression efficiency and enhanced capabilities for compression of
various header fields including TCP options.
Existing TCP/IP header compression schemes do not work well when used
over links with significant error rates and long round-trip times.
For many bandwidth limited links where header compression is
essential, such characteristics are common. In addition, existing
schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP
options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-
2883] and Timestamps [RFC-1323].
Pelletier, Zhang, Jonsson, Liao, West. [Page 1]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
Table of contents
1. Introduction....................................................3
2. Terminology.....................................................3
3. Background......................................................4
3.1. Existing TCP/IP header compression schemes................4
3.2. Classification of TCP/IP header fields....................5
3.3. Characteristics of short-lived TCP transfers..............6
4. Overview of the TCP/IP profile..................................7
4.1. General concepts..........................................7
4.1.1. Context replication.....................................7
4.1.2. Feedback channel considerations.........................8
4.1.3. Master sequence number (MSN)............................8
4.2. ROHC-TCP operation........................................9
4.3. Encoding methods..........................................9
5. ROHC-TCP - TCP/IP compression (Profile 0x0006).................10
5.1. Packet types.............................................10
5.1.1. Initialization and Refresh packets (IR)................10
5.1.2. Compressed packets (CO)................................10
5.2. Compression logic........................................10
5.2.1. Compressor states and logic............................10
5.2.2. Initialization and Refresh (IR) state..................11
5.2.3. Compression (CO) state.................................11
5.2.4. Context replication....................................11
5.2.5. Feedback logic.........................................12
5.2.6. State transition logic.................................12
5.2.6.1. Optimistic approach, upward transition...............13
5.2.6.2. Optional acknowledgements (ACKs), upward transition..13
5.2.6.3. Timeouts, downward transition........................13
5.2.6.4. Negative ACKs (NACKs), downward transition...........13
5.2.6.5. Need for updates, downward transition................13
5.3. Decompression logic......................................14
5.3.1. Decompressor states and logic..........................14
5.3.2. No Context (NC) state..................................14
5.3.3. Full Context (FC) state................................15
5.3.4. Static Context (SC) state..............................15
5.3.5. Context replication....................................16
5.3.6. Allowing decompression.................................16
5.3.7. Reconstruction and verification........................16
5.3.8. Actions upon CRC failure...............................16
5.3.9. Feedback logic.........................................16
5.4. Packet formats...........................................16
6. Implementation considerations..................................16
6.1. Determination of the value N.............................16
7. Security considerations........................................17
8. IANA considerations............................................17
9. Acknowledgements...............................................18
10. References.....................................................18
10.1. Normative references.........................................18
10.2. Informative references.......................................18
11. Authors' addresses.............................................19
Pelletier, Zhang, Jonsson, Liao, West. [Page 2]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
1. Introduction
There are several reasons to perform header compression on low- or
medium-speed links for TCP/IP traffic, and these have already been
discussed in [RFC-2507]. [TCP-REQ] introduces additional
considerations making robustness an important objective for a TCP
compression scheme. Finally, existing TCP/IP header compression
schemes [RFC-1144, RFC-2507] are limited in their handling of the TCP
options field and cannot compress the headers of handshaking packets
(SYNs and FINs).
It is thus desirable for a header compression scheme to be able to
handle loss on the link between the compression and decompression
point as well as loss before the compression point. The header
compression scheme also needs to consider how to efficiently compress
short-lived TCP transfers and TCP options, such as SACK [RFC-2018,
RFC-2883] and Timestamps [RFC-1323].
The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets, or
for different compression strategies. This document defines a TCP/IP
compression profile for the ROHC framework [RFC-3095], compliant with
the requirements on ROHC TCP/IP header compression [TCP-REQ].
Specifically, it describes a header compression scheme for TCP/IP
header compression (ROHC-TCP) that is robust against packet loss and
that offers enhanced capabilities, in particular for the compression
of header fields including TCP options. The profile identifier for
TCP/IP compression is 0x0006.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
This document reuses some of the terminology found in [RFC-3095]. In
addition, this document defines the following terms:
Base context
The base context is a context that has been validated by both the
compressor and the decompressor. A base context can be used as the
reference when building a new context using replication.
Context replication
Content replication is the mechanism that establishes and
initializes a new context based on another existing valid context
(a base context). This mechanism is introduced to reduce the
overhead of the context establishment procedure, and is especially
Pelletier, Zhang, Jonsson, Liao, West. [Page 3]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
useful for compression of multiple short-lived TCP connections that
may be occurring simultaneously or near-simultaneously.
Short-lived TCP Transfer
Short-lived TCP transfers refer to the TCP connections transmitting
only small amounts of data for each single connection. Short TCP
flows seldom need to operate beyond the slow-start phase of TCP to
complete their transfer, which also means that the transmission
ends before any significant increase of the TCP congestion window
may occur.
3. Background
This chapter provides some background information on TCP/IP header
compression. The fundamentals of general header compression may be
found in [RFC-3095]. In the following sections, two existing TCP/IP
header compression schemes are first described along with a
discussion of their limitations, followed by the classification of
TCP/IP header fields. Finally, some of the characteristics of short-
lived TCP transfers are summarized.
The behavior analysis of TCP/IP header fields among multiple short-
lived connections may be found in [TCP-BEH].
3.1. Existing TCP/IP header compression schemes
Compressed TCP (CTCP) and IP Header Compression (IPHC) are two
different schemes that may be used to compress TCP/IP headers. Both
schemes transmit only the differences from the previous header in
order to reduce the large overhead of the TCP/IP header.
The CTCP [RFC-1144] compressor detects transport-level
retransmissions and sends a header that updates the context
completely when they occur. While CTCP works well over reliable
links, it is vulnerable when used over less reliable links as even a
single packet loss results in loss of synchronization between the
compressor and the decompressor. This in turn leads to the TCP
receiver discarding all remaining packets in the current window
because of a checksum error. This effectively prevents the TCP Fast
Retransmit algorithm [RFC-2001] from being triggered. In such case,
the compressor must wait until the TCP timeout to resynchronize.
To reduce the errors due to the inconsistent contexts between
compressor and decompressor when compressing TCP, IPHC [RFC-2507]
improves somewhat on CTCP by augmenting the repair mechanism of CTCP
with a local repair mechanism called TWICE and with a link-level
nacking mechanism to request a header that updates the context.
Pelletier, Zhang, Jonsson, Liao, West. [Page 4]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
The TWICE algorithm assumes that only the Sequence Number field of
TCP segments are changing with the deltas between consecutive packets
being constant in most cases. This assumption is however not always
true, especially when TCP Timestamps and SACK options are used.
The full header request mechanism requires a feedback channel that
may be unavailable in some circumstances. This channel is used to
explicitly request that the next packet be sent with an uncompressed
header to allow resynchronization without waiting for a TCP timeout.
In addition, this mechanism does not perform well on links with long
round-trip time.
Both CTCP and IPHC are also limited in their handling of the TCP
options field. For IPHC, any change in the options field (caused by
timestamps or SACK, for example) renders the entire field
uncompressible, while for CTCP such a change in the options field
effectively disables TCP/IP header compression altogether.
Finally, existing TCP/IP compression schemes do not compress the
headers of handshaking packets (SYNs and FINs). Compressing these
packets may greatly improve the overall header compression ratio for
the cases where many short-lived TCP connections share the same link.
3.2. Classification of TCP/IP header fields
Header compression is possible due to the fact that there is much
redundancy between header field values within packets, especially
between consecutive packets. To utilize these properties for TCP/IP
header compression, it is important to understand the change patterns
of the various header fields.
All fields of the TCP/IP packet header have been classified in detail
in [TCP-BEH]. The main conclusion is that most of the header fields
can easily be compressed away since they never or seldom change. The
following fields do however require more sophisticated mechanisms:
- IPv4 Identification (16 bits) - IP-ID
- TCP Sequence Number (32 bits) - SN
- TCP Acknowledgement Number (32 bits) - ACKN
- TCP Reserved (4 bits)
- TCP ECN flags (2 bits) - ECN
- TCP Window (16 bits) - WINDOW
- TCP Options
- Maximum Segment Size (4 octets) - MSS
- Window Scale (3 octets) - WSopt
- SACK Permitted (2 octets)
- TCP SACK - SACK
- TCP Timestamp (32 bits) - TS
The assignment of IP-ID values can be done in various ways, which are
Sequential jump, Random, and Sequential, respectively. However,
Pelletier, Zhang, Jonsson, Liao, West. [Page 5]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
designers of IPv4 stacks for cellular terminals should use an
assignment policy close to Sequential. In [RFC-3095], the IP-ID is
generally inferred from the RTP Sequence Number. However, with regard
to TCP compression, the analysis in [TCP-BEH] reveals that there is
no obvious candidate to this purpose among the TCP fields.
The change pattern of several TCP fields (Sequence Number,
Acknowledgement Number, Window, etc.) are very hard to predict and
differs entirely from the behavior of RTP fields discussed in [RFC-
3095]. Of particular importance to a TCP/IP header compression scheme
is the understanding of the sequence and acknowledgement number [TCP-
BEH]. Specifically, at any point on the path (i.e. wherever a
compressor might be deployed), the sequence number can be anywhere
within a range defined by the TCP window. Missing packets or
retransmissions can cause the TCP sequence number to fluctuate within
the limits of this window. The jumps in acknowledgement number are
also bounded by this TCP window.
Another important behavior of the TCP/IP header is the dependency
between the sequence number and the acknowledgment number. It is
well-known that most TCP connections only have one-way traffic (web
browsing and FTP downloading, for example). This means that on the
forward path (from server to client), only the sequence number is
changing while the acknowledgement number remains constant for most
packets; on the backward path (from client to server), only the
sequence number is changing and the acknowledgement number remains
constant for most packets.
With respect to TCP options, it is noted that most options (such as
MSS, WSopt, SACK-permitted, etc.) may appear only on a SYN segment.
Every implementation should (and we expect most will) ignore unknown
options on SYN segments.
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
special treatment in this document, for similar reasons as those
described in [RFC-3095].
3.3. Characteristics of short-lived TCP transfers
Recent studies shows that the majority of TCP flows are short-lived
transfers with an average and a median size no larger than 10KB.
Short-lived TCP transfers will degrade the performance of header
compression schemes that establish a new context by initially sending
full headers.
It is hard to improve the performance for a single, unpredictable,
short-lived connection. However, there are common cases where there
will be multiple TCP connections between the same pair of hosts. A
mobile user browsing several web pages from the same web server (this
is more the case with HTTP/1.0 than HTTP/1.1) is one example.
Pelletier, Zhang, Jonsson, Liao, West. [Page 6]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
In such case, multiple short-lived TCP/IP flows occur simultaneously
or near simultaneously within a relatively short time interval. It
may be expected that most (if not all) of the IP header of the these
connections will be almost identical to each other, with only small
relative jumps for the IP-ID field.
Furthermore, a subset of the TCP fields may also be very similar from
one connection to another. For example, one of the port numbers may
be reused (the service port) while the other (the ephemeral port) may
be changed only by a small amount relative to the just-closed
connection.
With regard to header compression, this means that parts of a
compression context used for a TCP connection may be reusable for
another TCP connection. A mechanism supporting context replication,
where a new context is initialized from an existing one, provide
useful optimizations for a sequence of short-lived TCP connections.
Context replication is possible due to the fact that there is much
similarity in header field values and context values among multiple
simultaneous or near simultaneous connections. All header fields and
related context values have been classified in detail in [TCP-BEH].
The main conclusion is that most part of the IP sub-context, some TCP
fields, and some context values can easily be replicated since they
seldom change or change with only a small jump.
4. Overview of the TCP/IP profile
4.1. General concepts
Many of the concepts behind the ROHC-TCP profile are similar to those
described in [RFC-3095]. Like for other ROHC profiles, ROHC-TCP makes
use of the ROHC protocol as described in [RFC-3095, sections 5.1 to
5.2.6 inclusively]. This include data structures, general packet
formats, reserved packet types, segmentation and initial decompressor
processing. ROHC-TCP also integrally reuse some of the encoding
methods defined in [RFC-3095, section 4.5].
4.1.1. Context replication
For ROHC-TCP, context replication for short-lived TCP flows is
performed by the compressor first initializing a new context for the
new TCP flow. This context is then populated using parts of an
existing context, i.e. a base context, to create the replicated
context. The compressor then sends to the decompressor a packet that
contains a reference to the selected base context, along with some
data for the fields that need to be updated when creating the
replicated context. Finally, the decompressor creates the replicated
context based on the reference to the base context and the
uncompressed data from the received packet.
Pelletier, Zhang, Jonsson, Liao, West. [Page 7]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
To ensure the reliability of the context replication mechanism, only
a context that has previously been acknowledged by a decompressor can
be selected as the base context, and the base context must be valid
at the decompressor at replication time.
The criterion to determine whether two contexts can be replicable is
an implementation issue. For simplicity, contexts with the same
Source-IP should be considered as replicable contexts, and only the
most recent one should be used as the candidate to be replicated.
4.1.2. Feedback channel considerations
The ROHC-TCP profile may be used in environments with or without
feedback capabilities from decompressor to compressor. ROHC-TCP
however assumes that if a ROHC feedback channel is available and is
used at least once by the decompressor, this channel will be present
during the entire compression operation. The occurrence of this
channel will be further referred as the "established" feedback
channel. Otherwise, if the connection is broken and the channel
disappears, header compression should be restarted.
To parallel [RFC-3095], this is similar to allowing only one
transition per compressor state machine: from the initial
unidirectional mode to the bi-directional mode of operation, with the
transition being triggered by the reception of the first packet
containing feedback from the decompressor. This effectively means
that ROHC-TCP does not explicitly define any operational modes.
4.1.3. Master sequence number (MSN)
Feedback packets of types ACK and NACK carry information about
sequence number or acknowledgement number from decompressor to
compressor. Unfortunately, there is no guarantee that sequence number
and acknowledgement number fields will be used by every IP protocol
stack. In addition, the combined size of the sequence number field
and the acknowledgement number field is rather large, and they can
therefore not be carried efficiently within the feedback packet.
To overcome this problem, ROHC-TCP introduces a control field called
the Master Sequence Number (MSN) field. The MSN field is created at
the compressor, rather than using one of the fields already present
in the uncompressed header.
If a feedback channel is established, the MSN field is present in
every packets sent by the compressor when in the Initialization and
Refresh state (IR) as well as in every m compressed header. The
decompressor always sends the MSN as part of the feedback
information. The MSN can later be used by the compressor to infer
which packet is being acknowledged by the decompressor.
Pelletier, Zhang, Jonsson, Liao, West. [Page 8]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
The value of m is chosen as trade-off between compression efficiency
and acknowledgement efficiency.
4.2. ROHC-TCP operation
Header compression with ROHC can be characterized as an interaction
between two state machines, one compressor machine and one
decompressor machine, each instantiated once per context.
For ROHC-TCP compression, the compressor has two states and the
decompressor has three states. The two compressor states are the
Initialization and Refresh (IR) state, and the Compression (CO)
state. The three states of the decompressor are No Context (NC),
Static Context (SC) and Full Context (FC). Transitions need not be
synchronized between the two state machines.
4.3. Encoding methods
<# Editor's Note: This section needs to be completed and formatted #>
As mentioned earlier, ROHC-TCP integrally reuse some of the encoding
methods defined in [RFC-3095, section 4.5].
Considering the changing pattern of several TCP fields, such as
sequence number, acknowledgement number, etc., Window-based LSB
encoding [RFC-3095], which does not assume the linear changing
pattern of the target header fields, is more suitable to encode those
TCP fields both efficiently and robustly.
Fixed-payload encoding
If the compressor finds that the payload size of consecutive packets
is a constant value and one of such packets has been removed from the
context window, which means the decompressor has known the exact
value of the constant size, it may use fixed-payload encoding scheme
to improve the compression efficiency.
For some applications, such as bulk data transfer, the payload size
of each packet is usually a constant value, e.g. 1460 bytes. In such
case, the sequence number and acknowledgment number can be
represented using the following equation:
SEQ (or ACK) = m * PAYLOAD + n.
If all the packets in context window have the same 'n', only 'm'
needs to be transmitted to the decompressor. The decompressor can
assign the value of æPAYLOADÆ using the packet size of the reference
packet. The decompressor can then obtain the sequence number or
acknowledgment number after correctly decoding 'm', and use those as
reference values. This encoding method is called fixed-payload
encoding.
Pelletier, Zhang, Jonsson, Liao, West. [Page 9]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
5. ROHC-TCP - TCP/IP compression (Profile 0x0006)
This section describes a ROHC profile for TCP/IP compression. The
profile identifier for ROHC-TCP is 0x0006.
<# Editor's Note: This chapter needs to be completed #>
5.1. Packet types
ROHC-TCP defines two different packet types: the Initialization and
Refresh (IR) packet type, and the Compressed packet type (CO). Each
type correspond to one of the possible state of the compressor.
Each packet type also define a number of packet formats: [#TBD]
packet formats are defined for compressed headers (CO), and three for
initialization/refresh/replication (IR).
5.1.1. Initialization and Refresh packets (IR)
The ROHC-TCP IR packet follows the general format of the ROHC IR
packet, as defined in [RFC-3095, section 5.2.3].
Packet type: IR
This packet type communicates the static part of the context. It
can optionally also communicate the dynamic part of the context.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context.
Packet type: IR-REPLICATE
This packet communicates the static and dynamic parts of the
replicated context.
5.1.2. Compressed packets (CO)
<# Editor's Note: #>
<# To be written once the ROHC-TCP packet formats are defined #>
5.2. Compression logic
5.2.1. Compressor states and logic
For ROHC-TCP, the two compressor states are the Initialization and
Refresh (IR) state, and the Compression (CO) state. The compressor
always start in the lower compression state (IR). The compressor will
normally operate in the higher compression state (CO), under the
constraint that the compressor is sufficiently confident that the
Pelletier, Zhang, Jonsson, Liao, West. [Page 10]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
decompressor has the information necessary to reconstruct a header
compressed according to this state.
The figure below shows the state machine for the compressor. The
details of each state, state transitions, and compression logic are
given in sub-sections following the figure.
Optimistic approach / ACK ACK
+------>------>------>------+ +->-+
| | | |
| v | v
+----------+ +----------+
| IR State | | CO State |
+----------+ +----------+
^ |
| Timeout / NACK / STATIC-NACK |
+-------<-------<-------<--------+
The transition from IR state to CO state is based on the following
principles: the need for update and the optimistic approach principle
or, if a feedback channel is established, feedback received from the
decompressor.
In ROHC-TCP, the compressor will start in the IR state. The following
sub-sections will describe further the logic for the compressor.
5.2.2. Initialization and Refresh (IR) state
<# Editor's Note: To be defined #>
5.2.3. Compression (CO) state
<# Editor's Note: To be defined #>
5.2.4. Context replication
<# Editor's Note: #>
<# The context replication procedure must be further elaborated #>
To ensure robustness of the context replication procedure, the
compressor must obtain enough confidence that a base context
corresponding to the one selected for replication is available at the
decompressor before sending an IR-REPLICATE packet. The most reliable
way to select the base context is thus to choose a context that has
previously been acknowledged by the decompressor.
For ROHC-TCP, only contexts that have previously been acknowledged by
the decompressor can be selected for replication. This also implies
that the compressor is not allowed to use the context replication
mechanism if a feedback channel is not present.
Pelletier, Zhang, Jonsson, Liao, West. [Page 11]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
If there is at least one candidate context available that can be used
as the base context, the context replication operation may be
summarized as follow: during the context establishment procedure (in
IR state), the compressor may replace all IR/IR-DYN packets with an
IR-REPLICATE packet for each IR/IR-DYN packets it would have normally
sent; when the decompressor receives IR-REPLICATE packets, it will
decompress the packet, reconstruct the context using the reference to
the base context and the uncompressed data received, and send
feedback accordingly.
5.2.5. Feedback logic
ROHC-TCP makes use of feedback from decompressor to compressor for
transitions in the backward direction, and optionally to improve the
forward transition.
The reception of either positive feedback (ACKs) or negative feedback
(NACKs) establishes the feedback channel from the decompressor. Once
there is an established feedback channel, the compressor makes use of
this feedback for optionally improving the transitions among
different states. This helps increasing the compression efficiency by
providing the information necessary for the compressor to achieve the
necessary confidence level. When the feedback channel is established,
it becomes superfluous for the compressor to send periodic refreshes.
In the IR state, the compressor can transit to the CO state once it
receives a valid ACK for an IR/IR-REPLICATE packet sent (an ACK can
only be valid if it refers to a packet sent earlier). If the packet
referred by the feedback is in the context window, the compressor
will remove packets older than the referred packet from the context
window. Because ACK means that the packet referred by feedback has
been the reference of the decompressor, the compressor doesn't need
to keep older packets.
If the compressor is in the CO state, it will remove the packets
older than the referred packet by the feedback from the context
window.
Upon receiving an NACK, the compressor transits back to IR state.
5.2.6. State transition logic
Decisions about transitions between the IR and the CO states are
taken by the compressor on the basis of:
- variations in the packet headers
- positive feedback from decompressor (Acknowledgements -- ACKs)
- negative feedback from decompressor (Negative ACKS -- NACKs)
- confidence level regarding error-free decompression of a packet
Pelletier, Zhang, Jonsson, Liao, West. [Page 12]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
5.2.6.1. Optimistic approach, upward transition
Transition to the CO state is carried out according to the optimistic
approach principle. This means that the compressor transits to the CO
state when it is fairly confident that the decompressor has received
enough information to correctly decompress packets sent according to
the higher compression state.
In general, there are many approaches where the compressor can obtain
such information. A simple and general approach can be achieved by
sending uncompressed or partial full headers periodically.
5.2.6.2. Optional acknowledgements (ACKs), upward transition
The compressor can also transit to the CO state based on feedback
received by the decompressor. If a feedback channel is available,
positive feedback (ACKs) MAY be used for acknowledging successful
decompression of packets. Upon reception of an ACK for a context
updating packet, the compressor knows that the decompressor has
received the acknowledged packet and the transition to the CO state
can be carried out immediately. This functionality is optional, so a
compressor MUST NOT expect to get such ACKs initially or during
normal operation, even if a feedback channel is available or
established.
5.2.6.3. Timeouts, downward transition
When the optimistic approach is used, e.g. until a feedback channel
is established, there will always be a possibility of failure since
the decompressor may not have received sufficient information for
correct decompression. Therefore, unless a feedback channel has been
established, the compressor MUST periodically transit to the IR
state.
5.2.6.4. Negative ACKs (NACKs), downward transition
Negative acknowledgments (NACKs) are also called context requests.
Upon reception of a NACK the compressor transits back to the IR state
and sends updates (IR-DYN, or possibly IR or IR-REPLICATE) to the
decompressor. NACKs carry the MSN of the latest packet successfully
decompressed.
5.2.6.5. Need for updates, downward transition
When the header to be compressed does not conform to the established
pattern or the compressor is not confident whether the decompressor
has the synchronized context, the compressor will transit to the IR
state.
Pelletier, Zhang, Jonsson, Liao, West. [Page 13]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
5.3. Decompression logic
5.3.1. Decompressor states and logic
The three states of the decompressor are No Context (NC), Static
Context (SC) and Full Context (FC). The decompressor starts in its
lowest compression state, the NC state. Successful decompression will
always move the decompressor to the FC state. The decompressor state
machine normally never leaves the FC state once it has entered this
state; only repeated decompression failures will force the
decompressor to transit downwards to a lower state. The decompressor
does not attempt to decompress headers at all in the NC state and SC
states unless sufficient information is included in the received
packet itself.
Below is the state machine for the decompressor. Details of the
transitions between states and decompression logic are given in the
sub-sections following the figure.
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+-----------------+ +---------------------+ +-------------------+
| No Context (NC) | | Static Context (SC) | | Full Context (FC) |
+-----------------+ +---------------------+ +-------------------+
^ | ^ |
| k_2 out of n_2 failures | | k_1 out of n_1 failures |
+-----<------<------<-----+ +-----<------<------<-----+
5.3.2. No Context (NC) state
Initially, while working in the NC state, the decompressor has not
yet successfully decompressed a packet. Upon receiving an IR-STATIC,
IR-DYN or IR-REPLICATE packet, the decompressor will verify the
correctness of this packet by validating its header using the CRC
check.
For an IR-REPLICATE packet, the decompressor builds a new context
from the existing base context and make the necessary update. For an
IR-STATIC or an IR-DYN packet, the decompressor simply updates the
context. Finally, the decompressor uses the successfully decompressed
packet as the reference packet.
When an IR-REPLICATE packet passes the verification, the decompressor
must send an ACK. When an IR, an IR-DYN or any other packet is
correctly decompressed, the compressor may optionally send an ACK. In
either cases, the feedback packet will carry the master sequence
Pelletier, Zhang, Jonsson, Liao, West. [Page 14]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
number (MSN) information corresponding to the latest correctly
decompressed packet.
In the NC state, when any packet fails the verification, the
decompressor should send a NACK. The decompressor discards all
packets until a static update (IR-STATIC) or replication (IR-
REPLICATE) that passes the verification check is received.
Once a packet has been decompressed correctly, the decompressor can
transit to the FC state, and only upon repeated failures will it
transit back to a lower state. Only IR, IR-DYN or IR-REPLICATE
packets may be decompressed in the NC state.
5.3.3. Full Context (FC) state
Upon receiving an IR, IR-DYN or IR-REPLICATE packet, the decompressor
should verify the correctness of its header by CRC check. If the
verification succeeds, the decompressor will update the context and
use this packet as the reference packet. Consequently, the
decompressor will convert the packet into the original packet and
pass it to the network layer of the system.
Upon receiving other types of packet, the decompressor will
decompress it. The decompressor MUST verify the correctness of the
decompressed packet. If this verification succeeds, the decompressor
passes the decompressed packet to the system's network layer. The
decompressor will then use this packet as the reference value, if it
is not older than the current reference packet (by checking the MSN
of the compressed packet, or the sequence number and/or the
acknowledgement number field of the TCP header).
When the verification check of k_1 out of the last n_1 decompressed
packets have failed, context damage SHOULD be assumed and a NACK
SHOULD be sent. The decompressor moves to the SC state and discards
all packets until an update that successfully passes the
verification check is received.
5.3.4. Static Context (SC) state
In the SC state, when the verification check of k_2 out of the last
n_2 decompressed packets have failed, context damage is assumed and a
STATIC-NACK SHOULD be sent. The decompressor moves to the NC state
and discards all packets until an IR, IR-DYN or IR-REPLICATE that
successfully passes the verification check is received.
Note that appropriate values for k and n, are related to the residual
error rate of the link. When the residual error rate is close to
zero, k = n = 1 may be appropriate.
<# Editor's Note: Parts if this logic may have to be refined #>
># based on the packet formats and types to be defined, and #>
Pelletier, Zhang, Jonsson, Liao, West. [Page 15]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
<# when the context replication mechanism will be defined. #>
5.3.5. Context replication
<# Editor's Note: To be defined #>
5.3.6. Allowing decompression
<# Editor's Note: To be written #>
5.3.7. Reconstruction and verification
<# Editor's Note: To be written #>
5.3.8. Actions upon CRC failure
<# Editor's Note: To be defined #>
5.3.9. Feedback logic
The decompressor may send positive feedback (ACKs) to initially
establish the feedback channel. Either positive feedback (ACKs) or
negative feedback (NACKs) will establish the feedback channel between
decompressor and compressor. Once a feedback channel is established,
it will be used by the decompressor to send error recovery requests
and (optionally) acknowledgements of significant context updates.
When the feedback channel is established, it becomes superfluous for
the compressor to send periodic refreshes.
5.4. Packet formats
<# Editor's Note: To be defined #>
6. Implementation considerations
6.1. Determination of the value N
N represents the number of consecutive packets missing from a
sequence between two successfully decompressed packets, due to losses
between compressor and decompressor or due to context damage. When
choosing a value for N, we should however distinguish loss of context
synchronization from packet losses caused by the link. So considering
the error condition of the link, N should be higher than the packet
burst error length, a practical range of N is around [#TBD, 4~5?].
<# Editor's Note: The usefulness of this parameter #>
<# is currently not clear within the document #>
Pelletier, Zhang, Jonsson, Liao, West. [Page 16]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
7. Security considerations
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.
However, for those cases where encryption of data (and not headers)
is sufficient, TCP does specify an alternative encryption method in
which only the TCP payload is encrypted and the headers are left in
the clear. That would still allow header compression to be applied.
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, and TCP headers and
possibly also valid TCP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms which will
not be affected by the compression. Moreover, this header
compression scheme uses an internal checksum for verification of
reconstructed headers. This reduces the probability of producing
decompressed headers not matching the original ones without this
being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR, CO or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
8. IANA Considerations
ROHC profile identifier 0x00XX <# Editor's Note: To be replaced
before publication #> has been reserved by the IANA for the profile
defined in this document.
<# Editor's Note: To be removed before publication #>
A ROHC profile identifier must be reserved by the IANA for the
profile defined in this document. Profiles 0x0000-0x0005 have
previously been reserved, which means this profile could be 0x0006.
As for previous ROHC profiles, profile numbers 0xnnXX must also be
reserved for future updates of this profile. A suggested
registration in the "RObust Header Compression (ROHC) Profile
Identifiers" name space would then be:
Profile Usage Document
identifier
0x0006 ROHC TCP [RFCXXXX (this)]
0xnn06 Reserved
Pelletier, Zhang, Jonsson, Liao, West. [Page 17]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
9. Acknowledgements
Header compression schemes from [RFC-1144, RFC-2507, RFC-3095] have
been important sources of ideas and knowledge. The authors would like
to thank [TBW] for valuable input.
10. References
10.1 Normative References
[RFC-3095] Bormann (ed.), et al., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP and
uncompressed", RFC 3095, July 2001.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC-1072] Jacobson, V., and R. Braden, "TCP Extensions for Long-
Delay Paths", LBL, ISI, October 1988.
[RFC-1323] V. Jacobson, R. Braden, and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC-1644] Braden, R. "T/TCP -- TCP Extensions for Transactions
Functional Specification", ISI, July 1994.
[RFC-1693] Connolly, T., et al, "An Extension to TCP : Partial
Order Service", University of Delaware, November 1994.
[RFC-2001] Stevens, W., TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms, NOAO, January
1997
[RFC-2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP
Selective Acknowledgment Options", RFC 2018, October
1996.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC-2883] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
10.2 Informative References
[TCP-REQ] L-E. Jonsson, "Requirements for ROHC IP/TCP header
Pelletier, Zhang, Jonsson, Liao, West. [Page 18]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
compression", Internet Draft (work in progress), June 20,
2001.
[TCP-BEH] M. West, S. McCann, ôTCP/IP Field Behaviorö, draft-ietf-
rohc-tcp-field-behavior-00.txt (work in progress), March
2002.
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC-1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC-1889] Schulzrinne, H., Casner S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC-2026] S. Bradner, "The Internet Standards Process û Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2507] M. Degermark, B. Nordgren, and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[E2E] V. Jacobson, "Fast Retransmit", Message to the end2end-
interest mailing list, April 1990.
[Mobi96] M. Degermark, M. Engan, B. Nordgren, and Stephen Pink,
"Low-loss TCP/IP header compression for wireless
networks", In the Proceedings of MobiCom, 1996.
11. Authors' addresses
Ghyslain Pelletier Tel: +46 920 20 24 32
Ericsson AB Fax: +46 920 20 20 99
Box 920 Email: ghyslain.pelletier@epl.ericsson.se
SE-971 28 Lulea
Sweden
Qian Zhang Tel: +86 10 62617711-3135
Microsoft Research Asia Email: qianz@microsoft.com
Beijing Sigma Center
No.49, Zhichun Road, Haidian District
Beijing 100080, P.R.C.
Pelletier, Zhang, Jonsson, Liao, West. [Page 19]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson AB Fax: +46 920 20 20 99
Box 920 Email: lars-erik.jonsson@ericsson.com
SE-971 28 Lulea
Sweden
HongBin Liao Tel: +86 10 62617711-3156
Microsoft Research Asia Email: i-hbliao@microsoft.com
Beijing Sigma Center
No.49, Zhichun Road, Haidian District
Beijing 100080, P.R.C.
Mark A West Tel: +44 1794 833311
Roke Manor Research Ltd Email: mark.a.west@roke.co.uk
Romsey, Hants, SO51 0ZN
United Kingdom
This Internet-Draft expires May 1, 2003.
Pelletier, Zhang, Jonsson, Liao, West. [Page 20]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
<# Editor's Note: To be moved to [TCP-BEH] #>
Detailed classification of the "replicable" property of TCP/IP header
fields
All header fields and related context values have been classified.
The main conclusion that can be drawn is that most part of the IP
sub-context, some TCP fields, and some context values can easily be
replicated since they seldom change or change with only a small jump.
A brief study on the TCP/IP field behavior among 'replicable' packet
stream is given in the following.
IPv4 Header (inner and/or outer)
Field Class Replicable
------------------------------------------------
Header Length STATIC-KNOWN Yes
ToS CHANGING Yes
Packet Length INFERRED N/A
Identification CHANGING Yes
Time To Live CHANGING Yes
Protocol STATIC N/A
Header Checksum INFERRED N/A
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
IPv6 Header (inner and/or outer)
Field Class Replicable
------------------------------------------------
Version STATIC N/A
Traffic Class CHANGING Yes
Flow Label STATIC-DEF N/A
Payload Length INFERRED N/A
Next Header STATIC N/A
Hop Limit CHANGING Yes
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
TCP Header
Field Class Replicable
------------------------------------------------
Source Port STATIC-DEF Yes
Destination Port STATIC-DEF Yes
Data Offset INFERRED N/A
Window CHANGING Yes
Reserved Bits CHANGING Yes
Init-Window (Context) CHANGING Yes
Pelletier, Zhang, Jonsson, Liao, West. [Page 21]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
TCP Options
Option SYN-only Replicable
-----------------------------------------------------
Maximum Segment Size Option Yes Yes
Window Scale Option Yes Yes
SACK-Permitted Option Yes Yes
Timestamps Option No Yes
Short-lived TCP transfers refer to the TCP connections those
transmitting small documents. According to the recent studies, among
the TCP flows, a large majority are short lived flows with the
average and the median lengths no larger than 10 KB. These figures
highlight the importance of efficiently compressing for short lived
TCP flows.
Short-lived TCP transfers will degrade the performances of header
compression schemes which establish a new context by sending full
headers initially. It is hard to see what can be done to improve
performance for a single, unpredictable, short-lived connection.
However, there are commonly cases where there will be multiple TCP
connections between the same pair of hosts or at least send from the
same source host.
Context replication is possible due to the fact that there is much
similarity in header field values and context values among multiple
simultaneously or near simultaneously short-lived connections. To
utilize these properties for header compression, it is important to
understand the replicable characteristics for the various header
fields and context values.
A brief study on the TCP/IP field behavior among 'replicable' packet
stream is given in the following.
TERMS
'Replicable' - Two packet streams are defined as replicable if they
belong to the same profile (ROHC/TCP, etc.) AND have
at least the identical Source IP address.
- The replicable property of a field specifies how
similar the value in a new context is to the existing
one. It has the following values:
'N/A' - The field is unnecessary to be replicated
since it can be inferred or used to define a
packet stream
'No' - The field is impossible to be replicated
since its change pattern between two packet
streams are irregular
Pelletier, Zhang, Jonsson, Liao, West. [Page 22]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
'Yes' - The field is possible to be replicated.
Specific encoding method can be used to
improve the compression efficiency.
IPv4 Header (inner and/or outer)
Field Class Replicable
------------------------------------------------
Version STATIC N/A
Header Length STATIC-KNOWN Yes
ToS CHANGING Yes (1)
Packet Length INFERRED N/A
Identification CHANGING Yes (2)
Reserved flag STATIC-KNOWN No (3)
Don't Fragment flag STATIC No
More Fragments flag STATIC-KNOWN No
Fragment Offset STATIC-KNOWN No
Time To Live CHANGING Yes
Protocol STATIC N/A
Header Checksum INFERRED N/A
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
(1) ToS is marked based on the applicationÆs requirement. Considering
that the replicable connections usually belong to same type of
traffic, it can be regarded as replicable.
(2) The replicable context for this field includes IP-ID, NBO, and
RND flags.
(3) Since the possible future behavior of the 'Reserved Flag' cannot
be predicted, it is considered as not replicable.
IPv6 Header (inner and/or outer)
Field Class Replicable
------------------------------------------------
Version STATIC N/A
Traffic Class CHANGING No
Flow Label STATIC-DEF N/A
Payload Length INFERRED N/A
Next Header STATIC N/A
Hop Limit CHANGING Yes
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
Pelletier, Zhang, Jonsson, Liao, West. [Page 23]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
TCP Header
Field Class Replicable
------------------------------------------------
Source Port STATIC-DEF Yes (4)
Destination Port STATIC-DEF Yes (4)
Sequence Number CHANGING No (5)
Acknowledgement Number CHANGING No
Data Offset INFERRED N/A
Reserved Bits CHANGING Yes (6)
Control Bits
URG CHANGING No
ACK CHANGING No
PSH CHANGING No
RST CHANGING No
SYN CHANGING No
FIN CHANGING No
Window CHANGING Yes (7)
CHECKSUM CHANGING No
Urgent Pointer CHANGING No
(4) On the server side, the port number should be well-known value.
On the client side, the port number is selected by OS automatically.
Whether the port number is replicable depends on how the OS chooses
port number. However, most implementation uses a simple scheme which
just search next available port number.
(5) With the deployment of TCP Initial Sequence Number Randomization,
the Sequence Number will be impossible to be replicated at all.
Thus, this field will not be regarded as replicable.
(6) Don't include ECN flags if ECT is enabled
(7) The Window, here, should be referred as the initial value (or
maximum value) of RWND. Since replicable packet streams are likely to
have the same initial RWND, it would optimize the SYN packet size for
short-lived TCP traffics.
ECN Flags
Field Class Replicable
------------------------------------------------
ECT CHANGING No (8)
CE CHANGING No
ECN CHANGING No
CWR CHANGING No
(8) Considering that the IP ECN bits will also make use of the ECN
nonce scheme. None of the ECN flags could be regarded as replicable.
Pelletier, Zhang, Jonsson, Liao, West. [Page 24]
INTERNET-DRAFT ROHC Profile for TCP November 1, 2002
TCP Options
Option SYN-only (9) Replicable
-----------------------------------------------------
End of option list Option No No
No-Operation Option No No
Maximum Segment Size Option Yes Yes
Window Scale Option Yes Yes
SACK-Permitted Option Yes Yes
SACK Option No No
Timestamps Option No Yes
(9) SYN-only indicates whether the options only appear in SYN packet
or not. For 'Yes', the option only appears in SYN packet; otherwise,
the option may appear in any packets.
Most TCP options are used only in SYN packet. Some options, such as
MSS, Window Scale, SACK-Permitted and etc., tend to have the same
value among replicable packet streams. Since TCP options may not be
included in the context if the header compression scheme doesn't
support context replication. Thus, to support context replication,
the compressor should maintain such TCP options in the context.
Pelletier, Zhang, Jonsson, Liao, West. [Page 25]
