[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                         Hans Hannu
INTERNET-DRAFT                                           Krister Svanbro
Expires: November 2000                                 Lars-Erik Jonsson
                                                        Ericsson, Sweden
                                                            May 24, 2000






                      ROCCO Performance Evaluation
             <draft-ietf-rohc-rtp-rocco-performance-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

   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.
           <draft-ietf-rohc-rtp-rocco-00.txt>

   [CRTPC]  Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister
            Svanbro, "CRTP over cellular radio links", Internet Draft
            (work in progress), December 1999.
            <draft-degermark-crtp-cellular-01.txt>

   [CELL]   Lars Westberg, Morgan Lindqvist, "Realtime traffic over
            cellular access networks", Internet Draft (work in
            progress), October 1999.
            <draft-westberg-realtime-cellular-01.txt>

   [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
            <draft-ietf-rohc-rtp-requirements-00.txt>,



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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/