draft-ietf-rohc-tcp-requirements-01.txt   draft-ietf-rohc-tcp-requirements-02.txt 
Network Working Group Lars-Erik Jonsson (Editor), Ericsson Network Working Group Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT Sweden INTERNET-DRAFT Sweden
Expires: December 2001 June 20, 2001 Expires: May 2002 November 21, 2001
Requirements for ROHC IP/TCP Header Compression Requirements for ROHC IP/TCP Header Compression
<draft-ietf-rohc-tcp-requirements-01.txt> <draft-ietf-rohc-tcp-requirements-02.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 authors or the ROHC WG mailing list, directed to the ROHC WG mailing list, rohc@cdt.luth.se.
rohc@cdt.luth.se.
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 February 23, 2001 - draft-ietf-rohc-tcp-requirements-00.txt
Initial version of this document to initiate discussion on Initial version to initiate discussion of TCP aspects in ROHC.
requirements for TCP compression in ROHC.
June 20, 2001 - draft-ietf-rohc-tcp-requirements-01.txt June 20, 2001 - draft-ietf-rohc-tcp-requirements-01.txt
ECN requirements, note to "Short lived TCP transfers", a section ECN requirements, note to "Short lived TCP transfers", and a
discussing the IPR issue, and a new open issue about reordering section discussing the IPR issue have been added.
have been added. The packet size restriction requirement has been
removed. Several open issues still not solved. November 21, 2001 - draft-ietf-rohc-tcp-requirements-02.txt
The error propagation requirement has been split in two parts and
updated. Further have references to PILC documents and a note for
"Ubiquity" about TCP versions been added.
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]. However, compression solutions for IP/TCP [RFC-791, RFC-793]. Since TCP
existing schemes for TCP [RFC-1144, RFC-2507] do not have the same traffic, in contrast to RTP, has usually been sent over reliable
robustness problems as RTP compression has had since overall links, existing schemes for TCP [RFC-1144, RFC-2507] have not
efficiency for TCP traffic is usually achieved by using reliable experienced the same robustness problems as RTP compression. However,
links where losses do not occur. Therefore the objectives for a new there are still many scenarios where TCP header compression will be
TCP compression are instead ; improved compression efficiency, implemented over less reliable links [RFC-3150, PILC-ARQ], making
enhanced capabilities for compression of header fields including TCP robustness an important objective also for the new TCP compression
options and finally incorporation of TCP compression into the ROHC scheme. Other, as important, objectives for ROHC TCP compression are;
framework [ROHC]. improved compression efficiency, enhanced capabilities for
compression of header fields including TCP options, and finally
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 that must be compressed efficiently while the third and forth
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.
>> In chapter 2.5, some issues are listed that MUST be subject to
>> further discussions within the WG.
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 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.
This requirement implies that the header compression scheme must
work efficiently and correct for all expected TCP versions.
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. The compression scheme must consider as
normal operation the scenario where Early Congestion Notification normal operation the scenario where Early Congestion Notification
[ECN] is used and support efficient compression also in the case [RFC-3168] is used and support efficient compression also in the
when the ECN bits are used. 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 during the
foreseeable future. ECN is expected to get a breakthrough and be foreseeable future. ECN is expected to get 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 these 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 support compression of headers of arbitrary TCP 3. Generality: Must compress headers from arbitrary TCP streams.
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 Note: This applies to the TCP stream before as well as after it
has passed through an internet. 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.
skipping to change at page 4, line 51 skipping to change at page 5, line 12
- 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: Must provide low relative
overhead under expected operating conditions; compression overhead under expected operating conditions; compression
efficiency should be better than for RFC2507 under equivalent efficiency should be better than for RFC2507 under equivalent
operating conditions. operating conditions.
Justification: Spectrum efficiency is the primary goal here since Justification: Spectrum efficiency is a primary goal.
the requirements for robustness [see 2. below] is less stringent
for TCP traffic than for UDP(/RTP) [RTP-REQ].
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. Error propagation: For TCP traffic, link layer retransmissions 2. Loss propagation: Loss propagation due to header compression
should be applied to make use of the bandwidth in the most should be avoided. Loss propagation is defined as the loss of
efficient way. Lost or damaged headers should thus not occur and headers subsequent to headers lost by the link, even if those
therefore it is not a primary goal to have mechanisms for error subsequent headers are not lost by the link.
propagation avoidance in case of such events.
Justification: To provide robustness against loss or damage Justification: Even though link layer retransmission in most
introduced by the link, efficiency must be sacrificed. Since loss cases is expected to make loss propagation an irrelevant issue,
or damage is not expected for TCP traffic, efficiency should there are still many scenarios where TCP header compression will
instead be prioritized. This does not mean that some robustness be implemented over less reliable links [RFC-3150, PILC-ARQ]. In
should not be provided, if efficiency can still be optimized. such cases, loss propagation due to header compression could
affect certain TCP mechanisms that are capable of handling some
losses, and thereby cause significant performance degradation.
Note: In general, error propagation due to header compression 3. Damage propagation and handling of residual errors: Damage
should be kept at an absolute minimum. Error propagation is propagation is defined as the damage of headers subsequent to
defined as the loss or damage of headers subsequent to headers headers damaged by the link, even if those subsequent headers are
lost or damaged by the link, even if those subsequent headers are not damaged by the link. For TCP, the compression scheme is not
not lost or damaged. required to explicitly implement mechanisms for damage
propagation avoidance, but the compression scheme must not affect
TCP's end-to-end mechanisms for handling of residual errors.
Note: There are at least two kinds of error propagation; loss Justification: For links carrying TCP traffic, the residual error
propagation, where a lost header causes subsequent headers to be rate is expected to be insignificant. However, residual errors
lost or damaged, and damage propagation, where a damaged header may still occur, especially in the end-to-end path, and therefore
causes subsequent headers to be lost or damaged. it is crucial that TCP is not prevented from handling these.
3. 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 means Justification: Many TCP transfers are short-lived. This means
that the gain of header compression could be low since normally that the gain of header compression could be low since normally
header compression sends full headers initially and small header compression sends full headers initially and small
compressed headers first after the initiation phase. compressed headers first 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" or "context re-use" should be considered.
4a. Moderate Packet Reordering: The scheme should efficiently handle 5a. Moderate Packet Reordering: The scheme should efficiently handle
moderate reordering (2-3 packets) in the packet stream reaching moderate reordering (2-3 packets) in the packet stream reaching
the compressor. the compressor.
Justification: This kind of reordering is common. Justification: This kind of reordering is common.
4b. Packet Reordering: The scheme should be able to compress when 5b. Packet Reordering: The scheme should be able to compress when
there are reordered packets in the TCP stream reaching the there are reordered packets in the TCP stream reaching the
compressor. compressor.
Justification: Reordering happens regularly in the Internet. Justification: Reordering 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 reordering will not be common and need not be
handled with optimum efficiency. handled with optimum efficiency.
5. Processing delay: The scheme must not contribute significantly to 6. Processing delay: The scheme must not contribute significantly to
system delay budget. 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 feedback is not desirable for other reasons.
skipping to change at page 6, line 42 skipping to change at page 7, line 5
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 can be applicable in
the wide area Internet, not only over error-prone radio links. It the 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, in
particular, only unencumbered solutions will be acceptable to the particular, only unencumbered solutions will be acceptable to the
Internet at large. Internet at large.
2.6. Open issues - For further discussions 3. Open questions - For further discussion
1. The draft is still written to assume that TCP traffic is sent
over links where link-layer retransmissions are applied. This
issue was somewhat discussed at the last IETF meeting in
Minneapolis, but without conclusions in any direction.
Alternative approaches could be to require a scheme with some
robustness capabilities, an adaptable scheme or TWO different
solutions, one for links with retransmissions and one for links
where errors and loss may occur.
2. What should be the approach for residual bit errors? Should we Q: Should we require the scheme to be capable of handling some
split the error propagation section into two sections, one for reordering between compressor and decompressor?
loss propagation and one for damage propagation?
3. Should we require the scheme to be capable of handling some Q: Should we have a separate requirement for reordering of acks?
reordering between compressor and decompressor? Should we have a
separate requirement for reordering of acks?
3. IANA Considerations 4. IANA Considerations
A protocol which meets these requirements, e.g., [ROHC], will require A protocol which meets these requirements, will require the IANA to
the IANA to assign various numbers. This document by itself, however, assign various numbers. This document by itself, however, does not
does not require any IANA involvement. require any IANA involvement.
4. Security Considerations 5. Security Considerations
A protocol specified to meet these requirements, e.g., [ROHC], must A protocol specified to meet these requirements must be able to
be able to compress packets containing IPSEC headers according to the compress packets containing IPSEC headers according to the IPSEC
IPSEC requirement, 2.2.4. There may be other security aspects to requirement, 2.2.4. There may be other security aspects to consider
consider in such protocols. This document by itself, however, does in such protocols. This document by itself, however, does not add
not add any security risks. any security risks.
5. 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.
[RFC-2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP [RFC-2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP
Header Compression", RFC 2507, February 1999. Header Compression", RFC 2507, February 1999.
[RTP-REQ] Mikael Degermark, "Requirements for IP/UDP/RTP header [RFC-3096] Mikael Degermark, "Requirements for IP/UDP/RTP header
compression", Internet draft (work in progress), compression", RFC 3096, July 2001.
February 2001.
<draft-ietf-rohc-rtp-requirements-05.txt>
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet [RFC-3095] Carsten Bormann, et. al., "Robust Header Compression
draft (work in progress), February 2001. (ROHC)", RFC 3095, July 2001.
<draft-ietf-rohc-rtp-08.txt>
[RFC-1323] Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions [RFC-1323] Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC-2018] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn [RFC-2018] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn
Romanow, "TCP Selective Acknowledgement Option", RFC Romanow, "TCP Selective Acknowledgement Option", RFC
2018, October 1996. 2018, October 1996.
[RFC-2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew [RFC-2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew
Podolsky, "An Extension to the Selective Acknowledgement Podolsky, "An Extension to the Selective Acknowledgement
(SACK) Option for TCP", RFC 2883, July 2000. (SACK) Option for TCP", RFC 2883, July 2000.
[ECN] 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", Internet Draft (work in progress), March 2001. IP", RFC 3168, September 2001.
<draft-ietf-tsvwg-ecn-03.txt>
6. Editor's address [RFC-3150] Spencer Dawkins, Gabriel Montenegro, Markku Kojo,
Vincent Magret, "End-to-end Performance Implications of
Slow Links", RFC 3150, July 2001.
[PILC-ARQ] Gorry Fairhurst, Lloyd Wood, "Advice to link designers
on link Automatic Repeat reQuest (ARQ)", Internet Draft
(work in progress), August 2001.
<draft-ietf-pilc-link-arq-issues-03.txt>
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 554 82 71 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 December 20, 2001. This Internet-Draft expires May 21, 2002.
 End of changes. 

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