draft-ietf-rohc-tcp-requirements-00.txt   draft-ietf-rohc-tcp-requirements-01.txt 
Network Working Group Lars-Erik Jonsson, Ericsson Network Working Group Lars-Erik Jonsson (Editor), Ericsson
INTERNET-DRAFT Sweden INTERNET-DRAFT Sweden
Expires: August 23, 2001 February 23, 2001 Expires: December 2001 June 20, 2001
Requirements for ROHC IP/TCP Header Compression Requirements for ROHC IP/TCP Header Compression
<draft-ietf-rohc-tcp-requirements-00.txt> <draft-ietf-rohc-tcp-requirements-01.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-rtp-requirements-00.txt February 23, 2001 - draft-ietf-rohc-tcp-requirements-00.txt
Initial version of this document to initiate discussion on Initial version of this document to initiate discussion on
requirements for TCP compression in ROHC. requirements for TCP compression in ROHC.
June 20, 2001 - draft-ietf-rohc-tcp-requirements-01.txt
ECN requirements, note to "Short lived TCP transfers", a section
discussing the IPR issue, and a new open issue about reordering
have been added. The packet size restriction requirement has been
removed. Several open issues still not solved.
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
skipping to change at page 2, line 36 skipping to change at page 2, line 43
efficiency for TCP traffic is usually achieved by using reliable efficiency for TCP traffic is usually achieved by using reliable
links where losses do not occur. Therefore the objectives for a new links where losses do not occur. Therefore the objectives for a new
TCP compression are instead ; improved compression efficiency, TCP compression are instead ; improved compression efficiency,
enhanced capabilities for compression of header fields including TCP enhanced capabilities for compression of header fields including TCP
options and finally incorporation of TCP compression into the ROHC options and finally incorporation of TCP compression into the ROHC
framework [ROHC]. framework [ROHC].
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 four 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 concerns what kind of the Internet infrastructure. The second group defines what kind of
headers that must be compressed efficiently. The third and forth headers that must be compressed efficiently while the third and forth
groups finally concern performance requirements and capability groups concern performance requirements and capability requirements
requirements which stem from the properties of the anticipated link which stem from the properties of the anticipated link technologies.
technologies. Finally, the fifth section discusses Intellectual Property Rights
related to ROHC TCP compression.
---- TO BE REMOVED ---- >> In chapter 2.5, some issues are listed that MUST be subject to
In chapter 2.5, some issues are listed that MUST be subject to >> further discussions within the WG.
further discussions within the WG.
--------- END ---------
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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.
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. 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
the compression scheme and commonly changing fields should be
compressed efficiently. The compression scheme must consider as
normal operation the scenario where Early Congestion Notification
[ECN] is used 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 during the
foreseeable future. foreseeable future. ECN is expected to get a breakthrough and be
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.
skipping to change at page 4, line 14 skipping to change at page 4, line 24
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 of course not possible to compress the encrypted part
of an ESP header, nor the cryptographic data in an AH header. of an ESP header, nor the cryptographic data in an AH header.
5. TCP: All fields supported by [RFC-2507] should be handled, and in 5. TCP: All fields supported by [RFC-2507] must be handled with
addition to that also the case when the SYN or FIN bits are set. efficient compression, and so also the cases when the SYN, FIN or
ECN bits are set.
Justification: These bits are commonly used today. 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.
skipping to change at page 5, line 31 skipping to change at page 5, line 42
3. Short lived TCP transfers: The scheme should provide mechanisms 3. 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
sharing" or "context re-use" should be considered.
4a. Moderate Packet Reordering: The scheme should efficiently handle 4a. 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 4b. 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.
skipping to change at page 6, line 14 skipping to change at page 6, line 22
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.
2. Configurable frame size fluctuation: It should be possible to 2. Link delay: Must operate under all expected link delay conditions.
restrict the number of different frame sizes used by the scheme.
Justification: Some radio technologies support only a limited
number of frame sizes efficiently.
Note: Somewhat degraded performance is to be expected when such 3. Header compression coexistence: The scheme must fit into the ROHC
restrictions are applied. framework together with other ROHC profiles
Note: This implies that a list of "good" frame sizes must be made 2.5. Intellectual property rights (IPR)
available and that ROHC may pick a suitable header format to
utilize available space as well as possible.
3. Link delay: Must operate under all expected link delay conditions. 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.
4. Header compression coexistence: The scheme must fit into the ROHC Justification: Currently there is no TCP header compression
framework together with other ROHC profiles scheme 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 providing a ROHC TCP scheme that can be applicable in
the wide area Internet, not only over error-prone radio links. It
must thus attempt to be as future-proof as possible, and, in
particular, only unencumbered solutions will be acceptable to the
Internet at large.
2.5. Open issues - For further discussions 2.6. Open issues - For further discussions
1. As this draft is written today it assumes that TCP traffic is sent 1. The draft is still written to assume that TCP traffic is sent
over links where link-layer retransmissions are applied. This over links where link-layer retransmissions are applied. This
approached was chosen based on previous discussions but may of issue was somewhat discussed at the last IETF meeting in
course be questioned. One alternative could be to require TWO Minneapolis, but without conclusions in any direction.
different solutions, one for links with retransmissions and one Alternative approaches could be to require a scheme with some
for links where errors and loss may occur. robustness capabilities, an adaptable scheme or TWO different
solutions, one for links with retransmissions and one for links
2. Should there be any exceptions (notes) to the generality section, where errors and loss may occur.
2.2.->3.?
3. What should be the approach for residual bit errors? Should we 2. What should be the approach for residual bit errors? Should we
split the error propagation section into two sections, one for split the error propagation section into two sections, one for
loss propagation and one for damage propagation? loss propagation and one for damage propagation?
3. Should we require the scheme to be capable of handling some
reordering between compressor and decompressor? Should we have a
separate requirement for reordering of acks?
3. IANA Considerations 3. IANA Considerations
A protocol which meets these requirements, e.g., [ROHC], will require A protocol which meets these requirements, e.g., [ROHC], will require
the IANA to assign various numbers. This document by itself, however, the IANA to assign various numbers. This document by itself, however,
does not require any IANA involvement. does not require any IANA involvement.
4. Security Considerations 4. Security Considerations
A protocol specified to meet these requirements, e.g., [ROHC], must A protocol specified to meet these requirements, e.g., [ROHC], must
be able to compress packets containing IPSEC headers according to the be able to compress packets containing IPSEC headers according to the
skipping to change at page 8, line 5 skipping to change at page 8, line 13
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.
6. Author's address [ECN] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", Internet Draft (work in progress), March 2001.
<draft-ietf-tsvwg-ecn-03.txt>
6. Editor'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 554 82 71
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 August 23, 2001. This Internet-Draft expires December 20, 2001.
 End of changes. 

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