Network Working Group Hans Hannu INTERNET-DRAFT Krister Svanbro Expires: November 2000 Lars-Erik Jonsson Ericsson, Sweden May 24, 2000 ROCCO Performance Evaluation 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 The ROCCO header compression scheme [ROCCO] has been designed to compress the RTP/UDP/IP headers in an reliable, efficient and robust way also when used over links with high error rates and long round trip times, such as cellular links. This document evaluates the performance of ROCCO in such environments. It also summarizes how the scheme fulfills the requirements for a new RTP/UDP/IP compression scheme, as stated by the ROHC working group. Hannu, Svanbro, Jonsson [Page 1] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Table of contents 1. Introduction..................................................3 2. Simulated scenario............................................3 2.1. Input data.............................................3 2.2. Influence of pre-HC links..............................3 2.3. Used link layers.......................................4 2.4. The cellular link......................................4 3. Compression performance.......................................4 4. Robustness results............................................6 5. CRC strength considerations...................................8 6. Fulfillment of the ROHC requirements..........................9 6.1. Impact on Internet infrastructure......................9 6.2. Supported headers and kinds of RTP streams.............9 6.3. Efficiency............................................10 7. References...................................................12 8. Authors addresses............................................12 Hannu, Svanbro, Jonsson [Page 2] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 1. Introduction To evaluate the performance of ROCCO and the IP telephony compression profiles, two header compression schemes have been simulated; CRTP [CRTP] and ROCCO [ROCCO], both the 2 octet solution (profile number 8) and the 1 octet solution (profile number 7). Chapter 2 provide the parameters used in the simulations. Chapters 3 and 4 show the results. The strength of the header checksum is treated in chapter 5, while chapter 6 goes into how ROCCO fulfill or may fulfill the requirements on a robust RTP/UDP/IP header compression scheme, as stated by the ROHC working group. 2. Simulated scenario A source generates RTP packets, which are sent over a wired network to an end-system where the last link is a cellular link. The RTP stream is compressed over the last cellular link using one of the two header compression schemes. The simulated scenario is shown in Figure 2.1. Source Compression End-system point _____________ +-------+ / back channel \ | | +----+ +---+/ \+----+ | | |--------->---------| HC|-------->---------|HD | | +----+ Internet path +---+ Cellular link +----+ | (loss) | | +-------+ Figure 2.1 : Simulated scenario. 2.1. Input data The speech source generates packets with a fixed size, 244 bits, every 20 ms (12.2 kbps), corresponding to the GSM enhanced full-rate speech codec. On top of these bits, there is a 12 bit application CRC, making up a total of 256 bits (32 octets). The modeled scenario uses silence suppression, i.e., no speech packet are transmitted during silence periods. The length of the talk spurts and the silent intervals between them are both exponentially distributed with an expected length of 1 second. 2.2. Influence of pre-HC links The packet stream suffers from a 0.5% uniformly distributed packet loss before it reaches the compressor, i.e. in a prior IP network. There is no reordering of packets. The purpose of introducing a large packet loss rate is to test the capabilities of the header compression schemes also under rough conditions. Hannu, Svanbro, Jonsson [Page 3] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 2.3. Used link layers CRTP needs to have the packet type identification provided by the link layer, whereas ROCCO has the packet type identification integrated. Hence one octet extra of link layer overhead is added for the CRTP case. This octet is not included in the header sizes shown in the results section. A 16 bit link layer checksum provides error detection and covers only the header and not the payload. This fits in well with cellular speech coders, which can conceal some damage to the speech payload. This will also increase the numbers of headers that reach the decompressor and hence improve header compression performance. A packet is considered as lost if it is not passed up to the application (speech codec). There are three possible reasons for packet loss in these simulations: 1. A bit error has occurred in the compressed header. 2. A bit error has occurred in the link layer packet type identification (for the CRTP case only) or in the link layer checksum. 3. The header compression scheme has an invalid context and cannot decompress any received compressed header (context damage). Note that this can happen even if a received compressed header is error free. 2.4. The cellular link The cellular link is a WCDMA channel simulated with the fading model in [WCDMA]. The reported bit error rates, BER, are the BERs seen by the link layer and thus the BERs after channel coding. The back channel used in our simulations never damages FEEDBACK messages. The RTT between the header compressor and decompressor is set to 120 ms. 3. Compression performance Figure 3.1 shows the average header size plotted against BERs for the two header compression schemes. For BERs around 1e-4, CRTP and ROCCO profile 8 gives an average header size of just above 2 octets (2.15 for both). ROCCO profile 7 has an average header size just above 1 octet, 1.20, at the same BER. The average header size for CRTP starts to increase when BER becomes slightly larger than 1e-4; at BER 1e-3 it is 2.35. At higher BERs than 1e-3 the average header size for CRTP increases faster, and at 1e-2 it is almost 4 octets. For the two ROCCO profiles (7,8) the average header size remains constant at 2.15 octets and 1.20 octets respectively. The difference between CRTP and ROCCO is mainly that the latter tolerates losing several consecutive packets before it needs a context update packet, while CRTP needs a context update for each loss. ROCCO therefore requires less updates than CRTP introducing less header overhead and a significantly lower packet loss rate. Hannu, Svanbro, Jonsson [Page 4] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Figure 3.1 : Average header sizes Figure 3.2 shows the variation in header sizes for the schemes. The variations are due to silence periods, causing the RTP timestamp to increase with more than 1 timestamp delta (i.e., timer-based time stamp reconstruction is not used in ROCCO). Most headers are however the smallest available, around 85-95% for both schemes. As ROCCO can handle several consecutive packet losses it never has to make any context requests, but CRTP does have to make context requests and sends thus more often larger headers. Hannu, Svanbro, Jonsson [Page 5] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Figure 3.2 : Header size variations 4. Robustness results A packet (or speech frame) is considered as lost if it is not passed up to the application (speech codec), meaning that a packet with errors in the payload is not regarded as lost as long as it is deemed ok by the header compression scheme. In figure 4.1 the packet loss or FER (speech Frame Error Rate) is shown for the two header compression schemes. At BER 2e-4 the FER for CRTP is 1.10%; for both ROCCO profiles the FER is 0.12%. When the FER increases to 1e-3, CRTP gives 4.06% FER, ROCCO profile 4 gives 0.81% and ROCCO profile 24 gives 0.69%. The difference in robustness is clearly visible for the two header compression schemes. For CRTP a packet loss between compressor and decompressor triggers a burst of additional losses due to its round-trip based error recovery. In figure 4.2 this is clearly visible. Hannu, Svanbro, Jonsson [Page 6] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Figure 4.1 : Packet loss rate versus BER Figure 4.2 shows the loss pattern for CRTP and ROCCO at BER 4e-3. It is evident from this figure that the majority of the losses are such that 7 consecutive packets are lost for CRTP. This comes from CRTPs round-trip dependent context repair mechanism. For ROCCO all loss events include 1 or 2 consecutive lost packets, which means that it does not suffer from context damage. Hence, there was never any need for context request and context updates with ROCCO. Hannu, Svanbro, Jonsson [Page 7] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Figure 4.2 : Packet loss patterns for CRTP and ROCCO 5. CRC strength considerations The header checksum in ROCCO is used to verify reconstruction attempts of the header and/or to verify a correct context. It is important that a header compression scheme has mechanisms for verifying that the context is correct at the decompressor to ensure the transparency of a header compression scheme, erroneous decompressed headers may not be sent to upper layers. The header fields which might change between reconstruction attempts are the IP identification, RTP marker, RTP sequence number and RTP timestamp. Profile number 8 has a 10 bits CRC, which may be used to both ensure the header compression context and to verify that the context is correct. More than 300,000 different combinations of these fields, Hannu, Svanbro, Jonsson [Page 8] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 according to what ROCCO should manage, have gone through a CRC calculation without letting any erroneous packets through. I.e., without not detecting an erroneous decompressed header. This therefore strongly indicates that 10 bits of CRC is enough to both verify header reconstruction attempts and the correctness of the header compression context. 6. Fulfillment of the ROHC requirements The requirements of a robust RTP/UDP/IP header compression scheme can be found in [ROHC-REQ]. There, the requirements on header compression are divided into: Impact on Internet infrastructure; Supported headers and kinds of RTP streams; and Efficiency. Below these requirements are summarized and comments how ROCCO fulfill or may fulfill these requirements are provided. 6.1 Impact on Internet infrastructure 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. Fulfillment with ROCCO: ROCCO ensures transparency through continuos verification of decompressed headers with the header checksum. The resulting headers after decompression are bit wise identical to the original in ROCCO. The probability for producing an erroneous header is in practice neglectable through the header checksum. Ubiquity: Must not require modifications to existing IP (v4 or v6), UDP, or RTP implementations. Fulfillment with ROCCO: ROCCO does not require any modifications to existing implementations of IP, UDP or RTP. 6.2 Supported headers and kinds of RTP streams Ipv4 and Ipv6: Must support both IPv4 and IPv6. Fulfillment with ROCCO: Compression profiles are defined in ROCCO for both IPv6 and IPv4. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be compressed efficiently. Fulfillment with ROCCO: ROCCO does not, at current date, explicitly compress IPv4 tunneling headers or IPv6 extension headers. Hannu, Svanbro, Jonsson [Page 9] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Genericity: Must support compression of headers of arbitrary RTP streams. Fulfillment with ROCCO: Any current ROCCO compression profile is capable of compressing any RTP stream. Compression is however substantially improved if compression profiles optimized for a known traffic pattern are used, e.g., low-bandwidth voice or low- bandwidth video. With the same principles, compression profiles optimized for genericity may also be developed. 6.3 Efficiency 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. Fulfillment with ROCCO: ROCCO provides efficient compression with a minimum header size of 1 byte. Under error prone conditions, ROCCO provides significant better compression efficiency than RFC2508. See chapter 3. Error propagation: Error propagation due to header compression should be kept at an absolute minimum. Fulfillment with ROCCO: Defined ROCCO compression profiles handle all kind of loss events. Defined profiles also efficiently handle the link error rates that are acceptable for real-time services and prevents error propagation. See chapter 4. Cellular handover: Cellular handover must be supported. The header compression scheme should not cause packet loss after handover. Fulfillment with ROCCO: Depending on the type, handover may or may not cause additional packet loss. ROCCO handles efficiently the type of loss acceptable for real-time services. See requirement on error propagation and robustness. Link delay: Must operate under all expected link delay conditions. Fulfillment with ROCCO: ROCCO does not rely on any round trip based mechanism and link delay has thus no direct implication on performance. Processing delay: The scheme must not contribute significantly to system delay budget. Fulfillment with ROCCO: ROCCO does not significantly contribute to system delay budget. Hannu, Svanbro, Jonsson [Page 10] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 Multiple links: The scheme must perform well when there are two or more cellular links in the end-to-end path. Fulfillment with ROCCO: Two or more cellular links in the path before compression imply packet loss prior to the compressor. ROCCO handles equal amount of loss before compressor as after, with least significant type encoding. Packet Misordering: The scheme must tolerate moderate misordering in the packet stream reaching the compressor. Fulfillment with ROCCO: ROCCO handles misordering before the compressor with least significant type encoding. Unidirectional links/multicast: Must operate (possibly with less efficiency) over links where there is no feedback channel or where there are several receivers. Fulfillment with ROCCO: ROCCO does not rely on any round trip based mechanism and operates thus, with the same compression profiles as for the bidirectional case also in unidirectional and multicast scenarios. The removed possibility of FEEDBACK is simply replaced with periodic refresh. Configurable header size fluctuation: It should be possible to restrict the number of different header sizes used by the scheme. Fulfillment with ROCCO: The number of different header sizes may be restricted in implementations of compression profiles or in specific "restricted" compression profiles. Hannu, Svanbro, Jonsson [Page 11] INTERNET-DRAFT ROCCO Performance Evaluation May 24, 2000 7. References [CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ROCCO] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister Svanbro, "RObust Checksum-based header COmpression (ROCCO)", Internet Draft (work in progress), May 2000. [CRTPC] Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister Svanbro, "CRTP over cellular radio links", Internet Draft (work in progress), December 1999. [CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic over cellular access networks", Internet Draft (work in progress), October 1999. [WCDMA] "Procedure for Evaluation of Transmission Technologies for FPLMTS", ITU-R TG8-1,8-1/TEMP/233-E, September 1995. [ROHC-REQ] Mikael Degermark, _Requirements for IP/UDP/RTP header compression_, Internet draft (work in progress), March 2000 , 8. Authors addresses Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 Mobile: +46 70 559 90 15 SE-971 28 Lulea, Sweden EMail: hans.hannu@ericsson.com Krister Svanbro Tel: +46 920 20 20 77 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 Mobile: +46 70 531 25 08 SE-971 28 Lulea, Sweden EMail: krister.svanbro@ericsson.com 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 November 24, 2000. Hannu, Svanbro, Jonsson [Page 12]