draft-ietf-rohc-rtp-requirements-00.txt   draft-ietf-rohc-rtp-requirements-01.txt 
Network Working Group Mikael Degermark (editor) /University of Arizona
Network Working Group Mikael Degermark (editor) /Lulea University
INTERNET-DRAFT Sweden INTERNET-DRAFT Sweden
Expires: September 29, 2000 March 29, 2000 Expires: November 20, 2000 May 20, 2000
Requirements for IP/UDP/RTP header compression Requirements for IP/UDP/RTP robust header compression
<draft-ietf-rohc-rtp-requirements-00.txt> <draft-ietf-rohc-rtp-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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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 its mailing list, rohc@cdt.luth.se. directed to its mailing list, rohc@cdt.luth.se.
Abstract Abstract
This document gives draft requirements for robust IP/UDP/RTP header This document gives draft requirements for robust IP/UDP/RTP header
compression to be developed by the ROHC WG. It is based on the 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 charter, the 3GPP document "3GPP TR 23.922", version 1.0.0 of october
1999 [TR], as well as contributions from 3G.IP. 1999 [TR], as well as contributions from 3G.IP.
0. History and Change Log
May 20, 2000 - draft-ietf-rohc-rtp-requirements-01.txt
added "robust" to the title of the document.
2.1.2 Mobile-IP: Added requirement for compression of Home Address
option.
2.3.3 Cellular handover: Added note to requirement stating that
handover procedure will not be prescribed as the procedure will be
highly system-dependent. However, it must be possible to run ROHC
such that handover is an efficient operation.
2.3.7 Packet misordering: Added note to explain why only moderate
misordering needs to be handled efficiently.
2.3.10 Delay. New requirement.
March 29, 2000 - draft-ietf-rohc-rtp-requirements-00.txt
Initial version of this document. Distributed over the ROHC WG
mailing list prior to 47th IETF in Adelaide.
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 build using times. The schemes must perform well for cellular links build 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 following requirements have, more or less arbitrarily, been The following requirements have, more or less arbitrarily, been
divided into three groups. The first deals with requirements divided into three groups. The first group deals with requirements
concerning the impact of an header compression scheme on the rest of concerning the impact of an header compression scheme on the rest of
the Internet infrastructure. The second group concerns what kind of the Internet infrastructure. The second group concerns what kind of
headers that must be compressed efficiently. The final group concerns headers that must be compressed efficiently. The final group concerns
efficiency requirements and requirements which stem from the efficiency requirements and requirements which stem from the
properties of the anticipated link technologies. properties of the anticipated link technologies.
2. Header compression requirements 2. Header compression requirements
Several current standardization efforts in the cellular arena aim at Several current standardization efforts in the cellular arena aim at
supporting voice over IP and other real-time services over IP, e.g., supporting voice over IP and other real-time services over IP, e.g.,
skipping to change at page 3, line 14 skipping to change at page 4, line 14
2.1 Supported headers and kinds of RTP streams 2.1 Supported headers and kinds of RTP streams
1. Ipv4 and Ipv6: Must support both IPv4 and IPv6. 1. Ipv4 and Ipv6: Must support both IPv4 and IPv6.
Justification: IPv4 and IPv6 will both be around during the Justification: IPv4 and IPv6 will both be around during the
foreseeable future. foreseeable future.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be
compressed efficiently. For IPv4 these include headers of tunneled compressed efficiently. For IPv4 these include headers of tunneled
packets. For IPv6 these include headers containing the Routing Header packets. For IPv6 these include headers containing the Routing
and the Binding Update Destination Option. Header, the Binding Update 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. Genericity: Must support compression of headers of arbitrary RTP 3. Genericity: Must support compression of headers of arbitrary RTP
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 payload type and traffic pattern. This does reasonably well for any payload type and traffic pattern. This does
not preclude optimizations for certain media types where the traffic not preclude optimizations for certain media types where the traffic
skipping to change at page 4, line 10 skipping to change at page 5, line 12
Justification: Error propagation reduces spectral efficiency and Justification: Error propagation reduces spectral efficiency and
reduces voice quality. CRTP suffers severely from error propagation. reduces voice quality. CRTP suffers severely from error propagation.
3. Cellular handover: Cellular handover must be supported. The header 3. Cellular handover: Cellular handover must be supported. The header
compression scheme should not cause packet loss after handover. compression scheme should not cause packet loss after handover.
Justification: Handover can be a frequent operation in cellular Justification: Handover can be a frequent operation in cellular
systems. Failure to handle it well can adversely impact spectrum systems. Failure to handle it well can adversely impact spectrum
efficiency and voice quality. efficiency and voice quality.
Note: "Supported" does not imply that a handover procedure will be
prescribed by the ROHC specification. Handover is a highly system-
dependent operation as is handover frequency and characteristics of
loss events related to handover. "Supported" does imply that there
must be a way to run ROHC that deals well with handover in target
systems. The specification shall outline possible handover schemes
and pitfalls. The specification will outline what parts of the
context is to be transfered, as well as conditions for using
transfered context, to aid developers of handover implementations
that transfer context between compressors or decompressors.
4. Link delay: Must operate under all expected link delay conditions. 4. Link delay: Must operate under all expected link delay conditions.
5. Processing delay: The scheme must not contribute significantly to 5. Processing delay: The scheme must not contribute significantly to
system delay budget. system delay budget.
6. Multiple links: The scheme must perform well when there are two or 6. Multiple links: The scheme must perform well when there are two or
more cellular links in the end-to-end path. more cellular links in the end-to-end path.
Justification: Such paths will occur. Note: loss on previous links Justification: Such paths will occur. Note: loss on previous links
will cause irregularities in the RTP stream reaching the compressor. will cause irregularities in the RTP stream reaching the compressor.
Such irregularities should only marginally affect performance. Such irregularities should only marginally affect performance.
7. Packet Misordering: The scheme must tolerate moderate misordering 7. Packet Misordering: The scheme must tolerate moderate misordering
in the packet stream reaching the compressor. No misordering is in the packet stream reaching the compressor. No misordering is
expected on the link between compressor and decompressor. expected on the link between compressor and decompressor.
Justification: Misordering happens regularly in the Internet. Justification: Misordering happens regularly in the Internet.
Note: Since the Internet is engineered to run TCP reasonably well,
excessive misordering will not be common, and need not be handled
efficiently. Moderate misordering (up to 2-3 packets) should be
handled efficiently.
8. Unidirectional links/multicast: Must operate (possibly with less 8. Unidirectional links/multicast: Must operate (possibly with less
efficiency) over links where there is no feedback channel or where efficiency) over links where there is no feedback channel or where
there are several receivers. there are several receivers.
9. Configurable header size fluctuation: It should be possible to 9. Configurable header size fluctuation: It should be possible to
restrict the number of different header sizes used by the scheme. restrict the number of different header sizes used by the scheme.
Justification: Some radio technologies support only a limited number Justification: Some radio technologies support only a limited number
of frame sizes efficiently. Note: Somewhat degraded performance is to of frame sizes efficiently. Note: Somewhat degraded performance is to
be expected when such restrictions are applied. be expected when such restrictions are applied.
10. Delay: The scheme should not delay packets.
Justification: RTP packets carrying data for interactive voice or
video have a limited end-to-end delay budget. ROHC should not
noticeably add to the end-to-end delay.
Note: This requirement is intended to prevent schemes that achieve
robustness at the expense of delay, for example schemes that require
that packet i+x, x>0, is received before packet i can be
decompressed.
Note: Together with 2.3.5, this requirement implies that ROHC will
not noticeably add to the jitter of the RTP stream, other than what
is caused by variations in header size.
Note: This requirement does not prevent a queue from forming upstream
a bottleneck link. Nor does it prevent a compressor from utilizing
information from more than one header in such a queue.
3. Editor's address 3. Editor's address
Mikael Degermark Tel: +1 520 621-3498 Mikael Degermark Tel (May-July): +46 70 833-8933
Dept. of Computer Science Fax: +1 520 621-3498 Dept. of Computer Science Tel: +1 520 621-3489
University of Arizona University of Arizona Fax: +1 520 621-4246
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077 Tucson, AZ 85721-0077
USA EMail: micke@cs.arizona.edu USA EMail: micke@cs.arizona.edu
4. References 4. References
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership [TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
Project; Technical Specification Group Services and Project; Technical Specification Group Services and
Systems Aspects; Architecture for an All IP network. Systems Aspects; Architecture for an All IP network.
skipping to change at page 5, line 18 skipping to change at page 7, line 6
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. [RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed [RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990. Serial Links, RFC 1144, February 1990.
[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers [CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508. for Low-Speed Serial Links, RFC 2508.
This draft expires in September 2000. This draft expires November 20, 2000.
 End of changes. 

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