draft-ietf-rohc-tcp-field-behavior-03.txt   draft-ietf-rohc-tcp-field-behavior-04.txt 
Network Working Group M. West Network Working Group M. West
Internet-Draft S. McCann Internet-Draft S. McCann
Expires: February 16, 2005 Siemens/Roke Manor Research Expires: April 25, 2005 Siemens/Roke Manor Research
August 18, 2004 October 25, 2004
TCP/IP Field Behavior TCP/IP Field Behavior
draft-ietf-rohc-tcp-field-behavior-03.txt draft-ietf-rohc-tcp-field-behavior-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 16, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo describes TCP/IP field behavior in the context of header This memo describes TCP/IP field behavior in the context of header
compression. compression.
Header compression is possible thanks to the fact that most header Header compression is possible thanks to the fact that most header
fields do not vary randomly from packet to packet. Many of the fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less fields exhibit static behavior or change in a more or less
predictable way. When designing a header compression scheme, it is predictable way. When designing a header compression scheme, it is
of fundamental importance to understand the behavior of the fields in of fundamental importance to understand the behavior of the fields in
detail. An example of this analysis can be seen in RFC 3095 [34]. detail. An example of this analysis can be seen in RFC 3095 [36].
This memo performs a similar role for the compression of TCP/IP. This memo performs a similar role for the compression of TCP/IP
headers.
Change History Change History
-00 : Initial version -00 : Initial version
-01 : Corrections and clarifications from review comments plus -01 : Corrections and clarifications from review comments plus
analysis of shareable fields analysis of shareable fields
-02 : Re-write shareable field section + incorporate Gorry's -02 : Re-write shareable field section + incorporate Gorry's
comments comments
-03 : Correct references -03 : Correct references
-04 : Incorporate WGLC comments
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. General classification . . . . . . . . . . . . . . . . . . . . 5
3. General classification . . . . . . . . . . . . . . . . . . . . 5 2.1 IP header fields . . . . . . . . . . . . . . . . . . . . . 5
3.1 IP header fields . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 IPv6 header fields . . . . . . . . . . . . . . . . . . 6
3.1.1 IPv6 header fields . . . . . . . . . . . . . . . . . . 6 2.1.2 IPv4 header fields . . . . . . . . . . . . . . . . . . 7
3.1.2 IPv4 header fields . . . . . . . . . . . . . . . . . . 7 2.2 TCP header fields . . . . . . . . . . . . . . . . . . . . 10
3.2 TCP header fields . . . . . . . . . . . . . . . . . . . . 10 2.3 Summary for IP/TCP . . . . . . . . . . . . . . . . . . . . 11
3.3 Summary for IP/TCP . . . . . . . . . . . . . . . . . . . . 11 3. Classification of replicable header fields . . . . . . . . . . 12
4. Classification of replicable header fields . . . . . . . . . . 11 3.1 IPv4 Header (inner and/or outer) . . . . . . . . . . . . . 13
4.1 IPv4 Header (inner and/or outer) . . . . . . . . . . . . . 12 3.2 IPv6 Header (inner and/or outer) . . . . . . . . . . . . . 14
4.2 IPv6 Header (inner and/or outer) . . . . . . . . . . . . . 13 3.3 TCP Header . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 TCP Header . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4 TCP Options . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 TCP Options . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Summary of replication . . . . . . . . . . . . . . . . . . 16
4.5 Summary of replication . . . . . . . . . . . . . . . . . . 15 4. Analysis of change patterns of header fields . . . . . . . . . 17
5. Analysis of change patterns of header fields . . . . . . . . . 15 4.1 IP header . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 IP header . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 IP Traffic-Class / Type-Of-Service (TOS) . . . . . . . 19
5.1.1 IP Traffic-Class / Type-Of-Service (TOS) . . . . . . . 18 4.1.2 ECN Flags . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 ECN Flags . . . . . . . . . . . . . . . . . . . . . . 18 4.1.3 IP Identification . . . . . . . . . . . . . . . . . . 20
5.1.3 IP Identification . . . . . . . . . . . . . . . . . . 19 4.1.4 Don't Fragment (DF) flag . . . . . . . . . . . . . . . 22
5.1.4 Don't Fragment (DF) flag . . . . . . . . . . . . . . . 21 4.1.5 IP Hop-Limit / Time-To-Live (TTL) . . . . . . . . . . 22
5.1.5 IP Hop-Limit / Time-To-Live (TTL) . . . . . . . . . . 21 4.2 TCP header . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 TCP header . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 Sequence number . . . . . . . . . . . . . . . . . . . 23
5.2.1 Sequence number . . . . . . . . . . . . . . . . . . . 22 4.2.2 Acknowledgement number . . . . . . . . . . . . . . . . 24
5.2.2 Acknowledgement number . . . . . . . . . . . . . . . . 23 4.2.3 Reserved . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.3 Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.5 Checksum . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.5 Checksum . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.6 Window . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.6 Window . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.7 Urgent pointer . . . . . . . . . . . . . . . . . . . . 26
5.2.7 Urgent pointer . . . . . . . . . . . . . . . . . . . . 25 4.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1 Options overview . . . . . . . . . . . . . . . . . . . 27
5.3.1 Options overview . . . . . . . . . . . . . . . . . . . 26 4.3.2 Option field behavior . . . . . . . . . . . . . . . . 28
5.3.2 Option field behavior . . . . . . . . . . . . . . . . 27 5. Other observations . . . . . . . . . . . . . . . . . . . . . . 34
6. Other observations . . . . . . . . . . . . . . . . . . . . . . 33 5.1 Implicit acknowledgements . . . . . . . . . . . . . . . . 34
6.1 Implicit acknowledgements . . . . . . . . . . . . . . . . 33 5.2 Shared data . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Shared data . . . . . . . . . . . . . . . . . . . . . . . 33 5.3 TCP header overhead . . . . . . . . . . . . . . . . . . . 35
6.3 TCP header overhead . . . . . . . . . . . . . . . . . . . 33 5.4 Field independence and packet behavior . . . . . . . . . . 35
6.4 Field independence and packet behavior . . . . . . . . . . 34 5.5 Short-lived flows . . . . . . . . . . . . . . . . . . . . 36
6.5 Short-lived flows . . . . . . . . . . . . . . . . . . . . 34 5.6 Master Sequence Number . . . . . . . . . . . . . . . . . . 36
6.6 Master Sequence Number . . . . . . . . . . . . . . . . . . 35 5.7 Size constraint for TCP options . . . . . . . . . . . . . 37
6.7 Size constraint for TCP options . . . . . . . . . . . . . 35 6. Security considerations . . . . . . . . . . . . . . . . . . . 37
7. Security considerations . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 38
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 8.2 Informative References . . . . . . . . . . . . . . . . . . . 39
9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . 41
1. Introduction 1. Introduction
This document describes TCP/IP field behavior, as it is essential to This document describes the format of the TCP/IP header and the
understand this before correct assumptions about header compression header field behavior (how fields vary within a TCP flow). The
can be made. description is presented in the context of its application to header
compression.
Since the IP header does exhibit some slightly different behavior Since the IP header does exhibit slightly different behavior from
from that previously presented in RFC 3095 [34] for the RTP case, it that previously presented in RFC 3095 [36] for UDP and RTP, it is
is also included in this document. also included in this document.
It is intentional that much of the classification text from RFC 3095 It is intentional that much of the classification text from RFC 3095
[34] has been borrowed. This is for easier reading rather than [36] has been borrowed. This is for easier reading rather than
inserting many references to that document. inserting many references to that document.
Again based on the format presented in RFC 3095 [34] TCP/IP header Again based on the format presented in RFC 3095 [36] TCP/IP header
fields are classified and analyzed in two steps. First, we have a fields are classified and analyzed in two steps. First, we have a
general classification in Section 3 where the fields are classified general classification in Section 2 where the fields are classified
on the basis of stable knowledge and assumptions. The general on the basis of stable knowledge and assumptions. The general
classification does not take into account the change characteristics classification does not take into account the change characteristics
of changing fields because those will vary more or less depending on of changing fields because those will vary more or less depending on
the implementation and on the application used. Section 4 considers the implementation and on the application used. Section 3 considers
how field values can be used to optimize short-lived flows. A less how field values can be used to optimize short-lived flows. A more
stable but more detailed analysis of the change characteristics is detailed analysis of the change characteristics is then done in
then done in Section 5. Finally, Section 6 summarizes with Section 4. Finally, Section 5 summarizes with conclusions about how
conclusions about how the various header fields should be handled by the various header fields should be handled by the header compression
the header compression scheme to optimize compression and scheme to optimize compression and functionality.
functionality.
A general question raised by this analysis is that of what 'baseline' A general question raised by this analysis is that of what 'baseline'
definition of all possible TCP/IP implementations is to be definition of all possible TCP/IP implementations is to be
considered? For the purposes of this document, a relatively considered? This review is based on an analysis of currently
up-to-date (as of the time of writing) implementation is considered, deployed TCP implementations supporting mechansims standardised by
with a view to ensuring compatibility with legacy implementations. the IETF.
The general requirement for transparency is also seen to be more The general requirement for transparency is also seen to be more
interesting. A number of recent proposals for extensions to TCP make interesting. A number of recent proposals for extensions to TCP make
use of some of the previously 'reserved' bits. It is therefore clear use of some of the previously 'reserved' bits in the TCP packet
that a 'reserved' bit cannot be taken to have a guaranteed zero header. It is therefore clear that a 'reserved' bit cannot be taken
value, but may change. Ideally, this should be accommodated by the to have a guaranteed zero value, but may change. Ideally, this
compression profile. should be accommodated by the compression profile.
It is unclear exactly how reserved bits should be handled, given that
the possible future uses cannot be predicted. It is accepted that if
these currently reserved bits were used, then efficiency may be
reduced. However, the compression scheme should still offer a useful
solution.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", There are a number of reserved bits which are available for future
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this expansion. Any treatment of field behavior cannot predict the future
document are to be interpreted as described in RFC 2119 [23]. use of such bits, but we expect that they will be used at some point.
Given this, a compression scheme can optimise for the current
situation but should be capable of supporting any arbitrary usage of
the reserved bits. However, it is impossible to optimise for usage
patterns that have yet to be defined.
3. General classification 2. General classification
The following definitions (and some text) are copied from RFC 3095 The following definitions (and some text) are copied from RFC 3095
[34] Appendix A. Differences between IP field behavior between RFC [36] Appendix A. Differences between IP field behavior between RFC
3095 [34] (i.e. IP/UDP/RTP behavior for audio and video 3095 [36] (i.e. IP/UDP/RTP behavior for audio and video
applications) and this document have been identified. applications) and this document have been identified.
For the following, we define "session" to mean a TCP packet stream,
being a series of packets with the same IP addresses and port
numbers. A packet flow is defined by certain fields (see STATIC-DEF
below) and may be considered as a subset of a session. See [36] for
a fuller discussion of separation of sessions into streams of packets
for header compression.
At a general level, the header fields are separated into 5 classes: At a general level, the header fields are separated into 5 classes:
o INFERRED o INFERRED
These fields contain values that can be inferred from other These fields contain values that can be inferred from other
values, for example the size of the frame carrying the packet, values, for example the size of the frame carrying the packet,
and thus do not have to be handled at all by the compression and thus do not have to be handled at all by the compression
scheme. scheme.
o STATIC o STATIC
These fields are expected to be constant throughout the These fields are expected to be constant throughout the
skipping to change at page 5, line 49 skipping to change at page 5, line 50
o CHANGING o CHANGING
These fields are expected to vary in some way: randomly, within These fields are expected to vary in some way: randomly, within
a limited value set or range, or in some other manner. 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 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 one of these classes. For all fields except those classified as
CHANGING, the motives for the classification are also stated. In CHANGING, the motives for the classification are also stated. In
section 4, CHANGING fields are further examined and classified on the section 4, CHANGING fields are further examined and classified on the
basis of their expected change behavior. basis of their expected change behavior.
3.1 IP header fields 2.1 IP header fields
3.1.1 IPv6 header fields 2.1.1 IPv6 header fields
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Field | Size (bits) | Class | | Field | Size (bits) | Class |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Version | 4 | STATIC | | Version | 4 | STATIC |
| DSCP* | 6 | CHANGING | | DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING | | ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING | | CE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF | | Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED | | Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC | | Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING | | Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF | | Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF | | Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
Figure 1 Figure 1: IPv6 header fields
* differs from RFC 3095 [34] * differs from RFC 3095 [36]
[The DSCP, ECT and CE flags were amalgamated into the Traffic Class [The DSCP, ECT and CE flags were amalgamated into the Traffic Class
octet in RFC 3095.] octet in RFC 3095.]
o Version o Version
The version field states which IP version is used. Packets The version field states which IP version is used. Packets
with different values in this field must be handled by with different values in this field must be handled by
different IP stacks. All packets of a packet stream must different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is therefore be of the same IP version. Accordingly, the field is
classified as STATIC. classified as STATIC.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
length) is expected to be provided by the link layer. The length) is expected to be provided by the link layer. The
field is therefore classified as INFERRED. field is therefore classified as INFERRED.
o Next Header o Next Header
This field will usually have the same value in all packets of a This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header. packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes present and sometimes Only when extension headers are sometimes present and sometimes
not, will the field change its value during the lifetime of the not, will the field change its value during the lifetime of the
stream. The field is therefore classified as STATIC. stream. The field is therefore classified as STATIC.
The classification of STATIC is inherited from RFC 3095 [34]. The classification of STATIC is inherited from RFC 3095 [36].
However, it should be pointed out that the next header field is However, it should be pointed out that the next header field is
actually determined by the type of the following header. Thus, actually determined by the type of the following header. Thus,
it might be more appropriate to view this as an inference, it might be more appropriate to view this as an inference,
although this depends upon the specific implementation of the although this depends upon the specific implementation of the
compression scheme. compression scheme.
o Source and Destination addresses o Source and Destination addresses
These fields are part of the definition of a stream and must These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF. therefore classified as STATIC-DEF.
This might be considered as a slightly simplistic view. This might be considered as a slightly simplistic view. In
However for now the IP addresses are associated with the this document, the IP addresses are associated with the
transport layer connection. More complex flow-separation transport layer connection and assumed to be part of the
could, of course, be considered. definition of a flow. More complex flow-separation could, of
course, be considered (see also RFC 3095 [36] for more
discussion of this issue). Where tunneling is being performed,
then the use of the IP addresses in outer tunnel headers is
also assumed to be STATIC-DEF.
Total size of the fields in each class: Total size of the fields in each class:
+--------------+--------------+ +--------------+--------------+
| Class | Size (octets)| | Class | Size (octets)|
+--------------+--------------+ +--------------+--------------+
| INFERRED | 2 | | INFERRED | 2 |
| STATIC | 1.5 | | STATIC | 1.5 |
| STATIC-DEF | 34.5 | | STATIC-DEF | 34.5 |
| STATIC-KNOWN | 0 | | STATIC-KNOWN | 0 |
| CHANGING | 2 | | CHANGING | 2 |
+--------------+--------------+ +--------------+--------------+
Figure 2 Figure 2: Field sizes
3.1.2 IPv4 header fields 2.1.2 IPv4 header fields
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Field | Size (bits) | Class | | Field | Size (bits) | Class |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Version | 4 | STATIC | | Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN | | Header Length | 4 | STATIC-KNOWN |
| DSCP* | 6 | CHANGING | | DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING | | ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING | | CE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED | | Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING | | Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING | | Reserved flag* | 1 | CHANGING |
| Don't Fragment flag*| 1 | CHANGING | | Don't Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN | | More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN | | Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING | | Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC | | Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED | | Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF | | Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF | | Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
Figure 3 Figure 3: IPv4 header fields
* differs from RFC 3095 [34] * differs from RFC 3095 [36]
[The DSCP, ECT and CE flags were amalgamated into the TOS octet in [The DSCP, ECT and CE flags were amalgamated into the TOS octet in
RFC 3095. RFC 3095.
The DF flag behavior is considered later. The DF flag behavior is considered later.
The reserved field is discussed below.] The reserved field is discussed below.]
o Version o Version
The version field states which IP version is used. Packets The version field states which IP version is used. Packets
with different values in this field must be handled by with different values in this field must be handled by
different IP stacks. All packets of a packet stream must different IP stacks. All packets of a packet stream must
therefore be of the same IP version. Accordingly, the field is therefore be of the same IP version. Accordingly, the field is
skipping to change at page 8, line 49 skipping to change at page 8, line 49
o Header Length o Header Length
As long as no options are present in the IP header, the header As long as no options are present in the IP header, the header
length is constant and well known. If there are options, the length is constant and well known. If there are options, the
fields would be STATIC, but it is assumed here that there are fields would be STATIC, but it is assumed here that there are
no options. The field is therefore classified as STATIC-KNOWN. no options. The field is therefore classified as STATIC-KNOWN.
o Packet Length o Packet Length
Information about packet length is expected to be provided by Information about packet length is expected to be provided by
the link layer. The field is therefore classified as INFERRED. the link layer. The field is therefore classified as INFERRED.
o Flags o Flags
The Reserved flag must be set to zero, as defined in RFC 791 The Reserved flag must be set to zero, as defined in RFC 791
[1]. In RFC 3095 [34] the field is therefore classified as [1]. In RFC 3095 [36] the field is therefore classified as
STATIC-KNOWN. However, it is expected that reserved fields may STATIC-KNOWN. However, it is expected that reserved fields may
be used at some future point. It appears unwise to select an be used at some future point. It is undesirable to select an
encoding that would preclude the use of a compression profile encoding that would preclude the use of a compression profile
for a future change in the use of reserved fields. For this for a future change in the use of reserved fields. For this
reason the alternative encoding of CHANGING is suggested. It reason the alternative encoding of CHANGING is used. (A
would also be possible to have more than one compression compression profile can, of course, still optimise for the
profile, in one of which this field was considered to be current situation, where the field value is known to be 0).
STATIC-KNOWN.
The More Fragments (MF) flag is expected to be zero because The More Fragments (MF) flag is expected to be zero because
fragmentation is generally not expected. As discussed in the fragmentation is, ideally, not expected. However, it is also
RTP case, only the first fragment will contain the transport understood that some scenarios (for example some tunnelling
layer protocol header; subsequent fragments would have to be architectures) do cause fragmentation. In general, though,
compressed with a different profile. In terms of the effect of fragmentation is not expected to be common in the Internet due
header overhead, if fragmentation does occur then the first to a combination of initial MSS negotiation and subsequent use
fragment, by definition, should be relatively large, minimizing of path-MTU discovery. RFC 3095 [36] points out that, for RTP,
the header overhead. In the case of TCP, fragmentation should only the first fragment will contain the transport layer
not be common due to a combination of initial MSS negotiation protocol header; subsequent fragments would have to be
and subsequent use of path-MTU discovery. The More Fragments compressed with a different profile. This is also obviously
flag is therefore classified as STATIC-KNOWN. However, a the case for TCP. If fragmentation were to occur then the
profile could accept that this flag may be set in order to cope first fragment, by definition, will be relatively large,
with fragmentation. minimizing the header overhead. Subsequent fragments would be
compressed with another profile. It is therefore considered
undesirable to optimise for fragmentation in performing header
compression. The More Fragments flag is therefore classified
as STATIC-KNOWN.
o Fragment Offset o Fragment Offset
Under the assumption that no fragmentation occurs, the fragment Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as offset is always zero. The field is therefore classified as
STATIC-KNOWN. Even if fragmentation were to be further STATIC-KNOWN. Even if fragmentation were to be further
considered, then only the first fragment would contain the TCP considered, then only the first fragment would contain the TCP
header and the fragment offset of this packet would still be header and the fragment offset of this packet would still be
zero. zero.
o Protocol o Protocol
This field will usually have the same value in all packets of a This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header. packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes present and sometimes Only where the sequence of headers changes (e.g. an extension
not, will the field change its value during the lifetime of a header is inserted or deleted; or a tunnel header is added or
stream. The field is therefore classified as STATIC. removed), will the field change its value. The field is
therefore classified as STATIC. Whether or not such a change
would cause the sequence of packets to be treated as a new flow
(for header compression) is an issue for profile design. ROHC
profiles must be able to cope with extension headers and
tunnelling, but the choice of strategy is outside the scope of
this document.
o Header Checksum o Header Checksum
The header checksum protects individual hops from processing a The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional compressed away, there is no point in having this additional
checksum; instead it can be regenerated at the decompressor checksum; instead it can be regenerated at the decompressor
side. The field is therefore classified as INFERRED. side. The field is therefore classified as INFERRED.
We note that the TCP checksum does not protect the whole TCP/IP We note that the TCP checksum does not protect the whole TCP/IP
header, but only the TCP pseudo-header (and the payload). header, but only the TCP pseudo-header (and the payload).
Compare this with ROHC [34], which uses a CRC to verify the Compare this with ROHC [36], which uses a CRC to verify the
uncompressed header. Given the need to validate the complete uncompressed header. Given the need to validate the complete
TCP/IP header; the cost of computing the TCP checksum over the TCP/IP header; the cost of computing the TCP checksum over the
entire payload; and known weaknesses in the TCP checksum [40], entire payload; and known weaknesses in the TCP checksum [41],
an additional check is necessary. Therefore, it is expected an additional check is necessary. Therefore, it is highly
than some additional checksum (such as a CRC) will be used to desirable that some additional checksum (such as a CRC) will be
validate correct decompression. used to validate correct decompression.
o Source and Destination addresses o Source and Destination addresses
These fields are part of the definition of a stream and must These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF. therefore classified as STATIC-DEF.
Total size of the fields in each class: Total size of the fields in each class:
+--------------+--------------+ +--------------+--------------+
| Class | Size (octets)| | Class | Size (octets)|
+--------------+--------------+ +--------------+--------------+
| INFERRED | 4 | | INFERRED | 4 |
| STATIC* | 1.5 | | STATIC* | 1.5 |
| STATIC-DEF | 8 | | STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 | | STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 | | CHANGING* | 4.25 |
+--------------+--------------+ +--------------+--------------+
Figure 4 Figure 4: Field sizes
* differs from RFC 3095 [34]
3.2 TCP header fields * differs from RFC 3095 [36]
2.2 TCP header fields
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Field | Size (bits) | Class | | Field | Size (bits) | Class |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
| Source Port | 16 | STATIC-DEF | | Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | | Destination Port | 16 | STATIC-DEF |
| Sequence Number | 32 | CHANGING | | Sequence Number | 32 | CHANGING |
| Acknowledgement Num | 32 | CHANGING | | Acknowledgement Num | 32 | CHANGING |
| Data Offset | 4 | INFERRED | | Data Offset | 4 | INFERRED |
| Reserved | 4 | CHANGING | | Reserved | 4 | CHANGING |
| CWR flag | 1 | CHANGING | | CWR flag | 1 | CHANGING |
skipping to change at page 11, line 4 skipping to change at page 11, line 26
| ACK flag | 1 | CHANGING | | ACK flag | 1 | CHANGING |
| PSH flag | 1 | CHANGING | | PSH flag | 1 | CHANGING |
| RST flag | 1 | CHANGING | | RST flag | 1 | CHANGING |
| SYN flag | 1 | CHANGING | | SYN flag | 1 | CHANGING |
| FIN flag | 1 | CHANGING | | FIN flag | 1 | CHANGING |
| Window | 16 | CHANGING | | Window | 16 | CHANGING |
| Checksum | 16 | CHANGING | | Checksum | 16 | CHANGING |
| Urgent Pointer | 16 | CHANGING | | Urgent Pointer | 16 | CHANGING |
| Options | 0(-352) | CHANGING | | Options | 0(-352) | CHANGING |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
Figure 5
Figure 5: TCP header fields
o Source and Destination ports o Source and Destination ports
These fields are part of the definition of a stream and must These fields are part of the definition of a stream and must
thus be constant for all packets in the stream. The fields are thus be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF. therefore classified as STATIC-DEF.
o Data Offset o Data Offset
The number of 4 octet words in the TCP header, thus indicating 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. 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 It can be re-constructed from the length of any options and
thus it is not necessary to carry this explicitly. The field thus it is not necessary to carry this explicitly. The field
is therefore classified as INFERRED. is therefore classified as INFERRED.
3.3 Summary for IP/TCP 2.3 Summary for IP/TCP
Summarizing this for IP/TCP one obtains Summarizing this for IP/TCP one obtains
+----------------+----------------+----------------+ +----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) | | Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+ +----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits | | INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits | | STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 | | STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits | | STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 4 bits | 19 + 6 bits | | CHANGING | 17 + 4 bits | 19 + 6 bits |
+----------------+----------------+----------------+ +----------------+----------------+----------------+
| Totals | 60 | 40 | | Totals | 60 | 40 |
skipping to change at page 11, line 33 skipping to change at page 12, line 16
+----------------+----------------+----------------+ +----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits | | INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits | | STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 | | STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits | | STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 4 bits | 19 + 6 bits | | CHANGING | 17 + 4 bits | 19 + 6 bits |
+----------------+----------------+----------------+ +----------------+----------------+----------------+
| Totals | 60 | 40 | | Totals | 60 | 40 |
+----------------+----------------+----------------+ +----------------+----------------+----------------+
Figure 6 Figure 6: Overall field sizes
(excludes options, which are all classified as CHANGING) (excludes options, which are all classified as CHANGING)
4. Classification of replicable header fields 3. Classification of replicable header fields
Where multiple flows either overlap in time or occur sequentially Where multiple flows either overlap in time or occur sequentially
within a short space of time there can be a great deal of similarity within a short space of time there can be a great deal of similarity
in header field values. Such commonality of field values is in header field values. Such commonality of field values is
reflected in the compression context. Thus, it should be possible to reflected in the compression context. Thus, it should be possible to
utilise links between fields across different flows to improve the utilise commonality between fields across different flows to improve
compression ratio. In order to do this, it is important to the compression ratio. In order to do this, it is important to
understand the 'replicable' characteristics of the various header understand the 'replicable' characteristics of the various header
fields. fields.
The key concept is that of 'replication', where an existing context The key concept is that of 'replication', where an existing context
is used as a baseline and replicated to initialise a new context. is used as a baseline and replicated to initialise a new context.
Those fields that are the same are then automatically initialised in Those fields that are the same are then automatically initialised in
the new context. Those that have changed will be updated or the new context. Those that have changed will be updated or
overwritten with values from the initialisation packet that triggered overwritten with values from the initialisation packet that triggered
the replication. This section considers the commonality between the replication. This section considers the commonality between
fields in different flows. fields in different flows.
skipping to change at page 12, line 20 skipping to change at page 13, line 4
(rather than just field values) and so compressor created fields that (rather than just field values) and so compressor created fields that
are part of the context may also be included. These, of course, are are part of the context may also be included. These, of course, are
dependent upon the nature of the compression protocol (ROHC profile) dependent upon the nature of the compression protocol (ROHC profile)
being applied. being applied.
A brief analysis of the relationship of TCP/IP fields among A brief analysis of the relationship of TCP/IP fields among
'replicable' packet streams follows. 'replicable' packet streams follows.
'N/A' -- The field need not be considered in the replication 'N/A' -- The field need not be considered in the replication
process as it is inferred or known 'a priori' (and, process as it is inferred or known 'a priori' (and,
therefore, does not appear in the context). therefore, does not appear in the context).
'No' -- The field cannot be replicated since its change pattern 'No' -- The field cannot be replicated since its change pattern
between two packet flows is uncorrelated. between two packet flows is uncorrelated.
'Yes' -- The field may be replicated. This does not guarantee 'Yes' -- The field may be replicated. This does not guarantee
that the field value will be the same across two candidate that the field value will be the same across two candidate
streams, only that it might be possible to exploit streams, only that it might be possible to exploit
replication to increase the compression ratio. Specific replication to increase the compression ratio. Specific
encoding methods can be used to improve the compression encoding methods can be used to improve the compression
efficiency. efficiency.
4.1 IPv4 Header (inner and/or outer) 3.1 IPv4 Header (inner and/or outer)
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Field | Class | Replicable | | Field | Class | Replicable |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Version | STATIC | N/A | | Version | STATIC | N/A |
| Header Length | STATIC-KNOWN | N/A | | Header Length | STATIC-KNOWN | N/A |
| DSCP | CHANGING | No (1) | | DSCP | ALTERNATING | No (1) |
| ECT flag | CHANGING | No (2) | | ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) | | CE flag | CHANGING | No (2) |
| Packet Length | INFERRED | N/A | | Packet Length | INFERRED | N/A |
| Identification | CHANGING | Yes (3) | | Identification | CHANGING | Yes (3) |
| Reserved flag | CHANGING | No (4) | | Reserved flag | CHANGING | No (4) |
| Don't Fragment flag | CHANGING | No | | Don't Fragment flag | CHANGING | Yes (5) |
| More Fragments flag | STATIC-KNOWN | N/A | | More Fragments flag | STATIC-KNOWN | N/A |
| Fragment Offset | STATIC-KNOWN | N/A | | Fragment Offset | STATIC-KNOWN | N/A |
| Time To Live | CHANGING | Yes | | Time To Live | CHANGING | Yes |
| Protocol | STATIC | N/A | | Protocol | STATIC | N/A |
| Header Checksum | INFERRED | N/A | | Header Checksum | INFERRED | N/A |
| Source Address | STATIC-DEF | Yes | | Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes | | Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
Figure 7: IPv4 header
(1) The DSCP is marked based on the application's requirements. If (1) The DSCP is marked based on the application's requirements. If
it can be assumed that replicable connections often carry the same it can be assumed that replicable connections belong to the same
type of traffic, the DSCP may be regarded as replicable. However, diffserv class, then it is likely that the DSCP will be
issues such as re-marking will need to be taken into account. replicable. The DSCP can be set not only by the sender but by any
packet marker. Thus, a flow may have a number of DSCP values at
different points in the network. However, header compression
operates on a point-to-point link and so would expect to see a
relatively stable value. If re-marking is being done based on the
state of a meter) then the value may change mid-flow. Overall,
though, we expect supporting replication of the DSCP to be useful
for header compression.
(2) It is not possible for the ECN bits to be replicated (note that (2) It is not possible for the ECN bits to be replicated (note that
use of the ECN nonce scheme [38] is anticipated). However, it use of the ECN nonce scheme [20] is anticipated). However, it
seems likely that all TCP flows between ECN-capable hosts will use seems likely that all TCP flows between ECN-capable hosts will use
ECN, the use (or not) of ECN for flows between the same end-points ECN, the use (or not) of ECN for flows between the same end-points
might be considered replicable. See also note (4). might be considered replicable. See also note (4).
(3) The replicable context for this field includes the IP-ID, NBO, (3) The replicable context for this field includes the IP-ID, NBO,
and RND flags (as described in ROHC RTP). This highlights that and RND flags (as described in ROHC RTP). This highlights that
the replication is of the context, rather than just the header the replication is of the context, rather than just the header
field values and, as such, needs to be considered based on the field values and, as such, needs to be considered based on the
exact nature of compression applied to each field. exact nature of compression applied to each field.
(4) Since the possible future behavior of the 'Reserved Flag' cannot (4) Since the possible future behavior of the 'Reserved Flag' cannot
be predicted, it is not considered as replicable. However, it be predicted, it is not considered as replicable. However, it
might be expected that the behavior of the reserved flag between might be expected that the behavior of the reserved flag between
the same end-points will be similar. In this case, any selection the same end-points will be similar. In this case, any selection
of packet formats (for example) based on this behavior might carry of packet formats (for example) based on this behavior might carry
across to the new flow. In the case of packet formats, this can across to the new flow. In the case of packet formats, this can
probably be considered as a compressor-local decision. probably be considered as a compressor-local decision.
(5) In theory, the DF bit may be replicable. However, this is not
guaranteed and, in practice, it is unlikely to be useful to do
this. From the perspective of header compression, having to
indicate whether or not a 1-bit flag should be replicated or
specified explicitly is likely to require more bits than simply
conveying the value of the flag. We do not rule out DF
replication.
4.2 IPv6 Header (inner and/or outer) 3.2 IPv6 Header (inner and/or outer)
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Field | Class | Replicable | | Field | Class | Replicable |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Version | STATIC | N/A | | Version | STATIC | N/A |
| Traffic Class | CHANGING | Yes (1) | | Traffic Class | CHANGING | Yes (1) |
| ECT flag | CHANGING | No (2) | | ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) | | CE flag | CHANGING | No (2) |
| Flow Label | STATIC-DEF | N/A | | Flow Label | STATIC-DEF | N/A |
| Payload Length | INFERRED | N/A | | Payload Length | INFERRED | N/A |
| Next Header | STATIC | N/A | | Next Header | STATIC | N/A |
| Hop Limit | CHANGING | Yes | | Hop Limit | CHANGING | Yes |
| Source Address | STATIC-DEF | Yes | | Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes | | Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
Figure 8: IPv6 header
(1) See comment about DSCP field for IPv4, above. (1) See comment about DSCP field for IPv4, above.
(2) See comment about ECT and CE flags for IPv4, above. (2) See comment about ECT and CE flags for IPv4, above.
4.3 TCP Header 3.3 TCP Header
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Field | Class | Replicable | | Field | Class | Replicable |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
| Source Port | STATIC-DEF | Yes (1) | | Source Port | STATIC-DEF | Yes (1) |
| Destination Port | STATIC-DEF | Yes (1) | | Destination Port | STATIC-DEF | Yes (1) |
| Sequence Number | CHANGING | No (2) | | Sequence Number | CHANGING | No (2) |
| Acknowledgement Number| CHANGING | No | | Acknowledgement Number| CHANGING | No |
| Data Offset | INFERRED | N/A | | Data Offset | INFERRED | N/A |
| Reserved Bits | CHANGING | No (3) | | Reserved Bits | CHANGING | No (3) |
skipping to change at page 14, line 30 skipping to change at page 15, line 32
| ACK | CHANGING | No | | ACK | CHANGING | No |
| PSH | CHANGING | No | | PSH | CHANGING | No |
| RST | CHANGING | No | | RST | CHANGING | No |
| SYN | CHANGING | No | | SYN | CHANGING | No |
| FIN | CHANGING | No | | FIN | CHANGING | No |
| Window | CHANGING | Yes | | Window | CHANGING | Yes |
| Checksum | CHANGING | No | | Checksum | CHANGING | No |
| Urgent Pointer | CHANGING | Yes (5) | | Urgent Pointer | CHANGING | Yes (5) |
+-----------------------+---------------+------------+ +-----------------------+---------------+------------+
Figure 9: TCP Header
(1) On the server side, the port number is likely to be a well-known (1) On the server side, the port number is likely to be a well-known
value. On the client side, the port number is generally selected value. On the client side, the port number is generally selected
by the stack automatically. Whether the port number is replicable by the stack automatically. Whether the port number is replicable
depends upon how the stack chooses the port number. However, most depends upon how the stack chooses the port number. Whilst most
implementations use a simple scheme which sequentially picks the implementations use a simple scheme which sequentially picks the
next available port number. This is clearly exploitable in a next available port number, it may not be desirable to to rely
compression scheme. upon this behavior.
(2) With the recommendation (and expected deployment) of TCP Initial (2) With the recommendation (and expected deployment) of TCP Initial
Sequence Number randomization, defined in RFC 1948 [16], it will Sequence Number randomization, defined in RFC 1948 [10], it will
be impossible to share the sequence number. Thus, this field will be impossible to share the sequence number. Thus, this field will
not be regarded as replicable. not be regarded as replicable.
(3) See comment (4) for the IPv4 header, above. (3) See comment (4) for the IPv4 header, above.
(4) See comment (2) on ECN flags for the IPv4 header, above. (4) See comment (2) on ECN flags for the IPv4 header, above.
(5) The urgent pointer is very rarely used. This means that, in (5) The urgent pointer is very rarely used. This means that, in
practice, the field may be considered replicable. practice, the field may be considered replicable.
4.4 TCP Options 3.4 TCP Options
+---------------------------+--------------+------------+ +---------------------------+--------------+------------+
| Option | SYN-only (1) | Replicable | | Option | SYN-only (1) | Replicable |
+---------------------------+--------------+------------+ +---------------------------+--------------+------------+
| End of Option List | No | No (2) | | End of Option List | No | No (2) |
| No-Operation | No | No (2) | | No-Operation | No | No (2) |
| Maximum Segment Size | Yes | Yes | | Maximum Segment Size | Yes | Yes |
| Window Scale | Yes | Yes | | Window Scale | Yes | Yes |
| SACK-Permitted | Yes | Yes | | SACK-Permitted | Yes | Yes |
| SACK | No | No | | SACK | No | No |
| Timestamp | No | No | | Timestamp | No | No |
+---------------------------+--------------+------------+ +---------------------------+--------------+------------+
Figure 10: TCP Options
(1) This indicates whether the option only appears in SYN packet or (1) This indicates whether the option only appears in SYN packet or
not. Options that are not 'SYN-only' may appear in any packet. not. Options that are not 'SYN-only' may appear in any packet.
Many TCP options are used only in SYN packets. Some options, such Many TCP options are used only in SYN packets. Some options, such
as MSS, Window Scale, SACK-Permitted etc., will tend to have the as MSS, Window Scale, SACK-Permitted etc., will tend to have the
same value among replicable packet streams. same value among replicable packet streams.
Thus, to support context sharing, the compressor should maintain Thus, to support context sharing, the compressor should maintain
such TCP options in the context (even though they only appear in such TCP options in the context (even though they only appear in
the SYN segment). the SYN segment).
(2) Since these options have fixed values, they could be regarded as (2) Since these options have fixed values, they could be regarded as
replicable. However, the only interesting thing to convey about replicable. However, the only interesting thing to convey about
these options is their presence: if it is known that such an these options is their presence: if it is known that such an
option exists, its value is defined. option exists, its value is defined.
4.5 Summary of replication 3.5 Summary of replication
From the above analysis, it can be seen that there are reasonable From the above analysis, it can be seen that there are reasonable
grounds for exploiting redundancy between flows, as well as between grounds for exploiting redundancy between flows, as well as between
packets within a flow. Simply consider the advantage of being able packets within a flow. Simply consider the advantage of being able
to elide the source and destination addresses for a repeated to elide the source and destination addresses for a repeated
connection between two IPv6 endpoints. There will also be a cost (in connection between two IPv6 endpoints. There will also be a cost (in
terms of complexity and robustness) for replicating contexts, and terms of complexity and robustness) for replicating contexts, and
this must be considered when deciding what constitutes an appropriate this must be considered when deciding what constitutes an appropriate
solution. solution.
The final point to note for the use of replication is that it The final point to note for the use of replication is that it
requires the compressor to have a suitable degree of confidence that requires the compressor to have a suitable degree of confidence that
the source data is present and correct at the decompressor. This may the source data is present and correct at the decompressor. This may
place some restrictions on which of the 'changing' fields, in place some restrictions on which of the 'changing' fields, in
particular, can be utilised during replication. particular, can be utilised during replication.
5. Analysis of change patterns of header fields 4. Analysis of change patterns of header fields
To design suitable mechanisms for efficient compression of all header To design suitable mechanisms for efficient compression of all header
fields, their change patterns must be analyzed. For this reason, an fields, their change patterns must be analyzed. For this reason, an
extended classification is done based on the general classification extended classification is done based on the general classification
in 2, considering the fields which were labeled CHANGING in that in 2, considering the fields which were labeled CHANGING in that
classification. classification.
The CHANGING fields are separated into five different subclasses: The CHANGING fields are separated into five different subclasses:
o STATIC o STATIC
skipping to change at page 16, line 47 skipping to change at page 17, line 52
When the classification is done, other details are also stated When the classification is done, other details are also stated
regarding possible additional knowledge about the field values and/or regarding possible additional knowledge about the field values and/or
field deltas, according to the classification. For fields classified field deltas, according to the classification. For fields classified
as STATIC or SEMISTATIC, the case could be that the value of the 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 field is not only STATIC but also well KNOWN a priori (two states for
SEMISTATIC fields). For fields with non-irregular change behavior, SEMISTATIC fields). For fields with non-irregular change behavior,
it could be known that changes usually are within a LIMITED range it could be known that changes usually are within a LIMITED range
compared to the maximal change for the field. For other fields, the compared to the maximal change for the field. For other fields, the
values are completely UNKNOWN. values are completely UNKNOWN.
Table 1 classifies all the CHANGING fields on the basis of their Figure 11 classifies all the CHANGING fields on the basis of their
expected change patterns. (4) refers to IPv4 fields and (6) refers expected change patterns. (4) refers to IPv4 fields and (6) refers
to IPv6. to IPv6.
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge | | Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+ +========================+=============+=============+=============+
| IP TOS(4) / Tr.Class(6)| Value | RC | UNKNOWN | | DSCP(4) / Tr.Class(6) | Value | ALTERNATING | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| IP ECT flag(4) | Value | RC | UNKNOWN | | IP ECT flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| IP CE flag(4) | Value | RC | UNKNOWN | | IP CE flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| Sequential | Delta | STATIC | KNOWN | | Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+ | -----------+-------------+-------------+-------------+
| IP Id(4) Seq. jump | Delta | RC | LIMITED | | IP Id(4) Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+ | -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN | | Random | Value | IRREGULAR | UNKNOWN |
skipping to change at page 17, line 49 skipping to change at page 19, line 4
| FIN flag | Value | SEMISTATIC | KNOWN | | FIN flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| TCP Window | Value | ALTERNATING | KNOWN | | TCP Window | Value | ALTERNATING | KNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| TCP Checksum | Value | IRREGULAR | UNKNOWN | | TCP Checksum | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| TCP Urgent Pointer | Value | IRREGULAR | KNOWN | | TCP Urgent Pointer | Value | IRREGULAR | KNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| TCP Options | Value | IRREGULAR | UNKNOWN | | TCP Options | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
Figure 11: Classification of CHANGING fields
Table 1 : Classification of CHANGING header fields
Figure 11
The following subsections discuss the various header fields in The following subsections discuss the various header fields in
detail. Note that table 1 and the discussions below do not consider detail. Note that table 1 and the discussions below do not consider
changes caused by loss or reordering before the compression point. changes caused by loss or reordering before the compression point.
5.1 IP header 4.1 IP header
5.1.1 IP Traffic-Class / Type-Of-Service (TOS) 4.1.1 IP Traffic-Class / Type-Of-Service (TOS)
The Traffic-Class (IPv6) or Type-Of-Service/DSCP (IPv4) field might The Traffic-Class (IPv6) or Type-Of-Service/DSCP (IPv4) field might
be expected to change during the lifetime of a packet stream. This be expected to change during the lifetime of a packet stream. This
analysis considers several RFCs that describe modifications to the analysis considers several RFCs that describe modifications to the
original RFC 791 [1]. original RFC 791 [1].
The TOS byte was initially described in RFC 791 [1] as 3 bits of The TOS byte was initially described in RFC 791 [1] as 3 bits of
precedence followed by 3 bits of TOS and 2 reserved bits (defined to precedence followed by 3 bits of TOS and 2 reserved bits (defined to
be 0). RFC 1122 [5] extended this to specify 5 bits of TOS, although be 0). RFC 1122 [22] extended this to specify 5 bits of TOS,
the meanings of the additional 2 bits were not defined. RFC 1349 although the meanings of the additional 2 bits were not defined. RFC
[10] defined the 4th bit of TOS to be 'minimize monetary cost'. The 1349 [24] defined the 4th bit of TOS to be 'minimize monetary cost'.
next significant change was in RFC 2474 [25] which reworked the TOS The next significant change was in RFC 2474 [15] which reworked the
octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits. TOS octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits.
Most recently RFC 2780 [32] identified the 2 reserved bits in the TOS Most recently RFC 2780 [35] identified the 2 reserved bits in the TOS
or traffic class octet for experimental use with ECN. or traffic class octet for experimental use with ECN.
For the purposes of this classification, it is therefore proposed to 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 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 2 additional bits. These 2 bits may be expected to be 0 or to
data. From a future proofing perspective, it is preferable to assume contain ECN data. From a future proofing perspective, it is
the use of ECN, especially with respect to TCP. preferable to assume the use of ECN, especially with respect to TCP.
It is also considered important that the profile works with legacy It is also considered important that the profile works with legacy
stacks, since these will be in existence for some considerable time stacks, since these will be in existence for some considerable time
to come. For simplicity, this will be considered as 6 bits of TOS 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 information and 2 bits of ECN data, so the fields are always
considered to be structured the same way. considered to be structured the same way.
The DSCP (as for TOS in ROHC RTP) is not expected to change The DSCP (as for TOS in ROHC RTP) is not expected to change
frequently (although it could change mid-flow, for example as a frequently (although it could change mid-flow, for example as a
result of a route change). result of a route change).
5.1.2 ECN Flags 4.1.2 ECN Flags
Initially we describe the ECN flags as specified in RFC 2481 [26] and Initially we describe the ECN flags as specified in RFC 2481 [16] and
RFC 3168 [27]. Subsequently, a suggested update is described which RFC 3168 [17]. Subsequently, a suggested update is described which
would alter the behavior of the flags. would alter the behavior of the flags.
In RFC 2481 [26] there are 2 separate flags, the ECT (ECN Capable In RFC 2481 [16] there are 2 separate flags, the ECT (ECN Capable
Transport) flag and the CE (Congestion Experienced) flag. The ECT Transport) flag and the CE (Congestion Experienced) flag. The ECT
flag, if negotiated by the TCP stack, will be '1' for all data flag, if negotiated by the TCP stack, will be '1' for all data
packets and '0' for all 'pure acknowledgement' packets. This means packets and '0' for all 'pure acknowledgement' packets. This means
that the behavior of the ECT flag is linked to behavior in the TCP 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. stack. Whether this can be exploited for compression is not clear.
The CE flag is only used if ECT is set to '1'. It is set to '0' by The CE flag is only used if ECT is set to '1'. It is set to '0' by
the sender and can be set to '1' by an ECN capable router in the the sender and can be set to '1' by an ECN capable router in the
network to indicate congestion. Thus the CE flag is expected to be network to indicate congestion. Thus the CE flag is expected to be
randomly set to '1' with a probability dependent upon the congestion randomly set to '1' with a probability dependent upon the congestion
state of the network and the position of the compressor in the path. state of the network and the position of the compressor in the path.
So, a compressor located close to the receiver in a congested network So, a compressor located close to the receiver in a congested network
will see the CE bit set frequently, but a compressor located close to will see the CE bit set frequently, but a compressor located close to
a sender will rarely, if ever, see the CE bit set to '1'. a sender will rarely, if ever, see the CE bit set to '1'.
A recent, experimental proposal [38] suggests an alternative view of A recent, experimental proposal [20] suggests an alternative view of
these 2 bits. This considers the two bits together as having 4 these 2 bits. This considers the two bits together as having 4
possible codepoints. Meanings are then assigned to the codepoints: possible codepoints. Meanings are then assigned to the codepoints:
00 Not ECN capable 00 Not ECN capable
01 ECN capable, no congestion [known as ECT(0)] 01 ECN capable, no congestion [known as ECT(0)]
10 ECN capable, no congestion [known as ECT(1)] 10 ECN capable, no congestion [known as ECT(1)]
11 Congestion experienced 11 Congestion experienced
The use of 2 codepoints for signaling ECT allows the sender to detect The use of 2 codepoints for signaling ECT allows the sender to detect
when a receiver is not reliably echoing congestion information. when a receiver is not reliably echoing congestion information.
skipping to change at page 19, line 39 skipping to change at page 20, line 41
For the purposes of compression, this update means that ECT(0) and 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' ECT(1) are equally likely (for an ECN capable flow) and that '11'
will be relatively rarely seen. The probability of seeing a will be relatively rarely seen. The probability of seeing a
congestion indication is discussed above in the description of the CE congestion indication is discussed above in the description of the CE
flag. flag.
It is suggested that, for the purposes of compression, ECN with It is suggested that, for the purposes of compression, ECN with
nonces is assumed as the baseline, although the compression scheme nonces is assumed as the baseline, although the compression scheme
must be able to transparently compress the original ECN scheme. must be able to transparently compress the original ECN scheme.
5.1.3 IP Identification 4.1.3 IP Identification
The Identification field (IP ID) of the IPv4 header is there to The Identification field (IP ID) of the IPv4 header is there to
identify which fragments constitute a datagram when reassembling identify which fragments constitute a datagram when reassembling
fragmented datagrams. The IPv4 specification does not specify fragmented datagrams. The IPv4 specification does not specify
exactly how this field is to be assigned values, only that each 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 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) 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 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 values can be done in various ways, which we have separated into
three classes: three classes:
skipping to change at page 21, line 14 skipping to change at page 22, line 15
between the two solutions above. Finally, even for IPv4, header between the two solutions above. Finally, even for IPv4, header
compression could be designed without any additional information for compression could be designed without any additional information for
the ID field included in compressed headers. To use such schemes, it 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 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 by the sender. That might not be possible to know, which implies
that the applicability of such solutions is very uncertain. However, that the applicability of such solutions is very uncertain. However,
designers of IPv4 stacks for cellular terminals should use an designers of IPv4 stacks for cellular terminals should use an
assignment policy close to sequential. assignment policy close to sequential.
With regard to TCP compression, the behavior of the IP ID field is With regard to TCP compression, the behavior of the IP ID field is
considered to be essentially the same. However, in RFC 3095 [34] it considered to be essentially the same. However, in RFC 3095 [36] it
is noted that the IP ID is generally inferred from the RTP Sequence is noted that the IP ID is generally inferred from the RTP Sequence
Number. There is no obvious candidate in the TCP case for a field to Number. There is no obvious candidate in the TCP case for a field to
offer this 'master sequence number' role. offer this 'master sequence number' role.
Clearly from a busy server the observed behavior may well be quite Clearly from a busy server the observed behavior may well be quite
erratic. This is a case where the ability to share the IP erratic. This is a case where the ability to share the IP
compression context between a number of flows (between the same end- compression context between a number of flows (between the same end-
points) could offer potential benefits. However, this would only points) could offer potential benefits. However, this would only
have any real impact where there were a large number of flows between have any real impact where there were a large number of flows between
one machine and the server. If context sharing is being considered, one machine and the server. If context sharing is being considered,
then it is preferable to share the IP part of the context. then it is preferable to share the IP part of the context.
5.1.4 Don't Fragment (DF) flag 4.1.4 Don't Fragment (DF) flag
Due to the use of path-MTU discovery RFC 1191 [8], the value is more Path-MTU discovery RFC 1191 for IPv4 [6] and RFC 1981 for IPv6 [11],
likely to be '1', than found in UDP/RTP streams since DF should be is widely deployed for TCP (in contrast to little current use for UDP
set to check for fragmentation in the end-to-end path. In practice packet streams). This employs the DF flag value of '1' to detect the
it is hard to predict the behavior of this field. However, it is need for fragmentation in the end-to-end path and to probe the
considered that the most likely case is that it will generally stay minimum MTU along the network path. End hosts using this technique
at either '0' or '1'. When using PMTU discovery [8] it is expected may be expected to send all packets with DF set to '1', although a
that DF will always be set to '1', although a host may end PMTU host may end PMTU discovery by clearing the DF bit to '0'. Thus, for
discovery by clearing the DF bit to '0'. the purpose of compression, we expect the field value to be stable.
5.1.5 IP Hop-Limit / Time-To-Live (TTL) 4.1.5 IP Hop-Limit / Time-To-Live (TTL)
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be 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 constant during the lifetime of a packet stream or to alternate
between a limited number of values due to route changes. between a limited number of values due to route changes.
5.2 TCP header 4.2 TCP header
Any discussion of compressability of TCP fields borrows heavily from Any discussion of compressability of TCP fields borrows heavily from
RFC 1144 [6]. However, the premise of how the compression is RFC 1144 [23]. However, the premise of how the compression is
performed is slightly different and the protocol has evolved slightly performed is slightly different and the protocol has evolved slightly
in the intervening time. in the intervening time.
5.2.1 Sequence number 4.2.1 Sequence number
An understanding of the sequence and acknowledgement number behavior An understanding of the sequence and acknowledgement number behavior
are essential for a TCP compression scheme. are essential for a TCP compression scheme.
At the simplest level the behavior of the sequence number can be At the simplest level the behavior of the sequence number can be
described relatively easily. However, there are a number of described relatively easily. However, there are a number of
complicating factors that also need to be considered. complicating factors that also need to be considered.
For transferring in-sequence data packets, the sequence number will For transferring in-sequence data packets, the sequence number will
increment for each packet by between 0 and an upper limit defined by increment for each packet by between 0 and an upper limit defined by
the MSS (Maximum Segment Size). the MSS (Maximum Segment Size) and, if being used, Path-MTU
discovery.
Although there are common MSS values, these can be quite variable. There are common MSS values, but these can be quite variable and
Given this variability and the range of window sizes it is hard unpredictable for any given flow. Given this variability and the
(compared with the RTP case, for example) to select a 'one size fits range of window sizes it is hard (compared with the RTP case, for
all' encoding for the sequence number. (The same argument applies example) to select a 'one size fits all' encoding for the sequence
equally to the acknowledgement number). number. (The same argument applies equally to the acknowledgement
number).
We note that the increment of the sequence number in a packet is the We note that the increment of the sequence number in a packet is the
size of the data payload of that packet (including the SYN and FIN size of the data payload of that packet (including the SYN and FIN
flags; see later). This is, of course, exactly the relationship that flags). This is, of course, exactly the relationship that RFC 1144
RFC 1144 [6] exploits to compress the sequence number in the most [23] exploits to compress the sequence number in the most efficient
efficient case. This technique may not be directly applicable to a case. This technique may not be directly applicable to a robust
robust solution, but may be a useful relationship to consider. solution, but may be a useful relationship to consider.
However, at any point on the path (i.e. wherever a compressor might However, at any point on the path (i.e. wherever a compressor might
be deployed), the sequence number can be anywhere within a range be deployed), the sequence number can be anywhere within a range
defined by the TCP window. This is a combination of a number of defined by the TCP window. This is a combination of a number of
values (buffer space at the sender; advertised buffer size at the values (buffer space at the sender; advertised buffer size at the
receiver; and TCP congestion control algorithms). Missing packets or receiver; and TCP congestion control algorithms). Missing packets or
retransmissions can cause the TCP sequence number to fluctuate within retransmissions can cause the TCP sequence number to fluctuate within
the limits of this window. the limits of this window.
It would also be desirable to be able to predict the sequence number It is desirable to be able to predict the sequence number from some
from some regularity. However, this also appears to be difficult to regularity. However, this also appears to be difficult to do. For
do. For example, during bulk data transfer the sequence number will example, during bulk data transfer the sequence number will tend to
tend to go up by 1 MSS per packet (assuming no packet loss). Higher go up by 1 MSS per packet (assuming no packet loss). Higher layer
level values have been seen to have an impact as well, where sequence values have been seen to have an impact as well, where sequence
number behavior has been observed with an 8 kbyte repeating pattern number behavior has been observed with an 8 kbyte repeating pattern
-- 5 segments of 1460 bytes followed by 1 segment of 892 bytes. It -- 5 segments of 1460 bytes followed by 1 segment of 892 bytes. The
appears that implementation and how data is presented to the stack implementation of TCP and hte management of buffers within a protocol
can affect the sequence number. stack can affect the behavior of the sequence number.
It has been suggested that the TCP window can be tracked by the It may be possible to track the TCP window by the compressor,
compressor, allowing it to bound the size of these jumps. allowing it to bound the size of these jumps.
For interactive flows (for example telnet), the sequence number will For interactive flows (for example telnet), the sequence number will
change by small irregular amounts. In this case the Nagle algorithm change by small irregular amounts. In this case the Nagle algorithm
[3] commonly applies, coalescing small packets where possible to [3] commonly applies, coalescing small packets where possible to
reduce the basic header overhead. This may also mean that is less reduce the basic header overhead. This may also mean that it is less
likely that predictable changes in the sequence number will occur. likely that predictable changes in the sequence number will occur.
The Nagle algorithm is an optimisation and not required to be used. The Nagle algorithm is an optimisation and not required to be used
Also, applications can disable the Nagle algorithm (which may be done (applications can disable its use). However, it is turned on by
to mitigate the delays associated with its use). default in all common TCP implementations.
It is also noted that the SYN and FIN flags (which have to be It is also noted that the SYN and FIN flags (which have to be
acknowledged) consume 1 byte of sequence space. acknowledged) consume 1 byte of sequence space.
5.2.2 Acknowledgement number 4.2.2 Acknowledgement number
Much of the information about the sequence number applies equally to Much of the information about the sequence number applies equally to
the acknowledgement number. However, there are some important the acknowledgement number. However, there are some important
differences. differences.
For bulk data transfers there will tend to be 1 acknowledgement for For bulk data transfers there will tend to be 1 acknowledgement for
every 2 data segments. The algorithm is specified in RFC 2581 [31]. every 2 data segments. The algorithm is specified in RFC 2581 [18].
An ACK need not always be send immediately on receipt of a data An ACK need not always be sent immediately on receipt of a data
segment, but must be sent within 500ms and should be generated for at segment, but must be sent within 500ms and should be generated for at
least every second full sized segment (MSS) of received data. It may least every second full sized segment (MSS) of received data. It may
be seen from this that the delta for the acknowledgement number is be seen from this that the delta for the acknowledgement number is
roughly twice that of the sequence number. This is not always the roughly twice that of the sequence number. This is not always the
case and the discussion about sequence number irregularity should be case and the discussion about sequence number irregularity should be
applied. applied.
As an aside, a common implementation bug was 'stretch ACKs' As an aside, a common implementation bug is 'stretch ACKs' [38]
(acknowledgements may be generated less frequently than every two (acknowledgements may be generated less frequently than every two
full-size data segments). This pattern can also occur following loss full-size data segments). This pattern can also occur following loss
on the return path. on the return path.
Since the acknowledgement number is cumulative, dropped packets in Since the acknowledgement number is cumulative, dropped packets in
the forward path will result in the acknowledgement number remaining the forward path will result in the acknowledgement number remaining
constant for a time in the reverse direction. Retransmission of a constant for a time in the reverse direction. Retransmission of a
dropped segment can then cause a substantial jump in the dropped segment can then cause a substantial jump in the
acknowledgement number. These jumps in acknowledgement number are acknowledgement number. These jumps in acknowledgement number are
bounded by the TCP window, just as for the jumps in sequence number. bounded by the TCP window, just as for the jumps in sequence number.
In the acknowledgement case, information about the advertised In the acknowledgement case, information about the advertised
received window gives a bound to the size of any ACK jump. received window gives a bound to the size of any ACK jump.
5.2.3 Reserved 4.2.3 Reserved
This field is reserved and as such might be expected to be zero. 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 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. matter of time before a suggestion for using the flag is made.
5.2.4 Flags 4.2.4 Flags
o ECN-E (Explicit Congestion Notification) o ECN-E (Explicit Congestion Notification)
'1' to echo CE bit in IP header. Will be set in several '1' to echo CE bit in IP header. Will be set in several
consecutive headers (until 'acknowledged' by CWR) consecutive headers (until 'acknowledged' by CWR)
If ECN nonces get used, then there will be a 'nonce-sum' (NS) If ECN nonces get used, then there will be a 'nonce-sum' (NS)
bit in the flags, as well. Again, transparency of the reserved bit in the flags, as well. Again, transparency of the reserved
bits is crucial for future-proofing this compression scheme. bits is crucial for future-proofing this compression scheme.
From an efficiency/compression standpoint, the NS bit will From an efficiency/compression standpoint, the NS bit will
either be unused [always 0] or randomly changing). The either be unused [always 0] or randomly changing). The
nonce-sum is the 1-bit sum of the ECT codepoints, as described nonce-sum is the 1-bit sum of the ECT codepoints, as described
in [38]. in [20].
o CWR (Congestion Window Reduced) o CWR (Congestion Window Reduced)
'1' to signal congestion window reduced on ECN. Will generally '1' to signal congestion window reduced on ECN. Will generally
be set in individual packets. The flag will be set once per be set in individual packets. The flag will be set once per
loss event. Thus, the probability of it being set is loss event. Thus, the probability of it being set is
proportional to the degree of congestion in the network, but proportional to the degree of congestion in the network, but
less likely to be set than the CE flag. less likely to be set than the CE flag.
o ECE (Echo Congestion Experience) o ECE (Echo Congestion Experience)
If 'congestion experienced' is signaled on a received IP If 'congestion experienced' is signaled on a received IP
header, this is echoed through the ECE bit in segments sent by header, this is echoed through the ECE bit in segments sent by
the receiver until acknowledged by seeing the CWR bit set. the receiver until acknowledged by seeing the CWR bit set.
skipping to change at page 25, line 5 skipping to change at page 26, line 5
to the implementation of the stack) to the implementation of the stack)
o RST (Reset Connection) o RST (Reset Connection)
'1' to reset a connection [unlikely with any flag other than '1' to reset a connection [unlikely with any flag other than
ACK] ACK]
o SYN (Synchronize Sequence Number) o SYN (Synchronize Sequence Number)
'1' for the SYN/SYN-ACK only at the start of a connection '1' for the SYN/SYN-ACK only at the start of a connection
o FIN (End of Data : FINished) o FIN (End of Data : FINished)
'1' to indicate 'no more data' [unlikely with any flag other '1' to indicate 'no more data' [unlikely with any flag other
than ACK] than ACK]
5.2.5 Checksum 4.2.5 Checksum
Carried as the end-to-end check for the TCP data. See RFC 1144 [6] Carried as the end-to-end check for the TCP data. See RFC 1144 [23]
for a discussion of why this should be carried. A header compression for a discussion of why this should be carried. A header compression
scheme should not rely upon the TCP checksum for robustness, though, scheme should not rely upon the TCP checksum for robustness, though,
and should apply appropriate error-detection mechanisms of its own. and should apply appropriate error-detection mechanisms of its own.
The TCP checksum has to be considered as randomly changing. The TCP checksum has to be considered as randomly changing.
5.2.6 Window 4.2.6 Window
May oscillate randomly between 0 and the receiver's window limit (for May oscillate randomly between 0 and the receiver's window limit (for
the connection). the connection).
In practice, the window will either not change, or may alternate In practice, the window will either not change, or may alternate
between a relatively small number of values. Particularly when between a relatively small number of values. Particularly when
closing (the value is getting smaller), the change in window is closing (the value is getting smaller), the change in window is
likely to be related to the segment size, but it is not clear that likely to be related to the segment size, but it is not clear that
this necessarily offers any compression advantage. When the window this necessarily offers any compression advantage. When the window
is opening, the effect of 'Silly-Window Syndrome' avoidance should be is opening, the effect of 'Silly-Window Syndrome' avoidance should be
remembered. This prevents the window opening by small amounts that remembered. This prevents the window opening by small amounts that
would encourage the sender to clock out small segments. would encourage the sender to clock out small segments.
When thinking about what fields might change in a sequence of TCP When thinking about what fields might change in a sequence of TCP
segments, it should be noted that the receiver can generate 'window segments, it should be noted that the receiver can generate 'window
update' segments in which only the window advertisement changes. update' segments in which only the window advertisement changes.
5.2.7 Urgent pointer 4.2.7 Urgent pointer
From a compression point of view, the Urgent Pointer is interesting From a compression point of view, the Urgent Pointer is interesting
because it offers an example where 'semantically identical' because it offers an example where 'semantically identical'
compression is not the same as 'bitwise identical'. This is because 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. 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 However, the TCP checksum must be passed transparently, in order to
realized that this enforces bitwise transparency of the scheme and so maintain its end-to-end integrity checking property. Since the TCP
this argument is not particularly important. checksum includes the Urgent Pointer in its coverage, this enforces
bitwise transparency of the Urgent Pointer. Thus, the issue of
'semantic' vs 'bitwise' identity is presented as a note: the Urgent
Pointer must be compressed in a way that preserves its value.
If the URG flag is set, then this pointer indicates the end of the 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 urgent data and so can point to anywhere in the window. This may be
be set (and changing) over several segments. Note that urgent data set (and changing) over several segments. Note that urgent data is
is rarely used, since it is not a particularly clean way of managing rarely used, since it is not a particularly clean way of managing
out-of-band data. out-of-band data.
5.3 Options 4.3 Options
Options occupy space at the end of the TCP header. All options are 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. 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 The TCP header must be padded with zeros to make the header length a
multiple of 32 bits. multiple of 32 bits.
Optional header fields are identified by an option kind field. Optional header fields are identified by an option kind field.
Options 0 and 1 are exactly one octet that is their kind field. All 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 other options have their one octet kind field, followed by a one
octet length field, followed by length-2 octets of option data. octet length field, followed by length-2 octets of option data.
5.3.1 Options overview 4.3.1 Options overview
Table 2 classifies the IANA known options together with their The IANA provides the authoritative list of TCP options. Figure 12
associated RFCs, if applicable, from describes the current allocations at the time of publication. Any
<http://www.iana.org/assignments/tcp-parameters> new option would have a 'kind' value assigned by IANA. The list is
available at [21]. Where applicable, the associated RFC is also
cited.
+------+--------+------------------------------------+----------+-----+ +------+--------+------------------------------------+----------+-----+
| Kind | Length | Meaning | RFC | Use | | Kind | Length | Meaning | RFC | Use |
| |(octets)| | | | | |(octets)| | | |
+------+--------+------------------------------------+----------+-----+ +------+--------+------------------------------------+----------+-----+
| 0 | - | End of Option List | RFC 793 | * | | 0 | - | End of Option List | RFC 793 | * |
| 1 | - | No-Operation | RFC 793 | * | | 1 | - | No-Operation | RFC 793 | * |
| 2 | 4 | Maximum Segment Size | RFC 793 | * | | 2 | 4 | Maximum Segment Size | RFC 793 | * |
| 3 | 3 | WSopt - Window Scale | RFC 1323 | * | | 3 | 3 | WSopt - Window Scale | RFC 1323 | * |
| 4 | 2 | SACK Permitted | RFC 2018 | * | | 4 | 2 | SACK Permitted | RFC 2018 | * |
skipping to change at page 26, line 50 skipping to change at page 28, line 10
| 19 | 18 | MD5 Signature Option | RFC 2385 | | | 19 | 18 | MD5 Signature Option | RFC 2385 | |
| 20 | | SCPS Capabilities | | | | 20 | | SCPS Capabilities | | |
| 21 | | Selective Negative Acks | | | | 21 | | Selective Negative Acks | | |
| 22 | | Record Boundaries | | | | 22 | | Record Boundaries | | |
| 23 | | Corruption experienced | | | | 23 | | Corruption experienced | | |
| 24 | | SNAP | | | | 24 | | SNAP | | |
| 25 | | Unassigned (released 12/18/00) | | | | 25 | | Unassigned (released 12/18/00) | | |
| 26 | | TCP Compression Filter | | | | 26 | | TCP Compression Filter | | |
+------+--------+------------------------------------+----------+-----+ +------+--------+------------------------------------+----------+-----+
Table 2 Description of common TCP options Figure 12: Common TCP Options
Figure 12
The 'use' column is marked with '*' to indicate those options that The 'use' column is marked with '*' to indicate those options that
are most likely to be seen in TCP flows. are most likely to be seen in TCP flows.
5.3.2 Option field behavior 4.3.2 Option field behavior
Generally speaking all option fields have been classified as Generally speaking all option fields have been classified as
changing. This section describes the behavior of each option changing. This section describes the behavior of each option
referenced within an RFC, listed by 'kind' indicator. referenced within an RFC, listed by 'kind' indicator.
0. End of option list 0. End of option list
This option code indicates the end of the option list. This This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according to 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, 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 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 the options would not otherwise coincide with the end of the
skipping to change at page 27, line 39 skipping to change at page 28, line 45
There is no guarantee that senders will use this option, so There is no guarantee that senders will use this option, so
receivers must be prepared to process options even if they do receivers must be prepared to process options even if they do
not begin on a word boundary RFC 793 [2]. not begin on a word boundary RFC 793 [2].
There is no data associated with this option, a compression There is no data associated with this option, a compression
scheme must simply be able to encode its presence. scheme must simply be able to encode its presence.
This may be done by noting that the option simply maintains a This may be done by noting that the option simply maintains a
certain alignment and that compression need only convey this certain alignment and that compression need only convey this
alignment. In this way, padding can just be removed. alignment. In this way, padding can just be removed.
2. Maximum Segment Size 2. Maximum Segment Size
If this option is present, then it communicates the maximum If this option is present, then it communicates the maximum
receive segment size at the TCP that sends this segment. This segment size that may be used to send a packet to this
field must only be sent in the initial connection request end-host. This field must only be sent in the initial
(i.e., in segments with the SYN control bit set). If this connection request (i.e., in segments with the SYN control bit
option is not used, any segment size is allowed RFC 793 [2]. set). If this option is not used, any segment size is allowed
RFC 793 [2].
This option is very common. The segment size is a 16-bit This option is very common. The segment size is a 16-bit
quantity. Theoretically this could take any value, however quantity. Theoretically this could take any value, however
there are a number of values that are more common. For there are a number of values that are more common. For
example, 1460 bytes is very common for TCP/IPv4 over Ethernet example, 1460 bytes is very common for TCP/IPv4 over Ethernet
(though with the increased prevalence of tunnels, for example, (though with the increased prevalence of tunnels, for example,
smaller values such as 1400 have become more popular). 536 smaller values such as 1400 have become more popular). 536
bytes is the default MSS value. This may allow for common bytes is the default MSS value. This may allow for common
values to be encoded more efficiently. values to be encoded more efficiently.
3. Window Scale Option (WSopt) 3. Window Scale Option (WSopt)
This option may be sent in a SYN segment by TCP : This option may be sent in a SYN segment by the TCP end-host:
(1) to indicate that it is prepared to do both send and (1) to indicate that the sending TCP end-host is prepared
receive window scaling, and to perform both send and receive window scaling, and
(2) to communicate a scale factor to be applied to its (2) to communicate a scale factor to be applied to its
receive window. receive window.
The scale factor is encoded logarithmically, as a power of 2 The scale factor is encoded logarithmically, as a power of 2
(presumably to be implemented by binary shifts). Note: the (presumably to be implemented by binary shifts). Note: the
window in the SYN segment itself is never scaled RFC 1072 [4]. window in the SYN segment itself is never scaled RFC 1072 [4].
This option may be sent in an initial segment (i.e., a segment 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 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 in a segment, but only if a Window Scale option was received in
the initial segment. A Window Scale option in a segment the initial segment. A Window Scale option in a segment
without a SYN bit should be ignored. The Window field in a SYN without a SYN bit should be ignored. The Window field in a SYN
segment itself is never scaled RFC 1323 [9] segment itself is never scaled RFC 1323 [7]
The use of window scaling does not affect the encoding of any 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 other field during the life-time of the flow. It is only the
encoding of the window scaling option itself that is important. encoding of the window scaling option itself that is important.
The window scale must be between 0 and 14 (inclusive). The window scale must be between 0 and 14 (inclusive).
Generally smaller values would be expected (a window scale of Generally smaller values would be expected (a window scale of
14 allows for a 1Gbyte window, which is extremely large). 14 allows for a 1Gbyte window, which is extremely large).
4. SACK-Permitted 4. SACK-Permitted
This option may be sent in a SYN by a TCP that has been This option may be sent in a SYN by a TCP that has been
extended to receive (and presumably process) the SACK option extended to receive (and presumably process) the SACK option
once the connection has opened RFC 2018 [18]. once the connection has opened RFC 2018 [13].
There is no data in this option, all that is required is for There is no data in this option, all that is required is for
the presence of the option to be encoded. the presence of the option to be encoded.
5. SACK 5. SACK
This option is to be used to convey extended acknowledgment This option is to be used to convey extended acknowledgment
information over an established connection. Specifically, it information over an established connection. Specifically, it
is to be sent by a data receiver to inform the data transmitter is to be sent by a data receiver to inform the data transmitter
of non- contiguous blocks of data that have been received and of non- contiguous blocks of data that have been received and
queued. The data receiver is awaiting the receipt of data in queued. The data receiver is awaiting the receipt of data in
later retransmissions to fill the gaps in sequence space later retransmissions to fill the gaps in sequence space
between these blocks. between these blocks.
At that time, the data receiver will acknowledge the data At that time, the data receiver will acknowledge the data
normally by advancing the left window edge in the normally by advancing the left window edge in the
Acknowledgment Number field of the TCP header. It is important Acknowledgment Number field of the TCP header. It is important
to understand that the SACK option will not change the meaning to understand that the SACK option will not change the meaning
of the Acknowledgment Number field, whose value will still of the Acknowledgment Number field, whose value will still
specify the left window edge, i.e., one byte beyond the last specify the left window edge, i.e., one byte beyond the last
sequence number of fully-received data RFC 2018 [18]. sequence number of fully-received data RFC 2018 [13].
If SACK has been negotiated (through an exchange of SACK- If SACK has been negotiated (through an exchange of SACK-
Permitted options), then this option may occur when dropped Permitted options), then this option may occur when dropped
segments are noticed by the receiver. Because this identifies segments are noticed by the receiver. Because this identifies
ranges of blocks within the receiver's window, this can be ranges of blocks within the receiver's window, this can be
viewed as a base value with a number of offsets. The base viewed as a base value with a number of offsets. The base
value (left edge of the first block) can be viewed as offset value (left edge of the first block) can be viewed as offset
from the TCP acknowledgement number. There can be up to 4 SACK from the TCP acknowledgement number. There can be up to 4 SACK
blocks in a single option. SACK blocks may occur in a number blocks in a single option. SACK blocks may occur in a number
of segments (if there is more out-of-order data 'on the wire') of segments (if there is more out-of-order data 'on the wire')
and this will typically extend the size of or add to the and this will typically extend the size of or add to the
existing blocks. existing blocks.
Alternative proposals such as DSACK RFC 2883 [33] do not Alternative proposals such as DSACK RFC 2883 [19] do not
fundamentally change the behavior of the SACK block, from the fundamentally change the behavior of the SACK block, from the
point of view of the information contained within it. point of view of the information contained within it.
6. Echo 6. Echo
This option carries information that the receiving TCP may send This option carries information that the receiving TCP may send
back in a subsequent TCP Echo Reply option (see below). A TCP back in a subsequent TCP Echo Reply option (see below). A TCP
may send the TCP Echo option in any segment, but only if a TCP may send the TCP Echo option in any segment, but only if a TCP
Echo option was received in a SYN segment for the connection. Echo option was received in a SYN segment for the connection.
When the TCP echo option is used for RTT measurement, it will When the TCP echo option is used for RTT measurement, it will
be included in data segments, and the four information bytes be included in data segments, and the four information bytes
will define the time at which the data segment was transmitted will define the time at which the data segment was transmitted
skipping to change at page 30, line 6 skipping to change at page 31, line 12
Echo Reply field (TSecr) is only valid if the ACK bit is set in 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 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 that was sent by the remote TCP in the TSval field of a
Timestamps option. When TSecr is not valid, its value must be Timestamps option. When TSecr is not valid, its value must be
zero. The TSecr value will generally be from the most recent zero. The TSecr value will generally be from the most recent
Timestamp option that was received; however, there are Timestamp option that was received; however, there are
exceptions that are explained below. A TCP may send the exceptions that are explained below. A TCP may send the
Timestamps option (TSopt) in an initial segment (i.e., segment Timestamps option (TSopt) in an initial segment (i.e., segment
containing a SYN bit and no ACK bit), and may send a TSopt in 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 other segments only if it received a TSopt in the initial
segment for the connection RFC 1323 [9]. segment for the connection RFC 1323 [7].
Timestamps are quite commonly used. If timestamp options are Timestamps are quite commonly used. If timestamp options are
exchanged in the connection set-up phase, then they are exchanged in the connection set-up phase, then they are
expected to appear on all subsequent segments. If this expected to appear on all subsequent segments. If this
exchange does not happen, then they will not appear for the exchange does not happen, then they will not appear for the
remainder of the flow. remainder of the flow.
Note that currently it is assumed that the negotiation of
options such as timestamp occurs in the SYN packets. However,
should this ever be allowed to change (allowing timestamps to
be enabled during an existing connection, for example), the
presence of the option should still be handled correctly.
Because the value being carried is a timestamp, it is logical Because the value being carried is a timestamp, it is logical
to expect that the entire value need not be carried. There is to expect that the entire value need not be carried. There is
no obvious pattern of increments that might be expected, no obvious pattern of increments that might be expected,
however. however.
An important reason for using the timestamp option is to allow An important reason for using the timestamp option is to allow
detection of sequence space wrap-around (Protection Against detection of sequence space wrap-around (Protection Against
Wrapped Sequence-number, or PAWS RFC 1323 [9]). It is not Wrapped Sequence-number, or PAWS RFC 1323 [7]). It is not
expected that this is serious concern on the links that TCP expected that this is a serious concern on the links that TCP
header compression would be deployed on, but it is important header compression would be deployed on, but it is important
that the integrity of this option is maintained. This issue is that the integrity of this option is maintained. This issue is
discussed in, for example, RFC 3150 [35]. However, the discussed in, for example, RFC 3150 [37]. However, the
proposed Eifel algorithm [39] makes use of timestamps and so, proposed Eifel algorithm [40] makes use of timestamps and so,
currently, it is recommended that timestamps are used for currently, it is recommended that timestamps are used for
cellular-type links [37]. cellular-type links [39].
With regard to compression, it is further noted that the range With regard to compression, it is further noted that the range
of resolutions for the timestamp suggested in RFC 1323 [9] is of resolutions for the timestamp suggested in RFC 1323 [7] is
quite wide (1ms to 1s per 'tick'). This (along with the quite wide (1ms to 1s per 'tick'). This (along with the
perhaps wide variation in RTT) makes it hard to select a set of perhaps wide variation in RTT) makes it hard to select a set of
encodings that will be optimal in all cases. encodings that will be optimal in all cases.
9. Partial Order Connection (POC) permitted 9. Partial Order Connection (POC) permitted
This option represents a simple indicator communicated between This option represents a simple indicator communicated between
the two peer transport entities to establish the operation of the two peer transport entities to establish the operation of
the POC protocol RFC 1693 [12] the POC protocol RFC 1693 [9]
The Partial Order Connection option is in practice never seen, The Partial Order Connection option sees little (or no) use in
and so the only requirement is that the header compression the current Internet and so the only requirement is that the
scheme should be able to encode it. header compression scheme should be able to encode it.
10. POC service profile 10. POC service profile
This option serves to communicate the information necessary to This option serves to communicate the information necessary to
carry out the job of the protocol -- the type of information carry out the job of the protocol -- the type of information
that is typically found in the header of a TCP segment. that is typically found in the header of a TCP segment.
The Partial Order Connection option is in practice never seen, The Partial Order Connection option sees little (or no) use in
and so the only requirement is that the header compression the current Internet and so the only requirement is that the
scheme should be able to encode it. header compression scheme should be able to encode it.
11. Connection Count (CC) 11. Connection Count (CC)
This option is part of the implementation of TCP Accelerated This option is part of the implementation of TCP Accelerated
Open (TAO) that effectively bypasses the TCP Three-Way Open (TAO) that effectively bypasses the TCP Three-Way
Handshake (3WHS). TAO introduces a 32-bit incarnation number, Handshake (3WHS). TAO introduces a 32-bit incarnation number,
called a "connection count" (CC) that is carried in a TCP called a "connection count" (CC) that is carried in a TCP
option in each segment. A distinct CC value is assigned to option in each segment. A distinct CC value is assigned to
each direction of an open connection. The implementation each direction of an open connection. The implementation
assigns monotonically increasing CC values to successive assigns monotonically increasing CC values to successive
connections that it opens actively or passively RFC 1644 [11]. connections that it opens actively or passively RFC 1644 [8].
This option is in practice never seen, and so the only This option sees little (or no) use in the current Internet,
requirement is that the header compression scheme should be and so the only requirement is that the header compression
able to encode it. scheme should be able to encode it.
12. CC.NEW 12. CC.NEW
Correctness of the TAO mechanism requires that clients generate Correctness of the TAO mechanism requires that clients generate
monotonically increasing CC values for successive connection monotonically increasing CC values for successive connection
initiations. Receiving a CC.NEW causes the server to initiations. Receiving a CC.NEW causes the server to
invalidate its cache entry and do a 3WHS. RFC 1644 [11]. invalidate its cache entry and do a 3WHS. RFC 1644 [8].
This option is in practice never seen, and so the only This option sees little (or no) use in the current Internet,
requirement is that the header compression scheme should be and so the only requirement is that the header compression
able to encode it. scheme should be able to encode it.
13. CC.ECHO 13. CC.ECHO
When a server host sends a segment, it echoes the connection When a server host sends a segment, it echoes the connection
count from the initial in a CC.ECHO option, which is used by count from the initial in a CC.ECHO option, which is used by
the client host to validate the segment RFC 1644 [11]. the client host to validate the segment RFC 1644 [8].
This option is in practice never seen, and so the only This option sees little (or no) use in the current Internet,
requirement is that the header compression scheme should be and so the only requirement is that the header compression
able to encode it. scheme should be able to encode it.
14. Alternate Checksum Request 14. Alternate Checksum Request
This option may be sent in a SYN segment by a TCP to indicate 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 that the TCP is prepared to both generate and receive checksums
based on an alternate algorithm. During communication, the based on an alternate algorithm. During communication, the
alternate checksum replaces the regular TCP checksum in the alternate checksum replaces the regular TCP checksum in the
checksum field of the TCP header. Should the alternate checksum field of the TCP header. Should the alternate
checksum require more than 2 octets to transmit, the checksum checksum require more than 2 octets to transmit, the checksum
may either be moved into a TCP Alternate Checksum Data Option 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 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. data may be split between the header field and the option.
Alternate checksums are computed over the same data as the Alternate checksums are computed over the same data as the
regular TCP checksum RFC 1146 [7] regular TCP checksum RFC 1146 [5]
This option is in practice never seen, and so the only This option sees little (or no) use in the current Internet,
requirement is that the header compression scheme should be and so the only requirement is that the header compression
able to encode it. It would only occur in connection set-up scheme should be able to encode it. It would only occur in
(SYN) packets. connection set-up (SYN) packets.
Even if this option were used, it would not affect the handling Even if this option were used, it would not affect the handling
of the checksum, since this should be carried transparently in of the checksum, since this should be carried transparently in
any case. any case.
15. Alternate Checksum Data 15. Alternate Checksum Data
This field is used only when the alternate checksum that is This field is used only when the alternate checksum that is
negotiated is longer than 16 bits. These checksums will not negotiated is longer than 16 bits. These checksums will not
fit in the checksum field of the TCP header and thus at least 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 part of them must be put in an option. Whether the checksum is
split between the checksum field in the TCP header and the split between the checksum field in the TCP header and the
option or the entire checksum is placed in the option is option or the entire checksum is placed in the option is
determined on a checksum by checksum basis. The length of this determined on a checksum by checksum basis. The length of this
option will depend on the choice of alternate checksum option will depend on the choice of alternate checksum
algorithm for this connection RFC 1146 [7]. algorithm for this connection RFC 1146 [5].
If an alternative checksum were negotiated in the connection If an alternative checksum were negotiated in the connection
set-up, then this option may appear on all subsequent packets set-up, then this option may appear on all subsequent packets
(if needed to carry the checksum data). However, this option (if needed to carry the checksum data). However, this option
is in practice never seen, and so the only requirement is that is in practice never seen, and so the only requirement is that
the header compression scheme should be able to encode it. the header compression scheme should be able to encode it.
16. -- 18. 16. -- 18.
Are non-RFC references and are not considered in this document. Are non-RFC references and are not considered in this document.
19. MD5 Digest 19. MD5 Digest
Every segment sent on a TCP connection to be protected against Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by spoofing will contain the 16-byte MD5 digest produced by
applying the MD5 algorithm to a concatenated block of data. applying the MD5 algorithm to a concatenated block of data.
Upon receiving a signed segment, the receiver must validate it Upon receiving a signed segment, the receiver must validate it
by calculating its own digest from the same data (using its own by calculating its own digest from the same data (using its own
key) and comparing the two digest. A failing comparison must key) and comparing the two digest. A failing comparison must
result in the segment being dropped and must not produce any result in the segment being dropped and must not produce any
response back to the sender. Logging the failure is probably response back to the sender. Logging the failure is probably
advisable. advisable.
Unlike other TCP extensions (e.g., the Window Scale option Unlike other TCP extensions (e.g., the Window Scale option
[9]), the absence of the option in the SYN, ACK segment must [7]), the absence of the option in the SYN-ACK segment must not
not cause the sender to disable its sending of signatures. cause the sender to disable its sending of signatures. This
This negotiation is typically done to prevent some TCP negotiation is typically done to prevent some TCP
implementations from misbehaving upon receiving options in implementations from misbehaving upon receiving options in
non-SYN segments. This is not a problem for this option, since non-SYN segments. This is not a problem for this option, since
the SYN, ACK sent during connection negotiation will not be the SYN-ACK sent during connection negotiation will not be
signed and will thus be ignored. The connection will never be signed and will thus be ignored. The connection will never be
made, and non-SYN segments with options will never be sent. made, and non-SYN segments with options will never be sent.
More importantly, the sending of signatures must be under the More importantly, the sending of signatures must be under the
complete control of the application, not at the mercy of the complete control of the application, not at the mercy of the
remote host not understanding the option. remote host not understanding the option.
MD5 digest information should, like any cryptographically MD5 digest information should, like any cryptographically
secure data, be incompressible. Therefore the compression secure data, be incompressible. Therefore the compression
scheme must simply transparently carry this option, if it scheme must simply transparently carry this option, if it
occurs. occurs.
20. -- 26. 20. -- 26.
Are non-RFC references and are not considered in this document. Are non-RFC references and are not considered in this document.
This only means that their behavior is not described in detail This only means that their behavior is not described in detail
as a compression scheme is not expected to be optimised for as a compression scheme is not expected to be optimised for
these options. However any unrecognised option must be these options. However any unrecognised option must be
transparently carried by a TCP compression scheme in order to transparently carried by a TCP compression scheme in order to
work efficiently in the presence of new or rare options. work efficiently in the presence of new or rare options.
In the discussion above regarding timestamps it is pointed out that The above list covers options known at the time of writing. Other
there is the possibility (at some time in the future) of negotiations options are expected to be defined. It is important that any future
being permitted more generally than in the SYN packets at connection options can be handled by a header compression scheme. The
set-up. Although there seems to be no compelling need to optimise processing of as yet undefined options cannot be optimised but, at
for this, it is worth pointing out that the compression scheme should the very least, unknown options should be carried transparently.
be able to cope with arbitrary options appearing at any point within
the flow. There is also no guarantee that a compression scheme will
see the SYN packets of a connection set-up.
6. Other observations The current model for TCP options is that an option is negotiated in
the SYN exchange and used thereafter, if the negotiation succeeds.
This leads to some assumptions about the presence of options (being
only on packets with the SYN flag set, or appearing on every packet,
for example). Where such assumptions hold true, it may be possible
to optimise compression of options slightly. However, it is seen as
undesirable to be so constrained, as there is no guarantee that
option handling and negotiation will remain the same in the future.
Also note that a compressor may not process the SYN packets of a flow
and cannot, therefore, be assumed to know which options have been
negotiated.
6.1 Implicit acknowledgements 5. Other observations
5.1 Implicit acknowledgements
There may be a small number of cues for '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 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 direction, for example, then seeing a packet without the SYN flag set
implies that the SYN packet has been received. implies that the SYN packet has been received.
There is a clear requirement for the deployment of compression to be There is a clear requirement for the deployment of compression to be
topologically independent. This means that it is not actually topologically independent. This means that it is not actually
possible to be sure that seeing a data packet at the compressor possible to be sure that seeing a data packet at the compressor
guarantees that the SYN packet has been correctly received by the guarantees that the SYN packet has been correctly received by the
decompressor (as the SYN packet may have taken an alternative path). decompressor (as the SYN packet may have taken an alternative path).
However, it may be that there are other such cues that may be used in However, it may be that there are other such cues that may be used in
certain circumstances to improve compression efficiency. certain circumstances to improve compression efficiency.
6.2 Shared data 5.2 Shared data
It can be seen that there are two distinct deployments -- one where It can be seen that there are two distinct deployments (i) where the
the forward and reverse paths share a link and one where they do not. forward (data) and reverse (ACK) path are both carried over a common
link; and (ii) where the forward (data) and reverse (ACK) path are
carried over different paths, with a specific link carrying packets
corresponding to only one direction of communication.
In the former case a compressor and decompressor could be co-located. In the former case a compressor and decompressor could be co-located.
It may then be possible for the compressor and decompressor at each It may then be possible for the compressor and decompressor at each
end of the link to exchange information. This could lead to possible end of the link to exchange information. This could lead to possible
optimizations. optimizations.
For example, acknowledgement numbers are generally taken from the For example, acknowledgement numbers are generally taken from the
sequence numbers in the opposite direction. Since an acknowledgement sequence numbers in the opposite direction. Since an acknowledgement
cannot be generated for a packet that has not passed across the link, cannot be generated for a packet that has not passed across the link,
this offers an efficient way of encoding acknowledgements. this offers an efficient way of encoding acknowledgements.
6.3 TCP header overhead 5.3 TCP header overhead
For a TCP bulk data-transfer the overhead is not that onerous, For a TCP bulk data-transfer the overhead of the TCP header does not
particularly compared to the typical RTP voice case. Although form a large proportion of the data packet (e.g. <3% for a 1460
spectral efficiency is clearly an important goal, it does not seem octet packet) particularly compared to the typical RTP voice case.
critical to extract every last bit of compression gain. Spectral efficiency is clearly an important goal. However,
extracting every last bit of compression gain offers only marginal
benefit at a considerable cost in complexity. This trade-off, of
efficiency and complexity, must be addressed in the design of a TCP
compression profile.
However, in the acknowledgement direction (i.e. for 'pure' However, in the acknowledgement direction (i.e. for 'pure'
acknowledgement headers) the overhead could be said to be infinite acknowledgement headers) the overhead could be said to be infinite
(since there is no data being carried). This is why optimizations (since there is no data being carried). This is why optimizations
for the acknowledgement path may be considered useful. for the acknowledgement path may be considered useful.
There are a number of schemes for manipulating TCP acknowledgements There are a number of schemes for manipulating TCP acknowledgements
to reduce the ACK bandwidth. Many of these are documented in [36] to reduce the ACK bandwidth. Many of these are documented in [38]
and [35]. Most of these schemes are entirely compatible with header and [37]. Most of these schemes are entirely compatible with header
compression, without requiring any particular support from either. compression, without requiring any particular support from either.
While it is not expected that a compression scheme will support While it is not expected that a compression scheme will be optimised
experimental options, it is useful that these be considered when for experimental options, it is useful that these be considered when
developing header compression schemes, and vice versa. developing header compression schemes, and vice versa. A header
compression scheme must be able to support any option (including ones
as yet undefined).
6.4 Field independence and packet behavior 5.4 Field independence and packet behavior
It should be apparent that direct comparisons with the highly It should be apparent that direct comparisons with the highly
'packet' based view of RTP compression are hard. RTP header fields 'packet' based view of RTP compression are hard. RTP header fields
tend to change regularly per-packet and many fields (IPv4 IP ID, RTP tend to change regularly per-packet and many fields (IPv4 IP ID, RTP
sequence number and RTP timestamp, for example) typically change in a sequence number and RTP timestamp, for example) typically change in a
dependent manner. However, TCP fields, such as sequence number tend dependent manner. However, TCP fields, such as sequence number tend
to change more unpredictably, partly because of the influence of to change more unpredictably, partly because of the influence of
external factors (size of TCP windows, application behavior, etc.) external factors (size of TCP windows, application behavior, etc.)
Also, the field values tend to change indpendently. Overall, this Also, the field values tend to change indpendently. Overall, this
makes compression more challenging and makes it harder to select a makes compression more challenging and makes it harder to select a
set of encodings that can successfully trade-off efficiency and set of encodings that can successfully trade-off efficiency and
robustness. robustness.
6.5 Short-lived flows 5.5 Short-lived flows
It is hard to see what can be done to improve performance for a It is hard to see what can be done to improve performance for a
single, unpredictable, short-lived connection. However, there are single, unpredictable, short-lived connection. However, there are
commonly cases where there will be multiple TCP connections between commonly cases where there will be multiple TCP connections between
the same pair of hosts. As a particular example, consider web the same pair of hosts. As a particular example, consider web
browsing (this is more the case with HTTP/1.0 [15] than HTTP/1.1 browsing (this is more the case with HTTP/1.0 [27] than HTTP/1.1
[22]). [31]).
When a connection closes, it is either the last connection between When a connection closes, it is either the last connection between
that pair of hosts or it is likely that another connection will open 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 within a relatively short space of time. In this case, the IP header
part of the context will probably be almost identical. Certain part of the context (i.e. those fields characterised in Section 2.1)
aspects of the TCP context may also be similar. will probably be almost identical. Certain aspects of the TCP
context may also be similar.
Support for context replication is discussed in more detail in Support for context replication is discussed in more detail in
Section 4. Overall, support for sub-context sharing, or initializing Section 3. Overall, support for sub-context sharing, or initializing
one context from another offers useful optimizations for a sequence one context from another offers useful optimizations for a sequence
of short-lived connections. of short-lived connections.
It is noted that although TCP is connection oriented, it is hard for It is noted that although TCP is connection oriented, it is hard for
a compressor to tell whether or not a TCP flow has finished. For a compressor to tell whether or not a TCP flow has finished. For
example, even in the 'bi-directional' link case, seeing a FIN and the 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 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 FIN cannot be retransmitted. Thus it may be more useful to think
about initializing a new context from an existing one, rather than about initializing a new context from an existing one, rather than
re-using an existing one. re-using an existing one.
As mentioned previously, in Section 5.1.3, the IP header can clearly As mentioned previously, in Section 4.1.3, the IP header can clearly
be shared between any transport-layer flows between the same two be shared between any transport-layer flows between the same two
end-points. There may be limited scope for initialisation of a new end-points. There may be limited scope for initialisation of a new
TCP header from an existing one. The port numbers are the most TCP header from an existing one. The port numbers are the most
obvious starting point. obvious starting point.
6.6 Master Sequence Number 5.6 Master Sequence Number
As pointed out earlier in Section 5.1.3 there is no obvious candidate As pointed out earlier in Section 4.1.3 there is no obvious candidate
for a 'master sequence number' in TCP. Moreover, it is noted that for a 'master sequence number' in TCP. Moreover, it is noted that
such a master sequence number is only required to allow a such a master sequence number is only required to allow a
decompressor to acknowledge packets in bi-directional mode. It can decompressor to acknowledge packets in bi-directional mode. It can
also be seen that such a sequence number would not be required for also be seen that such a sequence number would not be required for
every packet. every packet.
While the sequence number only needs to be 'sparse', it is clear that While the sequence number only needs to be 'sparse', it is clear that
there is a requirement for an explicitly added sequence number. there is a requirement for an explicitly added sequence number.
There are no obvious ways of guaranteeing the unique identity of a There are no obvious ways of guaranteeing the unique identity of a
packet other than by adding such a sequence number (sequence and packet other than by adding such a sequence number (sequence and
acknowledgement numbers can both remain the same, for example). acknowledgement numbers can both remain the same, for example).
As a further note, support for re-ordering of compressed packets 5.7 Size constraint for TCP options
would require a sequence number external to the compressed packet.
This is so that re-ordering could be identified prior to attempting
decompression.
6.7 Size constraint for TCP options
It can be seen from the above analysis, most TCP options, such as As can be seen from the above analysis, most TCP options, such as
MSS, WSopt, SACK-Permitted, may appear only on a SYN segment. Every MSS, WSopt, SACK-Permitted, may appear only on a SYN segment. Every
implementation should (and we expect that most will) ignore unknown implementation should (and we expect that most will) ignore unknown
options on SYN segments. TCP options will be sent on non-SYN options on SYN segments. TCP options will be sent on non-SYN
segments only when an exchange of options on the SYN segments has segments only when an exchange of options on the SYN segments has
indicated that both sides understand the extension. Other TCP indicated that both sides understand the extension. Other TCP
options, such as MD5 Digest, Timestamp also tend to be sent when the options, such as MD5 Digest, Timestamp also tend to be sent when the
connection is initiated (i.e. in the SYN packet). connection is initiated (i.e. in the SYN packet).
The total header size is also an issue. The TCP header specifies The total header size is also an issue. The TCP header specifies
where segment data starts with a 4-bit field which gives the total where segment data starts with a 4-bit field which gives the total
size of the header (including options) in 32-bit words. This means size of the header (including options) in 32-bit words. This means
that the total size of the header plus option must be less than or that the total size of the header plus option must be less than or
equal to 60 bytes -- this leaves 40 bytes for options. equal to 60 bytes -- this leaves 40 bytes for options.
7. Security considerations 6. Security considerations
Since this document only describes TCP field behavior there are no Since this document only describes TCP field behavior there are no
direct security concerns raised by it. direct security concerns raised by it.
This memo is intended to be used to aid the compression of TCP/IP This memo is intended to be used to aid the compression of TCP/IP
headers. Where authentication mechanisms such as IPsec AH [13] are headers. Where authentication mechanisms such as IPsec AH [25] are
used, it is important that compression is transparent. Where used, it is important that compression is transparent. Where
encryption methods such as IPsec ESP [14] are used, the TCP fields encryption methods such as IPsec ESP [26] are used, the TCP fields
may not be visible, preventing compression. may not be visible, preventing compression.
8. Acknowledgements 7. Acknowledgements
Many IP and TCP RFCs (hopefully all of which have been collated Many IP and TCP RFCs (hopefully all of which have been collated
below) have been sources of ideas and knowledge, together with header below) have been sources of ideas and knowledge, together with header
compression schemes from RFC 1144, RFC 2509 and RFC 3095, and of compression schemes from RFC 1144, RFC 2509 and RFC 3095, and of
course the detailed analysis of RTP/UDP/IP in RFC 3095. course the detailed analysis of RTP/UDP/IP in RFC 3095.
This draft also benefited from discussion on the rohc mailing list This draft also benefited from discussion on the rohc mailing list
and in various corridors (virtual or otherwise) about many key and in various corridors (virtual or otherwise) about many key
issues; special thanks to Qian Zhang, Carsten Bormann and Gorry issues; special thanks to Qian Zhang, Carsten Bormann and Gorry
Fairhurst. Fairhurst.
Qian Zhang and Hongbin Liao contributed the extensive analysis of Qian Zhang and Hongbin Liao contributed the extensive analysis of
shareable header fields. shareable header fields.
Any remaining misrepresentation or misinterpretation of information Any remaining misrepresentation or misinterpretation of information
is entirely the fault of the authors. is entirely the fault of the authors.
9. References 8. References
9.1 Normative References
9.2 Informative References 8.1 Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC [3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
896, January 1984. 896, January 1984.
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay [4] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, October 1988. paths", RFC 1072, October 1988.
[5] Braden, R., "Requirements for Internet Hosts - Communication [5] Zweig, J. and C. Partridge, "TCP alternate checksum options",
Layers", STD 3, RFC 1122, October 1989.
[6] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[7] Zweig, J. and C. Partridge, "TCP alternate checksum options",
RFC 1146, March 1990. RFC 1146, March 1990.
[8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[9] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for [7] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[10] Almquist, P., "Type of Service in the Internet Protocol Suite", [8] Braden, B., "T/TCP -- TCP Extensions for Transactions
RFC 1349, July 1992.
[11] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[12] Connolly, T., Amer, P. and P. Conrad, "An Extension to TCP : [9] Connolly, T., Amer, P. and P. Conrad, "An Extension to TCP :
Partial Order Service", RFC 1693, November 1994. Partial Order Service", RFC 1693, November 1994.
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [10] Bellovin, S., "Defending Against Sequence Number Attacks", RFC
November 1998.
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[15] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[16] Bellovin, S., "Defending Against Sequence Number Attacks", RFC
1948, May 1996. 1948, May 1996.
[17] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast [11] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[12] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001, January Retransmit, and Fast Recovery Algorithms", RFC 2001, January
1997. 1997.
[18] and, M., Floyd, S. and A. Romanow, "TCP Selective [13] and, M., Floyd, S. and A. Romanow, "TCP Selective
Acknowledgment Options", RFC 2018, October 1996. Acknowledgment Options", RFC 2018, October 1996.
[19] Bradner, S., "The Internet Standards Process -- Revision 3", [14] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
BCP 9, RFC 2026, October 1996.
[20] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[21] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
[22] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[23] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[24] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[25] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of [15] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[26] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit [16] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999. Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[27] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of [17] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
[28] Degermark, M., Nordgren, B. and S. Pink, "IP Header [18] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[19] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[20] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003.
8.2 Informative References
[21] IANA, "IANA", IANA TCP options, February 1998,
<http://www.iana.org/assignments/tcp-parameters>.
[22] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[23] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[24] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[25] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[26] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[27] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[28] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[29] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[30] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
[31] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[32] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[29] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for [33] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999. Low-Speed Serial Links", RFC 2508, February 1999.
[30] Engan, M., Casner, S. and C. Bormann, "IP Header Compression [34] Engan, M., Casner, S. and C. Bormann, "IP Header Compression
over PPP", RFC 2509, February 1999. over PPP", RFC 2509, February 1999.
[31] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion [35] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Control", RFC 2581, April 1999.
[32] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37, Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000. RFC 2780, March 2000.
[33] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An [36] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[34] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[35] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, [37] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret,
"End-to-end Performance Implications of Slow Links", BCP 48, "End-to-end Performance Implications of Slow Links", BCP 48,
RFC 3150, July 2001. RFC 3150, July 2001.
[36] Balakrishnan, Padmanabhan, V., Fairhurst, G. and M. [38] Balakrishnan, Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of Network Path Sooriyabandara, "TCP Performance Implications of Network Path
Asymmetry", RFC 3449, December 2002. Asymmetry", RFC 3449, December 2002.
[37] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. [39] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F.
Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks", RFC 3481, February 2003. Wireless Networks", RFC 3481, February 2003.
[38] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit [40] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
Congestion Notification (ECN) Signaling with Nonces", RFC TCP", RFC 3522, April 2003.
3540, June 2003.
[39] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522.txt, April 2003.
[40] Karn, Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., [41] Karn, Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R.,
Mahdavi, J., Montenegro, G., Touch, J. and L. Wood, "Advice for Mahdavi, J., Montenegro, G., Touch, J. and L. Wood, "Advice for
Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
Authors' Addresses Authors' Addresses
Mark A. West Mark A. West
Siemens/Roke Manor Research Siemens/Roke Manor Research
Roke Manor Research Ltd. Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN Romsey, Hants SO51 0ZN
UK UK
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/