Network Working Group Qian Zhang, (ed.), Microsoft Research Asia
Internet Draft Robert Hancock, Siemens/Roke Manor
Expires: July 2002 HongBin Liao, Microsoft Research Asia
Stephen McCann, Siemens/Roke Manor
Paul Ollis, Siemens/Roke Manor
Richard Price, Siemens/Roke Manor
Abigail Surtees, Siemens/Roke Manor
Mark A West, Siemens/Roke Manor
Ya-Qin Zhang, Microsoft Research Asia
Wenwu Zhu, Microsoft Research Asia
January, 2001
TCP/IP Header Compression for ROHC (ROHC-TCP)
<draft-ietf-rohc-tcp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [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 obsolete by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Existing TCP/IP header compression schemes do not work well on noisy
links, especially the one with high bit error rate and long
roundtrip time. For many bandwidth limited links where header
compression is essential, such characteristics are common. In
addition, existing schemes [VJHC, IPHC] have not addressed how to
compress TCP options such as SACK [RFC2018, RFC2883] and Timestamps
[RFC1323].
A robust and efficient header compression scheme for TCP/IP, called
ROHC-TCP, is proposed within the basic RObust Header Compression
[ROHC] framework.
Zhang, et al. [Page 1]
draft-ietf-rohc-tcp-00.txt
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................5
2. Terminology.....................................................5
3. Background......................................................7
3.1 Existing TCP/IP header compression schemes..................7
3.2 Classification of header fields.............................8
4. TCP/IP header compression framework.............................9
4.1 Compression and decompression states........................9
4.1.1 Compressor states......................................9
4.1.1.1. Initialization and Refresh (IR) state...........10
4.1.1.2. First Order (FO) State..........................11
4.1.1.3. Second Order (SO) State.........................12
4.1.2. Decompressor states..................................12
4.2 Modes of operation.........................................12
4.2.1. Unidirectional mode -- U-mode........................12
4.2.2. Bi-directional mode -- B-mode........................13
5. The Protocol...................................................13
5.1 TCP congestion window tracking.............................14
5.1.1. General principle of congestion window tracking......15
5.1.2. Congestion window tracking based on Sequence Number..15
5.1.3. Congestion window tracking based on Acknowledgment
Number......................................................17
5.1.4. Further discussion on congestion window tracking.....18
5.2 Operation in unidirectional mode...........................18
5.2.1. Compressor logic.....................................19
5.2.1.1. IR state........................................19
5.2.1.2. FO state........................................20
5.2.1.3. SO state........................................21
5.2.2. Decompressor logic...................................21
5.2.2.1. No Context State................................21
5.2.2.2. Full Context State..............................22
5.3 Operations in bi-directional mode..........................22
5.3.1. Compressor states and logic..........................22
5.3.1.1 Master Sequence Number (MSN) for packet
acknowledging............................................23
5.3.1.2 State transition logic...........................23
5.3.2. Decompressor states and logic........................23
5.4. Implementation issues.....................................24
5.4.1. Determine the value K................................24
5.4.2. Determine the value N................................24
5.4.3. Determine the frequency of updating context..........24
5.4.4. Possible optimization in U-mode......................25
5.5. Mode transitions..........................................26
5.5.1. Compression and decompression during mode transitions26
5.5.2. Transition from Unidirectional to Bidirectional mode.27
5.5.3. Transition to Unidirectional mode....................28
6. Coding Scheme and compressed packet header format..............28
6.1. Windowed LSB encoding and fixed-payload encoding..........29
6.2. The framework of EPIC-LITE scheme.........................29
6.3. ROHC Profile for compression of TCP/IP....................29
Zhang (ed.), et al. [Page 2]
draft-ietf-rohc-tcp-00.txt
7. Security considerations.......................................40
8. Acknowledgements...............................................40
9. References.....................................................40
10. Authors' addresses............................................42
Appendix A - Detailed classification of header fields.............44
A.1. General classification....................................44
A.1.1. IP header fields.....................................45
A.1.1.1. IPv6 header fields..............................45
A.1.1.2. IPv4 header fields..............................46
A.1.2. TCP header fields....................................48
A.1.3. Summary for IP/TCP...................................49
A.2. Analysis of change patterns of header fields..............49
A.2.1. IP header fields.....................................52
A.2.1.1. IP Traffic-Class / Type-Of-Service (TOS)........52
A.2.1.2. ECN Flags.......................................52
A.2.1.3. IP Identification...............................53
A.2.1.4. Don't Fragment (DF) flag........................54
A.2.1.5. IP Hop-Limit / Time-To-Live (TTL)...............55
A.2.2. TCP header fields....................................55
A.2.2.1. Sequence number.................................55
A.2.2.2. Acknowledgement number..........................56
A.2.2.3. Reserved........................................56
A.2.2.4. Flags...........................................56
A.2.2.5. Checksum........................................58
A.2.2.6. Window..........................................58
A.2.2.7. Urgent pointer..................................58
A.2.3. Options..............................................58
A.2.3.1. Options overview................................59
A.2.3.2. Option field behavior...........................59
Zhang (ed.), et al. [Page 3]
draft-ietf-rohc-tcp-00.txt
Document History
00 January 31, 2002 First release.
Zhang (ed.), et al. [Page 4]
draft-ietf-rohc-tcp-00.txt
1. Introduction
The necessity and importance of doing TCP/IP header compression on
low- or medium-speed links have been discussed in [IPHC].
However, some links, such as cellular links, have characteristics
that make header compression as defined in [IPHC, VJHC] perform less
than well. The most important characteristic is the lossy behavior
of cellular links, where a bit error rate (BER) as high as 1e-3 must
be accepted to keep the radio resources efficiently utilized. In
severe operating situations, the BER can be as high as 1e-2. The
other problematic characteristic is the long round-trip time (RTT)
of the cellular link. An additional issue that needs to be
considered in TCP/IP header compression is how to efficiently
compress the TCP options, such as SACK and Timestamp.
Bandwidth is the most costly resource in cellular links. Processing
power is very cheap in comparison. Implementation or computational
simplicity of a header compression scheme is therefore of less
importance than its compression ratio and robustness.
This document describes a new header compression scheme for TCP/IP
header compression (ROHC-TCP), which consists of two components, the
state machine and the encoding mechanism. As stated in [EPIC],
Efficient Protocol Independent Compression (EPIC-LITE) is a generic
encoding scheme which can automatically generate efficient packet
format for the compressed header. In this document, ROHC-TCP adopts
EPIC-LITE as the encoding framework. By combining state machine and
EPIC-LITE together, ROHC-TCP is more robust against packet loss and
hence achieves better performance over lossy links.
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 RFC 2119 [RFC2119].
Compressed header format
A compressed header format describes how to compress each field in
the chosen protocol stack. It consists of two parts: a bit pattern
to indicate to the decompressor which format is being used,
followed by a list of the compressed versions of each field.
Context
The context is an array storing one or more previous values of
each field in the uncompressed header. The compressor and
compressor both maintain a copy of the context, and fields can be
Zhang (ed.), et al. [Page 5]
draft-ietf-rohc-tcp-00.txt
compressed relative to their stored values for better compression
efficiency.
Context identifiers
On some channels, the ability to transport multiple packet streams
is required. It can also be feasible to have channels dedicated
to individual packet streams. Therefore, ROHC uses a distinct
context identifier space per channel and can eliminate context
identifiers completely for one of the streams when few streams
share a channel.
Control field
The term 'control field' refers to any field passed between the
compressor and decompressor, that is not part of the uncompressed
header. An example of a control field is the header checksum
calculated by EPIC-LITE over the uncompressed header to ensure
robustness against bit errors and dropped packets.
Encoding method
An encoding method is a procedure for compressing fields. Examples
include STATIC encoding (field is the same as the context),
INFERRED encoding (field is calculated at the decompressor) and
IRREGULAR encoding (field must be transmitted in full).
Indicator flags
Each EPIC-LITE compressed packet contains a set of indicator flags.
The flags are placed at the front of the packet as a single bit
pattern, and indicate to the decompressor exactly which encoding
method has been applied to which field.
Input language
EPIC-LITE offers a simple input language (2 commands) that can be
used to create new ROHC profiles. The input language assigns one
or more encoding methods to each field in the chosen protocol
stack.
Library of encoding methods
The library of encoding methods contains a number of commonly used
procedures that can be called to compress fields in the chosen
protocol stack. More encoding methods can be added to the library
if they are needed.
Profile
A [ROHC] profile is a description of how to compress a certain
protocol stack over a certain type of link. Each profile includes
Zhang (ed.), et al. [Page 6]
draft-ietf-rohc-tcp-00.txt
one or more sets of compressed header formats and a state machine
to control the compressor and the decompressor.
Set of compressed header formats
A complete set of compressed header formats uses up all of the
indicator bit patterns available at the start of the compressed
header. A profile may have several sets of compressed header
formats available, but only one set can be in use at a given time.
3. Background
This chapter provides a background to the subject of TCP/IP header
compression. The fundamentals of general header compression had
been introduced in [ROHC]. Here two existing TCP/IP header
compression schemes are described. Their drawbacks are then
discussed, following by the classification of TCP/IP header fields.
3.1 Existing TCP/IP header compression schemes
There are two typical existing TCP/IP header compression schemes,
which are VJHC [VJHC] and IPHC [IPHC], respectively. Both of them
rely on transmitting only the difference from the previous header in
order to reduce the large overhead of TCP/IP header.
Although VJHC works well over reliable links, when used over
unreliable links, such as cellular links, it induces many additional
errors due to inconsistent contexts between the compressor and the
decompressor. Considering the high bit error rate in wireless
channel, if a packet gets lost, the compressed header of next packet
cannot be correctly decompressed. Then the decompressor must send
the request for resynchronization and in the meanwhile discard all
compressed header. A fatal result of this effect is that it prevents
TCP Fast Retransmit algorithm [E2E] from being fired and always
causes TCP retransmission timeout. This effect is shown in detail in
[MOBI96].
IPHC proposes two simple mechanisms, the TWICE algorithm and the
full header request mechanism, to reduce the errors due to the
inconsistent contexts between the compressor and the decompressor.
The TWICE algorithm assumes that only the Sequence Number field of
TCP segments are changing during the connection and the deltas among
consecutive packets are constant in most cases. However, these
assumptions are not always true, especially when TCP Timestamp and
SACK options are used. The full header request mechanism needs a
feedback channel, which is unavailable in some circumstances. Even
when the feedback channel is available, this mechanism still cannot
perform well enough if the roundtrip time of this link is very long.
Once a packet is corrupted on the noisy link, there are still
several consecutive packets dropped due to the inconsistency between
the compressor and the decompressor.
Zhang (ed.), et al. [Page 7]
draft-ietf-rohc-tcp-00.txt
3.2 Classification of 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 header
compression, it is important to understand the change patterns of
the various header fields.
All header fields have been classified in detail in appendix A. The
fields are first classified at a high level and then some of them
are studied more in detail. Finally, the appendix concludes with
recommendations on how the various fields should be handled by
header compression algorithms. The main conclusion that can be
drawn is that most of the header fields can easily be compressed
away since they never or seldom change. Only several fields need
more sophisticated mechanisms. These fields are:
- 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 SACK - SACK
- TCP Timestamp (32 bits) - TS
It is known that the change patterns of several TCP fields (for
example, Sequence Number, Acknowledgement Number, Window, etc.) are
completely different from the ones of RTP, which had already
discussed in detail in [ROHC], and are very hard to predict. The
analysis in Appendix A reveals that an understanding of the sequence
and acknowledgement number behavior are essential for a TCP
compression scheme.
Note that 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.
The way ROHC TCP compression operates, then, is to first track the
TCP window by the compressor side, and then bound the size of jumps
in SN and ACK by this estimated TCP window.
The analysis in Appendix A also reveals that in the TCP case, there
is no obvious candidate for a field to offer the Master sequence
number to compress IP-ID field than in the RTP case. The assignment
Zhang (ed.), et al. [Page 8]
draft-ietf-rohc-tcp-00.txt
of IP-ID values can be done in various ways, which are Sequential
jump, Random, and Sequential, respectively. However, designers of
IPv4 stacks for cellular terminals SHOULD use an assignment policy
close to sequential.
The way ROHC TCP compression operates, then, is to share the context
among the short-live TCP flows so as to improve the compression
efficiency.
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
special treatment in this document. They are compressible, however,
and it is expected that the compression efficiency for Mobile IP
headers will be good enough due to the handling of extension header
lists and tunneling headers. The handling of this issue is conforms
with [ROHC].
4. TCP/IP header compression framework
Similar to the ROHC framework, the ROHC-TCP protocol achieves its
compression gain by establishing state information at both ends of
the link, i.e., at the compressor and at the decompressor.
4.1 Compression and decompression states
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. The
compressor and the decompressor have three and two states,
respectively. Both machines start in the lowest compression state
and transit gradually to higher states. Transitions need not be
synchronized between the two machines. In normal operation it is
only the compressor that temporarily transits back to lower states.
The decompressor will transit back only when context damage is
detected.
Subsequent sections present an overview of the state machines and
their corresponding states, respectively, starting with the
compressor.
4.1.1 Compressor states
There are three compressor states in ROHC-TCP: Initialization and
Refresh (IR) state, First Order (FO), and Second Order (SO) states.
The compressor starts in the lowest compression state (IR) and
transits gradually to the higher compression state. The compressor
will always operate in the highest possible compression state, under
the constraint that the compressor is sufficiently confident that
Zhang (ed.), et al. [Page 9]
draft-ietf-rohc-tcp-00.txt
the decompressor has the information necessary to decompress a
header, which is compressed according to the state.
+----------+
| |
+----------+ | FO State | +----------+
| | <--------> | | <--------> | |
| IR State | +----------+ | SO State |
| | <----------------------------------> | |
+----------+ +----------+
4.1.1.1. Initialization and Refresh (IR) state
The purpose of IR state is to initialize or refresh the static parts
of the context at the decompressor. In this state, the compressor
sends full header periodically with an exponentially increasing
period, which is so-called compression slow-start [IPHC]. The
compressor leaves the IR state only when it is confident that the
decompressor has correctly received the static information.
4.1.1.1.1 Optimization for short-live TCP transfers
Two approaches are introduced in ROHC-TCP to compress short-lived
TCP transfers more efficiently.
The first approach is that the compressor should try to speed up the
initialization process. This approach can be applied is the
compressor is able to see the SYN packet. The compressor enters the
IR state when it receives the packet with SYN bit set and sends IR
packet. When it receives the first data packet of the transfer, it
should transit to FO state because that means the decompressor has
received the packet with SYN bit set and established the context
successfully at its side. Using this mechanism can significantly
reduce the number of context initiation headers.
The second approach is to share the context among different short-
lived TCP transfers so that to improve the compression efficiency.
There are commonly cases where there will be multiple short-live TCP
connections between the same cellular links. As a particular
example, consider web browsing that can be illustrated in Figure
4.1.1.1.1. In this figure, the mobile terminal is connected to base
station over cellular link, and the base station is connected to
multiple web servers through wired (or possibly wireless) networks.
Zhang (ed.), et al. [Page 10]
draft-ietf-rohc-tcp-00.txt
Mobile Base Web
Terminal Station Servers
+----------+
| ~ ~ ~ \ / ||============= | Server 1 |
| | || +----------+
+--+ | ||
| | | || . . . . . .
| | | ||
+--+ | ||
| || +----------+
|============||============= | Server n |
+----------+
Cellular Wired
Link Network
Figure 4.1.1.1.1 : Scenario for web browsing over cellular links
When a connection closes, it is either the last connection between
that pair of hosts or it is likely that another connection will open
within a relatively short space of time. In this case, the IP
header part of the context will probably be almost identical.
Certain aspects of the TCP context may also be similar.
For example, it may be that one of the port numbers will stay the
same (the service port) and the other will change by a small amount
relative to the just-closed connection (the ephemeral port). Also,
unless [RFC 1948] ISN selection is implemented, the initial sequence
number for the SYN packet may be 'close' to the sequence number
range used for the closed connection.
Thus, ROHC-TCP provides sub-context sharing for multiple short-live
TCP connections. The new connection initializes a new context,
(partially) copied the context from an existing one, and send out
PARTIAL-FULL header periodically with an exponentially increasing
period. This PARTIAL-FULL header should indicate the existing
context that can be shared with the new connection, and also the
fields that need to be updated in the new context.
<To be revised after further discussion, especially the packet
format for the PARTIAL-FULL header.>
4.1.1.2. First Order (FO) State
The purpose of FO state is to efficiently transmit the difference
between the two consecutive packets in the TCP stream. When
operating in this state, the compressor and the decompressor should
have the same context. Only compressed packet is transmitted from
Zhang (ed.), et al. [Page 11]
draft-ietf-rohc-tcp-00.txt
the compressor to the decompressor in this state. The compressor
transits back to IR state only when it finds that the context of
decompressor may be inconsistent, or there are remarkable changes in
the TCP/IP header.
4.1.1.3. Second Order (SO) State
The purpose of SO state is to efficiently transmit the fixed-payload
data. The compressor enters this state when it is sufficiently
confident that the decompressor has got the constant payload size of
the data transferring.
The compressor leaves this state and transits to the FO state when
the current payload size no longer conforms to the constant payload.
The compressor transits back to IR state only when it finds that the
context of decompressor may be inconsistent, or there are remarkable
changes in the TCP/IP header.
4.1.2. Decompressor states
The decompressor starts in its lowest compression state, "No
Context" and gradually transits to higher state, "Full Context". The
decompressor state machine normally never leaves the "Full Context"
state once it has entered this state.
+--------------+ +--------------+
| No Context | <---> | Full Context |
+--------------+ +--------------+
4.2 Modes of operation
There are two modes in ROHC-TCP, called Unidirectional and Bi-
directional mode, respectively. The mode transitions are conformed
to ROHC framework. However, the operations of each mode are
different.
4.2.1. Unidirectional mode -- U-mode
When in U-mode, packets are sent in one direction only: from
compressor to decompressor. Therefore, feedbacks from decompressor
to the compressor are unavailable under this mode.
In the U-mode, the compressor and decompressor logic is the same as
the discussion in section 5.3 and 5.4.
Compression with ROHC-TCP MUST starts in the Unidirectional mode.
Transition to the Bidirectional mode can be performed as soon as a
packet has reached the decompressor and it has replied with a
Zhang (ed.), et al. [Page 12]
draft-ietf-rohc-tcp-00.txt
feedback packet indicating that a mode transition is desired (see
chapter 5).
4.2.2. Bi-directional mode -- B-mode
The Bidirectional mode is similar to the Unidirectional mode. The
difference is that a feedback channel is used to send error recovery
requests and (optionally) acknowledgments of significant context
updates from decompressor to compressor (not, however, for pure
sequence number updates). In this mode, the number of context
values can be reduced more efficiently.
B-mode aims to maximize compression efficiency and sparse usage of
the feedback channel. It reduces the number of damaged headers
delivered to the upper layers due to residual errors or context
invalidation.
5. The Protocol
Considering the changing pattern of several TCP fields, Window-based
LSB encoding [ROHC] or windowed LSB encoding [EPIC-LITE], 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.
Using EPIC-LITE, the compressor and decompressor maintain a context
value for some or all of the "field encodings" specified in the BNF
description. To provide robustness, the compressor can maintain more
than one context value for each field. These values represent the r
most likely candidatesÂ’ values for the context at the decompressor.
EPIC-LITE ensures that the compressed header contains enough
information so that the uncompressed header can be extracted no
matter which one of the compressor context values is actually stored
at the decompressor. The only problem arises if the decompressor has
a context value that does not belong to the set of values stored at
the compressor; this situation is detected by a checksum over the
uncompressed header and the packet is discarded at the decompressor.
If more than one value for a field is stored in the compressor
context, LSB encoding will only succeed if sufficient LSBs are sent
to infer correct value of the field regardless of the precise value
stored in the decompressor context.
Storing more context values at the compressor reduces the chance
that the decompressor will have a context value different from any
of the values stored at the compressor (which could cause the packet
to be decompressed incorrectly).
As an example, an implementation may choose to store the last r
values of each field in the compressor context. In this case
Zhang (ed.), et al. [Page 13]
draft-ietf-rohc-tcp-00.txt
robustness is guaranteed against up to r - 1 consecutive dropped
packets between the compressor and the decompressor. Thus, by
keeping the value r large enough, the compressor rarely gets out of
synchronization with the decompressor.
However, the trade-off is that the larger the number of context
values is, the compressed header will be larger because it must
contain enough information to decompress relative to any of the
candidate context values.
The main idea of the control mechanism of ROHC-TCP is the
combination of the windowed LSB encoding and dynamically TCP
congestion window tracking. With this combination, the value r can
be controlled effectively.
To reduce the number of context value r, the compressor needs some
form of feedback to get sufficient confidence that a certain context
value will not be used as a reference by the decompressor. Then the
compressor can remove that value and all other values older than it
from its context. Obviously, when a feedback channel is available,
confidence can be achieved by proactive feedback in the form of ACKs
from the decompressor. A feedback channel, however, is unavailable
or expensive in some environments. In this Internet draft, a
mechanism based on dynamically tracking TCP congestion window is
proposed to explore such feedbacks from the nature feedback-loop of
TCP protocol itself.
Since TCP is a window-based protocol, a new segment cannot be
transmitted without getting the acknowledgment of segment in the
previous window. Upon receiving the new segment, the compressor can
get enough confidence that the decompressor has received the segment
in the previous window and then shrink the context window by
removing all the values older than that segment.
As originally outlined in [CAC] and specified in [RFC2581], TCP is
incorporated with four congestion control algorithms: slow-start,
congestion-avoidance, fast retransmit, and fast recovery. The
effective window of TCP is mainly controlled by the congestion
window and may change during the entire connection life. ROHC-TCP
designs a mechanism to track the dynamics of TCP congestion window,
and control the number of context value r of windowed LSB encoding
by the estimated congestion window. By combining the windowed LSB
encoding and TCP congestion window tracking, ROHC-TCP can achieve
better performance over high bit-error-rate links.
Note that in one-way TCP traffic, only the information about
sequence number or acknowledgment number is available for tracking
TCP congestion window. ROHC-TCP does not require that all one-way
TCP traffics must cross the same compressor. The detail will be
described in the following sections.
5.1 TCP congestion window tracking
Zhang (ed.), et al. [Page 14]
draft-ietf-rohc-tcp-00.txt
5.1.1. General principle of congestion window tracking
The general principle of congestion window tracking is as follows.
The compressor imitates the congestion control behavior of TCP upon
receiving each segment, in the meantime, estimates the congestion
window (cwnd) and the slow start threshold (ssthresh). Besides the
requirement of accuracy, there are also some other requirements for
the congestion window tracking algorithms:
- Simplex link. The tracking algorithm SHOULD always only take
Sequence Number or Acknowledgment Number of a one-way TCP
traffic into consideration. It SHOULD NOT use Sequence Number
and Acknowledgment Number of that traffic simultaneously.
- Misordering resilience. The tracking algorithm SHOULD work
well while receiving misordered segments.
- Multiple-links. The tracking algorithm SHOULD work well when
not all the one-way TCP traffics are crossing the same link.
- Slightly overestimation. If the tracking algorithm cannot
guarantee the accuracy of the estimated cwnd and ssthresh, it is
RECOMMANDED that it produces a slightly overestimated one.
The following sections will describe two congestion window tracking
algorithms, which use Sequence Number and Acknowledgment Number of a
one-way TCP traffic, respectively.
5.1.2. Congestion window tracking based on Sequence Number
This algorithm (Algorithm SEQ) contains 3 states: SLOW-START,
CONGESTION-AVOIDANCE, and FAST-RECOVERY, which are equivalent to the
states in TCP congestion control algorithms. It maintains 2
variables: cwnd and ssthresh.
+-------------+
| |
---------------->| CONGESTION- |
| | AVOIDANCE |
| ----| |<---
+------------+ | +-------------+ |
| | | |
| SLOW-START | | |
| | | +-------------+ |
+------------+ | | | |
| |-->| FAST- |----
| | RECOVERY |
---------------->| |
+-------------+
Zhang (ed.), et al. [Page 15]
draft-ietf-rohc-tcp-00.txt
Initially, this algorithm starts in state SLOW-START with ssthresh
set to ISSTHRESH and cwnd set to IW.
Upon receiving a segment, if it is the first segment, which is not
necessary to be the SYN segment, the algorithm sets the current
maximum Sequence Number (CMAXSN) and the current minimum Sequence
Number (CMINSN) to this segment's sequence number; otherwise, the
algorithm takes a procedure according to the current state.
- SLOW-START
* If the new Sequence Number (NSN) is larger than CMAXSN,
increase cwnd by the distance between NSN and CMAXSN, and
update CMAXSN and CMINSN based on the following rules:
CMAXSN = NSN
if (CMAXSN - CMINSN) > cwnd)
CMINSN = cwnd - CMAXSN;
If the cwnd is larger than ssthresh, the algorithm transits to
CONGESTION-AVOIDANCE state;
* If the distance between NSN and CMAXSN is less than or equal
to 3*MSS, ignore it;
* If the distance is larger than 3*MSS, halve the cwnd and set
ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm
transits into FAST-RECOVERY state.
- CONGESTION-AVOIDANCE
* If NSN is larger than CMAXSN, increase cwnd by ((NSN-
CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on
the following rules:
CMAXSN = NSN
if (CMAXSN - CMINSN) > cwnd)
CMINSN = cwnd - CMAXSN;
* If the distance between NSN and CMAXSN is less than or equal
to 3*MSS, ignore it;
* If the distance is larger than 3*MSS, halve the cwnd and set
ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm
transits into FAST-RECOVERY state.
- FAST-RECOVERY
* If NSN is larger than or equal to CMAXSN + cwnd, the algorithm
transits into CONGESTION-AVOIDANCE state;
* Otherwise, ignore it.
In this algorithm, MSS is denoted as the estimated maximum segment
size. The implementation can use the MTU of the link as an
approximation of this value. ISSHRESH and IW are the initial values
Zhang (ed.), et al. [Page 16]
draft-ietf-rohc-tcp-00.txt
of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
high. IW SHOULD be set to 4*MSS.
5.1.3. Congestion window tracking based on Acknowledgment Number
+-------------+
| |
---------------->| CONGESTION- |
| | AVOIDANCE |
| ----| |<---
+------------+ | +-------------+ |
| | | |
| SLOW-START | | |
| | | +-------------+ |
+------------+ | | | |
| |-->| FAST- |----
| | RECOVERY |
---------------->| |
+-------------+
This algorithm (Algorithm ACK) maintains 3 states: SLOW-START,
CONGESTION-AVOIDANCE and FAST-RECOVERY, which are equivalent to the
states in TCP congestion control algorithms. It also maintains 2
variables: cwnd and ssthresh.
Initially, this algorithm starts in state SLOW-START with ssthresh
set to ISSTHRESH and cwnd set to IW.
Upon receiving a segment, if it is the first segment, which is not
necessary to be the SYN segment, the algorithm sets the current
maximum Acknowledgment Number (CMAXACK) to this segment's
acknowledgment number; otherwise, the algorithm takes a procedure
according to the current state.
- SLOW-START
* If the new Acknowledgment Number (NEWACK) is larger than
CMAXACK, increase cwnd by the distance between NEWACK and
CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update
CMAXACK accordingly; If the cwnd is larger than ssthresh, the
algorithm transits to CONGESTION-AVOIDANCE state;
* If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If
NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
MAX(cwnd, 2*MSS). Consequently, the algorithm transits into
FAST-RECOVERY state;
* Otherwise, set NDUPACKS to 0.
- CONGESTION-AVOIDANCE
Zhang (ed.), et al. [Page 17]
draft-ietf-rohc-tcp-00.txt
* If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK-
CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK
accordingly;
* If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If
NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
MAX(cwnd, 2*MSS). After that, the algorithm transits into
FAST-RECOVERY state;
* Otherwise, set NDUPACKS to 0.
- FAST-RECOVERY
* If NEWACK is larger than CMAXACK, set NDUPACKS to 0.
Consequently, the algorithm transits into CONGESTION-AVOID
state;
* Otherwise, ignore it.
In this algorithm, MSS is denoted as the estimated maximum segment
size. The implementation can use the MTU of the link as an
approximation of this value. ISSHRESH and IW are the initial values
of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
high. IW SHOULD be set to 4*MSS.
5.1.4. Further discussion on congestion window tracking
In some cases, it is inevitable for the tracking algorithms to
overestimate the TCP congestion window. Also, it SHOULD be avoided
that the estimated congestion window gets significantly smaller that
the actual one. For all of these cases, ROHC-TCP simply applies two
boundaries on the estimated congestion window size. One of the two
boundaries is the MIN boundary, which is the minimum congestion
window size and whose value is determined according to the [INITWIN];
the other boundary is the MAX boundary, which is the maximum
congestion window size. There are two possible approaches to
setting this MAX boundary. One is to select a commonly used maximum
TCP socket buffer size. The other one is to use the simple equation
W=sqrt(8/3*l), where W is the maximum window size and l is the
typical packet loss rate.
If ECN mechanism is deployed, according to [RFC2481] and [ECN], the
TCP sender will set the CWR (Congestion Window Reduced) flag in the
TCP header of the first new data packet sent after the window
reduction, and the TCP receiver will reset the ECN-Echo flag back to
0 after receiving a packet with CWR flag set. Thus, the CWR flag
and the ECN-Echo flag's transition from 1 to 0 can be used as
another indication of congestion combined with other mechanisms
mentioned in the tracking algorithm.
5.2 Operation in unidirectional mode
Zhang (ed.), et al. [Page 18]
draft-ietf-rohc-tcp-00.txt
5.2.1. Compressor logic
In ROHC-TCP, the compressor will start in the IR state and perform
different logics in different states. The following sub-sections
will describe the logic for each compressor sate in detail.
5.2.1.1. IR state
The operations of compressor in IR state can be summarized as
follows:
a) Upon receiving the first packet, the compressor determines
whether the new connection can share the context with other
existing one.
b) If the new connection can share context with the existing one,
the compressor send out PARTIAL-FULL header packet in the step c)
instead of the full header packet.
c) Upon receiving a packet, the compressor sends IR or IR-DYN packet
on the following conditions: 1) if it is the turn to send full
header packet according to compression slow-start, i.e. after
sending F_PERIOD compressed packets; 2) if the packet to be sent
is a retransmission of the packet in context window and it was
sent as IR or IR-DYN packet previously. Otherwise, the
compressor compresses the packet using windowed LSB encoding. If
the compressor enters the IR state for the first time or the
static part of the TCP flow has changed, it will send IR packet.
Otherwise, it will send IR-DYN packet because the decompressor
has known the static part.
d) The packet is added into context window as a potential reference
after it has been sent out. The compressor then invokes the
Algorithm SEQ and Algorithm ACK to track the congestion windows
of the two one-way traffics with different directions in a TCP
connection. Suppose that the estimated congestion windows are
cwnd_seq and cwnd_ack, while the estimated slow start thresholds
are ssthresh_seq and ssthresh_ack, respectively. Let
W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
MAX(cwnd_ack, 2*ssthresh_ack)).
If the value of context window, r, is larger than W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is an
implementation parameter that will be further discussed in
Section 5.6.
e) After sending F_PERIOD compressed packets, F_PERIOD SHOULD be
doubled. If it gets larger than W(cwnd_seq, ssthresh_seq,
cwnd_ack, ssthresh_ack), the compressor transits to FO or SO
Zhang (ed.), et al. [Page 19]
draft-ietf-rohc-tcp-00.txt
state. If the compressor finds that the payload size of
consecutive packets is a constant value and one of such packets
is removed from the context window, which means the decompressor
has known the exact value of the constant size, it may transit to
SO state. Otherwise it will transit to the FO state.
5.2.1.2. FO state
The operations of the compressor in the FO state can be summarized
as follows:
a) Upon receiving a packet, if it falls behind the context window,
i.e. it is older than all the packets in context; the compressor
transits to IR state. Otherwise, the compressor compresses it
using windowed LSB encoding and sends it.
b) The packet is added into context window as a potential reference
after it has been sent out. The compressor then invokes the
Algorithm SEQ and Algorithm ACK to track the congestion windows of
the two one-way traffics with different directions in a TCP
connection. Suppose that the estimated congestion windows are
cwnd_seq and cwnd_ack, while the estimated slow start thresholds
are ssthresh_seq and ssthresh_ack, respectively. Let
W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
MAX(cwnd_ack, 2*ssthresh_ack)).
If the value of context window, r, is larger than W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is
also an implementation parameter, which can be set to the same
value as in the IR state.
c) If the context window contains only one packet, which means there
is a long jump in the packet sequence number or acknowledge number,
the compressor will transit to the IR state and re-initialize the
algorithm for tracking TCP congestion window. Here, a segment
causes a long jump when the distance between its sequence number
(or acknowledgment number) and CMAXSN (or CMAXACK) is larger than
the estimated congestion window size, i.e.,
|sequence number (acknowledgement number) - CMAXSN (CMAXACK)| >
estimated congestion window size.
d) 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 transit to the
SO state.
Zhang (ed.), et al. [Page 20]
draft-ietf-rohc-tcp-00.txt
e) If the static context of transfers changed, the compressor will
transit to the IR state and re-initialize the algorithms for
tracking TCP congestion window.
5.2.1.3. SO state
The operations of the compressor in the SO state can be summarized
as follows:
a) Upon receiving a packet, if it falls behind the context window,
i.e. it is older than all the packets in context window; the
compressor transits to IR state. Otherwise, the compressor
compresses it using fixed-payload encoding and sends it.
b) The packet is added into context window as a potential reference
after it has been sent out. The compressor then invokes the
Algorithm SEQ and Algorithm ACK to track the congestion windows of
the two one-way traffics with different directions in a TCP
connection. Suppose that the estimated congestion windows are
cwnd_seq and cwnd_ack, while the estimated slow start thresholds
are ssthresh_seq and ssthresh_ack, respectively. Let
W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
MAX(cwnd_ack, 2*ssthresh_ack)).
If the value of context window, r, is larger than W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is an
implementation parameter, which can be set to the same value as in
the IR state.
c) If the context window contains only one packet, which means there
is a long jump in the packet sequence number or acknowledge number,
the compressor will transit to the IR state and re-initialize the
algorithms for tracking TCP congestion window.
d) If the payload size of the packets in context window doesn't keep
constant, the compressor transits to the FO state.
e) If the static context of transfers changed, the compressor will
transit to the IR state and re-initialize the algorithms for
tracking TCP congestion window.
5.2.2. Decompressor logic
The logic of the decompressor is simpler compared to the compressor.
5.2.2.1. No Context State
Zhang (ed.), et al. [Page 21]
draft-ietf-rohc-tcp-00.txt
The decompressor starts in this state. Upon receiving an IR or IR-
DYN packet, the decompressor should first verify the correctness of
this packet. Then it will determine that whether this is a full
header packet or PARTIAL-FULL one. For a PARTIAL-FULL header, the
decompressor will re-build a new context from the existing one and
make the necessary update. Otherwise, the decompressor will just
update the context. Finally, the decompressor will use this packet
as the reference packet.
After that, the decompressor will pass it to the system's network
layer and transit to Full Context State. Conformed to ROHC
framework [ROHC], only IR or IR-DYN packets may be decompressed in
No Context state.
5.2.2.2. Full Context State
The operations of decompressor in Full Context state can be
summarized as follows:
a) Upon receiving an IR or IR-DYN packet, the decompressor should
verify the correctness of its header by TCP checksum. 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.
b) Upon receiving the other type of packet, the decompressor will
decompress it. After that, the decompressor MUST verify the
correctness of the decompressed packet by the TCP checksum. If the
verification succeeds, the decompressor passes it to the system's
network layer. Then the decompressor will use it as the reference
value if this packet is not older than the current reference packet.
c) If consequent N packets fail to be decompressed, the decompressor
should transit downwards to No Context State. N is an
implementation parameter that will be further discussed in Section
5.6.
5.3 Operations in bi-directional mode
5.3.1. Compressor states and logic
The bi-directional mode makes use of feedback from decompressor to
compressor for OPTIONAL improving the transitions among different
states. Feedback packet types ACK and NACK are conform to the ones
defined in [ROHC].
Following rules should be combined with the action defined in
section 5.2.1.
Zhang (ed.), et al. [Page 22]
draft-ietf-rohc-tcp-00.txt
5.3.1.1 Master Sequence Number (MSN) for packet acknowledging
Feedback of types ACK and NACK carry the information about sequence
number/ acknowledgement number from decompressor to the compressor.
Unfortunately, sequence number/acknowledgement number field is not
guaranteed to be present in every IP protocol stack. It is not
visible if the IP payload is encrypted. Meanwhile, the size of the
sequence number/acknowledgement number field is rather large, which
is not so efficient if it is carried in the feedback packet directly.
To overcome this problem ROHC-TCP introduces a control field called
the Master Sequence Number (MSN) field. This field is present in
every m compressed header and can be used to infer the acknowledged
sequence number.
The value of m is chosen for the best trade-off between compression
efficiency and the acknowledging efficiency.
5.3.1.2 State transition logic
In the IR state, the compressor can transit to the FO or SO state
once it receives a valid ACK(B) for an IR packet sent (an ACK(B) 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 the packets older than the referred packet from the
context window. Because ACK(B) 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 FO or SO state, it will remove the
packets older than the referred packet by the feedback from the
context window.
Upon receiving an NACK(B), the compressor transits back to IR state.
5.3.2. Decompressor states and logic
The decompression states and the state transition logic are the same
as in the Unidirectional case (see section 5.2.2.). What differs is
the feedback logic.
Below, rules are defined stating which feedback to use when.
When an IR packet passes the verification, send an ACK(B). When an
IR-DYN packet or other packet is correctly decompressed, optionally
send an ACK(B). In both cases, the feedback packet will carry the
master sequence number information about the nearest data packet
that had MSN.
In the Full Context state, when the verification check of x out of
the last y decompressed packets have failed, context damage SHOULD
be assumed and a NACK(B) SHOULD be sent. The decompressor moves to
Zhang (ed.), et al. [Page 23]
draft-ietf-rohc-tcp-00.txt
the No Context state and discards all packets until an update which
passes the verification check is received.
Note that appropriate values for x and y, are related to the
residual error rate of the link. When the residual error rate is
close to zero, x = y = 1 may be appropriate.
In the No Context state, when any packet fails the verification,
send an NACK(B). The decompressor discards all packets until a
static update (IR) which passes the verification check is received.
5.4. Implementation issues
5.4.1. Determine the value K
As mentioned above, the context window SHOULD be shrunk when its
size gets larger than K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
MAX(cwnd_ack, 2*ssthresh_ack)). Since the Fast Recovery algorithm
was introduced in TCP, several TCP variants had been proposed, which
are different only in the behaviors of Fast Recovery. Some of them
need several RTTs to be recovered from multiple losses in a window.
Ideally, they may send L*W/2 packets in this stage, where L is the
number of lost packets and W is the size of the congestion window
where error occurs. Some recent work [REQTCP] on improving TCP
performance allows transmitting packets even when receiving
duplicate acknowledgments. Due to the above concerns, it'd better
keep K large enough so as to prevent shrinking context window
without enough confidence that corresponding packets had been
successfully received.
Considering the bandwidth-limited environments and the limited
receiver buffer, a practical range of K is around 1~2. From the
simulation results, K=1 is good enough for most cases.
5.4.2. Determine the value N
We should distinguish out of synchronization from the packet errors
cause 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 8~10.
5.4.3. Determine the frequency of updating context
The choice of the frequency of updating context, ACK(R), is a
balance between the efficiency and robustness, i.e. sending ACK(R)
more frequently improves the compression robustness but adds more
system overhead, and the vice versa. From a practical view, the
ACK(R) SHOULD be sent for every 4~8 successfully decompressed
packets.
Zhang (ed.), et al. [Page 24]
draft-ietf-rohc-tcp-00.txt
5.4.4. Possible optimization in U-mode
It can be seen that there are two distinct deployments - one where
the forward and reverse paths share a link and one where they do not.
In the former case it may be the situation that a compressor and
decompressor could be co-located as illustrated in Figure 5.4.4. It
may then be possible for the compressor and decompressor at each end
of the link to exchange information. In such a scenario, ROHC-TCP
can make further optimization on context size for windowed LSB
encoding.
In Figure 5.4.4., C-SN represents the compressor for the sequence
number traffic that deployed in Host A, D-SN represents the
decompressor for the sequence number traffic that deployed in Host B.
Similarly, C-ACK represents the compressor for the acknowledgement
number traffic that deployed in Host B, D-ACK represents the
decompressor for the acknowledgement number traffic that deployed in
Host A.
Host A Host B
+------------------+ +------------------+
| | | |
| +---------+ | SN \ | +---------+ |
| | C-SN | | ~ ~ ~ ~ | | D-SN | |
| +---------+ | / | +---------+ |
| /|\ | | |
| | | | |
| +---------+ | / | +---------+ |
| | D-ACK | | ~ ~ ~ ~ | | C-ACK | |
| +---------+ | \ ACK | +---------+ |
| | | |
+------------------+ +------------------+
Figure 5.4.4.
It is known that acknowledgement numbers (from C-ACK to D-ACK) are
generally taken from the sequence numbers (from C-SN to D-SN) in the
opposite direction. Since an acknowledgement cannot be generated
for a packet that has not passed across the link, this offers an
efficient way of estimating the TCP congestion window.
Denote the current sequence number that is sending out from C-SN as
SN-New, denote the sequence number that been acknowledged by the D-
ACK as SN-Old, then the TCP congestion window (cwnd-bidir) can be
represented as
cwnd-bidir = SN-New - SN-Old.
Zhang (ed.), et al. [Page 25]
draft-ietf-rohc-tcp-00.txt
Having this new estimated congestion window, the control parameter W
that is calculated in Section 5.2.1. will be re-calculated as
W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack)
= min ( W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack),
cwnd-bidir)
5.5. Mode transitions
The decision to move from one compression mode to another is taken
by the decompressor and the possible mode transitions are shown in
the figure below. Subsequent chapters describe how the transitions
are performed together with exceptions for the compression and
decompression functionality during transitions.
+-------------------------+
| Unidirectional (U) mode |
+-------------------------+
| ^
| | Feedback(U)
| |
| |
Feedback(B) | |
v |
+-------------------------+
| Bidirectional (B) mode |
+-------------------------+
5.5.1. Compression and decompression during mode transitions
The following sections assume that, for each context, the compressor
and decompressor maintain a variable whose value is the current
compression mode for that context. The value of the variable
controls, for the context in question, which packet types to use,
which actions to be taken, etc.
As a safeguard against residual errors, all feedback sent during a
mode transition MUST be protected by a CRC, i.e., the CRC option
MUST be used. A mode transition MUST NOT be initiated by feedback
which is not protected by a CRC.
The subsequent subsections define exactly when to change the value
of the MODE variable. When ROHC transits between compression modes,
there are several cases where the behavior of compressor or
decompressor must be restricted during the transition phase. These
restrictions are defined by exception parameters that specify which
restrictions to apply. The transition descriptions in subsequent
chapters refer to these exception parameters and defines when they
are set and to what values. All mode-related parameters are listed
Zhang (ed.), et al. [Page 26]
draft-ietf-rohc-tcp-00.txt
below together with their possible values, with explanations and
restrictions:
Parameters for the compressor side:
- C_MODE:
Possible values for the C_MODE parameter are (U)NIDIRECTIONAL,
(B)IDIRECTIONAL. C_MODE MUST be initialized to U.
- C_TRANS:
Possible values for the C_TRANS parameter are (P)ENDING and
(D)ONE. C_TRANS MUST be initialized to D. When C_TRANS is P,
it is REQUIRED
1) that the compressor only use packet formats common to all
modes,
2) that mode information is included in packets sent, at least
periodically,
4) that new mode transition requests be ignored.
Parameters for the decompressor side:
- D_MODE:
Possible values for the D_MODE parameter are (U)NIDIRECTIONAL
and (B)IDIRECTIONAL. D_MODE MUST be initialized to U.
- D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D. A
mode transition can be initiated only when D_TRANS is D. While
D_TRANS is I, the decompressor sends a NACK or ACK carrying a
CRC option for each received packet.
5.5.2. Transition from Unidirectional to Bidirectional mode
When there is a feedback channel available, the decompressor may at
any moment decide to initiate transition from Unidirectional to
Bidirectional mode. Any feedback packet carrying a CRC can be used
with the mode parameter set to O. The decompressor can then
directly start working in Optimistic mode. The compressor transits
from Unidirectional to Bidirectional mode as soon as it receives any
feedback packet that has the mode parameter set to B and that passes
the CRC check. The transition procedure is described below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(B)/NACK(B) +-<-<-<-| D_MODE = B
Zhang (ed.), et al. [Page 27]
draft-ietf-rohc-tcp-00.txt
| +-<-<-<-<-<-<-<-+ |
C_MODE = B |-<-<-<-+ |
| |
If the feedback packet is lost, the compressor will continue to work
in Unidirectional mode, but as soon as any feedback packet reaches
the compressor it will transit to Bidirectional mode.
5.5.3. Transition to Unidirectional mode
The decompressor can force a transition back to Unidirectional mode
if it desires to do so. A three-way handshake MUST be carried out
to ensure correct transition on the compressor side. The transition
procedure is described below:
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = U | |
|->->->-+ IR/IR-DYN |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,U) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ U-mode packet |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D, D_MODE= U
After ACKing the IR-DYN(U), or IR(U), the decompressor MUST continue
to send feedback with the Mode parameter set to U until it receives
a U-mode packet.
6. Coding Scheme and compressed packet header format
Following the requirement of TCP/IP header compression [REQTCP],
ROHC-TCP should fit into the ROHC framework. Thus, ROHC-TCP will
conform to the general format and the reserved packet types defined
in [ROHC].
In this document, ROHC-TCP adopts EPIC-LITE as the coding framework.
The detail of EPIC-LITE scheme had been discussed in [EPIC]. EPIC-
LITE is used to generate new ROHC profiles. This scheme takes as
its input a list of fields in the protocol stack to be compressed,
Zhang (ed.), et al. [Page 28]
draft-ietf-rohc-tcp-00.txt
and for each field a choice of one or more compression techniques.
Using this input EPIC-LITE derives a set of compressed header
formats that can be used to quickly and efficiently compress and
decompress headers.
A TCP/IP profile is proposed to describe the behaviors of each field
in TCP/IP header.
6.1. Windowed LSB encoding and fixed-payload encoding
As stated above, the change patterns of several TCP fields (for
example, Sequence Number, Acknowledgement Number, Window, etc.) are
completely different from the ones of RTP, and are very hard to
predict. Thus, Windowed LSB encoding, which does not assume the
linear changing pattern of the target header fields, is used in
ROHC-TCP to encode those TCP fields both efficiently and robustly.
The Windowed LSB encoding will be applied to several fields, such as
IP-ID, Sequence Number, Acknowledgment Number, Window fields, TCP
Timestamp option, etc.
For some applications, such as bulk data transferring, etc., the
payload size of each packet is usually a constant value, e.g. 1460
bytes. In such a case, the sequence number and acknowledgment number
can be represented as the following equation:
SEQ (or ACK) = m * PAYLOAD + n.
If all the packets in context window have the same 'n', only 'm'
need be transmitted to the decompressor. The decompressor can
assign the value of PAYLOAD by the packet size of the reference
packet. Then, the decompressor can obtain the sequence number or
acknowledgment number after correctly decoding 'm', and use them as
the reference values. This encoding method is called fixed-payload
encoding.
6.2. The framework of EPIC-LITE scheme
The detailed information about EPIC-LITE, include the structure of
the EPIC-LITE compressed headers, the overview of the input language
for EPIC-LITE, the packet types available to EPIC-LITE, the library
of EPIC-LITE encoding methods, and how to create a new ROHC profile,
are described in [EPIC].
6.3. ROHC Profile for compression of TCP/IP
This session describes a ROHC profile for the compression of TCP/IP.
< need to be further refine>
Zhang (ed.), et al. [Page 29]
draft-ietf-rohc-tcp-00.txt
Note that the probabilities listed for each encoding method are
initial estimates only. These need to be refined with more accurate
values from genuine TCP/IP streams.
The profile for TCP/IP compression is given below:
only uses the following toolbox methods:
- STATIC-KNOWN
- STATIC-UNKNOWN
- STATIC
- IRREGULAR
- LSB
- VALUE
- C
profile_identifier 0xFFFF
max_formats 60
max_sets 48
bit_alignment 8
npatterns 224
CO_packet TCP-IP-CO
IR_packet TCP-IP-IR
IR-DYN_packet TCP-IP-DYN
TCP-IP-CO = INFERRED-IP-CHECKSUM(IPv4-co-header)
TCP-co-header
skip-msn
CRC(3,80%) | CRC(7,20%)
;
; since we want to have a MSN in some packets and not in others,
; there needs to be some way to indicate that there is a
; context value present.
;
; we need to agree on the degree of CRC protection that is
; appropriate for the various packets
;
TCP-IP-IR = INFERRED-IP-CHECKSUM(IPv4-ir-header)
TCP-ir-header
msn-ir
CRC(8,100%)
TCP-IP-DYN = INFERRED-IP-CHECKSUM(IPv4-dyn-header)
TCP-dyn-header
msn-dyn
CRC(8,100%)
IPv4-co-header = version
header_len
tos-co
Zhang (ed.), et al. [Page 30]
draft-ietf-rohc-tcp-00.txt
ecn
length
ip-id-co
rf_flag
df_flag-co
mf_flag
offset
ttl-co
protocol
ip_chksum
src_address-co
dst_address-co
IPv4-ir-header = version
header_len
tos-dyn
ecn
length
ip-id-dyn
rf_flag
df_flag-dyn
mf_flag
offset
ttl-dyn
protocol
ip_chksum
src_address-ir
dst_address-ir
IPv4-dyn-header = version
header_len
tos-dyn
ecn
length
ip-id-dyn
rf_flag
df_flag-dyn
mf_flag
offset
ttl-dyn
protocol
ip_chksum
src_address-co
dst_address-co
version = VALUE(4,4,100%)
header_len = VALUE(4,5,100%)
tos-co = STATIC(99%) | IRREGULAR(6,1%)
tos-dyn = IRREGULAR(6,100%)
Zhang (ed.), et al. [Page 31]
draft-ietf-rohc-tcp-00.txt
ecn = STACK-TO-CONTROL(2)
length = INFERRED-SIZE(16,128)
ip-id-co = NBO(16) ; check byte-order
FORMAT(ip-id-seq-co, ip-id-rnd)
STATIC(100%) ; nbo flag
ip-id-dyn = NBO(16) ; check byte-order
FORMAT(ip-id-seq-dyn, ip-id-rnd)
IRREGULAR(16,100%)
IRREGULAR(1,100%) ; nbo flag
ip-id-seq-co = LSB(4,3,70%) | LSB(6,8,15%) |
LSB(8,8,15%) | IRREGULAR(16,30%)
ip-id-rnd = IRREGULAR(16,100%)
ip-id-seq-dyn = IRREGULAR(16,100%)
rf_flag = STACK-TO-CONTROL(1)
df_flag-co = STATIC(80%) | IRREGULAR(20%)
df-flag-dyn = IRREGULAR(1,100%)
mf_flag = VALUE(1,0,100%)
offset = VALUE(13,0,100%)
ttl-co = STATIC(99%) | IRREGULAR(8,1%)
ttl-dyn = IRREGULAR(8,100%)
protocol = VALUE(8,6,100%)
; need to take account of extension
; headers at some point
;
ip_chksum = VALUE(16,0,100%)
src_address-co = STATIC(100%)
src_address-ir = IRREGULAR(32,100%)
dst_address-co = STATIC(100%)
dst_address-ir = IRREGULAR(32,100%)
Zhang (ed.), et al. [Page 32]
draft-ietf-rohc-tcp-00.txt
TCP-header-co = source_port-co
dest_port-co
seqno
ackno
data_offset
flags-co
window-co
tcp_chksum
urg_ptr-co
TCP-header-dyn = source_port-co
dest_port-co
seqno
ackno
data_offset
flags-dyn
window-dyn
tcp_chksum
urg_ptr-dyn
TCP-header-ir = source_port-ir
dest_port-ir
seqno
ackno
data_offset
flags-dyn
window-dyn
tcp_chksum
urg_ptr-dyn
source_port-co = STATIC(100%)
source_port-ir = IRREGULAR(16,100%)
dest_port-co = STATIC(100%)
dest_port-ir = IRREGULAR(16,100%)
seqno = STACK-TO-CONTROL(32)
ackno = STACK-TO-CONTROL(32)
seqno-co = LSB(8,63,5%) | LSB(14,4096,80%) |
LSB(20,16384,10%) | IRREGULAR(32,5%)
seqno-dyn = IRREGULAR(32,100%)
ackno-co = LSB(8,0,10%) | LSB(14,0,80%) |
LSB(20,0,5%) | IRREGULAR(32,5%)
ackno-dyn = IRREGULAR(32,100%)
data_offset = STACK-TO-CONTTROL(4)
Zhang (ed.), et al. [Page 33]
draft-ietf-rohc-tcp-00.txt
window-co = STATIC(80%) | LSB(12,63,10%) |
IRREGULAR(16,10%)
window-dyn = IRREGULAR(16,100%)
tcp_chksum = IRREGULAR(16,100%)
urg-ptr = STACK-TO-CONTROL(16)
urg_ptr-co = STATIC(99%) | IRREGULAR(16,1%)
urg_ptr-dyn = IRREGULAR(16,100%)
flags-co = reserved-co
cwr
ece
urg
ack
psh
rst-syn-fin-co
flags-dyn = reserved-dyn
IRREGULAR(2,100%)
urg
IRREGULAR(1,100%)
psh-dyn
rst-syn-fin-dyn
get-rf = ROTATE(4,1)
STACK-FROM-CONTROL(1)
reserved-co = get-rf
FORMAT(reserved-unused, reserved-used)
STATIC(100%) ; format selector
reserved-dyn = get-rf
FORMAT(reserved-unused, reserved-used)
IRREGULAR(1,100%) ; format selector
reserved-unused = VALUE(5,0,100%)
reserved-used = reserved-flag
reserved-flag
reserved-flag
reserved-flag
reserved-flag
reserved-flag = IRREGULAR(1,100%)
cwr-ece = STACK-TO-CONTROL(2)
Zhang (ed.), et al. [Page 34]
draft-ietf-rohc-tcp-00.txt
cwr = IRREGULAR(1,100%)
ece = IRREGULAR(1,100%)
urg = STACK-TO-CONTROL(1)
ack-co = VALUE(1,1,99.9%) | VALUE(1,0,0.1%)
ack-dyn = IRREGULAR(1,100%)
psh-co = FORMAT(reg-psh-co, irreg-psh)
STATIC(100%) ; format selector
psh-dyn = FORMAT(reg-psh-dyn, irreg-psh)
IRREGULAR(1,100%) ; format selector
reg-psh-co = STATIC(90%) | N(IRREGULAR(1,9%) |
IRREGULAR(1,9%)
reg-psh-dyn = IRREGULAR(1,100%)
irreg-psh = IRREGULAR(1,100%)
rst-syn-fin-co = no-flag(98%) | rst-only(1%) | fin-only(1%)
no-flag = VALUE(3,0x0,100%)
rst-only = VALUE(3,0x4,100%)
syn-only = VALUE(3,0x2,100%)
fin-only = VALUE(3,0x1,100%)
rst-syn-fin-dyn = IRREGULAR(3,100%)
tcp-options-co = ROTATE(3,1) ; get TCP data offset
LIST(4,1,32,-160,8,
U(OPTIONAL(tcp-sack-co)),
U(OPTIONAL(tcp-timestamp-co)),
U(OPTIONAL(tcp-mss)),
U(OPTIONAL(tcp-end)),
U(OPTIONAL(tcp-wscale)),
U(OPTIONAL(sack-permitted)),
U(OPTIONAL(tcp-generic-co)),
U(OPTIONAL(tcp-generic-co)),
5,8,2,0,3,4)
STATIC(100%) ; option order
STATIC(95%) | IRREGULAR(8,5%) ; option presence
tcp-options-dyn = ROTATE(3,1) ; get TCP data offset
Zhang (ed.), et al. [Page 35]
draft-ietf-rohc-tcp-00.txt
LIST(4,1,32,-160,8,
U(OPTIONAL(tcp-sack-dyn)),
U(OPTIONAL(tcp-timestamp-dyn)),
U(OPTIONAL(tcp-mss)),
U(OPTIONAL(tcp-end)),
U(OPTIONAL(tcp-wscale)),
U(OPTIONAL(sack-permitted)),
U(OPTIONAL(tcp-generic-dyn)),
U(OPTIONAL(tcp-generic-dyn)),
5,8,2,0,3,4)
IRREGULAR(24,100%) ; option order
IRREGULAR(8,100%) ; option presence
;
; need further discussion
;
tcp-sack-co = VALUE(8,5,100%) ; type
STACK-TO-CONTROL(8) ; length
LIST(8,1,8,-16,0,
OPTIONAL(sack-block-co),
OPTIONAL(sack-block-co),
OPTIONAL(sack-block-co),
OPTIONAL(sack-block-co))
STATIC(90%) | IRREGULAR(8,10%) ; order
sack-block-presence
sack-block-presence = VALUE(1,1,100%)
VALUE(1,1,50%) | VALUE(1,0,50%)
VALUE(1,1,20%) | VALUE(1,0,80%)
VALUE(1,1,5%) | VALUE(1,0,95%)
tcp-sack-dyn = VALUE(8,5,100%) ; type
STACK-TO-CONTROL(8) ; length
LIST(8,1,8,-16,0,
OPTIONAL(sack-block-dyn),
OPTIONAL(sack-block-dyn),
OPTIONAL(sack-block-dyn),
OPTIONAL(sack-block-dyn))
IRREGULAR(8,10%) ; order
Zhang (ed.), et al. [Page 36]
draft-ietf-rohc-tcp-00.txt
sack-block-presence-dyn
sack-block-presence-dyn = IRREGULAR(1,100%)
IRREGULAR(1,100%)
IRREGULAR(1,100%)
IRREGULAR(1,100%)
sack-block-dyn = sack-element-dyn
sack-element-dyn
sack-block-co = sack-element-co
sack-element-co
sack-element-dyn = INFERRED-OFFSET-LIST(32) ; offset from base
STACK-TO-CONTROL(32) ; preserve new base
IRREGULAR(32,100%)
sack-element = INFERRED-OFFSET-LIST(32) ; offset from base
STACK-TO-CONTROL(32) ; preserve new base
STATIC(50%) | LSB(16,32768,30%) |
LSB(24,1048576,20%)
tcp-timestamp-co = VALUE(8,8,100%) ; type
VALUE(8,10,100%) ; length
ts-entry
ts-entry
ts-entry-co = LSB(12,0,60%) | LSB(16,0,30%) |
IRREGULAR(32,10%)
ts-entry-dyn = IRREGULAR(32,100%)
tcp-mss = VALUE(8,2,100%) ; type
VALUE(8,4,100%) ; length
IRREGULAR-PADDED(16,11,99%) | IRREGULAR(16,1%)
tcp-end = VALUE(8,0,100%) ; type
tcp-wscale = VALUE(8,3,100%) ; type
VALUE(8,3,100%) ; length
IRREGULAR-PADDED(8,4,100%) ; scale
tcp-sack-permitted = VALUE(8,4,100%) ; type
Zhang (ed.), et al. [Page 37]
draft-ietf-rohc-tcp-00.txt
VALUE(8,2,100%) ; length
tcp-generic-co = STATIC(100%) ; type
STACK-TO-CONTROL(8) ; length
UNCOMPRESSED(8,1,8,-16) ; value
tcp-generic-dyn = IRREGULAR(8,100%) ; type
STACK-TO-CONTROL(8) ; length
UNCOMPRESSED(8,1,8,-16) ; value
get-seq-ack = ROTATE(2,1)
STACK-FROM-CONTROL(2) ; cwr/ece
ROTATE(4,1)
STACK-FROM-CONTROL(2) ; ecn
STACK-FROM-CONTROL(32) ; ack
STACK-FROM-CONTROL(32) ; seq
seqno-and-ackno-co = FORMAT(bulk-data-co, bulk-ack-co, interactive-
co)
STATIC(100%) ; format selector
seqno-and-ackno-dyn = FORMAT(bulk-data-dyn, bulk-ack-dyn,
interactive-dyn)
IRREGULAR(2,100%) ; format-selector
bulk-data-co = data-seqno-co
data-ackno-co
ecn-co
bulk-ack-co = ack-seqno-co
ack-ackno-co
ecn-co
interactive-co = interact-seqno-co
interact-ackno-co
ecn-co
bulk-data-dyn = seqno-dyn
ackno-dyn
ecn-dyn
bulk-ack-dyn = seqno-dyn
ackno-dyn
ecn-dyn
Zhang (ed.), et al. [Page 38]
draft-ietf-rohc-tcp-00.txt
interactive-dyn = seqno-dyn
ackno-dyn
ecn-dyn
;
; To be refined.
;
data-seqno-co = LSB(14,0,50%) | LSB(16,32768,30%) |
LSB(20,65536,20%)
data-ackno-co = STATIC(50%) | LSB(10,0,30%) | LSB(16,0,20%)
ecn-co = FORMAT(no-ecn-co, use-ecn-co)
no-ecn-co = VALUE(2,0,100%)
VALUE(2,0,100%)
use-ecn-co = IRREGULAR(4,100%)
seqno-dyn = IRREGULAR(32,100%)
ackno-dyn = IRREGULAR(32,100%)
ecn-dyn = FORMAT(no-ecn-dyn, use-ecn-dyn)
IRREGULAR(1,100%) ; format selector
no-ecn-dyn = VALUE(2,0,100%)
VALUE(2,0,100%)
use-ecn-dyn = IRREGULAR(2,100%)
IRREGULAR(2,100%)
ack-seqno-co = STATIC(50%) | LSB(10,0,30%) | LSB(16,0,20%)
ack-ackno-co = LSB(14,0,50%) | LSB(16,0,30%) |
LSB(20,0,20%)
interact-seqno-co = LSB(10,256,35%) | LSB(14,2048,50%) |
LSB(18,4096,15%)
interact-ackno-co = LSB(10,0,35%) | LSB(14,0,50%) | LSB(18,0,15%)
msn-ir = MSN-IRREGULAR(16,10%)
msn-dyn = MSN-LSB(3,0,90%) | MSN-LSB(7,0,9%) | MSN-
IRREGULAR(16,1%)
Zhang (ed.), et al. [Page 39]
draft-ietf-rohc-tcp-00.txt
7. Security considerations
ROHC-TCP is conformed to ROHC framework. Consequently the security
considerations for ROHC-TCP match those of [ROHC].
8. Acknowledgements
Header compression schemes from [VJHC, IPHC, ROHC] have been
important sources of ideas and knowledge. This document also
benefited from discussion on the rohc mailing list about some key
issues.
9. References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[VJHC] V. Jacobson, "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990.
[IPHC] M. Degermark, B. Nordgren, and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2018] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for TCP",
RFC 2883, July 2000.
[RFC1323] V. Jacobson, R. Braden, and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2119]7 S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3095] Bormann (ed.), et al., "RObust Header Compression (ROHC)",
RFC 3095, July 2001.
[CAC] V. Jacobson, "Congestion avoidance and control", In ACM
SIGCOMM '88, 1988.
Zhang (ed.), et al. [Page 40]
draft-ietf-rohc-tcp-00.txt
[RFC2581] M. Allman, V. Paxson, and W. R. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[ECN] K. K. RamaKrishnan, Sally Floyd, D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", Internet Draft
(work in progress), June, 2001. <draft-ietf-tsvwg-ecn-04.txt>
[REQTCP] L-E. Jonsson, "Requirements for ROHC IP/TCP header
compression", Internet Draft (work in progress), June 20, 2001.
[LTX] M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", Internet Draft (work in
progress), August 2000. <draft-ietf-tsvwg-limited-xmit-00.txt>
[RFC3096] M. Degermark, "Requirements for robust IP/UDP/RTP header
compression", RFC 3096, July 2001.
[INITWIN] M. Allman, S. Floyd, and C. Partridge, "Increasing TCP's
Initial Window", Internet Draft (work in progress), May 2001.
<draft-ietf-tsvwg-initwin-00.txt>
[EPIC] Richard Price et al, "Framework for EPIC-LITE", <draft-ietf-
rohc-epic-lite-00.txt>, Internet Draft (work in progress), Oct.
2001.
[RFC791] Postel, J., "Internet Protocol", STD 5, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
DARPA, September 1981.
[RFC1072] Jacobson, V., and R. Braden, "TCP Extensions for Long-
Delay Paths", LBL, ISI, October 1988.
[RFC1146] Zweig, J., and C. Partridge, "TCP Alternate Checksum
Options", UIUC, BBN, March 1990.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP
Extensions for High Performance", LBL, ISI, Cray Research, May 1992.
[RFC1644] Braden, R. "T/TCP -- TCP Extensions for Transactions
Functional Specification", ISI, July 1994.
[RFC1693] Connolly, T., et al, "An Extension to TCP : Partial
Order Service", University of Delaware, November 1994.
[RFC2001] Stevens, W., TCP Slow Start, Congestion Avoidance,
Fast Retransmit, and Fast Recovery Algorithms, NOAO, January 1997
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A.,
TCP Selective Acknowledgement Options, April 1996.
Zhang (ed.), et al. [Page 41]
draft-ietf-rohc-tcp-00.txt
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", October 1996
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", Cisco Systems, August 1998.
[RFC2474] Nichols, K., et al Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers, December
1998
[RFC2481] Ramakrishnan, K., Floyd, S., Proposal to add
Explicit Congestion Notification (ECN) to IP, AT&T Labs Research,
LBNL, January 1999
[RFC 2508] Casner, S., Jacobson, V., Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links, Cisco Systems, February 1999
[RFC2509] Engan, M., et al, IP Header Compression over PPP,
February 1999
[RFC2581] Allman, M., et al, TCP Congestion Control, April 1999
[RFC2883] Floyd, S., et al, An Extension to the Selective
Acknowledgement (SACK) Option for TCP, July 2000
[ECN-X] Spring, N., Wetherall, D., Ely, D., Robust ECN
Signaling with Nonces, draft-ietf-tsvwg-tcp-nonce-02.txt,
University of Washington, October 2001.
[IANA] http://www.iana.org/assignments/tcp-parameters
10. Authors' addresses
Qian Zhang Tel: +86 10 62617711-3135
Email: qianz@microsoft.com
HongBin Liao Tel: +86 10 62617711-3156
Email: i-hbliao@microsoft.com
Ya-Qin Zhang Tel: +86 10 62617711
Email: yzhang@microsoft.com
Wenwu Zhu Tel: +86 10 62617711-5405
Email: wwzhu@microsoft.com
Microsoft Research Asia
Beijing Sigma Center
No.49, Zhichun Road, Haidian District
Beijing 100080, P.R.C.
Robert Hancock Tel: +44 1794 833601
Zhang (ed.), et al. [Page 42]
draft-ietf-rohc-tcp-00.txt
Email: robert.hancock@roke.co.uk
Stephen McCann Tel: +44 1794 833341
Email: stephen.mccann@roke.co.uk
Paul Ollis Tel: +44 1794 833168
Email: paul.ollis@roke.co.uk
Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk
Abigail Surtees Tel: +44 1794 833131
Email: abigail.surtees@roke.co.uk
Mark A West Tel: +44 1794 833311
Email: mark.a.west@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Zhang (ed.), et al. [Page 43]
draft-ietf-rohc-tcp-00.txt
Appendix A - Detailed classification of header fields
Header compression is possible thanks to the fact that most header
fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less
predictable way. When designing a header compression scheme, it is
of fundamental importance to understand the behavior of the fields
in detail.
Since the IP header does exhibit some slightly different behavior
from that previously presented in [ROHC] for the RTP case, it is
also included in this document.
It is intentional that much of the classification text from [ROHC]
has been borrowed. This is for easier reading rather than inserting
many references to that document.
Again based on the format presented in [ROHC] TCP/IP header fields
are classified and analyzed in two steps. First, we have a general
classification in Section 3, where the fields are classified on the
basis of stable knowledge and assumptions. The general
classification does not take into account the change characteristics
of changing fields because those will vary more or less depending on
the implementation and on the application used. A less stable but
more detailed analysis of the change characteristics is then done in
Section A.4. Finally, Section A.5 summarizes this appendix with
conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and
functionality.
The general requirement for transparency is also seen to be more
interesting. A number of recent proposals for extensions to TCP
make use of some of the previously Reserved bits. It is therefore
clear that a Reserved bit cannot be taken to have a guaranteed zero
value, but may change. Ideally, this should be accommodated by the
compression profile.
A.1. General classification
Definitions (and some text) copied from [ROHC] Appendix A.
Differences between IP field behavior between [ROHC] (i.e.
IP/UDP/RTP behavior for audio and video applications) and this
document have been identified.
At a general level, the header fields are separated into 5 classes:
INFERRED These fields contain values that can be inferred from
other values, for example the size of the frame
carrying the packet, and thus do not have to be handled
at all by the compression scheme.
STATIC These fields are expected to be constant throughout the
Zhang (ed.), et al. [Page 44]
draft-ietf-rohc-tcp-00.txt
lifetime of the packet stream. Static information must
in some way be communicated once.
STATIC-DEF STATIC fields whose values define a packet stream. They
are in general handled as STATIC.
STATIC-KNOWN These STATIC fields are expected to have well-known
values and therefore do not need to be communicated at
all.
CHANGING These fields are expected to vary in some way:
randomly, within a limited value set or range, or in
some other manner.
In this section, each of the IP and TCP header fields is assigned to
one of these classes. For all fields except those classified as
CHANGING, the motives for the classification are also stated. In
section 4, CHANGING fields are further examined and classified on
the basis of their expected change behavior.
A.1.1. IP header fields
A.1.1.1. IPv6 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Traffic Class* | 6 | CHANGING |
| ECT flag* | 1 | CHANGING |
| ECE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
* differs from [ROHC]
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the same
IP version. Accordingly, the field is classified as STATIC.
Flow Label
This field may be used to identify packets belonging to a
specific packet stream. If not used, the value should be set to
Zhang (ed.), et al. [Page 45]
draft-ietf-rohc-tcp-00.txt
zero. Otherwise, all packets belonging to the same stream must have
the same value in this field, it being one of the fields that define
the stream. The field is therefore classified as STATIC-DEF.
Payload Length
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The field is
therefore classified as INFERRED.
Next Header
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header. Only
when extension headers are sometimes present and sometimes not, will
the field change its value during the lifetime of the stream. The
field is therefore classified as STATIC.
Source and Destination addresses
These fields are part of the definition of a stream and must thus be
constant for all packets in the stream. The fields are therefore
classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| CHANGING | 2 |
+--------------+--------------+
A.1.1.2. IPv4 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| Type of Service* | 6 | CHANGING |
| ECT flag* | 1 | CHANGING |
| ECE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING |
| Don't Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
Zhang (ed.), et al. [Page 46]
draft-ietf-rohc-tcp-00.txt
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
* differs from [ROHC]
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the same
IP version. Accordingly, the field is classified as STATIC.
Header Length
As long no options are present in the IP header, the header
length is constant and well known. If there are options, the fields
would be STATIC, but it is assumed here that there are no options.
The field is therefore classified as STATIC-KNOWN.
Packet Length
Information about packet length is expected to be provided by
the link layer. The field is therefore classified as INFERRED.
Flags
The Reserved flag must be set to zero, as defined in [RFC791].
In [ROHC] the field is therefore classified as STATIC-KNOWN.
However, it is expected that reserved fields may be used at some
future point. It appears unwise to select an encoding that would
preclude the use of a compression profile for a future change in the
use of reserved fields. For this reason the alternative encoding of
CHANGING is suggested. It would also be possible to have more than
one compression profile, in one of which this field was considered
to be STATIC-KNOWN.
The More Fragments (MF) flag is expected to be zero because
fragmentation is generally not expected. As discussed in the RTP
case, only the first fragment will contain the transport layer
protocol header; subsequent fragments would have to be compressed
with a different profile. In terms of the effect of header overhead,
if fragmentation does occur then the first fragment, by definition,
should be relatively large, minimizing the header overhead. In the
case of TCP, fragmentation should not be common due to a combination
of initial MSS negotiation and subsequent use of path-MTU discovery.
The More Fragments flag is therefore classified as STATIC-KNOWN.
However, a profile could accept that this flag may be set in order
to cope with fragmentation.
Fragment Offset
Zhang (ed.), et al. [Page 47]
draft-ietf-rohc-tcp-00.txt
Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as STATIC-
KNOWN. Even if fragmentation were to be further considered, then
only the first fragment would contain the TCP header and would still
be zero.
Protocol
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header. Only
when extension headers are sometimes present and sometimes not, will
the field change its value during the lifetime of a stream. The
field is therefore classified as STATIC.
Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum; instead it can be regenerated at the decompressor side.
The field is therefore classified as INFERRED.
Source and Destination addresses
These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+----------------+
| Class | Size (octets) |
+--------------+----------------+
| INFERRED | 4 |
| STATIC* | 1 + 4 bits |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2 + 2 bits |
| CHANGING* | 4 + 2 bits |
+--------------+----------------+
* differs from [ROHC]
A.1.2. TCP header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Sequence Number | 32 | CHANGING |
| Acknowledgement Num | 32 | CHANGING |
| Data Offset | 4 | INFERRED |
Zhang (ed.), et al. [Page 48]
draft-ietf-rohc-tcp-00.txt
| Reserved | 4 | CHANGING |
| ECN flags | 2 | CHANGING |
| CWR flag | 1 | CHANGING |
| ECE flag | 1 | CHANGING |
| URG flag | 1 | CHANGING |
| ACK flag | 1 | CHANGING |
| PSH flag | 1 | CHANGING |
| RST flag | 1 | CHANGING |
| SYN flag | 1 | CHANGING |
| FIN flag | 1 | CHANGING |
| Window | 16 | CHANGING |
| Checksum | 16 | CHANGING |
| Urgent Pointer | 16 | CHANGING |
| Options | 0(-352) | CHANGING |
+---------------------+-------------+----------------+
Source and Destination ports
These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Data Offset
The number of 4 octet words in the TCP header, thus indicating
The start of the data. It is always a multiple of 4 octets. It can
be re-constructed from the length of any options and is not
necessary. The field is therefore classified as INFERRED.
A.1.3. Summary for IP/TCP
Summarizing this for IP/TCP one obtains
+----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 6 bits | 17 |
| |(- 61 + 6 bits) | (- 61) |
+----------------+----------------+----------------+
| Totals | 60 + 2 bits | 37 + 2 bits |
| |(- 104 + 2 bits)|(- 81 + 2 bits) |
+----------------+----------------+----------------+
A.2. Analysis of change patterns of header fields
To design suitable mechanisms for efficient compression of all
header fields, their change patterns must be analyzed. For this
Zhang (ed.), et al. [Page 49]
draft-ietf-rohc-tcp-00.txt
reason, an extended classification is done based on the general
classification in 2, considering the fields which were labeled
CHANGING in that classification. Different applications will use the
fields in different ways, which may affect their behavior. For the
fields whose behavior is variable, typical behavior for
conversational audio and video will be discussed.
The CHANGING fields are separated into five different subclasses:
STATIC These are fields that were classified as CHANGING on a
general basis, but are classified as STATIC here due to certain
additional assumptions.
SEMISTATIC These fields are STATIC most of the time. However,
occasionally the value changes but reverts to its original value
after a known number of packets.
RARELY-CHANGING (RC) These are fields that change their values
occasionally and then keep their new values.
ALTERNATING These fields alternate between a small number of
different values.
IRREGULAR These, finally, are the fields for which no useful
change pattern can be identified.
To further expand the classification possibilities without
increasing complexity, the classification can be done either
according to the values of the field and/or according to the values
of the deltas for the field.
When the classification is done, other details are also stated
regarding possible additional knowledge about the field values
and/or field deltas, according to the classification. For fields
classified as STATIC or SEMISTATIC, the case could be that the value
of the field is not only STATIC but also well KNOWN a priori (two
states for SEMISTATIC fields). For fields with non-irregular change
behavior, it could be known that changes usually are within a
LIMITED range compared to the maximal change for the field. For
other fields, the values are completely UNKNOWN.
Table 1 classifies all the CHANGING fields on the basis of their
expected change patterns. (4) refers to IPv4 fields and (6) refers
to IPv6.
+------------------------+-------------+-------------+------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+============+
| IP TOS(4) / Tr.Class(6)| Value | RC | UNKNOWN |
+------------------------+-------------+-------------+------------+
| IP ECT flag(4) | Value | RC | UNKNOWN |
Zhang (ed.), et al. [Page 50]
draft-ietf-rohc-tcp-00.txt
+------------------------+-------------+-------------+------------+
| IP CE flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+------------+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+------------+
| IP Id(4) Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| IP DF flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+------------+
| IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+------------+
| TCP Sequence Number | Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+------------+
| TCP Acknowledgement Num| Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+------------+
| TCP Reserved | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP ECN flags | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP CWR flag | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP ECE flag | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP URG flag | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP ACK flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+------------+
| TCP PSH flag | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP RST flag | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP SYN flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+------------+
| TCP FIN flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+------------+
| TCP Window | Value | ALTERNATING | KNOWN |
+------------------------+-------------+-------------+------------+
| TCP Checksum | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
| TCP Urgent Pointer | Value | IRREGULAR | KNOWN |
+------------------------+-------------+-------------+------------+
| TCP Options | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+------------+
Table 1 : Classification of CHANGING header fields
The following subsections discuss the various header fields in
detail. Note that table 1 and the discussions below do not consider
changes caused by loss or reordering before the compression point.
Zhang (ed.), et al. [Page 51]
draft-ietf-rohc-tcp-00.txt
A.2.1. IP header fields
A.2.1.1. IP Traffic-Class / Type-Of-Service (TOS)
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field might be
expected to change during the lifetime of a packet stream. This
analysis considers several RFCs that describe modifications to the
original [RFC791].
The TOS byte was initially described in [RFC791] as 3 bits of
precedence followed by 3 bits of TOS and 2 reserved bits (defined to
be 0). [RFC1122] extended this to specify 5 bits of TOS, although
the meanings of the additional 2 bits were not defined. [RFC1349]
defined the 4th bit of TOS to be 'minimize monetary cost'.
The next significant change was in [RFC2474] which reworked the TOS
octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits.
Most recently [RFC2780] identified the 2 reserved bits in the TOS or
traffic class octet for experimental use with ECN.
For the purposes of this classification, it is therefore proposed to
classify the TOS (or traffic class) octet as 6 bits for the DSCP and
2 additional bits. This may be expected to be 0 or to contain ECN
data. From a future proofing perspective, it is preferable to
assume the use of ECN, especially with respect to TCP.
It is also considered important that the profile works with legacy
stacks, since these will be in existence for some considerable time
to come. For simplicity, this will be considered as 6 bits of TOS
information and 2 bits of ECN data, so the fields are always
considered to be structured the same way.
The DSCP (as for TOS in ROHC RTP) is not expected to change
frequently.
A.2.1.2. ECN Flags
Initially we describe the ECN flags as specified in [RFC2481].
Subsequently, a suggested update is described which would alter the
behavior of the flags.
In [RFC2481] there are 2 separate flags, the ECT (ECN Capable
Transport) flag and the CE (Congestion Experienced) flag.
The ECT flag, if negotiated by the TCP stack, will be on for all
data packets and off for all 'pure acknowledgement' packets. This
means that the behavior of the ECT flag is linked to behavior in the
TCP stack. Whether this can be exploited for compression is not
clear.
The CE flag is only used if ECT is set to on and indicates
congestion in the network. The CE flag is expected to be randomly
(and comparatively rarely, although this is dependent upon the
network congestion state) set to '1'.
Zhang (ed.), et al. [Page 52]
draft-ietf-rohc-tcp-00.txt
A recent draft [nonce] suggests an alternative view of these 2 bits.
This considers the two bits together as having 4 possible
codepoints. Meanings are then assigned to the codepoints:
00 Not ECN capable
01 ECN capable, no congestion [known as ECT(0)]
10 ECN capable, no congestion [known as ECT(1)]
11 Congestion experienced
The use of 2 codepoints for signaling ECT allows the sender to
detect when a receiver is not reliably echoing congestion
information.
For the purposes of compression, this update means that ECT(0) and
ECT(1) are equally likely (for an ECN capable flow) and that “11”
will be relatively rarely seen.
A.2.1.3. IP Identification
The Identification field (IP ID) of the IPv4 header is there to
identify which fragments constitute a datagram when reassembling
fragmented datagrams. The IPv4 specification does not specify
exactly how this field is to be assigned values, only that each
packet should get an IP ID that is unique for the source-destination
pair and protocol for the time the datagram (or any of its
fragments) could be alive in the network. This means that assignment
of IP ID values can be done in various ways, which we have separated
into three classes:
Sequential jump
This is the most common assignment policy in today's IP stacks.
A single IP ID counter is used for all packet streams. When the
sender is running more than one packet stream simultaneously, the IP
ID can increase by more than one between packets in a stream. The IP
ID values will be much more predictable and require less bits to
transfer than random values, and the packet-to-packet increment
(determined by the number of active outgoing packet streams and
sending frequencies) will usually be limited.
Random
Some IP stacks assign IP ID values using a pseudo-random number
generator. There is thus no correlation between the ID values of
subsequent datagrams. Therefore there is no way to predict the IP ID
value for the next datagram. For header compression purposes, this
means that the IP ID field needs to be sent uncompressed with each
datagram, resulting in two extra octets of header. IP stacks in
cellular terminals SHOULD NOT use this IP ID assignment policy.
Zhang (ed.), et al. [Page 53]
draft-ietf-rohc-tcp-00.txt
Sequential
This assignment policy keeps a separate counter for each
outgoing packet stream and thus the IP ID value will increment by
one for each packet in the stream, except at wrap around. Therefore,
the delta value of the field is constant and well known a priori.
This assignment policy is the most desirable for header compression
purposes. However, its usage is not as common as it perhaps should
be.
In order to avoid violating [IPv4], packets sharing the same IP
address pair and IP protocol number cannot use the same IP ID
values. Therefore, implementations of sequential policies must make
the ID number spaces disjoint for packet streams of the same IP
protocol going between the same pair of nodes. This can be done in a
number of ways, all of which introduce occasional jumps, and thus
makes the policy less than perfectly sequential. For header
compression purposes less frequent jumps are preferred.
It should be noted that the ID is an IPv4 mechanism and is therefore
not a problem for IPv6. For IPv4 the ID could be handled in three
different ways. First, we have the inefficient but reliable solution
where the ID field is sent as-is in all packets, increasing the
compressed headers by two octets. This is the best way to handle the
ID field if the sender uses random assignment of the ID field.
Second, there can be solutions with more flexible mechanisms
requiring less bits for the ID handling as long as sequential jump
assignment is used. Such solutions will probably require even more
bits if random assignment is used by the sender. Knowledge about the
sender's assignment policy could therefore be useful when choosing
between the two solutions above. Finally, even for IPv4, header
compression could be designed without any additional information for
the ID field included in compressed headers. To use such schemes, it
must be known which assignment policy for the ID field is being used
by the sender. That might not be possible to know, which implies
that the applicability of such solutions is very uncertain. However,
designers of IPv4 stacks for cellular terminals SHOULD use an
assignment policy close to sequential.
With regard to TCP compression, the behavior of the IP ID field is
considered to be essentially the same. However, it is noted that
the IP ID was generally inferred from the RTP Sequence Number.
There is no obvious candidate in the TCP case for a field to offer
this Master sequence number role.
Clearly from a busy server the observed behavior may well be quite
erratic. This is a case where the ability to share the IP
compression context between a number of flows (between the same end-
points) would offer potential benefits.
A.2.1.4. Don't Fragment (DF) flag
Zhang (ed.), et al. [Page 54]
draft-ietf-rohc-tcp-00.txt
Due to the use of path-MTU discovery [RFC1191], the value is more
likely to be '1', than found in UDP/RTP streams since DF should be
periodically set to check for fragmentation in the end-to-end path.
In practice it is hard to predict the behavior of this field.
However, it is considered that the most likely case is that it will
generally stay at either 0/1 (periodically being set to 0 or 1)
A.2.1.5. IP Hop-Limit / Time-To-Live (TTL)
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
constant during the lifetime of a packet stream or to alternate
between a limited number of values due to route changes.
A.2.2. TCP header fields
Any discussion of compressability of TCP fields borrows heavily from
[VJHC]. However, the premise of how the compression is
performed is slightly different and the protocol has evolved
slightly in the intervening time.
A.2.2.1. Sequence number
An understanding of the sequence and acknowledgement number behavior
are essential for a TCP compression scheme.
At the simplest level the behavior of the sequence number can be
described relatively easily. However, there are a number of
complicating factors that also need to be considered.
For transferring in-sequence data packets, the sequence number will
increment for each packet by between 0 and an upper limit defined by
the MSS (Maximum Segment Size).
However, 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. This is a combination of a number of
values (buffer space at the sender; advertised buffer size at the
receiver; and TCP congestion control algorithms). Missing packets
or retransmissions can cause the TCP sequence number to fluctuate
within the limits of this window.
It would also be desirable to be able to predict the sequence number
from some regularity. However, this also appears to be difficult to
do. For example, during bulk data transfer the sequence number will
tend to go up by 1 MSS per packet (assuming no packet loss). Higher
level values have been seen to have an impact as well, where
sequence number behavior has been observed with an 8 kbyte repeating
pattern - 5 segments of 1460 bytes followed by 1 segment of 892
bytes. It appears that implementation and how data is presented to
the stack can affect the sequence number.
Zhang (ed.), et al. [Page 55]
draft-ietf-rohc-tcp-00.txt
It has been suggested that the TCP window can be tracked by the
compressor, allowing it to bound the size of these jumps.
For interactive flows (for example telnet), the sequence number will
change by small irregular amounts. In this case the Nagle algorithm
commonly applies, coalescing small packets where possible to reduce
the basic header overhead. This may also mean that is less likely
that predictable changes in the sequence number will occur.
It is also noted that the SYN and FIN flags (which have to be
acknowledged) consume 1 byte of sequence space.
A.2.2.2. Acknowledgement number
Much of the information about the sequence number applies equally to
the acknowledgement number. However, there are some important
differences.
For bulk data transfers there will tend to be 1 acknowledgement for
every 2 data segments. It may be seen from this that the delta for
the acknowledgement number is roughly twice that of the sequence
number. This is not always the case and the discussion about
sequence number irregularity should be applied.
As an aside, a common implementation bug was Stretch ACKs,
(acknowledgements may be generated less frequently than every two
full-size data segments).
Since the acknowledgement number is cumulative, dropped packets in
the forward path will result in the acknowledgement number remaining
constant for a time in the reverse direction. Retransmission of a
dropped segment can then cause a substantial jump in the
acknowledgement number. These jumps in acknowledgement number are
bounded by the TCP window, just as for the jumps in sequence number.
A.2.2.3. Reserved
This field is reserved and as such might be expected to be zero.
This can no longer be assumed due to future proofing as it is only a
matter of time before a suggestion for using the flag is made.
A.2.2.4. Flags
ECN-E (Explicit Congestion Notification)
'1' to echo CE bit in IP header. Will be set in several
consecutive headers (until 'acknowledged' by CWR)
If ECN nonces get used, then there will be a 'nonce-sum' (NS)
bit in the flags, as well. Again, transparency of the reserved bits
Zhang (ed.), et al. [Page 56]
draft-ietf-rohc-tcp-00.txt
is crucial for future-proofing this compression scheme... From an
efficiency/compression standpoint, the NS bit will either be unused
[always 0] or randomly changing)
CWR (Congestion Window Reduced)
'1' to signal congestion window reduced on ECN. Will generally
be set in individual packets
ECE (Echo Congestion Experience)
If Congestion experienced is signaled on a received IP
header, this is echoed through the ECE bit in segments sent by the
receiver until acknowledged by seeing the CWR bit set.
During connection open (SYN and SYN/ACK packets) the ECN bits have
special meaning:
CWR + ECN-E are both set with SYN to indicate desire to use ECN
CWR only is set in SYN-ACK to agree ECN
(The difference in bit-patterns for the negotiation is so that it
will work with broken stacks that reflect the value of reserved
bits)
URG (Urgent Flag)
'1' to indicate urgent data [unlikely with any flag other than
ACK]
ACK (Acknowledgement)
'1' for all except the initial 'SYN' packet
PSH (Push Function Field)
generally accepted to be randomly '0' or '1'. However, may be
biased more to one value than the other (this is largely down to the
implementation of the stack)
RST (Reset Connection)
'1' to reset a connection [unlikely with any flag other than
ACK]
SYN (Synchronize Sequence Number)
'1' for the SYN/SYN-ACK only at the start of a connection
FIN (End of Data : FINished)
'1' to indicate 'no more data' [unlikely with any flag other
than ACK]
Zhang (ed.), et al. [Page 57]
draft-ietf-rohc-tcp-00.txt
A.2.2.5. Checksum
Carried as the end-to-end check for the TCP data. See [RFC 1144]
for a discussion of why this should be carried. There may be more
complex interactions with error detection and robustness that would
have to be addressed in a TCP header compression scheme. The TCP
checksum has to be considered as randomly changing.
A.2.2.6. Window
May oscillate randomly between 0 and the receiver window limit
(for the connection).
In practice, the window would not change, or may alternate between a
relatively small number of values. Particularly when closing (the
value is getting smaller), the change in window is likely to be
related to the segment size, but it not clear that this necessarily
offers any compression advantage. When the window is opening, the
effect of Silly-Window Syndrome avoidance should be remembered.
This prevents the window opening by small amounts that would
encourage the sender to clock out small segments.
When thinking about what fields might change in a sequence of TCP
segments, it should be noted that the receiver can generate 'window
update' segments in which only the window advertisement changes.
A.2.2.7. Urgent pointer
From a compression point of view, the Urgent Pointer is interesting
because it offers an example where Semantically identical
compression is not the same as Bitwise identical. This is because
the value of the Urgent Pointer is only valid if the URG flag is set.
However, from the discussion of the TCP Checksum above, it should be
realized that this enforces bitwise transparency of the scheme and
so this argument is not particularly important.
If the URG flag is set, then this pointer indicates the end of the
urgent data and so can be point to anywhere in the window. This may
be set (and changing) over several segments. Note that urgent data
is rarely used, since it is not a particularly clean way of managing
out-of-band data.
A.2.3. Options
Options occupy space at the end of the TCP header. All options are
included in the checksum. An option may begin on any byte boundary.
The TCP header must be padded with zeros to make the header length a
multiple of 32 bits.
Zhang (ed.), et al. [Page 58]
draft-ietf-rohc-tcp-00.txt
Optional header fields are identified by an option kind field.
Options 0 and 1 are exactly one octet that is their kind field. All
other options have their one octet kind field, followed by a one
octet length field, followed by length-2 octets of option data.
A.2.3.1. Options overview
Table 2 classifies the IANA known options together with their
associated RFCs, if applicable [IANA]
+------+--------+------------------------------------+-----------+
| Kind | Length | Meaning | RFC |
| |(octets)| | |
+------+--------+------------------------------------+-----------+
| 0 | - | End of Option List | [RFC793] |
| 1 | - | No-Operation | [RFC793] |
| 2 | 4 | Maximum Segment Size | [RFC793] |
| 3 | 3 | WSopt - Window Scale | [RFC1323] |
| 4 | 2 | SACK Permitted | [RFC2018] |
| 5 | N | SACK | [RFC2018] |
| 6 | 6 | Echo (obsoleted by option 8) | [RFC1072] |
| 7 | 6 | Echo Reply (obsoleted by option 8) | [RFC1072] |
| 8 | 10 | TSopt - Time Stamp Option | [RFC1323] |
| 9 | 2 | Partial Order Connection Permitted | [RFC1693] |
| 10 | 3 | Partial Order Service Profile | [RFC1693] |
| 11 | 6 | CC | [RFC1644] |
| 12 | 6 | CC.NEW | [RFC1644] |
| 13 | 6 | CC.ECHO | [RFC1644] |
| 14 | 3 | Alternate Checksum Request | [RFC1146] |
| 15 | N | Alternate Checksum Data | [RFC1146] |
| 16 | | Skeeter | |
| 17 | | Bubba | |
| 18 | 3 | Trailer Checksum Option | |
| 19 | 18 | MD5 Signature Option | [RFC2385] |
| 20 | | SCPS Capabilities | |
| 21 | | Selective Negative Acknowledgements| |
| 22 | | Record Boundaries | |
| 23 | | Corruption experienced | |
| 24 | | SNAP | |
| 25 | | Unassigned (released 12/18/00) | |
| 26 | | TCP Compression Filter | |
+------+--------+------------------------------------+-----------+
Table 2 Description of common TCP options
A.2.3.2. Option field behavior
Generally speaking all option fields have been classified as
changing. This section describes the behavior of each option
referenced within an RFC, listed by kind indicator.
Zhang (ed.), et al. [Page 59]
draft-ietf-rohc-tcp-00.txt
0. End of option list
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to the
Data Offset field. This is used at the end of all options, not the
end of each option, and need only be used if the end of the options
would not otherwise coincide with the end of the TCP header. [RFC793]
There is no data associated with this option, a compression scheme
must simply be able to encode its presence.
1. No-Operation
This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary. There
is no guarantee that senders will use this option, so receivers must
be prepared to process options even if they do not begin on a word
boundary [RFC793].
There is no data associated with this option, a compression scheme
must simply be able to encode its presence.
2. Maximum Segment Size
If this option is present, then it communicates the maximum
receive segment size at the TCP that sends this segment. This field
must only be sent in the initial connection request (i.e., in
segments with the SYN control bit set). If this option is not used,
any segment size is allowed [RFC793].
This option is very common. The segment size is a 16-bit
quantity. Theoretically this could take any value, however there
are a number of values that are more common. For example, 1460
bytes are very common for TCP/IPv4 over Ethernet. 536 bytes is the
default MSS value. This may allow for common values to be encoded
more efficiently.
3. Window Scale Option (WSopt)
This option may be sent in a SYN segment by TCP:
(1) to indicate that it is prepared to do both send and receive
window scaling, and
(2) to communicate a scale factor to be applied to its receive
window.
Zhang (ed.), et al. [Page 60]
draft-ietf-rohc-tcp-00.txt
The scale factor is encoded logarithmically, as a power of 2
(presumably to be implemented by binary shifts). Note: the window in
the SYN segment itself is never scaled [RFC1072].
This option may be sent in an initial segment (i.e., a segment
with the SYN bit on and the ACK bit off). It may also be sent in a
segment, but only if a Window Scale option was received in the
initial segment. A Window Scale option in a segment without a SYN
bit should be ignored. The Window field in a SYN segment itself is
never scaled [RFC1323]
The use of window scaling does not affect the encoding of any
other field during the life-time of the flow. It is only the
encoding of the window scaling option itself that is important.
The window scale must be between 0 and 14 (inclusive).
Generally smaller values would be expected (a window scale of 14
allows for a 1Gbyte window, which is extremely large).
4. SACK-Permitted
This option may be sent in a SYN by a TCP that has been
extended to receive (and presumably process) the SACK option once
the connection has opened [RFC2018].
There is no data in this option, all that is required is for
the presence of the option to be encoded.
5. SACK
This option is to be used to convey extended acknowledgment
information over an established connection. Specifically, it is to
be sent by a data receiver to inform the data transmitter of non-
contiguous blocks of data that have been received and queued. The
data receiver is awaiting the receipt of data in later
retransmissions to fill the gaps in sequence space between these
blocks.
At that time, the data receiver will acknowledge the data
normally by advancing the left window edge in the Acknowledgment
Number field of the TCP header. It is important to understand that
the SACK option will not change the meaning of the Acknowledgment
Number field, whose value will still specify the left window edge,
i.e., one byte beyond the last sequence number of fully-received
data [RFC2018].
If SACK has been negotiated (through an exchange of SACK-
Permitted options), then this option may occur when dropped segments
are noticed by the receiver. Because this identifies ranges of
blocks within the receiver window, this can be viewed as a base
value with a number of offsets. There can be up to 4 SACK blocks in
Zhang (ed.), et al. [Page 61]
draft-ietf-rohc-tcp-00.txt
a single option. SACK blocks may occur in a number of segments (if
there is more out-of-order data n the wire? and this will
typically extend the size of or add to the existing blocks.
Alternative proposals such as DSACK [RFC2883] do not
fundamentally change the behavior of the SACK block, from the point
of view of the information contained within it.
6. - 7. These options are generally not used in practice. It is
obsoleted by the Timestamp option. However, for transparency it is
desirable that a compression scheme be able to encode it.
8. Timestamps
This option carries two four-byte timestamp fields. The
Timestamp Value field (TSval) contains the current value of the
timestamp clock of the TCP sending the option. The Timestamp Echo
Reply field (TSecr) is only valid if the ACK bit is set in the TCP
header; if it is valid, it echoes a timestamp value that was sent by
the remote TCP in the TSval field of a Timestamps option. When TSecr
is not valid, its value must be zero. The TSecr value will generally
be from the most recent Timestamp option that was received; however,
there are exceptions that are explained below. A TCP may send the
Timestamps option (TSopt) in an initial segment (i.e., segment
containing a SYN bit and no ACK bit), and may send a TSopt in other
segments only if it received a TSopt in the initial segment for the
connection [RFC1323].
Timestamps are quite commonly used. If timestamp options are
exchanged in the connection set-up phase, then they will appear on
all subsequent segments. If this exchange does not happen, then
they will not appear for the remainder of the flow.
Because the value being carried is a timestamp, it is logical
to expect that the entire value need not be carried. There is no
obvious pattern of increments that might be expected, however.
An important reason for using the timestamp option is to allow
detection of sequence space wrap-around (Protection Against Wrapped
Sequence-number, or PAWS [RFC1323]). It is not expected that this
is serious concern on the links that TCP header compression would be
deployed on, but it is important that the integrity of this option
is maintained.
9. - 13. Those options are in practice never seen, and so the only
requirement is that the header compression scheme should be able to
encode it.
14. Alternate Checksum Request
Zhang (ed.), et al. [Page 62]
draft-ietf-rohc-tcp-00.txt
This option may be sent in a SYN segment by a TCP to indicate
that the TCP is prepared to both generate and receive checksums
based on an alternate algorithm. During communication, the alternate
checksum replaces the regular TCP checksum in the checksum field of
the TCP header. Should the alternate checksum require more than 2
octets to transmit, the checksum may either be moved into a TCP
Alternate Checksum Data Option and the checksum field of the TCP
header be sent as 0, or the data may be split between the header
field and the option. Alternate checksums are computed over the same
data as the regular TCP checksum [RFC1146]
This option is in practice never seen, and so the only
requirement is that the header compression scheme should be able to
encode it. It would only occur in connection set-up (SYN) packets.
Even if this option were used, it would not affect the handling
of the checksum, since this should be carried transparently in any
case.
15. Alternate Checksum Data
This field is used only when the alternate checksum that is
negotiated is longer than 16 bits. These checksums will not fit in
the checksum field of the TCP header and thus at least part of them
must be put in an option. Whether the checksum is split between the
checksum field in the TCP header and the option or the entire
checksum is placed in the option is determined on a checksum by
checksum basis. The length of this option will depend on the choice
of alternate checksum algorithm for this connection [RFC1146].
If an alternative checksum were negotiated in the connection
set-up, then this option may appear on all subsequent packets (if
needed to carry the checksum data). However, this option is in
practice never seen, and so the only requirement is that the header
compression scheme should be able to encode it.
16. - 18. Are non-RFC references and are not considered in this
document.
19. MD5 Digest
Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by applying
the MD5 algorithm to a concatenated block of data.
Upon receiving a signed segment, the receiver must validate it
by calculating its own digest from the same data (using its own key)
and comparing the two digest. A failing comparison must result in
the segment being dropped and must not produce any response back to
Zhang (ed.), et al. [Page 63]
draft-ietf-rohc-tcp-00.txt
the sender. Logging the failure is probably advisable.
Unlike other TCP extensions (e.g., the Window Scale option
[RFC1323]), the absence of the option in the SYN, ACK segment must
not cause the sender to disable its sending of signatures. This
negotiation is typically done to prevent some TCP implementations
from misbehaving upon receiving options in non-SYN segments. This is
not a problem for this option, since the SYN, ACK sent during
connection negotiation will not be signed and will thus be ignored.
The connection will never be made, and non-SYN segments with options
will never be sent. More importantly, the sending of signatures must
be under the complete control of the application, not at the mercy
of the remote host not understanding the option.
MD5 digest information should, like any cryptographically
secure data, be incompressible. Therefore the compression scheme
must simply transparently carry this option, if it occurs.
20. - 26. Are non-RFC references and are not considered in this
document.
5. Other observations
5.1. Implicit acknowledgements
There may be a small number of cues for 'implicit acknowledgements'
in a TCP flow. Even if the compressor only sees the data transfer
direction, for example, then seeing a packet without the SYN flag
set implies that the SYN packet has been received.
It may be that there are other such cues that may be used in certain
circumstances to improve compression efficiency.
5.2. Shared data
At the risk of drifting into solution space, it can be seen that
there are two distinct deployments - one where the forward and
reverse paths share a link and one where they do not.
In the former case it may be the case that a compressor and
decompressor could be co-located. It may then be possible for the
compressor and decompressor at each end of the link to exchange
information. This could lead to possible optimizations.
For example, acknowledgement numbers are generally taken from the
sequence numbers in the opposite direction. Since an
acknowledgement cannot be generated for a packet that has not passed
across the link, this offers an efficient way of encoding
acknowledgements.
Zhang (ed.), et al. [Page 64]
draft-ietf-rohc-tcp-00.txt
5.2.1. TCP header overhead
For a TCP bulk data-transfer the overhead is not that onerous,
particularly compared to the typical RTP voice case. Although
spectral efficiency is clearly an important goal, it does not seem
critical to extract every last bit of compression gain.
However, in the acknowledgement direction (i.e. for 'pure'
acknowledgement headers) the overhead could be said to be infinite
(since there is no data being carried). This is why optimizations
for the acknowledgement path may be considered useful.
5.3. Short-lived flows
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. As a particular example, consider web
browsing (this is more the case with HTTP/1.0 than HTTP/1.1).
When a connection closes, it is either the last connection between
that pair of hosts or it is likely that another connection will open
within a relatively short space of time. In this case, the IP
header part of the context will probably be almost identical.
Certain aspects of the TCP context may also be similar.
For example, it may be that one of the port numbers will stay the
same (the service port) and the other will change by a small amount
relative to the just-closed connection (the ephemeral port). Also,
unless [RFC1948] ISN selection is implemented, the initial sequence
number for the SYN packet may be 'close' to the sequence number
range used for the closed connection.
Thus, support for sub-context sharing, or initializing one context
from another offers useful optimizations for a sequence of short-
lived connections.
It is noted that although TCP is connection oriented, it is hard to
tell at a middle-box whether or not a TCP flow has finished. For
example, even in the 'bi-directional' link case, seeing a FIN and
the ACK of the FIN at the compressor/decompressor does not mean that
the FIN cannot be retransmitted. Thus it may be more useful to
think about initializing a new context from an existing one, rather
than re-using an existing one.
Zhang (ed.), et al. [Page 65]
