One document matched: draft-ietf-rohc-rtp-rocco-performance-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:52:45 |