[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 RFC 4163
Network Working Group Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT Sweden
Expires: August 23, 2001 February 23, 2001
Requirements for ROHC IP/TCP Header Compression
<draft-ietf-rohc-tcp-requirements-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to the authors or the ROHC WG mailing list,
rohc@cdt.luth.se.
Abstract
This document contains requirements for the IP/TCP header compression
scheme (profile) to be developed by the ROHC WG. The structure of
this document is inherited from the document defining IP/UDP/RTP
requirements for ROHC.
Jonsson [Page 1]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
0. Document history
February 23, 2001 - draft-ietf-rohc-rtp-requirements-00.txt
Initial version of this document to initiate discussion on
requirements for TCP compression in ROHC.
1. Introduction
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
times. The schemes must perform well for cellular links, using
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
should also be applicable to other future link technologies with high
loss and long roundtrip times.
The main objective for ROHC has been robust compression of
IP/UDP/RTP, but the WG is also chartered to develop new header
compression solutions for IP/TCP [RFC-791, RFC-793]. However,
existing schemes for TCP [RFC-1144, RFC-2507] do not have the same
robustness problems as RTP compression has had since overall
efficiency for TCP traffic is usually achieved by using reliable
links where losses do not occur. Therefore the objectives for a new
TCP compression are instead ; improved compression efficiency,
enhanced capabilities for compression of header fields including TCP
options and finally incorporation of TCP compression into the ROHC
framework [ROHC].
2. Header compression requirements
The following requirements have, more or less arbitrarily, been
divided into four groups. The first group deals with requirements
concerning the impact of a header compression scheme on the rest of
the Internet infrastructure. The second group concerns what kind of
headers that must be compressed efficiently. The third and forth
groups finally concern performance requirements and capability
requirements which stem from the properties of the anticipated link
technologies.
---- TO BE REMOVED ----
In chapter 2.5, some issues are listed that MUST be subject to
further discussions within the WG.
--------- END ---------
Jonsson [Page 2]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
2.1. Impact on Internet infrastructure
1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the
original header. If this cannot be achieved, the packet
containing the erroneous header must be discarded.
Justification: The header compression process must not produce
headers that might cause problems for any current or future part
of the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically
identical" is not the same as "bitwise identical".
2. Ubiquity: Must not require modifications to existing IP (v4 or
v6) or TCP implementations.
Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the TCP streams emitted by
implementations. However, ROHC cannot rely on such
recommendations being followed.
2.2. Supported headers and kinds of TCP streams
1. IPv4 and IPv6: Must support both IPv4 and IPv6.
Justification: IPv4 and IPv6 will both be around during the
foreseeable future.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
supported and should be compressed efficiently. For IPv4 these
include headers of tunneled packets. For IPv6 these include
headers containing the Routing Header, the Binding Update
Destination Option, and the Home Address option.
Justification: It is very likely that Mobile IP will be used by
cellular devices.
3. Generality: Must support compression of headers of arbitrary TCP
streams.
Justification: There must be a generic scheme which can compress
reasonably well for any TCP traffic pattern. This does not
preclude optimizations for certain traffic patterns.
Note: This applies to the TCP stream before as well as after it
has passed through an internet.
Jonsson [Page 3]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
4. IPSEC: The scheme should be able to compress headers containing
IPSEC sub-headers.
Justification: IPSEC is expected to be used to provide necessary
end-to-end security.
Note: It is of course not possible to compress the encrypted part
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
addition to that also the case when the SYN or FIN bits are set.
Justification: These bits are commonly used today.
6. TCP options: The scheme must support compression of packets with
any TCP option present, even if the option itself is not
compressed. Further, for some commonly used options the scheme
should provide compression mechanisms also for the options.
Justification: Since various TCP options are commonly used,
applicability of the compression scheme would be significantly
reduced if packets with options could not be compressed.
Note: Options that should be compressed are:
- Window scale, [RFC-1323]
- Selective Acknowledgement (SACK), [RFC-2018, RFC-2883]
- Timestamp, [RFC-1323]
2.3. Performance issues
1. Performance/Spectral Efficiency: Must provide low relative
overhead under expected operating conditions; compression
efficiency should be better than for RFC2507 under equivalent
operating conditions.
Justification: Spectrum efficiency is the primary goal here since
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
relative to the payload. Any auxiliary (e.g., control or
feedback) channels used by the scheme should be taken into
account when calculating the header overhead.
2. Error propagation: For TCP traffic, link layer retransmissions
should be applied to make use of the bandwidth in the most
efficient way. Lost or damaged headers should thus not occur and
therefore it is not a primary goal to have mechanisms for error
propagation avoidance in case of such events.
Jonsson [Page 4]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
Justification: To provide robustness against loss or damage
introduced by the link, efficiency must be sacrificed. Since loss
or damage is not expected for TCP traffic, efficiency should
instead be prioritized. This does not mean that some robustness
should not be provided, if efficiency can still be optimized.
Note: In general, error propagation due to header compression
should be kept at an absolute minimum. Error propagation is
defined as the loss or damage of headers subsequent to headers
lost or damaged by the link, even if those subsequent headers are
not lost or damaged.
Note: There are at least two kinds of error propagation; loss
propagation, where a lost header causes subsequent headers to be
lost or damaged, and damage propagation, where a damaged header
causes subsequent headers to be lost or damaged.
3. Short lived TCP transfers: The scheme should provide mechanisms
for efficient compression of short-lived TCP transfers,
minimizing the size of context initiation headers.
Justification: Many TCP transfers are short-lived. This means
that the gain of header compression could be low since normally
header compression sends full headers initially and small
compressed headers first after the initiation phase.
4a. Moderate Packet Reordering: The scheme should efficiently handle
moderate reordering (2-3 packets) in the packet stream reaching
the compressor.
Justification: This kind of reordering is common.
4b. Packet Reordering: The scheme should be able to compress when
there are reordered packets in the TCP stream reaching the
compressor.
Justification: Reordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably
well, excessive reordering will not be common and need not be
handled with optimum efficiency.
5. Processing delay: The scheme must not contribute significantly to
system delay budget.
Jonsson [Page 5]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
2.4. Capability requirements related to link layer characteristics
1. Unidirectional links: Must be possible to implement (possibly with
less efficiency) without explicit feedback messages from
decompressor to compressor.
Justification: There are links that do not provide a feedback
channel or feedback is not desirable for other reasons.
2. Configurable frame size fluctuation: It should be possible to
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
restrictions are applied.
Note: This implies that a list of "good" frame sizes must be made
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.
4. Header compression coexistence: The scheme must fit into the ROHC
framework together with other ROHC profiles
2.5. Open issues - For further discussions
1. As this draft is written today it assumes that TCP traffic is sent
over links where link-layer retransmissions are applied. This
approached was chosen based on previous discussions but may of
course be questioned. One alternative could be to require TWO
different solutions, one for links with retransmissions and one
for links where errors and loss may occur.
2. Should there be any exceptions (notes) to the generality section,
2.2.->3.?
3. What should be the approach for residual bit errors? Should we
split the error propagation section into two sections, one for
loss propagation and one for damage propagation?
Jonsson [Page 6]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
3. IANA Considerations
A protocol which meets these requirements, e.g., [ROHC], will require
the IANA to assign various numbers. This document by itself, however,
does not require any IANA involvement.
4. Security Considerations
A protocol specified to meet these requirements, e.g., [ROHC], must
be able to compress packets containing IPSEC headers according to the
IPSEC requirement, 2.2.4. There may be other security aspects to
consider in such protocols. This document by itself, however, does
not add any security risks.
5. References
[RFC-791] Jon Postel, Internet Protocol, RFC 791, September 1981.
[RFC-793] Jon Postel, Transport Control Protocol, RFC 793,
September 1981.
[RFC-1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC-2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP
Header Compression", RFC 2507, February 1999.
[RTP-REQ] Mikael Degermark, "Requirements for IP/UDP/RTP header
compression", Internet draft (work in progress),
February 2001.
<draft-ietf-rohc-rtp-requirements-05.txt>
[ROHC] C. Bormann, "Robust Header Compression (ROHC)", Internet
draft (work in progress), February 2001.
<draft-ietf-rohc-rtp-08.txt>
[RFC-1323] Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC-2018] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn
Romanow, "TCP Selective Acknowledgement Option", RFC
2018, October 1996.
[RFC-2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew
Podolsky, "An Extension to the Selective Acknowledgement
(SACK) Option for TCP", RFC 2883, July 2000.
Jonsson [Page 7]
INTERNET-DRAFT Requirements for IP/TCP ROHC February 23, 2001
6. Author's address
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 Mobile: +46 70 554 82 71
SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com
This Internet-Draft expires August 23, 2001.
Jonsson [Page 8]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/