draft-ietf-rohc-tcp-requirements-02.txt   draft-ietf-rohc-tcp-requirements-03.txt 
Network Working Group Lars-Erik Jonsson, Ericsson Network Working Group Lars-Erik Jonsson
INTERNET-DRAFT Sweden INTERNET-DRAFT Ericsson
Expires: May 2002 November 21, 2001 Expires: August 2002 February 15, 2002
Requirements for ROHC IP/TCP Header Compression Requirements for ROHC IP/TCP Header Compression
<draft-ietf-rohc-tcp-requirements-02.txt> <draft-ietf-rohc-tcp-requirements-03.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Abstract Abstract
This document contains requirements for the IP/TCP header compression This document contains requirements for the IP/TCP header compression
scheme (profile) to be developed by the ROHC WG. The structure of scheme (profile) to be developed by the ROHC WG. The structure of
this document is inherited from the document defining IP/UDP/RTP this document is inherited from the document defining IP/UDP/RTP
requirements for ROHC. requirements for ROHC.
0. Document history 0. Document history
February 23, 2001 - draft-ietf-rohc-tcp-requirements-00.txt 00: February 23, 2001
Initial version to initiate discussion of TCP aspects in ROHC.
June 20, 2001 - draft-ietf-rohc-tcp-requirements-01.txt
01: June 20, 2001:
ECN requirements, note to "Short lived TCP transfers", and a ECN requirements, note to "Short lived TCP transfers", and a
section discussing the IPR issue have been added. section discussing the IPR issue have been added.
November 21, 2001 - draft-ietf-rohc-tcp-requirements-02.txt 02: November 21, 2001:
The error propagation requirement has been split in two parts
and updated. Further references to PILC documents and a note
on "Ubiquity" regarding TCP variants have been added.
The error propagation requirement has been split in two parts and 03: February 7, 2002:
updated. Further have references to PILC documents and a note for Several minor corrections, and a new requirement added
"Ubiquity" about TCP versions been added. regarding misordering between compressor and decompressor.
1. Introduction 1. Introduction
The goal of the ROHC WG is to develop header compression schemes that The goal of the ROHC WG is to develop header compression schemes that
perform well over links with high error rates and long link roundtrip perform well over links with high error rates and long link roundtrip
times. The schemes must perform well for cellular links, using times. The schemes must perform well for cellular links, using
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
should also be applicable to other future link technologies with high should also be applicable to other future link technologies with high
loss and long roundtrip times. loss and long roundtrip times.
The main objective for ROHC has been robust compression of The main objective for ROHC has been robust compression of
IP/UDP/RTP, but the WG is also chartered to develop new header IP/UDP/RTP, but the WG is also chartered to develop new header
compression solutions for IP/TCP [RFC-791, RFC-793]. Since TCP compression solutions for IP/TCP [RFC-791, RFC-793]. Since TCP
traffic, in contrast to RTP, has usually been sent over reliable traffic, in contrast to RTP, has usually been sent over reliable
links, existing schemes for TCP [RFC-1144, RFC-2507] have not links, existing schemes for TCP [RFC-1144, RFC-2507] have not
experienced the same robustness problems as RTP compression. However, experienced the same robustness problems as RTP compression. However,
there are still many scenarios where TCP header compression will be there are still many scenarios where TCP header compression will be
implemented over less reliable links [RFC-3150, PILC-ARQ], making implemented over less reliable links [RFC-3150, PILC-ARQ], making
robustness an important objective also for the new TCP compression robustness an important objective also for the new TCP compression
scheme. Other, as important, objectives for ROHC TCP compression are; scheme. Other, equally important, objectives for ROHC TCP compression
improved compression efficiency, enhanced capabilities for are: improved compression efficiency, enhanced capabilities for
compression of header fields including TCP options, and finally compression of header fields including TCP options, and finally
incorporation of TCP compression into the ROHC framework [RFC-3095]. incorporation of TCP compression into the ROHC framework [RFC-3095].
2. Header compression requirements 2. Header compression requirements
The following requirements have, more or less arbitrarily, been The following requirements have, more or less arbitrarily, been
divided into five groups. The first group deals with requirements divided into five groups. The first group deals with requirements
concerning the impact of a header compression scheme on the rest of concerning the impact of a header compression scheme on the rest of
the Internet infrastructure. The second group defines what kind of the Internet infrastructure. The second group defines what kind of
headers that must be compressed efficiently while the third and forth headers must be compressed efficiently, while the third and fourth
groups concern performance requirements and capability requirements groups concern performance requirements and capability requirements
which stem from the properties of the anticipated link technologies. which stem from the properties of the anticipated link technologies.
Finally, the fifth section discusses Intellectual Property Rights Finally, the fifth section discusses Intellectual Property Rights
related to ROHC TCP compression. related to ROHC TCP compression.
2.1. Impact on Internet infrastructure 2.1. Impact on Internet infrastructure
1. Transparency: When a header is compressed and then decompressed, 1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the the resulting header must be semantically identical to the
original header. If this cannot be achieved, the packet original header. If this cannot be achieved, the packet
skipping to change at page 3, line 29 skipping to change at page 3, line 29
2. Ubiquity: Must not require modifications to existing IP (v4 or 2. Ubiquity: Must not require modifications to existing IP (v4 or
v6) or TCP implementations. v6) or TCP implementations.
Justification: Ease of deployment. Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the TCP streams emitted by compression efficiency for the TCP streams emitted by
implementations. However, ROHC cannot rely on such implementations. However, ROHC cannot rely on such
recommendations being followed. recommendations being followed.
Note: Several TCP versions are currently in use on the Internet. Note: Several TCP variants are currently in use on the Internet.
This requirement implies that the header compression scheme must This requirement implies that the header compression scheme must
work efficiently and correct for all expected TCP versions. work efficiently and correctly for all expected TCP variants.
2.2. Supported headers and kinds of TCP streams 2.2. Supported headers and kinds of TCP streams
1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that 1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that
all possible changes in the IP header fields must be handled by all possible changes in the IP header fields must be handled by
the compression scheme and commonly changing fields should be the compression scheme, and commonly changing fields should be
compressed efficiently. The compression scheme must consider as compressed efficiently. Compression must not be disabled if IPv4
normal operation the scenario where Early Congestion Notification Options or IPv6 Extensions are present. The compression scheme
[RFC-3168] is used and support efficient compression also in the must further consider as normal operation the scenario where
case when the ECN bits are used. Explicit Congestion Notification (ECN) [RFC-3168] is applied and
support efficient compression also in the case when the ECN bits
are used.
Justification: IPv4 and IPv6 will both be around during the Justification: IPv4 and IPv6 will both be around for the
foreseeable future. ECN is expected to get a breakthrough and be foreseeable future, and Options/Extensions are expected to be
more commonly used. ECN is expected to have a breakthrough and be
widely deployed, especially in combination with TCP. widely deployed, especially in combination with TCP.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
supported and should be compressed efficiently. For IPv4 these supported and should be compressed efficiently. For IPv4 these
include headers of tunneled packets. For IPv6 these include include headers of tunneled packets. For IPv6 they include
headers containing the Routing Header, the Binding Update headers containing the Routing Header, the Binding Update
Destination Option, and the Home Address option. Destination Option, and the Home Address Option.
Justification: It is very likely that Mobile IP will be used by Justification: It is very likely that Mobile IP will be used by
cellular devices. cellular devices.
3. Generality: Must compress headers from arbitrary TCP streams. 3. Generality: Must handle all headers from arbitrary TCP streams.
Justification: There must be a generic scheme which can compress Justification: There must be a generic scheme which can compress
reasonably well for any TCP traffic pattern. This does not reasonably well for any TCP traffic pattern. This does not
preclude optimizations for certain traffic patterns. preclude optimizations for certain traffic patterns.
Note: This applies to the TCP stream before as well as after it
has passed through an internet.
4. IPSEC: The scheme should be able to compress headers containing 4. IPSEC: The scheme should be able to compress headers containing
IPSEC sub-headers. IPSEC sub-headers.
Justification: IPSEC is expected to be used to provide necessary Justification: IPSEC is expected to be used to provide necessary
end-to-end security. end-to-end security.
Note: It is of course not possible to compress the encrypted part Note: It is not possible to compress the encrypted part of an ESP
of an ESP header, nor the cryptographic data in an AH header. header, nor the cryptographic data in an AH header.
5. TCP: All fields supported by [RFC-2507] must be handled with 5. TCP: All fields supported by [RFC-2507] should be handled with
efficient compression, and so also the cases when the SYN, FIN or efficient compression, and so also the cases when the SYN, FIN or
ECN bits are set. TCP ECN [RFC-3168] bits are set.
Justification: These bits are expected to be commonly used. Justification: These bits are expected to be commonly used.
6. TCP options: The scheme must support compression of packets with 6. TCP options: The scheme must support compression of packets with
any TCP option present, even if the option itself is not any TCP option present, even if the option itself is not
compressed. Further, for some commonly used options the scheme compressed. Further, for some commonly used options the scheme
should provide compression mechanisms also for the options. should provide compression mechanisms also for the options.
Justification: Since various TCP options are commonly used, Justification: Since various TCP options are commonly used,
applicability of the compression scheme would be significantly applicability of the compression scheme would be significantly
reduced if packets with options could not be compressed. reduced if packets with options could not be compressed.
Note: Options that should be compressed are: Note: Options that should be compressed are:
- Window scale, [RFC-1323]
- Selective Acknowledgement (SACK), [RFC-2018, RFC-2883] - Selective Acknowledgement (SACK), [RFC-2018, RFC-2883]
- Timestamp, [RFC-1323] - Timestamp, [RFC-1323]
2.3. Performance issues 2.3. Performance issues
1. Performance/Spectral Efficiency: Must provide low relative 1. Performance/Spectral Efficiency: The scheme must provide low
overhead under expected operating conditions; compression relative overhead under expected operating conditions;
efficiency should be better than for RFC2507 under equivalent compression efficiency should be better than for RFC2507 under
operating conditions. equivalent operating conditions.
Justification: Spectrum efficiency is a primary goal. Justification: Spectrum efficiency is a primary goal.
Note: the relative overhead is the average header overhead Note: The relative overhead is the average header overhead
relative to the payload. Any auxiliary (e.g., control or relative to the payload. Any auxiliary (e.g., control or
feedback) channels used by the scheme should be taken into feedback) channels used by the scheme should be taken into
account when calculating the header overhead. account when calculating the header overhead.
2. Loss propagation: Loss propagation due to header compression 2. Losses between compressor and decompressor: The scheme should make
should be avoided. Loss propagation is defined as the loss of sure that losses between compressor and decompressor do not
headers subsequent to headers lost by the link, even if those result in losses of subsequent packets, or cause damage to the
subsequent headers are not lost by the link. context that result in incorrect decompression of subsequent
packet headers.
Justification: Even though link layer retransmission in most Justification: Even though link layer retransmission in most cases
cases is expected to make loss propagation an irrelevant issue, is expected to almost eliminate losses between compressor and
there are still many scenarios where TCP header compression will decompressor, there are still many scenarios where TCP header
be implemented over less reliable links [RFC-3150, PILC-ARQ]. In compression will be implemented over less reliable links [RFC-
such cases, loss propagation due to header compression could 3150, PILC-ARQ]. In such cases, loss propagation due to header
affect certain TCP mechanisms that are capable of handling some compression could affect certain TCP mechanisms that are capable
losses, and thereby cause significant performance degradation. of handling some losses, and have a negative impact on the
performance of TCP loss recovery.
3. Damage propagation and handling of residual errors: Damage 3. Residual errors in compressed headers: Residual errors in
propagation is defined as the damage of headers subsequent to compressed headers may result in delivery of incorrectly
headers damaged by the link, even if those subsequent headers are decompressed headers not only for the damaged packet itself, but
not damaged by the link. For TCP, the compression scheme is not also for subsequent packets, since errors may be saved in the
required to explicitly implement mechanisms for damage context state. For TCP, the compression scheme is not required to
propagation avoidance, but the compression scheme must not affect implement explicit mechanisms for residual error detection, but
TCP's end-to-end mechanisms for handling of residual errors. the compression scheme must not affect TCP's end-to-end
mechanisms for handling of residual errors.
Justification: For links carrying TCP traffic, the residual error Justification: For links carrying TCP traffic, the residual error
rate is expected to be insignificant. However, residual errors rate is expected to be insignificant. However, residual errors
may still occur, especially in the end-to-end path, and therefore may still occur, especially in the end-to-end path, and therefore
it is crucial that TCP is not prevented from handling these. it is crucial that TCP is not prevented from handling these.
4. Short lived TCP transfers: The scheme should provide mechanisms Note: This requirement implies that the TCP checksum must be
carried unmodified in all compressed headers.
4. Short-lived TCP transfers: The scheme should provide mechanisms
for efficient compression of short-lived TCP transfers, for efficient compression of short-lived TCP transfers,
minimizing the size of context initiation headers. minimizing the size of context initiation headers.
Justification: Many TCP transfers are short-lived. This means Justification: Many TCP transfers are short-lived. This may lead
that the gain of header compression could be low since normally to a low gain for header compression schemes that for all new
header compression sends full headers initially and small packet streams require full headers to be sent initially and
compressed headers first after the initiation phase. allow small compressed headers only after the initiation phase.
Note: This requirement implies that mechanisms for "context Note: This requirement implies that mechanisms for "context
sharing" or "context re-use" should be considered. sharing" (concurrent packet streams share context information) or
"context re-use" (new contexts can be built on information from
previous contexts) should be considered.
5a. Moderate Packet Reordering: The scheme should efficiently handle 5a. Moderate Packet Misordering: The scheme should efficiently handle
moderate reordering (2-3 packets) in the packet stream reaching moderate misordering (2-3 packets) in the packet stream reaching
the compressor. the compressor.
Justification: This kind of reordering is common. Justification: This kind of misordering is common.
5b. Packet Reordering: The scheme should be able to compress when 5b. Packet Misordering: The scheme must be able to correctly handle
there are reordered packets in the TCP stream reaching the and preferably compress also when there are misordered packets in
compressor. the TCP stream reaching the compressor.
Justification: Reordering happens regularly in the Internet. Justification: Misordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably However, since the Internet is engineered to run TCP reasonably
well, excessive reordering will not be common and need not be well, excessive misordering will not be common and need not be
handled with optimum efficiency. handled with optimum efficiency.
6. Processing delay: The scheme must not contribute significantly to 6. Processing delay: The scheme should not contribute significantly
system delay budget. to the system delay budget.
2.4. Capability requirements related to link layer characteristics 2.4. Capability requirements related to link layer characteristics
1. Unidirectional links: Must be possible to implement (possibly with 1. Unidirectional links: Must be possible to implement (possibly with
less efficiency) without explicit feedback messages from less efficiency) without explicit feedback messages from
decompressor to compressor. decompressor to compressor.
Justification: There are links that do not provide a feedback Justification: There are links that do not provide a feedback
channel or feedback is not desirable for other reasons. channel or where feedback is not desirable for other reasons.
2. Link delay: Must operate under all expected link delay conditions. 2. Misordering between compressor and decompressor: The header
compression scheme must be able to handle misordered packets
between compressor and decompressor, but can assume that packet
misordering is indicated to the decompressor by the lower layers.
3. Header compression coexistence: The scheme must fit into the ROHC Justification: When compression is applied over tunnels,
framework together with other ROHC profiles misordering often cannot be completely avoided. A header
compression scheme that prohibits misordering between compressor
and decompressor would therefore not be applicable in many
tunneling scenarios. However, in the case of tunneling, it is
usually possible to get misordering indications. Therefore, the
compression scheme does not have to support detection of
misordering, but can assume that such information is available
from lower layers.
3. Link delay: Must operate under all expected link delay conditions.
4. Header compression coexistence: The scheme must fit into the ROHC
framework together with other ROHC profiles (e.g. [RFC-3095]).
2.5. Intellectual property rights (IPR) 2.5. Intellectual property rights (IPR)
The ROHC WG must spend effort to achieve a high degree of The ROHC WG must spend effort to achieve a high degree of
confidence that there is no IPR covering a final compression confidence that there is no IPR covering a final compression
solution for TCP. solution for TCP.
Justification: Currently there is no TCP header compression Justification: Currently there is no TCP header compression
scheme available that can efficiently compress the packet headers scheme available that can efficiently compress the packet headers
of modern TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill of modern TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill
this gap by providing a ROHC TCP scheme that can be applicable in this gap by providing a ROHC TCP scheme that is applicable in the
the wide area Internet, not only over error-prone radio links. It wide area Internet, not only over error-prone radio links. It
must thus attempt to be as future-proof as possible, and, in must thus attempt to be as future-proof as possible, and only
particular, only unencumbered solutions will be acceptable to the unencumbered solutions will be acceptable to the Internet at
Internet at large. large.
3. Open questions - For further discussion
Q: Should we require the scheme to be capable of handling some
reordering between compressor and decompressor?
Q: Should we have a separate requirement for reordering of acks?
4. IANA Considerations 3. IANA Considerations
A protocol which meets these requirements, will require the IANA to A protocol which meets these requirements will require the IANA to
assign various numbers. This document by itself, however, does not assign various numbers. This document by itself, however, does not
require any IANA involvement. require any IANA involvement.
5. Security Considerations 4. Security Considerations
A protocol specified to meet these requirements must be able to A protocol specified to meet these requirements must be able to
compress packets containing IPSEC headers according to the IPSEC compress packets containing IPSEC headers according to the IPSEC
requirement, 2.2.4. There may be other security aspects to consider requirement, 2.2.4. There may be other security aspects to consider
in such protocols. This document by itself, however, does not add in such protocols. This document by itself, however, does not add
any security risks. any security risks.
5. Acknowledgements
This document has evolved through fruitful discussions with and input
from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The
document quality was significantly improved thanks to Peter Eriksson,
who made a thorough linguistic review.
6. References 6. References
[RFC-791] Jon Postel, Internet Protocol, RFC 791, September 1981. [RFC-791] Jon Postel, Internet Protocol, RFC 791, September 1981.
[RFC-793] Jon Postel, Transport Control Protocol, RFC 793, [RFC-793] Jon Postel, Transport Control Protocol, RFC 793,
September 1981. September 1981.
[RFC-1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed [RFC-1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
skipping to change at page 8, line 26 skipping to change at page 9, line 5
<draft-ietf-pilc-link-arq-issues-03.txt> <draft-ietf-pilc-link-arq-issues-03.txt>
7. Author's address 7. Author's address
Lars-Erik Jonsson Tel: +46 920 20 21 07 Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99 Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 513 56 21 Box 920 Mobile: +46 70 513 56 21
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com Sweden EMail: lars-erik.jonsson@ericsson.com
This Internet-Draft expires May 21, 2002. Full copyright statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
This Internet-Draft expires August 15, 2002.
 End of changes. 

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