Network Working Group Mikael Degermark (editor) /University of Arizona INTERNET-DRAFT USA Expires: May 17, 2001 Nov 17, 2000 Requirements for robust IP/UDP/RTP header compression 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 contains requirements for robust IP/UDP/RTP header compression to be developed by the ROHC WG. It is based on the ROHC charter, discussions in the WG, 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 ROHC Nov 17, 2000 0. History and Change Log Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt Changed "packet" to "header" on several places. June 7, 2000 - draft-ietf-rohc-rtp-requirements-02.txt Transparency: Added note saying that the ROHC WG has not found an instance where semantically identical is not the same as bitwise identical. Ubiquity: Added note saying that ROHC may recommend changes that will improve compression efficiency. 2.2.4 IPSEC: new requirement Performance/Spectral Efficiency: changed "error conditions" to "operating conditions". Split Cellular Handover requirement in two: one dealing with loss events caused by handover, and another dealing with context recreation after switching compressor or decompressor to a new node. Added note to Genericity requirement stating that it applies to an RTP stream before as well as after it has passed through IP- networks. Added note to Error Propagation requirement that explains the terms "loss propagation" and "damage propagation". 2.3.11: Residual bit-error rate: New requirement 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. Degermark (Ed) [Page 2] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 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. Degermark (Ed) [Page 3] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 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 group 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. 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), UDP, or RTP implementations. Justification: Ease of deployment. Degermark (Ed) [Page 4] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 Note: The ROHC WG may recommend changes that would increase the compression efficiency for the RTP streams emitted by implementations. However, ROHC cannot rely on such recommendations being followed. 2.2 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, 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. 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. Note: This applies to the RTP stream before as well as after it has passed through an internet. 4. IPSEC: ROHC should be able to compress headers containing IPSEC subheaders. Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header. 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 operating conditions. The error rate should only marginally increase the overhead under expected operating conditions. Degermark (Ed) [Page 5] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 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 or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged. Justification: Error propagation reduces spectral efficiency and reduces quality. CRTP suffers severely from error propagation. 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. 3a. Handover loss events: Loss events of lenght 150 ms should be handled efficiently and without additional packet loss being introduced by ROHC. Justification: Such loss events can be introduced by handover operations in the (radio) network between compressor and decompressor. Handover operations can be frequent in cellular systems. Failure to handle handover well can adversely impact spectrum efficiency and quality. 3b. Handover context recreation: There must be a way to run ROHC that deals well with events where the route of an RTP conversation changes such that either the compressor or the decompressor of the conversation is relocated to another node, where the context needs to be recreated. ROHC must not create erroneous headers during such events. Justification: Such events can be frequent in cellular systems where the compressor/decompressor on the network side is close to the radio base stations. Note: In order to aid developers of context recreation schemes where context is transfered to the new node, the specification shall outline what parts of the context is to be transfered, as well as conditions for its use. Procedures for context recreation (and discard) without such context transfer will also be provided. 4. Link delay: Must operate under all expected link delay conditions. Degermark (Ed) [Page 6] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 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. 7a. Packet Misordering: The scheme should be able to compress when there are misordered packets in the RTP stream reaching the compressor. No misordering is expected on the link between compressor and decompressor. Justification: Misordering happens regularly in the Internet. However, since the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiently. 7b. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor. Note: This kind of reordering is common. 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 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. 10. Delay: ROHC should not noticeably add to the end-to-end delay. Justification: RTP packets carrying data for interactive voice or Degermark (Ed) [Page 7] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 video have a limited end-to-end delay budget. Note: This requirement is intended to prevent schemes that achieve robustness at the expense of delay, for example schemes that require that header i+x, x>0, is received before header 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. 11. Residual errors: For a residual bit-error rate of at most 1e-5, the ROHC scheme must not increase the error rate. Justification: Some target links have a residual error rate, i.e, rate of undetected errors, of this magnitude. Note: In the presence of residual bit-errors, ROHC will need error detection mechanisms to prevent damage propagation. These mechanisms will catch some residual errors, but those not caught might cause damage propagation. This requirement states that the reduction of the damage rate due to the error detection mechanisms must not be less than the increase in error rate due to damage propagation. 3. Editor's address Mikael Degermark Tel (May-July): +46 70 833-8933 Dept. of Computer Science Tel: +1 520 621-3489 University of Arizona Fax: +1 520 621-4246 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 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. Degermark (Ed) [Page 8] INTERNET-DRAFT Requirements for IP/UDP/RTP ROHC Nov 17, 2000 [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 May 17, 2001. Degermark (Ed) [Page 9]