draft-ietf-rohc-tcp-field-behavior-00.txt   draft-ietf-rohc-tcp-field-behavior-01.txt 
Network Working Group M. West Network Working Group M. West
Internet-Draft S. McCann Internet-Draft S. McCann
Expires: September 19, 2002 Siemens/Roke Manor Expires: April 28, 2003 Siemens/Roke Manor
March 21, 2002 October 28, 2002
TCP/IP Field Behavior TCP/IP Field Behavior
draft-ietf-rohc-tcp-field-behavior-00.txt draft-ietf-rohc-tcp-field-behavior-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 September 19, 2002. This Internet-Draft will expire on April 28, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This draft describes TCP/IP field behavior in the context of header This draft describes TCP/IP field behavior in the context of header
compression. compression.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General classification . . . . . . . . . . . . . . . . . . . 5 3. General classification . . . . . . . . . . . . . . . . . . . 5
3.1 IP header fields . . . . . . . . . . . . . . . . . . . . . . 6 3.1 IP header fields . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 IPv6 header fields . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 IPv6 header fields . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 IPv4 header fields . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 IPv4 header fields . . . . . . . . . . . . . . . . . . . . . 7
3.2 TCP header fields . . . . . . . . . . . . . . . . . . . . . 10 3.2 TCP header fields . . . . . . . . . . . . . . . . . . . . . 10
3.3 Summary for IP/TCP . . . . . . . . . . . . . . . . . . . . . 11 3.3 Summary for IP/TCP . . . . . . . . . . . . . . . . . . . . . 11
4. Analysis of change patterns of header fields . . . . . . . . 12 4. Classification of shareable header fields . . . . . . . . . 12
4.1 IP header . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Analysis of change patterns of header fields . . . . . . . . 15
4.1.1 IP Traffic-Class / Type-Of-Service (TOS) . . . . . . . . . . 14 5.1 IP header . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 ECN Flags . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 IP Traffic-Class / Type-Of-Service (TOS) . . . . . . . . . . 18
4.1.3 IP Identification . . . . . . . . . . . . . . . . . . . . . 16 5.1.2 ECN Flags . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 Don't Fragment (DF) flag . . . . . . . . . . . . . . . . . . 18 5.1.3 IP Identification . . . . . . . . . . . . . . . . . . . . . 19
4.1.5 IP Hop-Limit / Time-To-Live (TTL) . . . . . . . . . . . . . 18 5.1.4 Don't Fragment (DF) flag . . . . . . . . . . . . . . . . . . 21
4.2 TCP header . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.5 IP Hop-Limit / Time-To-Live (TTL) . . . . . . . . . . . . . 21
4.2.1 Sequence number . . . . . . . . . . . . . . . . . . . . . . 18 5.2 TCP header . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Acknowledgement number . . . . . . . . . . . . . . . . . . . 19 5.2.1 Sequence number . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3 Reserved . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.2 Acknowledgement number . . . . . . . . . . . . . . . . . . . 23
4.2.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.3 Reserved . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.5 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.6 Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.5 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.7 Urgent pointer . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.6 Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.7 Urgent pointer . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Options overview . . . . . . . . . . . . . . . . . . . . . . 23 5.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2 Option field behavior . . . . . . . . . . . . . . . . . . . 23 5.3.1 Options overview . . . . . . . . . . . . . . . . . . . . . . 26
5. Other observations . . . . . . . . . . . . . . . . . . . . . 31 5.3.2 Option field behavior . . . . . . . . . . . . . . . . . . . 27
5.1 Implicit acknowledgements . . . . . . . . . . . . . . . . . 31 6. Other observations . . . . . . . . . . . . . . . . . . . . . 35
5.2 Shared data . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1 Implicit acknowledgements . . . . . . . . . . . . . . . . . 35
5.3 TCP header overhead . . . . . . . . . . . . . . . . . . . . 31 6.2 Shared data . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Field independence and packet behavior . . . . . . . . . . . 32 6.3 TCP header overhead . . . . . . . . . . . . . . . . . . . . 35
5.5 Short-lived flows . . . . . . . . . . . . . . . . . . . . . 32 6.4 Field independence and packet behavior . . . . . . . . . . . 36
5.6 Master Sequence Number . . . . . . . . . . . . . . . . . . . 33 6.5 Short-lived flows . . . . . . . . . . . . . . . . . . . . . 36
6. Security considerations . . . . . . . . . . . . . . . . . . 33 6.6 Master Sequence Number . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 6.7 Size constraint for TCP options . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. Security considerations . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . 37 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document describes TCP/IP field behavior, as it is essential to This document describes TCP/IP field behavior, as it is essential to
understand this before correct assumptions about header compression understand this before correct assumptions about header compression
can be made. can be made.
Since the IP header does exhibit some slightly different behavior Since the IP header does exhibit some slightly different behavior
from that previously presented in RFC 3095 [28] for the RTP case, it from that previously presented in RFC 3095 [28] for the RTP case, it
is also included in this document. is 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
[28] has been borrowed. This is for easier reading rather than [28] 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 [28] TCP/IP header Again based on the format presented in RFC 3095 [28] 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 3 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. A less stable but the implementation and on the application used. Section 4 considers
more detailed analysis of the change characteristics is then done in how field values can be used to optimize short-lived flows. A less
Section 4. Finally, Section 5 summarizes this appendix with stable but more detailed analysis of the change characteristics is
then done in Section 5. Finally, Section 6 summarizes with
conclusions about how the various header fields should be handled by conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and the header compression 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 up-to- considered? For the purposes of this document, a relatively up-to-
date (as of the time of writing) implementation is considered, with a date (as of the time of writing) implementation is considered, with a
view to ensuring compatibility with legacy implementations. view to ensuring compatibility with legacy implementations.
skipping to change at page 4, line 13 skipping to change at page 4, line 13
solution. solution.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [18]. document are to be interpreted as described in RFC 2119 [18].
3. General classification 3. General classification
Definitions (and some text) copied from RFC 3095 [28] Appendix A. The following definitions (and some text) are copied from RFC 3095
Differences between IP field behavior between RFC 3095 [28] (i.e. [28] Appendix A. Differences between IP field behavior between RFC
IP/UDP/RTP behavior for audio and video applications) and this 3095 [28] (i.e. IP/UDP/RTP behavior for audio and video
document have been identified. applications) and this document have been identified.
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.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
| 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 |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
* differs from RFC 3095 [28] * differs from RFC 3095 [28]
[The DSCP, ECT and CE flags were amalgamated into the Traffic Class
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.
o Flow Label o Flow Label
skipping to change at page 7, line 27 skipping to change at page 7, line 27
| 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 |
+---------------------+-------------+----------------+ +---------------------+-------------+----------------+
* differs from RFC 3095 [28] * differs from RFC 3095 [28]
[The DSCP, ECT and CE flags were amalgamated into the TOS octet in
RFC 3095.
The DF flag behaviour is considered later.
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
classified as STATIC. classified as STATIC.
o Header Length o Header Length
skipping to change at page 11, line 18 skipping to change at page 11, line 18
| 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 |
+----------------+----------------+----------------+ +----------------+----------------+----------------+
(excludes options, which are all classified as CHANGING) (excludes options, which are all classified as CHANGING)
4. Analysis of change patterns of header fields 4. Classification of shareable header fields
For multiple flows that overlap in time (or occur sequentially within
a relatively short space of time), there can be much similarity in
header field values (and hence context values) among those
connections. To utilize these properties for header compression, it
is important to understand the shareable characteristics for the
various header fields and context values.
The intent here is to use an existing context as a baseline and to
'replicate' it to create a new context. The fields that have changed
will be updated in the replicated context. Hence it is important to
understand the degree of commonality between fields in different
flows.
A brief analysis of the relationship of TCP/IP fields among
'shareable' packet streams is given here.
'N/A' The field need not be shared since it can be inferred or
is used to define a packet flow.
'No' The field cannot be shared since its change pattern
between two packet flows is uncorrelated.
'Yes' The field can be shared. Specific encoding methods can
be used to improve the compression efficiency.
IPv4 Header (inner and/or outer)
Field Class Shareable
------------------------------------------------
Version STATIC N/A
Header Length STATIC-KNOWN Yes
DSCP CHANGING Yes (1)
Packet Length INFERRED N/A
Identification CHANGING Yes (2)
Reserved flag STATIC-KNOWN No (3)
Don't Fragment flag STATIC No
More Fragments flag STATIC-KNOWN No
Fragment Offset STATIC-KNOWN No
Time To Live CHANGING Yes
Protocol STATIC N/A
Header Checksum INFERRED N/A
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
(1) DSCP is marked based on the application's requirement.
Considering that shareable connections usually belong to same type
of traffic, it may be regarded as shareable.
(2) The shareable context for this field includes IP-ID, NBO, and RND
flags (as described in ROHC RTP).
(3) Since the possible future behavior of the 'Reserved Flag' cannot
be predicted, it is not considered as shareable. However, it
might be expected that the behaviour of the reserved flag between
the same end-points will be similar. In this case, any selection
of packet formats (for example) based on this behaviour might
carry across to the new flow. In the case of packet formats, this
can probably be considered as a compressor-local decision.
IPv6 Header (inner and/or outer)
Field Class Shareable
------------------------------------------------
Version STATIC N/A
Traffic Class CHANGING No
Flow Label STATIC-DEF N/A
Payload Length INFERRED N/A
Next Header STATIC N/A
Hop Limit CHANGING Yes
Source Address STATIC-DEF N/A
Destination Address STATIC-DEF N/A
TCP Header
Field Class Shareable
------------------------------------------------
Source Port STATIC-DEF Yes (4)
Destination Port STATIC-DEF Yes (4)
Sequence Number CHANGING No (5)
Acknowledgement Number CHANGING No
Data Offset INFERRED N/A
Reserved Bits CHANGING No (6)
Control Bits
URG CHANGING No
ACK CHANGING No
PSH CHANGING No
RST CHANGING No
SYN CHANGING No
FIN CHANGING No
Window CHANGING Yes (7)
CHECKSUM CHANGING No
Urgent Pointer CHANGING No
(4) On the server side, the port number is likely to be a well-known
value. On the client side, the port number is generally selected
by the stack automatically. Whether the port number is shareable
depends upon how the stack chooses the port number. However, most
implementations use a simple scheme which sequentially picks the
next available port number. This is clearly exploitable in
compression.
(5) With the recommendation (and expected deployment) of TCP Initial
Sequence Number randomization, defined in RFC 1948 [13], it will
be impossible to share the sequence number. Thus, this field will
not be regarded as shareable.
(6) Clearly the ECN flags are not considered shareable (if ECT is
enabled). Otherwise, the same caveats as with the IP reserved
flag (see point (3), above) apply.
(7) The window here should be referred to as the initial value (or
maximum value) of RWND. Since sharable packet streams are likely
to have the same initial RWND, this can help optimize the SYN
packet size for short-lived TCP flows.
ECN Flags
Field Class Shareable
------------------------------------------------
ECT CHANGING No (8)
CE CHANGING No
ECN CHANGING No
CWR CHANGING No
(8) We assume that the IP ECN bits will make use of the ECN nonce
scheme. Therefore, none of the ECN flags can be regarded as
shareable.
TCP Options
Option SYN-only (9) Shareable
-----------------------------------------------------
End of option list Option No No
No-Operation Option No No
Maximum Segment Size Option Yes Yes
Window Scale Option Yes Yes
SACK-Permitted Option Yes Yes
SACK Option No No
Timestamps Option No Yes
(9) SYN-only indicates whether the options only appear in SYN packet
or not. For 'yes', the option only appears in SYN packet;
otherwise, the option may appear in any packet.
Many TCP options are used only in SYN packets. Some options, such
as MSS, Window Scale, SACK-Permitted etc., will tend to have the
same value among shareable packet streams.
Thus, to support context sharing, the compressor should maintain
such TCP options in the context (even though they only appear in
the SYN segment).
5. 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 13, line 4 skipping to change at page 16, line 28
| IP DF flag(4) | Value | RC | UNKNOWN | | IP DF flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED | | IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
| TCP Sequence Number ª Delta ª IRREGULAR ª LIMITED ª | TCP Sequence Number ª Delta ª IRREGULAR ª LIMITED ª
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
ª TCP Acknowledgement Numª Delta ª IRREGULAR ª LIMITED ª ª TCP Acknowledgement Numª Delta ª IRREGULAR ª LIMITED ª
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
ª TCP Reserved ª Value ª RC ª UNKNOWN ª ª TCP Reserved ª Value ª RC ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
ª TCP ECN flags ª Value ª IRREGULAR ª UNKNOWN ª ª TCP flags ª
+------------------------+-------------+-------------+-------------+ ª ECN flags ª Value ª IRREGULAR ª UNKNOWN ª
ª TCP CWR flag ª Value ª IRREGULAR ª UNKNOWN ª ª CWR flag ª Value ª IRREGULAR ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+ ª ECE flag ª Value ª IRREGULAR ª UNKNOWN ª
ª TCP ECE flag ª Value ª IRREGULAR ª UNKNOWN ª ª URG flag ª Value ª IRREGULAR ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+ ª ACK flag ª Value ª SEMISTATIC ª KNOWN ª
ª TCP URG flag ª Value ª IRREGULAR ª UNKNOWN ª ª PSH flag ª Value ª IRREGULAR ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+ ª RST flag ª Value ª IRREGULAR ª UNKNOWN ª
ª TCP ACK flag ª Value ª SEMISTATIC ª KNOWN ª ª SYN flag ª Value ª SEMISTATIC ª KNOWN ª
+------------------------+-------------+-------------+-------------+ ª FIN flag ª Value ª SEMISTATIC ª KNOWN ª
ª TCP PSH flag ª Value ª IRREGULAR ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+
ª TCP RST flag ª Value ª IRREGULAR ª UNKNOWN ª
+------------------------+-------------+-------------+-------------+
ª TCP SYN flag ª Value ª SEMISTATIC ª KNOWN ª
+------------------------+-------------+-------------+-------------+
ª TCP FIN flag ª Value ª SEMISTATIC ª KNOWN ª
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
ª TCP Window ª Value ª ALTERNATING ª KNOWN ª ª TCP 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 ª
+------------------------+-------------+-------------+-------------+ +------------------------+-------------+-------------+-------------+
Table 1 : Classification of CHANGING header fields Table 1 : Classification of CHANGING header fields
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.
4.1 IP header 5.1 IP header
4.1.1 IP Traffic-Class / Type-Of-Service (TOS) 5.1.1 IP Traffic-Class / Type-Of-Service (TOS)
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field might be The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field might be
expected to change during the lifetime of a packet stream. This 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 [4] extended this to specify 5 bits of TOS, although be 0). RFC 1122 [4] extended this to specify 5 bits of TOS, although
the meanings of the additional 2 bits were not defined. RFC 1349 [9] the meanings of the additional 2 bits were not defined. RFC 1349 [9]
skipping to change at page 14, line 21 skipping to change at page 17, line 38
data. From a future proofing perspective, it is preferable to assume data. From a future proofing perspective, it is preferable to assume
the use of ECN, especially with respect to TCP. 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. frequently (although it could change mid-flow, for example as a
result of a route change).
4.1.2 ECN Flags 5.1.2 ECN Flags
Initially we describe the ECN flags as specified in RFC 2481 [21]. Initially we describe the ECN flags as specified in RFC 2481 [21].
Subsequently, a suggested update is described which would alter the Subsequently, a suggested update is described which would alter the
behaviour of the flags. behaviour of the flags.
In RFC 2481 [21] there are 2 separate flags, the ECT (ECN Capable In RFC 2481 [21] 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
skipping to change at page 15, line 17 skipping to change at page 18, line 35
will be relatively rarely seen. The probability of seeing a will be relatively rarely seen. The probability of seeing a
congestion indication depends upon the level of congestion in the congestion indication depends upon the level of congestion in the
network and this depends upon many factors. However, it is likely network and this depends upon many factors. However, it is likely
that the probability is non-trivial and may, in many cases, be that the probability is non-trivial and may, in many cases, be
significant. significant.
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.
4.1.3 IP Identification 5.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 17, line 10 skipping to change at page 20, line 29
'master sequence number' role. '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.
4.1.4 Don't Fragment (DF) flag 5.1.4 Don't Fragment (DF) flag
Due to the use of path-MTU discovery RFC 1191 [7], the value is more Due to the use of path-MTU discovery RFC 1191 [7], the value is more
likely to be '1', than found in UDP/RTP streams since DF should be likely to be '1', than found in UDP/RTP streams since DF should be
periodically set to check for fragmentation in the end-to-end path. periodically set to check for fragmentation in the end-to-end path.
In practice it is hard to predict the behavior of this field. In practice it is hard to predict the behavior of this field.
However, it is considered that the most likely case is that it will However, it is considered that the most likely case is that it will
generally stay at either '0' (periodically being set to '1') or '1'. generally stay at either '0' (periodically being set to '1') or '1'.
4.1.5 IP Hop-Limit / Time-To-Live (TTL) 5.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.
4.2 TCP header 5.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 [5]. However, the premise of how the compression is RFC 1144 [5]. 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.
4.2.1 Sequence number 5.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
skipping to change at page 18, line 40 skipping to change at page 22, line 12
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
commonly applies, coalescing small packets where possible to reduce commonly applies, coalescing small packets where possible to reduce
the basic header overhead. This may also mean that is less likely the basic header overhead. This may also mean that is less likely
that predictable changes in the sequence number will occur. that predictable changes in the sequence number will occur.
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.
4.2.2 Acknowledgement number 5.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. It may be seen from this that the delta for every 2 data segments. It may be seen from this that the delta for
the acknowledgement number is roughly twice that of the sequence the acknowledgement number is roughly twice that of the sequence
number. This is not always the case and the discussion about number. This is not always the case and the discussion about
sequence number irregularity should be applied. sequence number irregularity should be applied.
skipping to change at page 19, line 18 skipping to change at page 22, line 37
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.
4.2.3 Reserved 5.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.
4.2.4 Flags 5.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
skipping to change at page 20, line 43 skipping to change at page 24, line 15
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]
4.2.5 Checksum 5.2.5 Checksum
Carried as the end-to-end check for the TCP data. See RFC 1144 [5] Carried as the end-to-end check for the TCP data. See RFC 1144 [5]
for a discussion of why this should be carried. There may be more for a discussion of why this should be carried. There may be more
complex interactions with error detection and robustness that would complex interactions with error detection and robustness that would
have to be addressed in a TCP header compression scheme. The TCP have to be addressed in a TCP header compression scheme. The TCP
checksum has to be considered as randomly changing. checksum has to be considered as randomly changing.
4.2.6 Window 5.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.
4.2.7 Urgent pointer 5.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, from the discussion of the TCP Checksum above, it should be
realized that this enforces bitwise transparency of the scheme and so realized that this enforces bitwise transparency of the scheme and so
this argument is not particularly important. this argument is not particularly important.
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 be point to anywhere in the window. This may
be set (and changing) over several segments. Note that urgent data be set (and changing) over several segments. Note that urgent data
is rarely used, since it is not a particularly clean way of managing is rarely used, since it is not a particularly clean way of managing
out-of-band data. out-of-band data.
4.3 Options 5.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.
4.3.1 Options overview 5.3.1 Options overview
Table 2 classifies the IANA known options together with their Table 2 classifies the IANA known options together with their
associated RFCs, if applicable, from IANA [34] associated RFCs, if applicable, from IANA [34]
+------+--------+------------------------------------+------------+ +------+--------+------------------------------------+------------+
ª Kind ª Length ª Meaning ª RFC ª ª Kind ª Length ª Meaning ª RFC ª
ª ª(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 ª
ª 5 ª N ª SACK ª RFC 2018 ª ª 5 ª N ª SACK ª RFC 2018 ª
skipping to change at page 22, line 45 skipping to change at page 26, line 39
ª 21 ª ª Selective Negative Acknowledgementsª ª ª 21 ª ª Selective Negative Acknowledgementsª ª
ª 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 Table 2 Description of common TCP options
4.3.2 Option field behavior 5.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,
skipping to change at page 23, line 28 skipping to change at page 27, line 21
This option code may be used between options, for example, to This option code may be used between options, for example, to
align the beginning of a subsequent option on a word boundary. align the beginning of a subsequent option on a word boundary.
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
certain alignment and that compression need only convey this
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 receive segment size at the TCP that sends this segment. This
field must only be sent in the initial connection request field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this (i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed RFC 793 [2]. 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
skipping to change at page 30, line 6 skipping to change at page 34, line 5
Are non-RFC references and are not considered in this document. Are non-RFC references and are not considered in this document.
In the discussion above regarding timestamps it is pointed out that In the discussion above regarding timestamps it is pointed out that
there is the possibility (at some time in the future) of negotiations there is the possibility (at some time in the future) of negotiations
being permitted more generally than in the SYN packets at connection being permitted more generally than in the SYN packets at connection
set-up. Although there seems to be no compelling need to optimise set-up. Although there seems to be no compelling need to optimise
for this, it is worth pointing out that the compression scheme should for this, it is worth pointing out that the compression scheme should
be able to cope with arbitrary options appearing at any point within be able to cope with arbitrary options appearing at any point within
the flow. the flow.
5. Other observations 6. Other observations
5.1 Implicit acknowledgements 6.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.
It may be that there are other such cues that may be used in certain It is worth pointing out the implication of the requirement for
circumstances to improve compression efficiency. compression to be topologically independent. This means that it is
not actually possible to be sure that seeing a data packet at the
compressor guarantees that the SYN packet has been correctly received
by the decompressor.
5.2 Shared data However, it may be that there are other such cues that may be used in
certain circumstances to improve compression efficiency.
6.2 Shared data
At the risk of drifting into solution space, it can be seen that At the risk of drifting into solution space, it can be seen that
there are two distinct deployments -- one where the forward and there are two distinct deployments -- one where the forward and
reverse paths share a link and one where they do not. reverse paths share a link and one where they do not.
In the former case it may be the case that a compressor and In the former case it may be the case that a compressor and
decompressor could be co-located. It may then be possible for the decompressor could be co-located. It may then be possible for the
compressor and decompressor at each end of the link to exchange compressor and decompressor at each end of the link to exchange
information. This could lead to possible optimizations. information. This could lead to possible 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.
5.3 TCP header overhead 6.3 TCP header overhead
For a TCP bulk data-transfer the overhead is not that onerous, For a TCP bulk data-transfer the overhead is not that onerous,
particularly compared to the typical RTP voice case. Although particularly compared to the typical RTP voice case. Although
spectral efficiency is clearly an important goal, it does not seem spectral efficiency is clearly an important goal, it does not seem
critical to extract every last bit of compression gain. critical to extract every last bit of compression gain.
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 [33] to reduce the ACK bandwidth. Many of these are documented in [33]
and [29]. Most of these schemes are entirely compatible with header and [29]. 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 support
experimental options, it is useful that these be considered when experimental options, it is useful that these be considered when
developing header compression schemes, and vice versa. developing header compression schemes, and vice versa.
5.4 Field independence and packet behavior 6.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.
5.5 Short-lived flows 6.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 [12] than HTTP/1.1 browsing (this is more the case with HTTP/1.0 [12] than HTTP/1.1
[17]). [17]).
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 will probably be almost identical. Certain
aspects of the TCP context may also be similar. aspects of the TCP context may also be similar.
For example, it may be that one of the port numbers will stay the Support for context replication is discussed in more detail in
same (the service port) and the other will change by a small amount Section 4. Overall, support for sub-context sharing, or initializing
relative to the just-closed connection (the ephemeral port). Also, one context from another offers useful optimizations for a sequence
unless RFC 1948 [13] ISN selection is implemented, the initial of short-lived connections.
sequence number for the SYN packet may be 'close' to the sequence
number range used for the closed connection.
Thus, support for sub-context sharing, or initializing one context
from another offers useful optimizations for a sequence of short-
lived connections.
It is noted that although TCP is connection oriented, it is hard to It is noted that although TCP is connection oriented, it is hard for
tell at a middle-box 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 4.1.3, the IP header can clearly As mentioned previously, in Section 5.1.3, the IP header can clearly
be shared between any transport-layer flows between the same two end- be shared between any transport-layer flows between the same two end-
points. There may be limited scope for initialisation of a new TCP points. There may be limited scope for initialisation of a new TCP
header from an existing one. The port numbers are the most obvious header from an existing one. The port numbers are the most obvious
starting point. starting point.
5.6 Master Sequence Number 6.6 Master Sequence Number
As pointed out earlier in Section 4.1.3 there is no obvious candidate As pointed out earlier in Section 5.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
there is a requirement for an explicitly added sequence number.
There are no obvious ways of guaranteeing the unique identity of a
packet other than by adding such a sequence number (sequence and
acknowledgement numbers can both remain the same, for example).
As a further note, support for re-ordering of compressed packets As a further note, support for re-ordering of compressed packets
would require a sequence number external to the compressed packet. would require a sequence number external to the compressed packet.
This is so that re-ordering could be identified prior to attempting This is so that re-ordering could be identified prior to attempting
decompression. decompression.
6. Security considerations 6.7 Size constraint for TCP options
It can be seen from the above analysis, most TCP options, such as
MSS, WSopt, SACK-Permitted, may appear only on a SYN segment. Every
implementation should (and we expect that most will) ignore unknown
options on SYN segments. TCP options will be sent on non-SYN
segments only when an exchange of options on the SYN segments has
indicated that both sides understand the extension. Other TCP
options, such as MD5 Digest, Timestamp also tend to be sent when the
connection is initiated (i.e. in the SYN packet).
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
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
equal to 60 bytes -- this leaves 40 bytes for options.
7. 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.
7. Acknowledgements 8. 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
shareable header fields.
Any remaining misrepresentation or misinterpretation of information Any remaining misrepresentation or misinterpretation of information
is entirely the fault of the authors of this draft. is entirely the fault of the authors of this draft.
References 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,
 End of changes. 

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