Network Working Group Mikael Degermark (editor) /Lulea University
INTERNET-DRAFT Sweden
Expires: September 29, 2000 March 29, 2000
Requirements for IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-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 to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-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 its mailing list, rohc@cdt.luth.se.
Abstract
This document gives draft requirements for robust IP/UDP/RTP header
compression to be developed by the ROHC WG. It is based on the
charter, the 3GPP document "3GPP TR 23.922", version 1.0.0 of october
1999 [TR], as well as contributions from 3G.IP.
Degermark (Ed) [Page 1]
INTERNET-DRAFT Requirements for IP/UDP/RTP hc Mar 29, 2000
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 build 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 following requirements have, more or less arbitrarily, been
divided into three groups. The first deals with requirements
concerning the impact of an header compression scheme on the rest of
the Internet infrastructure. The second group concerns what kind of
headers that must be compressed efficiently. The final group concerns
efficiency requirements and requirements which stem from the
properties of the anticipated link technologies.
2. Header compression requirements
Several current standardization efforts in the cellular arena aim at
supporting voice over IP and other real-time services over IP, e.g.,
GERAN (specified by the ETSI SMG2 standards group), and UTRAN
(specified by the 3GPP standards organization). It is critical for
these standardization efforts that a suitable header compression
scheme is developed before completion of the Release 2000 standards.
Therefore, it is imperative that the ROHC WG keeps its schedule.
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.
2. Ubiquity: Must not require modifications to existing IP (v4 or
v6), UDP, or RTP implementations.
Justification: Ease of deployment.
Degermark (Ed) [Page 2]
INTERNET-DRAFT Requirements for IP/UDP/RTP hc Mar 29, 2000
2.1 Supported headers and kinds of RTP 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} should be
compressed efficiently. For IPv4 these include headers of tunneled
packets. For IPv6 these include headers containing the Routing Header
and the Binding Update Destination Option.
Justification: It is very likely that Mobile IP will be used by
cellular devices.
3. Genericity: Must support compression of headers of arbitrary RTP
streams.
Justification: There must be a generic scheme which can compress
reasonably well for any payload type and traffic pattern. This does
not preclude optimizations for certain media types where the traffic
pattern is known, e.g., for low-bandwidth voice and low-bandwidth
video.
2.3 Efficiency
1. Performance/Spectral Efficiency: Must provide low relative
overhead under expected operating conditions; compression efficiency
should be better than for RFC2508 under equivalent error conditions.
The error rate should only marginally increase the overhead under
expected operating conditions.
Justification: Spectrum efficiency is a primary goal. RFC2508 does
not perform well enough. Notes: 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: Error propagation due to header compression
should be kept at an absolute minimum. Error propagation is defined
as the loss of packets subsequent to packets damaged by the link,
even if those subsequent packets are not damaged.
Justification: Error propagation reduces spectral efficiency and
reduces voice quality. CRTP suffers severely from error propagation.
3. Cellular handover: Cellular handover must be supported. The header
Degermark (Ed) [Page 3]
INTERNET-DRAFT Requirements for IP/UDP/RTP hc Mar 29, 2000
compression scheme should not cause packet loss after handover.
Justification: Handover can be a frequent operation in cellular
systems. Failure to handle it well can adversely impact spectrum
efficiency and voice quality.
4. Link delay: Must operate under all expected link delay conditions.
5. Processing delay: The scheme must not contribute significantly to
system delay budget.
6. Multiple links: The scheme must perform well when there are two or
more cellular links in the end-to-end path.
Justification: Such paths will occur. Note: loss on previous links
will cause irregularities in the RTP stream reaching the compressor.
Such irregularities should only marginally affect performance.
7. Packet Misordering: The scheme must tolerate moderate misordering
in the packet stream reaching the compressor. No misordering is
expected on the link between compressor and decompressor.
Justification: Misordering happens regularly in the Internet.
8. Unidirectional links/multicast: Must operate (possibly with less
efficiency) over links where there is no feedback channel or where
there are several receivers.
9. Configurable header size fluctuation: It should be possible to
restrict the number of different header 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.
3. Editor's address
Mikael Degermark Tel: +1 520 621-3498
Dept. of Computer Science Fax: +1 520 621-3498
University of Arizona
P.O. Box 210077
Tucson, AZ 85721-0077
USA EMail: micke@cs.arizona.edu
4. References
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
Project; Technical Specification Group Services and
Degermark (Ed) [Page 4]
INTERNET-DRAFT Requirements for IP/UDP/RTP hc Mar 29, 2000
Systems Aspects; Architecture for an All IP network.
[TS] TS 22.101 version 3.6.0: Service Principles
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990.
[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508.
This draft expires in September 2000.
Degermark (Ed) [Page 5]
