[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]
Versions: 00 draft-ietf-rohc-rtp
Robust Header Compression (ROHC) WG Khiem Le
INTERNET-DRAFT Christopher Clanton
Date: 24 May 2000 Zhigang Liu
Expires: 24 November 2000 Haihong Zheng
Nokia Research Center
Adaptive Header ComprEssion (ACE) for Real-Time Multimedia
<draft-ietf-rohc-rtp-ace-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 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
When Real-Time Multimedia over IP is applied to cellular systems, it
is critical to minimize the overhead of the IP/UDP/RTP header, as
spectral efficiency is a top requirement. Robustness to errors and
error bursts is also a must.
Existing IP/UDP/RTP header compression schemes such as that presented
in IETF RFC 2508 [CRTP], do not provide sufficient performance in
such environments. This report describes a new scheme (ACE, or
Le, Clanton, Liu, Zheng [Page i]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Adaptive header ComprEssion) , which like RFC 2508, is based on the
idea that most of the time IP/UDP/RTP fields are either constant or
can be extrapolated in a linear fashion. However, ACE incorporates
several additional concepts which enable it to provide excellent
compression efficiency (exceeds the performance of [CRTP]) along with
a high degree of error-resiliency. Some of the concepts employed,
such as Variable Length Encoding (VLE), enable ACE to adapt to
changing behavior in the IP/UDP/RTP header fields, such that good
efficiency and robustness characteristics are maintained over a wide
range of operating conditions.
ACE is a general framework that can be parameterized to account for
the existence/non-existence and performance characteristics of the
feedback channel. Thus, ACE is applicable over both bi-directional
and unidirectional links.
ACE is also able to perform a seamless handoff, i.e. the scheme can
resume efficient compression operation immediately after handoff.
Le, Clanton, Liu, Zheng [Page ii]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Basic Framework of ACE . . . . . . . . . . . . . . . . . . . . 1
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 1
2.2. ACE Assumptions . . . . . . . . . . . . . . . . . . . . . 2
2.3. ACE Modes of Operation . . . . . . . . . . . . . . . . . 3
2.4. Compression States . . . . . . . . . . . . . . . . . . . 3
2.4.1. Initialization/Refresh (IR) State . . . . . . . . . 4
2.4.2. First Order (FO) State . . . . . . . . . . . . . . . 4
2.4.3. Second Order (SO) State . . . . . . . . . . . . . . 4
2.5. Profiles and Context . . . . . . . . . . . . . . . . . . 5
2.6. ACE Feedback . . . . . . . . . . . . . . . . . . . . . . 6
2.6.1. ACE Acknowledgements . . . . . . . . . . . . . . . . 7
2.6.1.1. Flexibility of ACE ACKnowledgements . . . . . . 8
2.6.2. Refresh Requests . . . . . . . . . . . . . . . . . . 8
2.7. Bandwidth and Efficiency Constraints . . . . . . . . . . 8
2.7.1. Sparse IR and Sparse FO . . . . . . . . . . . . . . 8
2.7.2. Sparse ACK . . . . . . . . . . . . . . . . . . . . . 9
2.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9
2.9. Decompression Strategy . . . . . . . . . . . . . . . . . 10
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. VLE - Variable Length Encoding . . . . . . . . . . . . . 10
3.1.1. VLE Basics . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. One-Sided Variable Length Coding (OVLE) . . . . . . 13
3.2. Timer-Based Compression of RTP Timestamp . . . . . . . . 14
4. Protocol definition . . . . . . . . . . . . . . . . . . . . . 18
4.1. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Compressor/decompressor Logic . . . . . . . . . . . . . . 19
4.2.1. Starting point . . . . . . . . . . . . . . . . . . . 19
4.2.2. NRP Mode . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2.1. Compressor logic . . . . . . . . . . . . . . . . 20
4.2.2.2. Decompressor logic . . . . . . . . . . . . . . . 21
4.2.3. RPP Mode . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3.1. Compressor logic . . . . . . . . . . . . . . . . 22
4.2.3.2. Decompressor logic . . . . . . . . . . . . . . . 24
4.3. Compressed Packet Formats . . . . . . . . . . . . . . . . 25
5. Robustness/Efficiency Issues and Tradeoffs . . . . . . . . . . 31
5.1. RPP Mode - Rationale for ACK-based Robustness . . . . . . 31
Le, Clanton, Liu, Zheng [Page iii]
INTERNET-DRAFT Robust Header Compression 24 May 2000
5.2. NRP Mode - Rationale for Operation . . . . . . . . . . . 33
5.3. Checksum - Rationale for Use (Instead of CRC) . . . . . . 33
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Intellectual Property Considerations . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A - Header Field Classification . . . . . . . . . . . . 38
Appendix B - Implementation Hints . . . . . . . . . . . . . . . . 39
B.1. Considerations for Feeback Channel Realization
(RPP mode only) . . . . . . . . . . . . . . . . . . . . 40
B.2. ACK Transmission Frequency (RPP mode only) . . . . . . . 41
B.3. Transmission of Checksum Information (RPP mode only) . . 41
B.4. Suggested Parameter Values . . . . . . . . . . . . . . . 42
Appendix C - Experimental Results . . . . . . . . . . . . . . . . 44
C.1. Test Configuration . . . . . . . . . . . . . . . . . . . 44
C.2. Assumptions in implementing RFC 2508 . . . . . . . . . . 46
C.3. Test Results . . . . . . . . . . . . . . . . . . . . . . 47
Appendix D - Handoff Operation . . . . . . . . . . . . . . . . . 49
Le, Clanton, Liu, Zheng [Page iv]
INTERNET-DRAFT Robust Header Compression 24 May 2000
1. Introduction
This Internet draft describes a general header compression framework,
and specifies in detail a protocol to compress IP/UDP/RTP headers,
based on the framework. For conciseness, the general background
information on header compression, and requirements specific to
error-prone and low bandwidth environments is not elaborated on in
this document. Much of the information can be found in RFC2508 and
[REQ].
The remainder of this document is structured as follows. Section 2
is a conceptual introduction, which describes the basic ACE
framework, as well as its application to IP/UDP/RTP header
compression. Section 3 describes the different encoding techniques.
Section 4 is the protocol definition. It provides a detailed
description of the profile attributes and the resulting profiles, the
compressor/decompressor logic, packet header formats, and bit field
definitions. Section 5 specifies rationale for algorithm choices.
Some informative appendices are also included at the end.
2. Basic Framework of ACE
2.1. Terminology
- Static field: A header field that does not change for the duration
of the session. An example is the UDP port number.
- Random field: A field that is inherently unpredictible, e.g. UDP
checksum
- Compression context: The set of data used by the compressor to
compress the current header. The compression context is a dynamic
quantity that may change on a header-by-header basis
- Decompression context: The set of data used by the decompressor to
decompress the current header. The decompression context is a
dynamic quantity that may change on a header-by-header basis; to
enable correct decompression, the decompression context must be in
synchronization with the compression context
- Numerical field: A header field that can be interpreted as
numerical information, e.g. RTP Sequence Number. An example of non-
numerical field is the RTP CSRC list.
Le, Clanton, Liu, Zheng [Page 1]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- String: a sequence of headers whose 1) non-random numerical fields
change by a delta value which is constant within the string (a
particular case is delta equal to zero, if the field does not
change); and 2) other fields do not change
- String pattern: the set of information needed to decompress a
header belonging to a string For non-random numerical fields, it is
the delta value. For the other fields, it is the field itself.
- Error propagation: happens when the current compressed header, even
though it is not corrupted by transmission error, has to be
discarded by the decompressor, because the context synchronization
has been lost between the compressor and decompressor. Error
propagation lasts until the contexts have been resynchronized.
- Error cumulation: happens when the context synchronization is lost
due to undetected transmission errors, and subsequent headers are
likely to be incorrectly decompressed
- Window-based field: A header field that is encoded according to VLE
or Timer techniques
2.2. ACE Assumptions
ACE only requires a minimal set of assumptions, which are listed
here.
- The communication channel between the compressor and the
decompressor, referred to as 'CD-CC', could be a link or a
concatenation of links; in particular, it could include multiple IP
networks and/or multiple low-bandwidth links.
- Packet Ordering: Packets transferred between compressor and
decompressor may be lost or corrupted, but their order should be
maintained by the CD-CC (i.e., FIFO pipe).
- Error Detection: The scheme should include a mechanism to detect
errors in the compressed header; this mechanism may be provided by
the CD-CC. If CD-CC does not provide adequate error detection
capability, the scheme may be extended in a straightforward fashion
by adding an error detection code at the compressor- decompressor
level.
- Packet Length: If this information is provided by the link layer,
it may be excluded from the compressed header. Otherwise, packet
length must be carried in the compressed header.
Le, Clanton, Liu, Zheng [Page 2]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- Link-Layer Fragmentation: CD-CC may fragment packets in an
arbitrary manner, as long as they are reconstructed at the
decompressor.
2.3. ACE Modes of Operation
ACE is a general framework for robust header compression, that can be
parameterized to account for the existence/non-existence and
performance characteristics of a return path to carry feedback.
Specifically, environments where the compressor/decompressor operate
can be classified in one of the following cases:
- Return Path Present (RPP): This is the case where there is a
return path, which can be used to carry feedback information from
the decompressor to the compressor. ACE does not make any
assumptions on the performance of the return path. The return path
may experience a wide variance in delay, latency and/or error
performance. One example of return path with large latency
fluctuation is when feedback is piggybacked on the forward data
sent in the opposite direction, and the forward data is sent only
intermittently (e.g. speech that employs silence supression
tactics, where data is only transmitted when there is actual speech
detected at the transmitter).
- No Return Path (NRP): This mode of operation is used when there is
no reverse channel of any kind. In this case, no feedback can be
obtained from the decompressor.
ACE has 2 modes of operation, RPP and NRP. RPP mode is used when the
compressor knows it is in the RPP case. NRP mode is used when the
compressor knows it is in the NRP case. NRP mode is also used to
start the process if the compressor does not know which case is in
effect. If the compressor subsequently receives a feedback from the
decompressor, it will switch to the RPP mode and continue in that
mode.
2.4. Compression States
The compressor starts in the lowest compression state and gradually
transitions to higher compression states. The general principle is
the compressor will always operate in the highest possible
compression state, under the constraint that the compressor has
sufficient confidence that the decompressor has the information
necessary to decompress a header compressed according to that state.
In the RPP case, that confidence comes from receipt of ACKs from the
Le, Clanton, Liu, Zheng [Page 3]
INTERNET-DRAFT Robust Header Compression 24 May 2000
decompressor. In the NRP case, that confidence comes from sending
the information a certain number of times.
The compressor may also transition back to a lower compression state
when necessary.
Thus ACE's primary approach to robustness is proactive, i.e. it aims
at avoiding loss of context synchronization between the compressor
and decompressor, rather than reacting to it.
For IP/UDP/RTP compression, the three compressor states are the
Initialization/Refresh, First Order, and Second Order. A brief
description of each is given in the subsections below.
2.4.1. Initialization/Refresh (IR) State
In this state, the compressor essentially sends IR headers. The
information sent in a refresh may be static and non-static fields in
uncompressed form (full refresh), or just non-static fields in
uncompressed form (non-static refresh). The compressor enters this
state at initialization, upon request from decompressor, or upon
Refresh Time-out. The compressor leaves the IR state when it is
confident that the decompressor has correctly received the refresh
information.
2.4.2. First Order (FO) State
Subsequently to the IR state, the compressor operates in the FO state
when the header stream does not conform to a string, or when the
compressor is not confident that the decompressor has acquired the
string pattern. In this state, the compressor essentially sends FO
headers. In the case of speech with silence suppression turned on,
a new talk spurt following a silence interval will result in the RTP
TS incrementing by more than TS_stride, the regular TS increment.
Consequently, the header stream does not conform to the string
pattern, and the compressor is in the FO state. The compressor will
leave this state and transition to the SO state when the current
header conforms to a string, and the compressor is confident the
decompressor has acquired the string pattern.
2.4.3. Second Order (SO) State
The compressor enters this state when the header to be compressed
belongs to a string, and the compressor is sufficiently confident
that the decompressor has also acquired the string pattern. In the SO
Le, Clanton, Liu, Zheng [Page 4]
INTERNET-DRAFT Robust Header Compression 24 May 2000
state, the compressor sends SO headers, which essentially only
consist of a sequence number. While in the the SO state, the
decompressor does a simple extrapolation based on information it
knows about the pattern of change of the header fields and the
sequence number contained in the SO header in order to regenerate the
uncompressed header. The compressor leaves this state to go back to
FO state when the header no longer conforms to the string.
2.5. Profiles and Context
To be able to decompress, the decompressor must share a common
knowledge of some information with the compressor. The information
can be short term (i.e. may change frequently, e.g. from packet to
packet), or long term (remain constant for the duration of the
session, or seldom change).
A profile is a repository of the long term information. A profile is
determined by the flow to be compressed (e.g. IP version, whether it
is UDP, TCP, or RTP, if it is RTP, what is the codec behavior), the
system operating environment (e.g. RPP or NRP), the CD-CC performance
behavior and capabilities (e.g. error distributions, whether the CD-
CC provides packet boundary framing), and by the user-specified
required level of performance. A profile can be characterized by a
set of attributes.
A context is a repository of the short term information. For a given
profile, the compressor uses a compression context to compress the
current packet, while the decompressor uses a corresponding
decompression context. An example of information contained in the
context is the field values of the last decompressed header.
An IP/UDP/RTP compression or decompression profile is determined by
the following considerations:
- Stream to be compressed:
IP version: v4 or v6
UDP behavior: whether UDP checksum is used or not
RTP codec behavior: Value of TS_stride, Linearity of RTP TS with
respect to wall-clock
- CD-CC:
Distribution of header losses due to detected transmission errors
Capability to sustain transmission of consecutive large size
Le, Clanton, Liu, Zheng [Page 5]
INTERNET-DRAFT Robust Header Compression 24 May 2000
headers Residual error rate, seen by decompressor
- User requirements:
Maximum acceptable error propagation (in NRP case only)
Each of the above considerations corresponds to some profile
attribute.
Stream-related profile attributes are derived by the compressor from
observing the flow of headers. Some attributes (e.g. IP version) can
be instantaneously derived from the current header. Others may
require observation over multiple headers (e.g. Value of TS_stride).
CD-CC-related profile attributes are determined by the upfront
knowledge of the CD-CC. In the absence of such knowledge, default
attributes can be used.
The decompression profile must share some attribute values (e.g. IP
version, TS_stride value) with the compression profile, for the
decompression to succeed. Some values are acquired by the
decompressor through observing the flow of full headers sent at
initialization (e.g. IP version). Others may have to be explicitly
sent by the compressor, through in-band signaling, or some other
mechanism.
In-band signaling information is sent by the compressor in the in-
band signaling field of the compressed header. In-band signaling can
be used to update the decompressor on some information not found
explicitly in the non-static compressed header fields, and that
typically seldom changes. An example is the information that the
compressor is using Timer encoding technique for the RTP TS of the
current header, (and of subsequent headers, until further notice)
along with the value of TS_stride. Other uses are possible. See
section 3 for details on encoding techniques.
Some attributes do not need to be known by the decompressor.
See section 4 for a detailed specification of the profiles along with
their attributes.
2.6. ACE Feedback
This section is relevant only to the RPP mode. ACE has different
kinds of feedback:
Le, Clanton, Liu, Zheng [Page 6]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- Ack
- Refresh_Request (full or non-static)
2.6.1. ACE Acknowledgements
An ACK packet contains a sequence number that uniquely identifies the
compressed header packet that is being ACKed. ACE ACKnowledgements
have four main functions:
- To inform the compressor that Refresh information has been
received. In that case, the compressor knows that the decompressor
has acquired the information necessary to decompress FO headers.
This means the compressor can reliably transition to the next
higher compression state, the FO state. This kind of ACK is
referred to as an IR-ACK.
- To inform the compressor that FO information has been received; in
that case, the compressor knows that the decompressor has acquired
the information necessary to decompress SO headers. This means the
compressor can reliably transition to the next higher compression
state, SO; this kind of ACK is referred to as an FO-ACK.
- To inform the compressor that a header with a specific sequence
number n has been received; in that case, the compressor knows that
the decompressor can determine the sequence number without any
ambiguity (caused, e.g., by counter wrap-around) up to header
number n + seq_cycle, where seq_cycle is the counter cycle
(determined by the number of bits, k, in the sequence number).
This kind of ACK is referred to as an SO-ACK.
- When information is sent as in-band signaling, to confirm that the
in-band signaling information has been received
The control of transition from IR to FO to SO states by ACKs ensures
that there is no context desynchronization, and therefore no error
propagation. That is, a compressed header that is not received in
error can always be correctly decompressed, because synchronization
is never lost.
Reception of ACKs by the compressor can also be used to increase
compressor header field encoding efficiency. Compression is more
efficient because the compressor just has to send the necessary
Le, Clanton, Liu, Zheng [Page 7]
INTERNET-DRAFT Robust Header Compression 24 May 2000
information (but no more) to ensure correct decompression of the
current header. In general, the minimal information that the
compressor needs to send depends on what information the decompressor
already knows. The information known at the decompressor is
indicated to the compressor in the decompressor's ACK transmission.
2.6.1.1. Flexibility of ACE ACKnowledgements
There is a lot of flexibility with respect to when and how often the
decompressor sends an ACK. ACE is also extremely resilient to ACKs
being lost or delayed. The compressor constantly adapts its
compression strategy based on the current information to be
compressed and the ACKs received.
Loss or delay of an FO-ACK may result in the compressor staying
longer in the FO state. Loss or delay of an SO-ACK may result in
the compressor sending more bits for the sequence number, to prevent
any incorrect decompression at the decompressor caused by counter
wrap around.
An advantage of this flexibility is that the feedback channel
utilized to transmit the ACKs can have very loose requirements. This
is because ACKs only have an effect on the compression efficiency,
NOT the correctness. Delay or loss of ACKs might cause the size of
compressed headers to increase, but even in such cases the increase
is minor (logarithmic).
2.6.2. Refresh Requests
Refresh Requests are sent when the decompressor determines that it
needs refresh information. Requests can be for a Full Refresh or Non-
static Refresh.
2.7. Bandwidth and Efficiency Constraints
2.7.1. Sparse IR and Sparse FO
Larger size headers such as IR or some FO may cause a problem if too
many of them are sent consecutively. This might occur, e.g., if the
compressor waits for an ack to transition to a higher compression
state, but the round-trip delay between compressor and decompressor
is large, and in the meantime the CD-CC cannot accomodate on a
sustained basis the surge in bandwidth demand caused by the larger
Le, Clanton, Liu, Zheng [Page 8]
INTERNET-DRAFT Robust Header Compression 24 May 2000
size headers. There is also a negative impact on overall efficiency.
Sparse transmission technique can be used to alleviate the problem.
In that technique, the larger size headers are interspersed with
smaller size headers. The smaller size headers are the ones that
would be sent in the higher compression state, where the compressor
would transition to, if the larger size headers were acked. Sparse
transmission can be applied to IR headers interspersed with FO
headers, or FO headers interspersed with SO headers.
2.7.2. Sparse ACK
An enhancement to the acknowledgement procedure can be used to reduce
FO ACK traffic on the feedback channel; this traffic can be quite
high if there is significant round trip delay between compressor and
decompressor. In this case, several FO headers would be sent before
the compressor can receive an ACK, and normally, one ACK would be
sent by the decompressor for each FO header received.
The basic idea is that whenever the decompressor receives a packet
and needs to send an ACK to the compressor, it just sends the ACK
once (or twice if there is no default 'pattern' agreed on by the
compressor and decompressor) and waits for some round trip time (as
opposed to sending ACKs in response to each, e.g., FO packet on the
feedback channel). After the round trip time, if the decompressor
can confirm that the compressor received the ACK (evidenced by
receipt of an SO packet at the decompressor), it continues normal
decompression. Otherwise, it will send the ACK again and the process
repeats.
The only potential negative to this approach is if the ACK sent by
the decompressor is lost. In that case, progression to the next
higher compression state by the compressor is delayed until the next
ACK is correctly received (at least one round trip time).
2.8. Checksum
In the RPP mode, a checksum is used as a secondary means of
robustness, in complement to the ACK, which is the primary means of
robustness. The CS needs only be attached to a small percentage of
headers.
In the NRP mode, a checksum is used in conjunction with refresh for
robustness. The CS is attached to all headers.
The CS is calculated as a 8-bit one's complement checksum,
Le, Clanton, Liu, Zheng [Page 9]
INTERNET-DRAFT Robust Header Compression 24 May 2000
calculated over the whole uncompressed header. Refer to section 5 for
a more detailed discussion.
2.9. Decompression Strategy
The decompressor uses as reference for decompression only those
headers which it is sufficiently confident of the correct
decompression (secure reference). A secure reference must be chosen
from the headers received with an OK CS. Until a new secure reference
is chosen, all subsequent headers are decompressed with respect to
the current secure reference. A major advantage of this approach is
that an undetected error which affect correct decompression of
header m will not affect decompression of subsequent headers. For
example, if header # 3 is an FO used as a secure reference, and
header # 5 is an SO with an undetected error, the decompression of
header # 6 will be based solely on header # 3 and not affected by
header # 5. In other words, an undetected error will affect only the
current header, just like when headers are not compressed.
3. Encoding
This section describes techniques for minimizing the overhead
associated with transmitting this kind of compressed header
information in FO and SO packet headers, as well as ACK packets.
3.1. VLE - Variable Length Encoding
An alternative approach to encoding irregular changes in header
fields is to send the 'k' least significant bits of the original
header field value.
Clearly, it is desirable for the compressor to minimize this number
of bits. Due to the possible loss of packets on the channel between
compressor and decompressor (CD-CC), the compressor does not know
which packet will be used as the reference by the decompressor, and
hence, does not know how many LSBs need to be sent.
Variable Length Encoding (VLE) solves this problem. The basic
algorithm employs a 'sliding window', maintained by the compressor,
which is advanced when the compressor has sufficient confidence that
the compressor has certain information. The confidence may be
obtained by various means, e.g., an ACK from the decompressor if
operating in RPP. In the case of NRP a sliding window of fixed size,
Le, Clanton, Liu, Zheng [Page 10]
INTERNET-DRAFT Robust Header Compression 24 May 2000
e.g. M (described later) may be used. In either case, the value of
k determined depends on the current values in the sliding window.
Details of the operation follow below.
3.1.1. VLE Basics
Basic concepts of VLE are:
* The decompressor uses one of the decompressed header values as a
reference value, v_ref. The reference may be chosen by various
means- one approach might be to select only headers whose correct
reconstruction is verified by inclusion of a checksum with the
compressed header ("secure" reference).
* The compressor maintains a sliding window of the values (VSW) which
may be chosen as a reference by the decompressor. It also
maintains the maximum value (v_max) and the minimum value (v_min)
of VSW.
* When the compressor has to compress a value v, it calculates the
range r = max(|v - v_max|, |v - v_min|). The value of k needed is
k = ceiling(log2(2 * r + 1)), i.e., the compressor sends the
ceiling(log2(2 * r +1)) LSBs of v as the encoded value.
* The compressor adds v into the VSW and updates the v_min and v_max
IF the value v could potentially be used as a reference by the
decompressor.
* The decompressor chooses as the decompressed value the one that is
closest to v_ref and whose k LSB equals the compressed value that
has been received.
It is obvious that we need to move forward (or shrink) the sliding
window to prevent k from increasing too much. To do that, the
compressor only needs to know which values in VSW have been received
by the decompressor. In the case of RPP, that information is carried
in the ACKs. In the case of NRP, the VSW is moved without ACK, if
there are a maximum number of entries, 'M', already present in VSW.
M is defined in the compressor logic section and further elaborated
upon in the "Implementation Hints" appendix.
The VLE concept can be applied to RTP Timestamp, RTP Sequence Number,
IP-ID header fields, etc.
The examples below illustrate the operation of VLE under various
scenarios. The field values used in the examples could correspond to
any fields that we wish to compress. The examples illustrate the
scenario where the compressed field has resolution of one bit.
Le, Clanton, Liu, Zheng [Page 11]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Example 1: Normal operation (no packet loss prior to compressor, no
reodering prior to compressor).
Suppose packets with header fields 279, 280, 281, 282, and 283 have
been sent, and 279 and 283 are fields of potential reference packets.
The current VLE window is {279, 283}.
and a packet with field value = 284 is received next, VLE computes
the following values
New Value VMax VMin r # LSBs
284 283 279 max[|284-279|,|284-283|]=5 4
The window is unmodified if we assuming the new packet {284} is not a
potential reference. The field is encoded using 4 bits in this case,
and the actual encoded value is the 4 least significant bits of 284
(10011100) which = 1100.
Example 2: Packet Loss prior to compressor.
Suppose packets with header fields 279, 280, 281, 282, and 283 have
been sent, and 279 and 283 are fields of potential reference packets
such that the VSW is again {279, 283}.
If a packet with field value = 290 is received next, VLE computes the
following values
New Value VMax VMin r # LSBs
290 283 279 max[|290-283|,|290-279|]=11 5
So the field is encoded using 5 bits. Actual encoded value is the 5
LSBs of 290 (100100010) which = 00010.
If we assume the new value is a potential reference, the new VSW is
{279, 283, 290}.
Example 3: Packet Misordering prior to compressor.
Suppose packets with header fields 279, 280, 281, 282, and 283 have
been sent, and 279 and 283 are fields of potential reference packets
such that the VSW is again {279, 283}.
If a packet with field value = 278 is received next, VLE computes the
following values
Le, Clanton, Liu, Zheng [Page 12]
INTERNET-DRAFT Robust Header Compression 24 May 2000
New Value VMax VMin r # LSBs
278 283 279 max[|278-283|,|278-279|]=5 4
So the field is encoded using 4 bits. Actual encoded value is the 4
LSBs of 278 (10010110) which = 0110.
If we assume the new value is a potential reference, the new VSW is
{283, 290, 278}.
In any case, the VLE encoded fields must be accompanied by some bits
in order to identify the different possible encoded field sizes.
Sizes of this bit field can vary depending on the number of different
sizes one wishes to allow. The approach in ACE is to allow only a
few different sizes for byte-aligned header formats. Huffman coding
of the length is used to achieve some additional efficiency, based on
the expected frequency of needing the different sizes. 1 or 2
additional bits are actually sent in the ACE compressed header.
The decompressor behavior in all the example cases is the same- it
uses as a reference a specific decompressed header field value. The
header to use might be indicated by the presence of a checksum in the
compressed header packet, or by other means. The must by definition
be one of the values in the compressor's window.
For example let's assume that the last correctly decompressed packet
which qualifies as a reference was the packet with header field =
291. Now suppose the encoded field value of 303 (10001111) is
received and = 01111. The two values closest values to 291 which
have LSBs = 01111 are 271 and 303. 303 is closest, therefore it is
correctly selected as the uncompressed field value.
3.1.2. One-Sided Variable Length Coding (OVLE)
The VLE encoding scheme is very general and flexible, as it can
accommodate arbitrary changes (positive, negative) from one value to
the next. When VLE is applied to a field that is monotonic (e.g.
RTP SN), there is a loss in efficiency, because k, the number of bits
is defined by the condition
(2p+1)<2 to the kth(p=|current value-reference value|).
On the other hand, if the variation is known to be monotonic, the
required k is smaller, as it has to satisfy only
p < 2 to the kth.
One-Sided Variable Length Encoding (OVLE) is based on the idea to use
a k that satisfies the latter condition, when the field to be
Le, Clanton, Liu, Zheng [Page 13]
INTERNET-DRAFT Robust Header Compression 24 May 2000
compressed is monotonic (increasing or decreasing). When the field
is almost always monotonic (quasi-monotonic), OVLE compression can be
used when the field is behaving monotonically, and 'regular' VLE used
when it is not.
The savings over VLE is 1 bit, and since that saving is achieved most
of the time, it translates into a 1 bit savings in the average
overhead. Alternatively, the number of bits can be kept the same,
but the frequency of ACKs can be reduced by a factor of 2.
3.2. Timer-Based Compression of RTP Timestamp
A useful observation is that the RTP timestamps when generated at the
source closely follow a linear pattern as a function of the time of
day clock, particularly for the case when speech is being carried in
the RTP payload.
For example, if the time interval between consecutive speech samples
is 20 msec, then the RTP time stamp of header n (generated at time
n*20 msec) = RTP time stamp of header 0 (generated at time 0) +
TS_stride * n, where TS_stride is a constant dependent on the voice
codec. In what follows, n is referred to as the 'packed' RTP TS.
Consequently, the RTP TS in headers coming into the decompressor also
follow a linear pattern as a function of time, but less closely, due
to the delay jitter between the source and the decompressor. In
normal operation (no crashes or failures), the delay jitter is
bounded, to meet the requirements of conversational real-time
traffic. Thus, it is possible for the decompressor to obtain an
approximation of the packed RTP TS of the current header (the one to
be decompressed), by adding the time elapsed since the previous
header to the packed RTP TS of that previous header. The decompressor
then refines this approximation with the additional information
received in the compressed header. The compressed header carries the
k least significant bits of the packed RTP TS. The required value of
k to ensure correct decompression is a function of the jitter between
the source and decompressor. The compressor can estimate the jitter
and determine k, or alternatively it can have a fixed k, and filter
out the packets with excessive jitter. Once the decompressor has the
packed RTP TS, it can convert to the original RTP TS.
The advantages to this approach are many:
* The size of the compressed RTP TS is constant and small. In
particular, it does NOT depend on the length of the silence
interval. This is in contrast to other RTP TS compression
Le, Clanton, Liu, Zheng [Page 14]
INTERNET-DRAFT Robust Header Compression 24 May 2000
techniques, which require a variable number of bits dependent on
the duration of the preceding silence interval. It is very
important to be able to efficiently compress the RTP TS, as it is
one of the essential changing fields (see Appendix A).
* No synchronization is required between the timer process and the
decompressor process.
* Robustness to errors: the partial RTP TS information in the
compressed header is self contained and only needs to be combined
with the decompressor timer to yield the full RTP TS value. Loss
or corruption of a header will not invalidate subsequent compressed
headers.
As an example, consider the scenario in which a long silence interval
has just ended, and the header compressor scheme is preparing to send
an FO header to decompressor to adjust for the unexpected change in
RTP timestamp. The compressor knows that the packet which has just
arrived is the first packet of a new talkspurt as opposed to
following a lost packet because the RTP SN increments by only one.
Note that we need not assume any special behavior of the input to the
compressor (i.e. the scheme tolerates reordering, or more generally,
non-increasing RTP timestamp behavior observed prior to the
compressor).
At the end of the silence interval, the compressor sends in the FO
compressed header the k least significant bits of
p_TS_current = (current RTP time stamp - TS0)/TS stride.
p_TS_current is the "packed" representation of the current time; it
has granularity of TS stride, which is the RTP timestamp increment
observed during e.g. a VoIP session (e.g. 160 for a 20 mS voice
codec).
TS0 is an arbitrary timestamp offset.
The compressor runs the following algorithm to determine k.
STEP 1: calculate Network_Jitter (Current_header, j) as
| (T_current - T_j) - (p_TS_current - p_TS_j) |
for all packets in a sliding window, TSW. TSW contains several pairs
(T_j, p_TS_j) of values corresponding to the packets sent that may be
used as a reference, including the last packet which was ACKed. In
the case of RPP, TWS is moved when an ACK with some indication (e.g.,
Le, Clanton, Liu, Zheng [Page 15]
INTERNET-DRAFT Robust Header Compression 24 May 2000
checksum) is received from the decompressor. In the case of NRP mode,
the TSW is moved without ACK if there are a maximum number of
entries, 'M', present in TSW. I.e., the sliding window is managed
just like for the case of VLE.
T_current is the current wall clock time at the compressor, and T_j
is the wall clock time at which the packet j in the sliding window
was received by the compressor. Both T_current and T_j are in units
of TS stride.
p_TS_current & p_TS_j are the packed RTP timestamp times of the
packets, determined from the actual RTP header.
STEP 2: compute Max_Network_Jitter, where
Max_Network_Jitter = Max{Network_Jitter(current, j)},for all headers j
in TSW
Note that Max_Network_Jitter is positive.
STEP 3: k is then calculated as
k = ceiling(log2(2 * J + 1), where
J = Max_Network_Jitter + Max_CD_CC_Jitter + 2.
Max_CD_CC_Jitter is the maximum possible CD-CC jitter expected on the
CD-CC. Such a maximum depends only on the characteristics of the CD-
CC, and is expected to be reasonably small in order to have good
quality for real-time services.
The factor + 2 is to account for the quantization error caused by the
timers at the compressor and decompressor, which can be +/- 1.
As a an example of operation, consider the case of a voice codec (20
mS), such that TS_stride = 160 mS. Assume T_current and p_TS_current
are 357 and 351, respectively, and that we have sliding window TSW
which contains the following values 4 entries:
j T_j p_TS_j
1 9 7
2 8 6
3 7 4
4 3 1
j above is the packet number.
Le, Clanton, Liu, Zheng [Page 16]
INTERNET-DRAFT Robust Header Compression 24 May 2000
In this case we have
Network_jitter(1)=|(357-9)-(351-7)|=4 (80 mS Network Jitter)
Network_jitter(2)=|(357-8)-(351-6)|=4 (80 mS Network Jitter)
Network_jitter(3)=|(357-7)-(351-4)|=3 (60 mS Network Jitter)
Network_jitter(4)=|(357-3)-(351-1)|=4 (80 mS Network Jitter)
So Max_Network_Jitter = 4.
We assume a maximum CD-CC jitter of 2 (40 mS); the total jitter to be
handled in this case is then
J = 4 + 2 + 2 = 8 packets (160 mS)
and k = 5 bits (since 2 * 5 + 1 < 2^5). The compressor sends the 5
LSBs of p_TS_current to the decompressor (351 = 101011111, so the
encoded TS value = 11111).
When the decompressor receives this value, it first attempts to
estimate the timestamp by computing the time difference between the
last reference established and the current packet
T_current - T_ref, where T_ref is the value of the packed
TS corresponding to the reference used by the decompressor.
That value is added to p_TS_ref to get the estimate.
Assume that at the decompressor packet #3 is used as the reference:
- T_current = 359
- T_ref = 7
- p_TS_ref = 4
Note:
T_current is picked here as any value; the difference between it and
T_ref represents the length of the silence interval as observed at
the decompressor. Then:
T_current - T_ref = 359 - 7 = 352
p_TS_current(estimate) = 352 + 4 = 356
The decompressor searches for the closest value to 356 which has, in
this case, LSBs = 11111. The value in this case is 351, the original
p_TS.
Le, Clanton, Liu, Zheng [Page 17]
INTERNET-DRAFT Robust Header Compression 24 May 2000
If instead the compressor were to send the timestamp jump as simply
the difference in consecutive packed RTP Timestamps, that value would
be
p_TS_current - p_TS_ref = 351-4 = 347 = 101011011
So over twice as many bits would be sent for a silence interval of
347 (20 mS) = 6.94 seconds
Due to basic conversational real-time requirements, the cumulative
jitter in normal operation is expected to be at most only a few times
T stride for voice. For this reason, the FO payload formats in
section 3 are optimized (in terms of representing different k- length
encoded TS values) for the case of k=4 (handles up to 16
discrepencies in the timestamp). The remaining formats allow a wide
range of jitter conditions (outside of just voice) to be handled as
well.
4. Protocol definition
4.1. Profiles
For IP/UDP/RTP compression, a profile has the following attributes:
- Mode: NRP or RPP; derived as described below
- IP version: v4 or v6; derived from IR header
- UDP checksum: yes or no; derived from IR header
- RTP TS encoding technique: VLE or Timer; encoding derived from
negotiation
This set of profile attributes can be configured to support either
audio or video. In addition, the value of TS_stride is a numerical
parameter predefined or sent by in-band signaling, or determined by
some other means.
In-band signaling can be carried using FO_EXT header, with S bit set
to 1. In the RPP mode, an ACK of the FO_EXT confirms that the
decompressor has received the signal and thus allows the compressor
to stop sending in-band signal (means smaller headers afterward).
Note that the in-band signaling is optional and can be replaced by
other signaling channel if provided by the links.
A default profile will be used when there is no prior knowledge on
Le, Clanton, Liu, Zheng [Page 18]
INTERNET-DRAFT Robust Header Compression 24 May 2000
some attributes: Mode, or UDP Checksum or RTP TS behavior. In that
case,
- Mode is set to NRP
- UDP Checksum is yes
- RTP TS encoding is VLE
This profile will work with both audio and video.
In addition, depending on the specific CD-CC, the following may have
to be added:
- CRC at the compressor/decompressor level to detect transmission errors;
this is needed to reduce the probability of undetected transmission
error from the CD-CC to an acceptable level if it is not sufficiently
low
- Packet length information: this is needed if the CD-CC does not provide
the information
- CID: this is needed if the CD-CC does not provide a means to
discriminate between flows
When CRC, Packet length and/or CID are needed, the exact formats and
lengths depend on the CD-CC technology, and therefore would have to
be defined on a case-by-case basis, as an implementation issue.
For simplicity, we assume no compressor level CRC is needed, packet
length information is provided, as well as a means to discriminate
between flows.
4.2. Compressor/decompressor Logic
4.2.1. Starting point
The compressor will start in the Initialization state and assume NRP
mode. If no ACK is ever received, it stays in NRP mode. Otherwise,
after receiving the first ACK, the compressor will switch to and stay
in RPP mode.
However, if by some other means (e.g. profile, or interface to link
layer, etc) the compressor knows there is a feedback channel, the
compressor can start in Initialization state of RPP mode directly.
The following sections will describe the logic for each operation
mode. Note that the logic is designed such that the switch from NRP
to RPP mode is seamless.
Le, Clanton, Liu, Zheng [Page 19]
INTERNET-DRAFT Robust Header Compression 24 May 2000
4.2.2. NRP Mode
4.2.2.1. Compressor logic
Below is the state machine for the compressor in NRP mode. Details of
each state and the transitions between states will follow the
diagram.
Lr refresh sent end of string
+----->------->----------+ +------<-------<--------+
| | | |
| v v |
+----------+ +----------+ +----------+
| IR state | | FO state | | SO state |
+----------+ +----------+ +----------+
^ ^ | | ^ |
| | refresh time-out | | Lf FO sent | |
| +-----<----------<-------+ +------->------->----+ |
| |
+----------------<---------------<---------------------+
refresh time-out
* IR state
The compressor starts in IR state and sends full refresh headers
using FH header format (see header format section).
The compressor leaves the IR state and transitions to FO state
when it has sent Lr Refresh headers, where Lr is a parameter.
Note that the compressor needs not to send Lr refresh headers
consecutively. Sparse IR scheme can be applied to alleviate the
surge of bandwidth problem. The compressor can send IR_IR1
refresh packets, followed by IR_FO1 FO packets, then IR_IR2
refresh packets, then IR_FO2 FO packets, and so on ... Note that
each FO packet send in IR state MUST carry a checksum.
Dynamic refresh is carried using FO_EXT header format with ST =
11 and all the Mi bits set to 1. However, the compressor may
want to send a full refresh sometime during the session to fully
update the context of the decompressor. One simple
implementation could be that a full refresh will be sent after
Cfr packets has elapsed since the last full refresh.
Le, Clanton, Liu, Zheng [Page 20]
INTERNET-DRAFT Robust Header Compression 24 May 2000
* FO state
FO headers are sent in this state. Every FO header MUST carry a
checksum.
The compressor leaves this state and transitions to the SO state
when the current header conforms to a string, and the compressor
has sent Lf FO headers since the last string pattern change. Lf
is a parameter.
Similarly to the IR state, a sparse FO scheme can be used here.
Basically, the compressor can send FO_FO1 FO packets, then FO_SO1
SO packets, then FO_FO2 FO packets, then FO_SO2 SO packets, etc.
Note that each SO packet MUST carry a checksum.
The compressor will also go back to IR state after a Refresh
time-out. A Refresh Time-out occurs when the maximum time or
number of packets allowed to elapse since the last refresh. In a
simple implementation, a parameter Cr (number of packets) can be
used for the time-out purpose.
* SO state
SO headers are sent in this state. Every SO header MUST carry a
checksum.
Fields in SO headers are encoded using as reference only those
headers in the sliding window (see below).
The compressor will transit back to FO state if the current
string terminates, or back to IR state after refresh time-out
(see Cr above).
* Sliding window management
Each window-based field value of a transmitted IR header or FO
header MUST be added to the sliding window. If window reaches the
size of M, it will slide (i.e. the oldest header will be removed
to make room for the new one). M is an implementation parameter.
4.2.2.2. Deompressor logic
* Only a full refresh (FH) packet can create a new context. Any
headers (other than FH) belonging to an invalid (i.e. non-
Le, Clanton, Liu, Zheng [Page 21]
INTERNET-DRAFT Robust Header Compression 24 May 2000
existing) context will be discarded until the corresponding
context is created.
* Both full and dynamic refresh will update the context without
decompression.
.IP "*" 4 If checksum is present in a compressed header, the
decompressor MUST use it to verify a correct decompression. If
the checksum test fails, the decompressor MUST discard the
packet.
* The decompressor MUST use only the following headers as reference
for decompression of subsequent headers:
1) A full or dynamic refresh header with a correct checksum
2) A FO header with a correct checksum
4.2.3. RPP Mode
4.2.3.1. Compressor logic
Below is the state machine for the compressor in RPP mode. Details of
each state and the transitions between states will follow the
diagram.
receive 1 ACK end of string
+----->------->----------+ +------<-------<--------+
| | | |
| v v |
+----------+ +----------+ +----------+
| IR state | | FO state | | SO state |
+----------+ +----------+ +----------+
^ ^ | | ^ |
| | receive REFRESH_REQ | | receive 1 or 2 ACKs | |
| +-----<----------<-------+ +------->------->-----+ |
| |
+----------------<---------------<----------------------+
receive REFRESH_REQ
* IR state
At the beginning of a session, the compressor starts in IR state
and sends full refresh headers using FH header format (see header
Le, Clanton, Liu, Zheng [Page 22]
INTERNET-DRAFT Robust Header Compression 24 May 2000
format section).
During the session, the compressor MUST go to IR state upon
receiving an REFRESH_REQ packet. It MUST send either full refresh
or dynamic refresh, depending on the F-bit in the REFRESH_REQ
packet.
Each window-based field value of a transmitted IR header, MUST be
added to the sliding window.
The compressor MUST leave the IR state and transition to FO state
when it receives an ACK confirming that the decompressor has
correctly received the refresh information. The ACK also triggers
the deletion of older headers in the sliding window.
Note that sparse IR as described in section 4.2.2.1 can be also
applied here.
* FO state
FO headers are sent in this state. The shortest FO header format
that can carry enough information MUST be used.
The compressor MAY choose to send checksum in a FO header. In the
case of audio, the compressor SHOULD attach the checksum in every
FO header.
Each window-based field value of an FO header with checksum, MUST
be added to the sliding window.
The compressor leaves this state and transition to the SO state
when the current header conforms to a string, and 2 ACKs (1 ACK
if default FO information has been established between the
compressor and decompressor) older than the current string has
been received.
Upon receiving an ACK, the compressor SHOULD shrink the sliding
window by deleting any value that is older than the one in the
ACKed header.
FO_EXT headers SHOULD be sent in FO state when FO header format
is incapable to handle the change of current header (e.g., non-
essential fields changed, see FO_EXT format).
Note that sparse FO as described in section 4.2.2.1 can be also
applied here.
Le, Clanton, Liu, Zheng [Page 23]
INTERNET-DRAFT Robust Header Compression 24 May 2000
* SO state
SO headers are sent in this state. Checksum needs not to be
transmitted in an SO header unless the compressor wants the
decompressor to ACK that header.
Each window-based field value of an SO header with checksum, MUST
be added to the sliding window.
The compressor may also need to send SO_EXT header if, 1) the
compressed RTP SN needs more bits than allowed in SO header, or
2) there is a misordering of packets before the compressor which
prevents the use of OVLE (as defined in SO packet). Note that not
every misordering of packets will trigger an SO_EXT packet. An
SO_EXT header is needed only in a severe misordering event, in
which the RTP SN in a misordered packet is smaller than the all
the RTP SN values in the sliding window.
The compressor will transit back to FO state if the current
string terminates. In addition, it MUST go to IR state upon
receiving a REFRESH_REQ packet from the decompressor.
* Sliding window management
The compressor controls the size of the sliding window by sending
more or less headers with checksum. The compressor will shrink
the sliding window after receiving an ACK.
In implementation, it may also set an maximum window size M and
slides the sliding window even if no ACK is received. M can
depend on the round trip time between the compressor and
decompressor and/or the memory available to the compressor.
However, the value of M SHOULD be large enough to avoid
triggering the decompressor to send a REFRESH_REQ (see
decompressor logic).
4.2.3.2. Deompressor logic
* Decompressor MUST use only a secure reference to decompress. A
secure reference is a compressed header with a checksum
(calculated over the uncompressed header) AND the checksum test
succeeds.
* The decompression of an FO header is achieved using the last
secure reference and applying different decoding rules (e.g. VLE
Le, Clanton, Liu, Zheng [Page 24]
INTERNET-DRAFT Robust Header Compression 24 May 2000
or OVLE for RTP SN and Timer-based scheme for RTP TS) to
different fields.
* The decompression of an SO header is achieved in two steps:
1) Decompress the RTP SN in current header by using the
decompressed RTP SN in the last secure reference and applying
OVLE (if SO header) or VLE (if SO_EXT header) decoding
algorithm.
2) Decompress RTP TS and IP ID using linear extrapolation.
* If a header with checksum is received, the decompressor MUST
verify the checksum after decompression. If the checksum test
succeeds, the decompressor MUST send an ACK for that header. If
it fails, the decompressor MUST discard the packet.
* The decompressor MUST send REFRESH_REQ after receiving Lcs
consecutive headers with incorrect checksum, where Lcs is an
implementation parameter.
4.3. Compressed Packet Formats
Here we describe the different header formats which are used by ACE.
The compressed RTP SN is used as the sequence number of the packet.
A compressed packet may include a 8-bit checksum, defined as the
one's complement of the one's complement sum of the uncompressed
(original) IP/UDP/RTP header.
Note that for simplicity, RTP payload will not be shown in the
following descriptions, since we understand it always follows the
compressed headers. Besides, an extra CID field will be added if the
link layer does not provide mux/demux of different flows.
The following header formats are for IPv4. IPv6 formats will be
provided later.
SO: 1 byte without checksum or 2 bytes with checksum.
Consists only of Packet Type (PT), used to distinguish the
different types of header formats at the decompressor, C-bit,
used to indicate the presence of checksum, Compressed RTP
sequence number, C_RTP_SN, and the payload. Checksum is present
if C = 1. SO packets are the most optimal packets to send, due to
Le, Clanton, Liu, Zheng [Page 25]
INTERNET-DRAFT Robust Header Compression 24 May 2000
their small size.
+----+---+----------+::::::::::::+
| PT | C | C_RTP_SN | checksum |
+----+---+----------+::::::::::::+
PT: 1 bit (value = "0")
C: 1 bit (value = "1" indicates the presence of checksum)
C_RTP_SN: 6 bits (LSBs of RTP SN, OVLE encoded)
checksum: 8 bits (present if C = 1; not present if C = 0)
FO: 2 to 6 bytes.
FO packets are sent as as a result of observing unrepresentable
irregularities in the expected behavior pattern of the header
fields. One purpose of this structure is to optimize coding
(usually requires only 2 bytes) for the case of irregular change
in RTP TS, which is usually the most frequent case of
irregularity.
Note that the C_RTP_TS carries LSBs of the packed RTP-TS value.
The coding rules can be either VLE or timer-based.
Le, Clanton, Liu, Zheng [Page 26]
INTERNET-DRAFT Robust Header Compression 24 May 2000
+----+---+---+-----+-----+----------+::::::::::+:::::::::+
| PT | C | M | TI | FMT | C_RTP_SN | C_RTP_TS | C_IP_ID |
+----+---+---+-----+-----+----------+::::::::::+:::::::::+
::::::::::+
checksum |
::::::::::+
PT: 2 bits (value = "10")
C: 1 bit (indicates if checksum is present in this header)
M: 1 bit (the Marker bit in the original RTP header)
TI: = 0 (1 bit), if only C_RTP_TS is present
= 10 (2 bits), if only C_IP_ID is present
= 11 (2 bits), if both fields are present
FMT: 1 or 2 bits, combined with TI-bit, indicating the exact
structure of FO header (see table below)
C_RTP_SN: 6 or 8 bits (LSBs of RTP SN, VLE encoded)
C_RTP_TS: variable length (LSBs of the packed RTP TS,
VLE or timer-based encoding )
C_IP_ID: variable length (LSBs of IP ID, VLE encoded)
checksum: 8 bits (present if C = 1; not present if C = 0)
+------------------------------------------------------------+
| TI | FMT | C_RTP_SN | C_RTP_TS | C_IP_ID | Length* of |
| Value | Value | Length | Length | Length | FO Header |
| | | (bits) | (bits) | (bits) | (bytes) |
+-------+-------+----------+----------+---------+------------+
| 0 | 0 | 6 | 4 | N.P. | 2 |
| | 10 | 6 | 11 | N.P. | 3 |
| | 11 | 8 | 9 | N.P. | 3 |
+-------+-------+----------+----------+---------+------------+
| 10 | 0 | 6 | N.P. | 11 | 3 |
| | 1 | 8 | N.P. | 16 | 4 |
+-------+-------+----------+----------+---------+------------+
| 11 | 00 | 6 | 4 | 6 | 3 |
| | 01 | 7 | 8 | 9 | 4 |
| | 10 | 8 | 12 | 12 | 5 |
| | 11 | 8 | 8 | 16 | 5 |
+-------+-------+----------+----------+---------+------------+
Note: N.P. -- Not Present
* length not including checksum
ACK: 2 bytes.
Le, Clanton, Liu, Zheng [Page 27]
INTERNET-DRAFT Robust Header Compression 24 May 2000
+----+----------+
| PT | C_RTP_SN |
+----+----------+
PT: 3 bits (value = "110")
C_RTP_SN: 13 bits (LSBs of the acked RTP SN)
SO_EXT: 2 bytes without checksum or 3 bytes with checksum.
+----+---+----------+::::::::::+
| PT | C | C_RTP_SN | checksum |
+----+---+----------+::::::::::+
PT: 4 bits (value = "1110")
C: 1 bit (indicates the presence of checksum)
C_RTP_SN: 11 bits (LSBs of RTP SN, VLE encoded)
checksum: 8 bits (present if C = 1; not present if C = 0)
SO_EXT is sent if the compressor is in SO state, but the
6-bit C_RTP_SN (OVLE encoded) is not long enough. (for
example, due to a large amount of packet loss before the
compressor, or no ACK has been received after sending 64 SO
packets). Another reason for the compressor to send SO_EXT
packet is to handle the misordering case, since C_RTP_SN is
VLE encoded in this header.
FO_EXT: variable length.
general structure
+----+----+---+---+-----------------------------+
| PT | ST | C | M | depending on ST value |
+----+----+---+---+-----------------------------+
Le, Clanton, Liu, Zheng [Page 28]
INTERNET-DRAFT Robust Header Compression 24 May 2000
PT: 5 bits (value = "11110")
ST: Sub-type, 1 or bits (see notes below)
C: 1 bit (indicating the presence of the checksum
M: 1 bit (Marker bit in RTP header)
Two reasons that could trigger the transmition of FO_EXT header:
1) Changes in the RTP-SN, RTP-TS, or IP-ID cannot be carried
using FO format, i.e. the number of bits are not enough.
2) Some non-essential header fields changed.
Therefore, we have three cases:
Case 1 (ST = 0): reason 1 only.
+----+----+---+---+--------+--------+-------+::::::::::+
| PT | ST | C | M | RTP_SN | RTP_TS | IP_ID | checksum |
+----+----+---+---+--------+--------+-------+::::::::::+
- RTP_SN, RTP_TS, and IP_ID are uncompressed.
- checksum is 8 bits and present if C = 1.
- Total length: 9 bytes without checksum or 10 bytes
with checksum
case 2 (ST = 10): reason 2 only.
+----+----+---+---+---+----+-----+----------+::::::::::+
| PT | ST | S | C | M | TI | FMT | C_RTP_SN | C_RTP_TS |
+----+----+---+---+---+----+-----+----------+::::::::::+
:::::::::+::::::::::+::::::::::::::+::::::::::+::::::::::+
C_IP_ID | Bit Mask | Field Values | signal | checksum |
:::::::::+::::::::::+::::::::::::::+::::::::::+::::::::::+
- S: in-band signal flag (1 means signal field is present)
- Everything from C bit up to and including C_IP_ID is the same
as in FO header
- Bit Mask (1 byte): indicates which fields are present
M1 - Type of Service (in IPv4 header)
M2 - Don't Fragment Flag (in IPv4 header)
M3 - Time to Live (in IPv4 header);
M4 - Padding-bit (in RTP header)
M5 - Extension-bit (in RTP header, note that RTP header
extension will be carried as RTP payload)
M6 - Payload Type (in RTP header)
M7 - CSRC Count (in RTP header)
M8 - CSRC List (in RTP header)
Le, Clanton, Liu, Zheng [Page 29]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- Field Values: For simplicity, uncompressed values. Further
optimization are possible.
- Signal: Used for in-band signaling
- checksum: at least 8 bits, but may be longer to fit the
byte boundary.
case 3 (ST = 11): reason 1 and 2.
+----+----+---+---+---+--------+--------+-------+
| PT | ST | S | C | M | RTP_SN | RTP_TS | IP_ID |
+----+----+---+---+---+--------+--------+-------+
::::::::::+::::::::::::::+::::::::::+::::::::::+
Bit Mask | Field Values | signal | checksum |
::::::::::+::::::::::::::+::::::::::+::::::::::+
- S: in-band signal flag (1 means in-band signal is present)
- RTP_SN, RTP_TS, and IP_ID are uncompressed
- Bit Mask, Field Values, Signal and checksum are same as in case 2
FH: Consists of the PT ("111110", 6 bits), followed by full headers
from RTP, UDP, and IP, checksum, plus the payload. Some of the
fields in the UDP and IP header could be inferred from the link
layer (e.g. packet length), and may be replaced with compressor /
decompressor level information (e.g., CID). This type of packet
header is normally sent only at session initiation, or in
response to an FH_REQ Packet, described below. The extra bits can
be padding or used for other purpose.
+----+------------+-------------+-------------+---------+
| PT | IP header* | UDP header* | RTP header* |checksum |
+----+------------+-------------+-------------+---------+
* some field(s) may be modified (see above)
REFRESH_REQ:
These packets are sent only in extremely rare incidences, e.g.,
memory loss or CPU crash. It may also be sent by the decompressor
when undected transmission error is caught by the header
compression level checksum.
Le, Clanton, Liu, Zheng [Page 30]
INTERNET-DRAFT Robust Header Compression 24 May 2000
+----+---+
| PT | F |
+----+---+
PT: 7 bits (value = 1111110).
F: = 1, requesting full refresh
= 0, requesting only dynamic (non-static) refresh
5. Robustness/Efficiency Issues and Tradeoffs
This section provides the rationale behind the choices in ACE to
achieve robustness and efficiency.
5.1. RPP Mode - Rationale for ACK-based Robustness
The primary means for providing robustness in the RPP mode is to send
ACKs. When a return path is available, transitioning from a lower
compression state to a higher compression state in a manner
controlled by ACKs provides a proactive way to prevent loss of
context synchronization, and consequently error propagation. Context
loss is prevented because the compressor always uses as compression
reference some header that is known to be correctly decompressed
through an ack. The alternative is to have a reactive approach, i.e.
detect loss of context synchronization and react to it by requesting
the compressor to send information to resynchronize the contexts.
An issue that remains to be addressed is the residual transmission
errors undetected by the CD-CC. When such an undetected error occurs,
without any additional mechanism, the decompressor will decompress
incorrectly without knowing it. Depending on the technology of the
CD-CC, the residual error may or may not be large enough to be a
problem. If the residual error is excessive, there must be a
sufficiently strong CRC added at the compressor/decompressor level to
minimize the probability of undetected errors. However, even with a
strong CRC, there is a non-negligible chance that during the lifetime
of an RTP session, at least one header may have an undetected error.
When that happens, it is likely that decompression of the affected
header will be incorrect. If the incorrectly decompressed header
happens to be used as reference for decompressing subsequent
headers, it is likely that the subsequent headers will be incorrectly
decompressed, until another correctly decompressed header is used as
reference. This problem is referred to as error accumulation. To
address this problem, a checksum (CS) is attached to every header
Le, Clanton, Liu, Zheng [Page 31]
INTERNET-DRAFT Robust Header Compression 24 May 2000
candidate to be a reference, to allow the decompressor to verify the
correctness. The CS is calculated as a 8-bit one's complement
checksum, calculated over the whole uncompressed header. If the
decompressor detects an incorrect CS, it will simply discard the
header. Therefore, a secondary means of providing robustness is to
send compressed headers with a checksum.
Reasons why the checksum is used only as a secondary means of
providing robustness are:
- The extremely low probability of error accumulation when the link
error detection is reasonably good.
- The checksum is not meant to be a substitute for link error
detection CRC, and can dramatically reduce compression efficiency
if used in this way. Indeed, an incorrect checksum will trigger a
resynchronization process that is bandwidth costly because the
information sent consists of uncompressed "full" or large-sized
headers. The sudden surge in bandwidth caused by the large-sized
headers, may not be handled well by some radio technologies. The
resynchronization mechanism is sensitive to errors and delays. Due
to the round trip delay, there can be a significant time period
during which the decompressor has to discard all incoming headers,
while waiting for the requested resynchronization information from
the compressor.
This means that always or even frequently sending the checksum when
error detection is sufficient and ACKs are already being used is NOT
efficient use of transmission bandwidth. In ACE, a checksum need only
be sent in headers which may be used as decompression reference. In
the ACE decompression logic, these headers are usually a very small
percentage of the headers (FH, or FO). Since the checksum need not be
sent in every header, especially in 1 byte SO headers, the same bits
that would be used for the checksum can be used to send a longer
compressed sequence number and tolerate more packet loss. The loss
range tolerated grows exponentially with the number of bits
allocated to the sequence number. For example, when 2 more bits are
used (6 bits instead of 4), the range is multiplied by 4 (can
tolerate 64 packet loss rather than 16).
Another use of checksum is during sparse FO or sparse IR techniques.
If during the Sparse FO procedure, the decompressor receives an SO
without receiving any of the preceding FO headers, it will decompress
incorrectly without even knowing it. To alleviate this problem, a
checksum (CS) is appended to all the SO headers during the Sparse FO
procedure. Similarly, all FO during the Sparse IR procedure have a
CS.
Le, Clanton, Liu, Zheng [Page 32]
INTERNET-DRAFT Robust Header Compression 24 May 2000
5.2. NRP Mode - Rationale for Operation
The primary means for providing robustness in NRP mode is to send a
checksum in EVERY compressed header packet, along with occasional
refresh information. ACKs cannot be used, by definition of NRP mode.
The main reason for inclusion of the checksum in every compressed
header packet is that it provides a means of verifying that the
decompressor is functioning properly, i.e., a means to check
synchronization of contexts at compressor and decompressor.
The link layer error protection, alone or in combination with
additional protection at the compressor level, should result in very
few undetected errors reaching the decompressor. If they do, the
checksum can likely detect them, so they can be discarded before
causing any harm to the decompressor. The same behavior is observed
at the decompressor if the checksum fails due to other conditions,
e.g., excessive loss on the CD-CC.
However, unlike with RPP, there is by definition no way to let the
compressor know that such events have occurred. The compressor must
therefore periodically send some refresh information to the
decompressor 'just in case' something has gone wrong.
5.3. Checksum - Rationale for Use (Instead of CRC)
It is well-known that a CRC typically provides better error detection
capability than a checksum of the same length. The advantages of a
CRC are evident when isolated bit errors occur, or when the errors
are in a small burst. Such error patterns are often observed on many
types of transmission channels, including cellular channels.
However, the bit errors caused by loss of context synchronization,
unlike transmission errors, will tend to be widespread. This means
that a simple error detecting mechanism like a checksum would likely
suffice. Some other considerations in favor of using a checksum over
a CRC include:
- Complexity: The improved performance of CRC over checksum does not
come without cost- CRC implementation is more complex than
implementation of a checksum. In practice, the checksum
calculation can be provided in a very straightforward way, while
CRC computation likely requires additional CPU cycles due to the
bitwise operations that are often involved. The additional CPU
cycles could be significant if the header compressor needs to
process several flows in parallel, as would be the case for the
header compression entity that would reside in the cellular
Le, Clanton, Liu, Zheng [Page 33]
INTERNET-DRAFT Robust Header Compression 24 May 2000
infrastructure equipment. Processing a small number of flows might
be an issue for today's miniature wireless devices, which already
aim to stretch battery performance to new limits.
- Flexibility: It is likely much easier to implement checksums of
various lengths- one only needs to truncate the result of the one's
complement sum. This flexibility might be desirable if, e.g., one
wants to modify compressed header formats in the future in such a
way that more/fewer bits are allocated for the checksum.
Alternatively, changing the length of a CRC will, at minimum,
require definition of a new CRC polynomial. Further, if the CRC is
implemented in hardware, this kind of modification can be quite
significant.
6. Conclusions
Efficient IP/UDP/RTP Header Compression is a must for transmission of
real-time multimedia over bandwidth-limited channels. Cellular
systems in particular present significant challenges, not only in
terms of bandwidth limitations, but also issues such as bursty error
characteristics, and long round trip delays.
A new header compression scheme which is both efficient and robust to
a broad range of error and delay conditions has been presented. The
scheme overcomes the faults associated with the baseline IP/UDP/RTP
header compression technique [CRTP], using several new techniques.
These include the use of a controlled transition from lower
compression states to higher compression states, based on the
compressor confidence that the decompressor has acquired the needed
information to decompress compressed headers sent in the higher
compression state. When a feedback channel is available, confidence
is achieved by proactive feedback in the form of ACKs from the
decompressor. In addition to that state transition strategy, various
encoding schemes such as VLE, and timer-based RTP timestamp
compression are designed to minimize header overhead. ACE is also
able to continue compression/decompression process in a seamless
fashion across handoffs, including those which entail physical
relocation of the network-based compression/decompression function.
These features make this scheme ideal for VoIP transmission in
cellular environments, or in any system which is subject to non-
trivial error rates and delays.
Le, Clanton, Liu, Zheng [Page 34]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Basic ideas and principles of ACE are scalable to be able to handle a
large number of packet loss between the compressor and decompressor,
and a large degree of packet loss and misordering before the
compressor.
Preliminary results indicate that the new scheme's performance
thoroughly exceeds that of [CRTP], particularly at high random packet
error rates.
7. Intellectual Property Considerations
Nokia has filed patent applications that might possibly have
technical relation to this contribution.
Le, Clanton, Liu, Zheng [Page 35]
INTERNET-DRAFT Robust Header Compression 24 May 2000
8. References
[REQ] M. Degermark, "Requirements for IP/UDP/RTP robust header
compression", IETF Draft, May 2000.
[CRTP] S. Casner, V. Jacobson. "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", Internet Engineering Task Force
(IETF) RFC2508, February 1999.
[GSMSIG] ETSI Digital cellular telecommunications system (Phase 2+);
"Mobile radio interface layer 3 specification", (GSM 04.08
version 7.0.1 Release 1998).
Le, Clanton, Liu, Zheng [Page 36]
INTERNET-DRAFT Robust Header Compression 24 May 2000
9. Authors' Addresses
Khiem Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4882
Fax: +1 972 894-4589
E-mail: khiem.le@nokia.com
Christopher Clanton
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4886
Fax: +1 972 894-4589
E-mail: chris.clanton@nokia.com
Zhigang Liu
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-5935
Fax: +1 972 894-4589
E-mail: zhigang.liu@nokia.com
Haihong Zheng
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4232
Fax: +1 972 894-4589
E-mail: haihong.zheng@nokia.com
Le, Clanton, Liu, Zheng [Page 37]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Appendix A - Header Field Classification
In this section we describe a classification of the different
IP/UDP/RTP header fields. Three types of headers are identified:
* Static: a field which is expected to be constant during the
lifetime of the compressed packet flow. Examples of static fields
are the source and destination IP addresses, and the source and
destination UDP port numbers.
* Changing Essential: a field whose value will change with some
frequency. Examples of changing essential fields are the RTP
timestamp, RTP sequence number, and IP-ID. Each has a tendency to
change from one packet to the next. The term "essential" is used
here only for convenience, and does not mean to imply that these
fields are more essential than others.
* Changing Non-Essential: a field whose value can possibly change
during a session, but seldom does. Examples are the RTP payload
type, and the IP Time-To-Live (TTL) and Type of Service (TOS)
fields. This class of header fields also includes "inferred"
fields whose value may be provided by the link layer. An example
is the IP total length field.
The table below summarizes classification of the various IP/UDP/RTP
header fields.
Le, Clanton, Liu, Zheng [Page 38]
INTERNET-DRAFT Robust Header Compression 24 May 2000
+-----------+----------------+-------------------------------------+
| | Static | Non-static |
| | +-----------------+-------------------+
| | | Essential | Non-essential |
+-----------+----------------+-----------------+-------------------+
| IPv4 | version | IP-ID | type of service |
| Header | header length | | total length |
| Fields | protocol | | don't fragment |
| | source IP addr | | more fragment |
| | dest IP addr | | fragment offset |
| | | | time to live |
| | | | header checksum |
+-----------+----------------+-----------------+-------------------+
| IPv6 | version | | traffic class |
| Header | flow label | | next header |
| Fields | source IP addr | | hop limit |
| | dest IP addr | | |
+-----------+----------------+-----------------+-------------------+
| UDP | source port | | length |
| Header | dest port | | checksum |
| Fields | | | |
+-----------+----------------+-----------------+-------------------+
| RTP | version | marker-bit | padding-bit |
| Header | SSRC | sequence number | extension-bit |
| Fields | | timestamp | payload type |
| | | | CSRC count |
| | | | CSRC list |
+-----------+----------------+-----------------+-------------------+
Appendix B - Implementation Hints
This appendix is informative. It is meant to provide some
recommendations on how to best utilize the concepts discussed in this
draft. The descriptions below are not meant to restrict
implementations in any way; the primary objective is provide
suggestions and loose guidelines in the following areas:
- realization of channels for transmission of ACK information
- transmission frequency of ACK
- transmission frequency of compressed header with checksum
Le, Clanton, Liu, Zheng [Page 39]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- suggestions for setting ACE parameters (Lf, Lr, etc.)
B.1. Considerations for Feeback Channel Realization (RPP mode only)
ACK transmission flexibility means the implementor can utilize any of
several feedback channel options, depending on what facilities are
available in the target system. Some options (and associated
tradeoffs/considerations) follow below.
- Shared ACK channel: In this case, N channels are shared between M
decompressors, where typically N << M. Tradeoff here is bandwidth
used (low compared to dedicated case) vs. response time (slower
than dedicated case).
- Dedicated ACK channel: In this case, each decompressor has it's
own dedicated feedback channel. Tradeoff here is again bandwidth
used (high compared to shared case) vs. response time (faster than
dedicated case).
- Piggybacked ACK: In this case, ACKs in the reverse direction are
`piggybacked' on data packets already being sent in the reverse
direction. Bandwidth usage in this case could be quite low, since
transmission overhead (e.g., L1/L2 overhead) of ACK can be shared
with the packet already being sent. But response time could
suffer, since transmission of ACK can occur only when other packets
already need to be sent. In the case of speech, the ACK might be
piggybacked e.g., on actual speech from the remote endpoint.
During silence intervals, some cellular speech codecs send comfort
noise frames that might also be used to piggyback the ACK data.
- Hybrids: Combinations of the previous and the first two options
are also possible, e.g., use shared channel if piggybacking not
possible.
Clearly, it is desirable to have low delay ACK transmission using as
few system resources as is possible. As a general rule, it is
recommended that one should make use of ACK piggybacking if possible.
But as described below, ACK transmission frequency is quite low, so
that some inefficiency in transmitting them has minor effects on the
effectiveness of the compression.
Le, Clanton, Liu, Zheng [Page 40]
INTERNET-DRAFT Robust Header Compression 24 May 2000
B.2. ACK Transmission Frequency (RPP mode only)
Although the overhead due to the ACKs is quite low, it is still
desirable to minimize ACK transmission costs. This means reducing
transmission of ACKs to those times when they are absolutely needed.
By carefully managing ACK transmission, is possible to take full
advantage of the robustness/compression efficiency improvements they
can provide, without burdening the system with large amounts of
traffic on the feedback channels. The items below provide some
general guidelines for transmitting ACKs:
- In SO state, it is desirable that the compressor received an ACK in
enough time that increase of the sequence number sent in the SO
header is avoided. For example, if the compressor is sending a
6-bit sequence number while in SO state, an ACK is needed at least
once every 2^6 packets to avoid the need to send a larger sequence
number (e.g., using SO_EXT header). Note: to account for potential
loss of ACK and system round-trip delays, one may want to send them
at a slightly higher rate.
- If an estimate of the round trip time between compressor and
decompressor is known by the decompressor, the sparse ACK concept
should be used whenever possible to avoid transmission of many
consecutive ACKs during compressor state transitions.
If these guidelines are followed, one can expect very little overhead
contribution due to ACKs (normally << 1 bit per compressed header).
B.3. Transmission of Checksum Information (RPP mode only)
RPP mode only, since the checksum appears in all packets for NRP
mode.
As described in section 5, checksums provide only a secondary level
of robustness when a feedback channel is present. However, we
recommend that:
- Checksum is sent in EVERY FO header if the media is audio,
particulary when sparse IR/FO mechanisms are used, to avoid the
possibility of undetected error corrupting the decompression
context during state transitions.
- Checksum is sent in the SO header frequently enough that an ACK
transmission is triggered at the decompressor in accordance with
the guidelines for ACK transmission frequency described in section
Le, Clanton, Liu, Zheng [Page 41]
INTERNET-DRAFT Robust Header Compression 24 May 2000
B.2. I.e., sequence number wrap-around condition should be
avoided.
B.4. Suggested Parameter Values
This section provides some considerations which should be taken into
account when selected actual values for the ACE parameters described
throughout the document. In practice, it is good fine tune these
parameters in the actual operating enviroment to ensure that the best
performance is obtained.
IR_IRx/IR_FOx (x = 1, 2, 3, etc): These parameters define the
behavior of the compressor during sparse IR operation. An arbitrary
spacing between between IR and FO headers can be achieved by setting
the values appropriately; alternatively, sparse IR can be 'disabled'
by chosing IR_FOx for all x = 0. Selection of the parameters depends
on round trip time between compressor and decompressor, robustness of
the CD-CC, and bandwidth available for the header. For the cellular
case, we can expect non-negligible round-trip times, limited
transmission robustness, and very limited bandwidth. In such a
scenario, it probably makes sense to send an IR header followed by
several FO headers (e.g., IR_IR1=1, IR_FO1=N, IR_IR2=1, IR_FO2=N,
etc, where N corresponds to the number of FO packets that can be sent
in one round trip time observed on the CD-CC).
Also, note that sending IR headers could mean degradation or muting
of speech, due to their high bandwidth requirement. Also, very low
loss on CD-CC might mean very small values of x.
FO_FOx/FO_SOx (x = 1, 2, 3, etc): The same recommendations as were
given in the case of IR_IRx/IR_FOx parameters still apply. Since FO
header is typically smaller than a refresh header (and closer to the
size of an SO header), estimates of round trip time would need to be
adjusted (compared to IR_IRx/IR_FOx case).
Lr: This parameter indicates the number of refresh headers sent
before exiting the IR state, when the compressor operates in NRP
mode. The value of Lr should be selected such that there is high
probability of receiving at least one of the refresh headers at the
decompressor without errors. Factors which effect selection of this
parameter value are:
- loss characteristics of the CD-CC; e.g., if CD-CC is error-prone,
Lr may be high
- values of IR_IRx and IR_FOx (x = 1, 2, 3, etc) if sparse IR
technique is used
Le, Clanton, Liu, Zheng [Page 42]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Lf: This parameter indicates the number of FO headers that should be
sent (since the last string pattern change) before exiting the FO
state, when the compressor operates in NRP mode. The value of Lf is
chosen using similar criteria to that used to pick Lr.
Lcs: This parameter indicates the maximum number of consecutive
packets which can have an incorrect checksum value before some action
is taken by the decompressor in RPP mode.
With ACE, an incorrect checksum computation occurs when
- Link layer error detection mechanism has failed to detect an error
- FO received before IR in IR state (when sparse IR is used)
- SO received before FO in FO state (when sparse FO is used)
- Sliding window is managed in such a way that the decompression is
incorrect (i.e., value of M, described below, is too small)
Factors to consider when selecting Lcs are:
- Value of 'M' for sliding window
- Amount of degradation that is allowable in the application; in case
of RPP, refresh may be requested quicker if the application can not
tolerate much packet loss. This implies a smaller Lcs may be
desired.
- Effect of refresh packets on compressor/decompressor performance;
consideration should be given to the transmission medium's ability
to tolerate the bandwidth surge caused by the refresh; refresh also
negatively impacts compression efficiency. This may imply need for
a larger Lcs value.
Refresh Time Out: this parameter defines the amount of time between
transmission of refresh packets in NRP mode. There are several
factors to consider:
- Frequent refresh is inefficient in terms of compression
performance.
- Less frequent refresh can result in long periods where no data is
provided to the application; an application left 'starving' for
data for a considerable time may have problems or even terminate.
Le, Clanton, Liu, Zheng [Page 43]
INTERNET-DRAFT Robust Header Compression 24 May 2000
- Frequent refresh causes more frequent bandwidth surges; some
channels may be able to tolerate the larger refresh packets better
than others; a related consideration is that sending refresh info
may require `stealing' from the application data flow.
- Probability that refresh is lost due to transmission conditions;
since refresh packets are larger than other packets, probability of
corruption is higher.
It is recommended that one start with a long refresh timeout and then
lower the value to take into account the needs of the application,
the bandwidth available, and the robustness of the CD-CC.
M: M is a parameter that defines the max size of the the sliding
window (VLE and Timer-Based encoding schemes). Considerations when
selecting M include:
- Memory (cost) limitations; larger M means more memory/cost
- Round-Trip Time between compressor and decompressor
- Too small M could result in transmission of FH_REQ, sliding window
is moved without ACK (see Compressor Logic).
Appendix C - Experimental Results
The new header compression scheme was implemented (along with RFC
2508) on a testbed in order to validate its operation and
performance. This section describes the testbed and some of the
results obtained.
C.1. Test Configuration
Le, Clanton, Liu, Zheng [Page 44]
INTERNET-DRAFT Robust Header Compression 24 May 2000
+------------+ +-----+ +---------+
"Mobile Terminal" | Endpoint 1 | -- | Hub | -- | Linux 1 |---+
| (PC) | | 1 | | (UPA) | |
+------------+ +-----+ +---------+ |
|
+-------+
"Air Interface" | Hub 2 |
+-------+
|
"network" |
+------------+ ......... +---------+ |
| Endpoint 2 | --- : LAN : ---- | Linux 2 |---------+
| (PC) | : : | (UPA) |
+------------+ :.......: +---------+
The testbed employs a User Plane Adaptation (UPA) function on both
the "network" side (Linux 2) and the "mobile" side (Linux 1). The
adaptation function performs several functions:
* Header Compression: either IETF 2508, or ACE.
* Channel Delay Simulation: a fixed delay (set at run time) is
applied to each packet at the transmitter side. The same delay
model was applied on both forward and reverse channels. Delay is
simulated at the transmitting side.
* Channel Error Model: packet loss is simulated at decompressor.
The testbed can simulate channel conditions as either packet loss
or bit errors, according to random or template-based error
distributions. The same error model was applied on both forward
and feedback channels.
* H.225/H.245 Message Parser: the adaptation function on the mobile
side (in Linux 1) includes a control message parser which can
derive RTP port number information at call setup.
* This information is signalled to the network adaptation function
entity as well. The port number data allows each adaptation
function to easily determine which information flows should be
routed to the compressor.
* Handoff Manager: the adaptation function on the network side
(Linux 2) includes software for simulating handoff effects due to
the header compression (e.g., transfer of state information). The
Linux 2 can host two complete UPA entities simultaneously for this
purpose.
Le, Clanton, Liu, Zheng [Page 45]
INTERNET-DRAFT Robust Header Compression 24 May 2000
* Network Jitter Simuation: a model of the network jitter can be
included; this provides a controllable means to test the behavior
of the timer-based RTP timestamp compression scheme.
* Packet Reordering Simulation: various amounts of packet reordering
prior to the compressor can be simulated.
The endpoints are standard Windows PCs running a Microsoft
Netmeeting, a commonly used H.323 based audio/video conferencing
application. Netmeeting provides the IP/UDP/RTP data flows.
C.2. Assumptions in implementing RFC 2508
In the results which follow, it is important to note that the
following assumptions were made in implementing RFC 2508:
1. Assumes that the UDP Checksum can be omitted. This reduces the
minimal compressed header size to 2 bytes, compared to 4 with the
checksum. The same assumption is made regarding ACE.
2. Assumes that the compressor sends a large header upon receipt
of an explicit context state request from the decompressor,
compared to the compressor periodically sending a full header
every 'r' packets, where r is the 'refresh rate'.
3. The decompressor sends another context state request if the
next packet received after the previous request is NOT a full
header.
4. The decompressor drops any packets received until the full
header is received.
5. Assumes compressor responds to all context state requests,
i.e., full header may be sent unnecessarily due to timing of
request and delay of full header delivery to decompressor.
6. Assumes that the delta encoding rule given in the specification
is used.
7. The TWICE mechanism is not employed.
8. To be fair for RFC 2508, the size of "full header" is counted
as 17 bytes (COMPRESSED_NON_TCP), instead of 40 bytes
(FULL_HEADER).
9. CID is not used, e.g., the link layer provides enough
Le, Clanton, Liu, Zheng [Page 46]
INTERNET-DRAFT Robust Header Compression 24 May 2000
information to discriminate multiple flows (assumed for both ACE
and RFC 2508, for fairness).
10. Length information need not be sent in the compressed, e.g.,
the link layer provides the necessary data.
C.3. Test Results
This section summarizes performance when different channel
characteristics are simulated. The testbed is capable of simulating
random packet loss, random bit errors, and bit errors according to a
provided template. A short description of the meaning of these error
models follows.
* Random Packet Loss: Entire VoIP packets (each packet contains
one speech frame, representing a 20 or 30 mS speech sample) are
dropped at the decompressor according to a provided numerical
input.
The error simulation module at the decompressor runs a clock, and
update an error flag for each timeslot (20ms or 30ms, depending on
codec). If a compressed packet arrives at the time the flag is set
to true, the entire packet is dropped. Therefore, a value of 2%
means that on average, 2 out of every 100 opportunities to
transmit a packet would result in the packet being lost (i.e., the
error simulation is NOT driven by reception of RTP packets).
* Random Bit Errors: In this case, location of the bit error
determines whether or not the packet is dropped. If one or more
errors occur in the header of the packet (link layer header and/or
compressed header), then the packet is dropped. Errors in the
payload do not result in loss of the entire packet. A value of 2%
will result in on average 2 out of every 100 bits being corrupted.
As with the above, the simulation is not driven by reception of
bits.
Note again, that the bits may carry nothing if there is no
compressed packets being transmitted (e.g. during silence period).
* Errors According to Template: In this case, the error behavior
is determined by an error trace or template which may have been
obtained from a cellular channel simulator, or alternatively, an
actual cellular system with the capability to produce such traces.
Same rules for processing the packet apply as with the Random Bit
Le, Clanton, Liu, Zheng [Page 47]
INTERNET-DRAFT Robust Header Compression 24 May 2000
Error model.
Test Configuration Details and Assumptions:
* Microsoft Netmeeting G.723.1 6.4 kbps speech codec used; one frame
per VoIP packet (every 30 mS in this case)
* 60 mS one way delay
* Packet Loss rates (PER) of 1%, 2%, 5%, 10% and 20%
* Packet Loss rate of both payload channel and feedback channel is
the same.
Results for the case of random packet loss with VLE plus Timer-Based
coding of the RTP timestamp (no dynamic switching was used in this
case) is employed are shown in the tables below. Efficiency is
measured in terms of average packet header size (in bytes) with
overhead associated with ACK included. Link layer overhead for the
ACKs is NOT included, as it depends on the nature of the feedback
channel.
Conversational Speech Sample
+----------+-----------------------------------+
| PER (%) | 1.0 2.0 5.0 10.0 20.0 |
+ ---------+-----------------------------------+
| RFC 2508 | 1.86 2.64 3.93 5.10 5.83 |
+----------+-----------------------------------+
| ACE | 1.42 1.42 1.42 1.48 1.52 |
+----------+-----------------------------------+
To guarantee fairness, the same voice samples were used as the audio
source for each test. Silence suppression is used by Netmeeting to
induce RTP timestamp irregularities corresponding to 'real'
talkspurts and silence intervals. The adjustable threshold within
that application is set to be the same during the runs for each HC
scheme. As mentioned above, it is assumed that CID related
information can be derived from the link layer in the case of both
ACE and [CRTP]. Therefore, it is excluded from compressed headers
for both schemes.
Half time of the voice sample is in silence, which is typical for
real-life conversation. The silence periods range from 0.3 to 8.5
seconds. The talk spurts range from 1 to 10 seconds. Besides silence
periods, irregular changes of IP-ID trigger half of the FO packets.
Le, Clanton, Liu, Zheng [Page 48]
INTERNET-DRAFT Robust Header Compression 24 May 2000
For [CRTP], the actual packet loss measured is at least double the
PER over the simulated channel. This is expected since at least one
extra packet is invalidated by the decompressor and thus dropped, if
the preceding packet is detected as out of synchronization (error
propagation, see Appendix B for description). In general, with
[CRTP], the packet loss rate increases with the round trip delay.
But for ACE, error propagation has been completely eliminated. Also
of note is the near constant performance of ACE, even at high packet
loss rates.
A simple subjective evaluation proves consistent with the obtained
objective measurements. The voice quality in the case of ACE is
clearly better than that using plain RFC2508. Audio clips are
recorded into files for evaluation by interested parties. Audio
clips will be provided on the ACE homepage.
Appendix D - Handoff Operation
Handoff presents a problem for the header compression process because
it normally results in the loss of multiple packets between
compressor and decompressor. Most of the loss is the result of
sending/receiving necessary signalling and synchronization
information, when the mobile station would otherwise be
sending/receiving user traffic. For example, an upper bound in GSM
systems is 320 mS [GSMSIG], but more typically, when handoff occurs,
communications is disrupted for 100 mS, which translates into
multiple 20 msec speech packets.
Schemes such as [CRTP] will necessarily have to reinitialize the
compression/decompression process by sending large amounts of
synchronization information when handoff occurs. But ideally, the
process would not have to do any reinitialization after completion of
the handoff, if it can handle multiple packet loss. Efficiency of
this operation is important, since in some types of wireless systems
(e.g. PCS), cells can be small (several hundred to a few thousand
feet), such that handoff can occur quite frequently at mobile speeds.
Another issue with handoff is the network compressor/decompressor
relocation. In cellular systems, it is expected that the network part
of header compression/decompression is done by some network entity
that we refer to as the Access Network Infrastructure Adapter
(ANI_AD). As the MS moves farther and farther away from the location
where the call initially started, routing efficiency considerations
may require that the header compression/decompression function be
relocated from the initial ANI_AD to another ANI_AD. Such relocation
of functions already exists in third generation UMTS systems, for the
purpose of routing optimization when soft handover is done. The
Le, Clanton, Liu, Zheng [Page 49]
INTERNET-DRAFT Robust Header Compression 24 May 2000
impact of ANI_AD relocation is that to avoid reinitialization between
the MS and the new ANI_AD, some context information must be
transferred from the original ANI_AD to the new ANI_AD. The header
compression scheme must be such that it can handle that context
information transfer without being disrupted.
It is a must for the header compression scheme to handle cellular
handoff operations in an efficient manner.
When header compression is applied to a cellular environment, there
is an adaptation function in the MS and another one in the network
which is responsible for the header compression. The MS adapter
(MS_AD) acts as compressor for the uplink and a decompressor for the
downlink. Conversely, the access network infrastructure adapter
(ANI_AD) acts as decompressor for the uplink and a compressor for the
downlink.
With ACE, it is possible to do radio handoff as well as ANI_AD
relocation in a seamless manner, i.e. without requiring the
compression/decompression process to go through reinitialization or
resynchronization.
Key to the seamlessness are:
- ACE ability to withstand a very large number of packet losses
between the compressor and decompressor, caused by the radio
handoff
- ACE ability to tolerate context information transfer from the old
ANI_AD to the new ANI_AD, without disrupting the continuing
compression and decompression of user packets.
Le, Clanton, Liu, Zheng [Page 50]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/