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 (as the SYN packet may have taken an alternative path).
However, there may be other such cues, which may be used in certain
circumstances to improve compression efficiency.
5.2. Shared Data
It can be seen that there are two distinct deployments (i) where the
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 colocated.
It may then be possible for the compressor and decompressor at each
end of the link to exchange information. This could lead to possible
optimizations.
For example, acknowledgement numbers are generally taken from the
sequence numbers in the opposite direction. Since an acknowledgement
cannot be generated for a packet that has not passed across the link,
this offers an efficient way of encoding acknowledgements.
5.3. TCP Header Overhead
For a TCP bulk data-transfer, the overhead of the TCP header does not
form a large proportion of the data packet (e.g., < 3% for a 1460
octet packet), particularly compared to the typical RTP voice case.
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’
acknowledgement headers), the overhead could be said to be infinite
(since there is no data being carried). This is why optimizations
for the acknowledgement path may be considered useful.
There are a number of schemes for manipulating TCP acknowledgements
to reduce the ACK bandwidth. Many of these are documented in [33]
and [32]. Most of these schemes are entirely compatible with header
compression, without requiring any particular support. While it is
not expected that a compression scheme will be optimised for
experimental options, it is useful to consider these when developing
header compression schemes, and vice versa. A header compression
scheme must be able to support any option (including ones as yet
undefined).
5.4. Field Independence and Packet Behavior
It should be apparent that direct comparisons with the highly
’packet’-based view of RTP compression are hard. RTP header fields
tend to change regularly per-packet, and many fields (IPv4 IP ID, RTP
sequence number, and RTP timestamp, for example) typically change in
a dependent manner. However, TCP fields, such as sequence number
tend to change more unpredictably, partly because of the influence of
external factors (size of TCP windows, application behavior, etc.).
Also, the field values tend to change independently. Overall, this
makes compression more challenging and makes it harder to select a
set of encodings that can successfully trade off efficiency and
robustness.
5.5. Short-Lived Flows
It is hard to see what can be done to improve performance for a
single, unpredictable, short-lived connection. However, there are
commonly cases where there will be multiple TCP connections between
the same pair of hosts. As a particular example, consider web
browsing (this is more the case with HTTP/1.0 [25] than with HTTP/1.1
[26]).
When a connection closes, either it is the last connection between
that pair of hosts or it is likely that another connection will open
within a relatively short space of time. In this case, the IP header
part of the context (i.e., those fields characterised in Section 2.1)
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
Section 3. Overall, support for sub-context sharing or initializing
one context from another offers useful optimizations for a sequence
of short-lived connections.
Note that, although TCP is connection oriented, it is hard for a
compressor to tell whether a TCP flow has finished. For example,
even in the ’bi-directional’ link case, seeing a FIN and the ACK of
the FIN at the compressor/decompressor does not mean that the FIN
cannot be retransmitted. Thus, it may be more useful to think about
initializing a new context from an existing one, rather than re-using
an existing one.
As mentioned previously in Section 4.1.3, the IP header can clearly
be shared between any transport-layer flows between the same two
end-points. There may be limited scope for initialisation of a new
TCP header from an existing one. The port numbers are the most
obvious starting point.
5.6. Master Sequence Number
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 such a master sequence number is only required to allow a
decompressor to acknowledge packets in bi-directional mode. It can
also be seen that such a sequence number would not be required for
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 to guarantee 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).
5.7. Size Constraint for TCP Options
As can be seen from the above analysis, most TCP options, such as
MSS, WSopt, or 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 or 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 that 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.
6. Security Considerations
Since this document only describes TCP field behavior, it raises no
direct security concerns.
This memo is intended to be used to aid the compression of TCP/IP
headers. Where authentication mechanisms such as IPsec AH [24] are
used, it is important that compression be transparent. Where
encryption methods such as IPsec ESP [27] are used, the TCP fields
may not be visible, preventing compression.
7. Acknowledgements
Many IP and TCP RFCs (hopefully all of which have been collated
below), together with header compression schemes from RFC 1144 [22],
RFC 3544 [36], and RFC 3095 [31], and of course the detailed analysis
of RTP/UDP/IP in RFC 3095, have been sources of ideas and knowledge.
Further background information can also be found in [28] and [29].
This document also benefited from discussion on the ROHC mailing list
and in various corridors (virtual or otherwise) about many key
issues; special thanks go to Qian Zhang, Carsten Bormann, and Gorry
Fairhurst.
Qian Zhang and Hongbin Liao contributed the extensive analysis of
shareable header fields.
Any remaining misrepresentation or misinterpretation of information
is entirely the fault of the authors.
8. References
8.1. Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
896, January 1984.
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, October 1988.
[5] Zweig, J. and C. Partridge, "TCP alternate checksum options",
RFC 1146, March 1990.
[6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[7] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[8] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[9] Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP:
Partial Order Service", RFC 1693, November 1994.
[10] Bellovin, S., "Defending Against Sequence Number Attacks", RFC
1948, May 1996.
[11] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[12] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[15] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[16] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[17] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[18] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[19] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003.
8.2. Informative References
[20] IANA, "IANA", IANA TCP options, February 1998,
<http://www.iana.org/assignments/tcp-parameters>.
[21] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[22] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[23] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[24] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[25] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[27] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[26] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[28] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[29] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[30] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[31] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[32] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
end Performance Implications of Slow Links", BCP 48, RFC 3150,
July 2001.
[33] Balakrishnan, Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Path
Asymmetry", RFC 3449, December 2002.
[34] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F.
Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks", RFC 3481, February 2003.
[35] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522, April 2003.
[36] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header
Compression over PPP", RFC 3544, July 2003.
[37] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R.,
Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice
for Internet Subnetwork Designers", BCP 89, RFC 3819, July
2004.
Authors’ Addresses
Mark A. West
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Stephen McCann
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833341
EMail: stephen.mccann@roke.co.uk
URI: http://www.roke.co.uk
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).