< draft-ietf-rohc-tcp-requirements-07.txt   draft-ietf-rohc-tcp-requirements-08.txt >
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: December 2004 June 9, 2004 Expires: March 2005 September 14, 2004
Requirements on ROHC TCP/IP Header Compression Requirements on ROHC TCP/IP Header Compression
<draft-ietf-rohc-tcp-requirements-07.txt> <draft-ietf-rohc-tcp-requirements-08.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78). Section 3 of RFC 3667 (BCP 78).
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Header Compression Requirements..................................2 2. Header Compression Requirements..................................2
2.1. Impact on Internet Infrastructure...........................3 2.1. Impact on Internet Infrastructure...........................3
2.2. Supported Headers and Kinds of TCP Streams..................3 2.2. Supported Headers and Kinds of TCP Streams..................3
2.3. Performance Issues..........................................4 2.3. Performance Issues..........................................4
2.4. Requirements Related to Link Layer Characteristics..........6 2.4. Requirements Related to Link Layer Characteristics..........6
2.5. Intellectual Property Rights (IPR)..........................7 2.5. Intellectual Property Rights (IPR)..........................7
3. Security Consideration...........................................7 3. Security Consideration...........................................7
4. IANA Considerations..............................................7 4. IANA Considerations..............................................7
5. Acknowledgments..................................................7 5. Acknowledgments..................................................7
6. Authors' Address.................................................7 6. Authors' Address.................................................7
7. References.......................................................8 7. Informative References...........................................8
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 link technologies with high loss
loss and long roundtrip times. 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 [1], [2]. Since TCP traffic, in compression solutions for IP/TCP [1], [2]. Since TCP traffic, in
contrast to RTP, has usually been sent over reliable links, existing contrast to RTP, has usually been sent over reliable links, existing
schemes for TCP, [3] and [4], have not experienced the same schemes for TCP, [3] and [4], have not experienced the same
robustness problems as RTP compression. However, there are still many robustness problems as RTP compression. However, there are still many
scenarios where TCP header compression will be implemented over less scenarios where TCP header compression will be implemented over less
reliable links [11], [12], making robustness an important objective reliable links [11], [12], making robustness an important objective
also for the new TCP compression scheme. Other, equally important, also for the new TCP compression scheme. Other, equally important,
skipping to change at page 2, line 51 skipping to change at page 2, line 51
into the ROHC framework [6]. into the ROHC framework [6].
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 must be compressed efficiently, while the third and fourth 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. that stem from the properties of link technologies where ROHC TCP is
Finally, the fifth section discusses Intellectual Property Rights expected to be used. Finally, the fifth section discusses
related to ROHC TCP compression. Intellectual Property Rights 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 containing original header. If this cannot be achieved, the packet containing
the erroneous header must be discarded. the erroneous header must be discarded.
Justification: The header compression process must not produce Justification: The header compression process must not produce
headers that might cause problems for any current or future part headers that might cause problems for any current or future part
skipping to change at page 3, line 36 skipping to change at page 3, line 36
implementations. However, ROHC cannot rely on such recommendations implementations. However, ROHC cannot rely on such recommendations
being followed. being followed.
Note: Several TCP variants 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 correctly for all expected TCP variants. 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 expected 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. Compression must not be disabled if IPv4 compressed efficiently. Compression must still be possible when
Options or IPv6 Extensions are present. The compression scheme IPv6 Extensions are present in the header. When designing the
must further consider as normal operation the scenario where compression scheme, the usage of Explicit Congestion Notification
Explicit Congestion Notification (ECN) [10] is applied and support (ECN) [10] should be considered as a common behavior. Therefore,
efficient compression also in the case when the ECN bits are used. the scheme must compress efficiently also in the case when the ECN
bits are used.
Justification: IPv4 and IPv6 will both be around for the Justification: IPv4 and IPv6 will both be around for the
foreseeable future, and Options/Extensions are expected to be more foreseeable future, and Options/Extensions are expected to be more
commonly used. ECN is expected to have a breakthrough and be 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 they include headers include headers of tunneled packets. For IPv6 they include headers
containing the Routing Header, the Binding Update Destination containing the Routing Header, and the Home Address Option.
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 handle all 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.
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 where the NULL encryption algorithm is used.
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 not possible to compress the encrypted part of an ESP Note: It is not possible to compress the encrypted part 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 [4] should be handled with efficient 5. TCP: All fields supported by [4] should be handled with efficient
compression, and so also the cases when the SYN, FIN or TCP ECN compression, and so also the cases when the SYN, FIN or TCP ECN
[10] bits are set. [10] bits are set.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
still occur, especially in the end-to-end path, and therefore it still occur, especially in the end-to-end path, and therefore it
is crucial that TCP is not prevented from handling these. is crucial that TCP is not prevented from handling these.
Note: This requirement implies that the TCP checksum must be Note: This requirement implies that the TCP checksum must be
carried unmodified in all compressed headers. carried unmodified in all compressed headers.
Note: The error detection mechanism in TCP may be able to detect Note: The error detection mechanism in TCP may be able to detect
residual bit errors, but the mechanism is not designed for this residual bit errors, but the mechanism is not designed for this
purpose, and might actually provide a rather weak protection. purpose, and might actually provide a rather weak protection.
Therefore, although it is not a requirement on the compression Therefore, although it is not a requirement on the compression
scheme, the decompressor should discard packets which are known to scheme, it should be possible for the decompressor to detect
contain residual errors. residual errors and discard such packets.
4. Short-lived TCP transfers: The scheme should provide mechanisms 4. Short-lived TCP transfers: The scheme should provide mechanisms
for efficient compression of short-lived TCP transfers, minimizing for efficient compression of short-lived TCP transfers, minimizing
the size of context initiation headers. the size of context initiation headers.
Justification: Many TCP transfers are short-lived. This may lead Justification: Many TCP transfers are short-lived. This may lead
to a low gain for header compression schemes that for all new to a low gain for header compression schemes that, for each new
packet streams require full headers to be sent initially and allow packet stream, require full headers to be sent initially and allow
small compressed headers only after the initiation phase. small compressed headers only after the initialization phase.
Note: This requirement implies that mechanisms for "context Note: This requirement implies that mechanisms for building new
sharing" (concurrent packet streams share context information) or contexts based on information from previous contexts or for
"context re-use" (new contexts can be built on information from concurrent packet streams to share context information should be
previous contexts) should be considered. considered.
5a. Moderate Packet Misordering: The scheme should efficiently handle 5a. Moderate Packet Misordering: The scheme should efficiently handle
moderate misordering (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 misordering is common. Justification: This kind of misordering is common.
5b. Packet Misordering: The scheme must be able to correctly handle 5b. Packet Misordering: The scheme must be able to correctly handle
and preferably compress also when there are misordered packets in and preferably compress also when there are misordered packets in
the TCP stream reaching the compressor. the TCP stream reaching the compressor.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
2.4. Requirements Related to Link Layer Characteristics 2.4. 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 where feedback is not desirable for other reasons. channel or where feedback is not desirable for other reasons.
2. Misordering between compressor and decompressor: The header 2. Link delay: Must operate under all expected link delay conditions.
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.
Justification: When compression is applied over tunnels, 3. Header compression coexistence: The scheme must fit into the ROHC
misordering often cannot be completely avoided. A header framework together with other ROHC profiles (e.g. [6]).
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. Note on misordering between compressor and decompressor:
4. Header compression coexistence: The scheme must fit into the ROHC When compression is applied over tunnels, misordering often cannot
framework together with other ROHC profiles (e.g. [6]). be completely avoided. The header compression scheme should not
prohibit misordering between compressor and decompressor, as it
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 when misordering
can occur.
2.5. Intellectual Property Rights (IPR) 2.5. Intellectual Property Rights (IPR)
The ROHC WG must spend effort to achieve a high degree of confidence The ROHC WG must spend effort to achieve a high degree of confidence
that there is no IPR covering a final compression solution for TCP. that there are no known IPR that covers a final compression solution
for TCP.
Justification: Currently there is no TCP header compression scheme Justification: Currently there is no TCP header compression scheme
available that can efficiently compress the packet headers of modern available that can efficiently compress the packet headers of modern
TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill this gap by TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill this gap by
providing a ROHC TCP scheme that is applicable in the wide area providing a ROHC TCP scheme that is applicable in the wide area
Internet, not only over error-prone radio links. It must thus attempt Internet, not only over error-prone radio links. It must thus attempt
to be as future-proof as possible, and only unencumbered solutions to be as future-proof as possible, and only unencumbered solutions
will be acceptable to the Internet at large. will be acceptable to the Internet at large.
3. Security Consideration 3. Security Consideration
skipping to change at page 7, line 40 skipping to change at page 7, line 41
require any IANA involvement. require any IANA involvement.
5. Acknowledgments 5. Acknowledgments
This document has evolved through fruitful discussions with and input This document has evolved through fruitful discussions with and input
from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The
document quality was significantly improved thanks to Peter Eriksson, document quality was significantly improved thanks to Peter Eriksson,
who made a thorough linguistic review. who made a thorough linguistic review.
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served
as committed working group document reviewers.
6. Authors' Address 6. Authors' Address
Lars-Erik Jonsson Tel: +46 920 20 21 07 Lars-Erik Jonsson Phone: +46 8 404 29 61
Ericsson AB Fax: +46 920 20 20 99 Ericsson AB Fax: +46 920 996 21
Box 920 Box 920
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com Sweden EMail: lars-erik.jonsson@ericsson.com
7. References 7. Informative References
[1] Jon Postel, Internet Protocol, RFC 791, September 1981. [1] Jon Postel, Internet Protocol, RFC 791, September 1981.
[2] Jon Postel, Transport Control Protocol, RFC 793, September 1981. [2] Jon Postel, Transport Control Protocol, RFC 793, September 1981.
[3] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial [3] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990. Links", RFC 1144, February 1990.
[4] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header [4] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December 9, 2004. This Internet-Draft expires March 14, 2005.
 End of changes. 21 change blocks. 
46 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/