draft-ietf-rohc-tcp-requirements-03.txt   draft-ietf-rohc-tcp-requirements-04.txt 
Network Working Group Lars-Erik Jonsson Network Working Group Lars-Erik Jonsson
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: August 2002 February 15, 2002 Expires: November 2002 May 28, 2002
Requirements for ROHC IP/TCP Header Compression Requirements on ROHC TCP/IP Header Compression
<draft-ietf-rohc-tcp-requirements-03.txt> <draft-ietf-rohc-tcp-requirements-04.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 1, line 31 skipping to change at page 1, line 31
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-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 document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@cdt.luth.se. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document contains requirements for the IP/TCP header compression This document contains requirements on the TCP/IP header compression
scheme (profile) to be developed by the ROHC WG. The structure of scheme (profile) to be developed by the ROHC WG. The document
this document is inherited from the document defining IP/UDP/RTP discusses the scope of TCP compression, performance considerations,
requirements for ROHC. assumptions on the surrounding environment, as well as IPR concerns.
The structure of this document is inherited from the document
0. Document history defining RTP/UDP/IP requirements for ROHC.
00: February 23, 2001
01: June 20, 2001:
ECN requirements, note to "Short lived TCP transfers", and a
section discussing the IPR issue have been added.
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.
03: February 7, 2002:
Several minor corrections, and a new requirement 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.
skipping to change at page 2, line 45 skipping to change at page 2, line 28
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, equally important, objectives for ROHC TCP compression scheme. Other, equally important, objectives for ROHC TCP compression
are: 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 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. 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
containing the erroneous header must be discarded. containing 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
of the Internet infrastructure. of the Internet infrastructure.
skipping to change at page 3, line 33 skipping to change at page 3, line 19
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 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 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. Compression must not be disabled if IPv4 compressed efficiently. Compression must not be disabled if IPv4
Options or IPv6 Extensions are present. The compression scheme Options or IPv6 Extensions are present. The compression scheme
must further consider as normal operation the scenario where must further consider as normal operation the scenario where
Explicit Congestion Notification (ECN) [RFC-3168] is applied and Explicit Congestion Notification (ECN) [RFC-3168] is applied and
support efficient compression also in the case when the ECN bits support efficient compression also in the case when the ECN bits
are used. are used.
skipping to change at page 4, line 42 skipping to change at page 4, line 27
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:
- 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: The scheme must provide low 1. Performance/Spectral Efficiency: The scheme must provide low
relative overhead under expected operating conditions; relative overhead under expected operating conditions;
compression efficiency should be better than for RFC2507 under compression efficiency should be better than for RFC2507 under
equivalent 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
skipping to change at page 5, line 27 skipping to change at page 5, line 12
of handling some losses, and have a negative impact on the of handling some losses, and have a negative impact on the
performance of TCP loss recovery. performance of TCP loss recovery.
3. Residual errors in compressed headers: Residual errors in 3. Residual errors in compressed headers: Residual errors in
compressed headers may result in delivery of incorrectly compressed headers may result in delivery of incorrectly
decompressed headers not only for the damaged packet itself, but decompressed headers not only for the damaged packet itself, but
also for subsequent packets, since errors may be saved in the also for subsequent packets, since errors may be saved in the
context state. For TCP, the compression scheme is not required to context state. For TCP, the compression scheme is not required to
implement explicit mechanisms for residual error detection, but implement explicit mechanisms for residual error detection, but
the compression scheme must not affect TCP's end-to-end the compression scheme must not affect TCP's end-to-end
mechanisms for handling of residual errors. mechanisms for error detection.
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.
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
residual bit errors, but the mechanism is not designed for this
purpose, and might actually provide a rather weak protection.
Therefore, although it is not a requirement on the compression
scheme, the decompressor should discard packets which are known
to contain residual errors.
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, 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 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 all new
packet streams require full headers to be sent initially and packet streams require full headers to be sent initially and
allow small compressed headers only 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
skipping to change at page 6, line 17 skipping to change at page 6, line 10
the TCP stream reaching the compressor. the TCP stream reaching the compressor.
Justification: Misordering 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 misordering 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 should not contribute significantly 6. Processing delay: The scheme should not contribute significantly
to the 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 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. Misordering between compressor and decompressor: The header
compression scheme must be able to handle misordered packets compression scheme must be able to handle misordered packets
skipping to change at page 6, line 46 skipping to change at page 6, line 39
usually possible to get misordering indications. Therefore, the usually possible to get misordering indications. Therefore, the
compression scheme does not have to support detection of compression scheme does not have to support detection of
misordering, but can assume that such information is available misordering, but can assume that such information is available
from lower layers. from lower layers.
3. Link delay: Must operate under all expected link delay conditions. 3. Link delay: Must operate under all expected link delay conditions.
4. Header compression coexistence: The scheme must fit into the ROHC 4. Header compression coexistence: The scheme must fit into the ROHC
framework together with other ROHC profiles (e.g. [RFC-3095]). 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 is applicable in the this gap by providing a ROHC TCP scheme that is applicable in the
wide area Internet, not only over error-prone radio links. It wide area Internet, not only over error-prone radio links. It
skipping to change at page 8, line 23 skipping to change at page 8, line 15
[RFC-3168] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The [RFC-3168] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The
Addition of Explicit Congestion Notification (ECN) to Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001. IP", RFC 3168, September 2001.
[RFC-3150] Spencer Dawkins, Gabriel Montenegro, Markku Kojo, [RFC-3150] Spencer Dawkins, Gabriel Montenegro, Markku Kojo,
Vincent Magret, "End-to-end Performance Implications of Vincent Magret, "End-to-end Performance Implications of
Slow Links", RFC 3150, July 2001. Slow Links", RFC 3150, July 2001.
[PILC-ARQ] Gorry Fairhurst, Lloyd Wood, "Advice to link designers [PILC-ARQ] Gorry Fairhurst, Lloyd Wood, "Advice to link designers
on link Automatic Repeat reQuest (ARQ)", Internet Draft on link Automatic Repeat reQuest (ARQ)", Internet Draft
(work in progress), August 2001. (work in progress), March 2002.
<draft-ietf-pilc-link-arq-issues-03.txt> <draft-ietf-pilc-link-arq-issues-04.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 AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 513 56 21 Box 920
SE-971 28 Lulea SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com Sweden EMail: lars-erik.jonsson@ericsson.com
Full copyright statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 9, line 33 skipping to change at page 9, line 33
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires August 15, 2002. This Internet-Draft expires November 28, 2002.
 End of changes. 

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