Request for Comments: 4224 L-E. Jonsson
Category: Informational K. Sandlund
Ericsson
January 2006
RObust Header Compression (ROHC):
ROHC over Channels That Can Reorder Packets
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
RObust Header Compression (ROHC), RFC 3095, defines a framework for
header compression, along with a number of compression protocols
(profiles). One operating assumption for the profiles defined in RFC
3095 is that the channel between compressor and decompressor is
required to maintain packet ordering. This document discusses
aspects of using ROHC over channels that can reorder packets. It
provides guidelines on how to implement existing profiles over such
channels, as well as suggestions for the design of new profiles.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability of This Document to ROHC Profiles .................5
3.1. Profiles within Scope ......................................5
3.2. Profiles with Special Considerations .......................5
3.3. Profiles Incompatible with Reordering ......................6
4. Background ......................................................6
4.1. Reordering Channels ........................................6
4.2. Robustness Principles of ROHC ..............................6
4.2.1. Optimistic Approach (U/O-mode) ......................7
4.2.2. Secure Reference Principle (R-mode) .................7
5. Problem Description .............................................7
5.1. ROHC and Reordering Channels ...............................7
5.1.1. LSB Interpretation Interval and Reordering ..........7
5.1.2. Reordering of Packets in R-mode .....................9
5.1.2.1. Updating Packets ...........................9
5.1.2.2. Non-Updating Packets ......................10
5.1.3. Reordering of Packets in U/O-mode ..................10
5.1.4. Reordering on the Feedback Channel .................11
5.1.5. List Compression ...................................11
5.1.6. Reordering and Mode Transitions ....................12
5.2. Consequences of Reordering ................................13
5.2.1. Functionality Incompatible with Reordering .........13
5.2.2. Context Damage (Loss of Synchronization) ...........13
5.2.3. Detected Decompression Failures (U/O/R-mode) .......13
5.2.4. Undetected Decompression Failures (R-mode only) ....14
6. Making ROHC Tolerant against Reordering ........................14
6.1. Properties of ROHC Implementations ........................14
6.1.1. Compressing Headers with Robustness against
Reordering .........................................14
6.1.1.1. Reordering and the Optimistic Approach ....15
6.1.1.2. Reordering and the Secure
Reference Principle .......................15
6.1.1.3. Robust Selection of Compressed Header .....15
6.1.2. Implementing a Reordering-Tolerant Decompressor ....16
6.1.2.1. Decompressor Feedback Considerations ......16
6.1.2.2. Considerations for Local Repair
Mechanisms ................................17
6.2. Specifying ROHC Profiles with Robustness against
Reordering ................................................17
6.2.1. Profiles with Interpretation Interval
Offset p = -1 ......................................17
6.2.2. Modifying the Interpretation Interval Offset .......18
6.2.2.1. Example Profile for Handling Reordering ...18
6.2.2.2. Defining the Values of p for New
Profiles ..................................18
7. Security Considerations ........................................19
8. Acknowledgements ...............................................19
9. Informative References .........................................19
1. Introduction
RObust Header Compression (ROHC), RFC 3095 [1], defines a framework
for header compression, along with a number of compression protocols
(profiles). One operating assumption for the profiles defined in RFC
3095 is that the channel between compressor and decompressor is
required to maintain packet ordering for each compressed flow. The
motivation behind this assumption was that the primary candidate
channels considered did guarantee in-order delivery of header-
compressed packets. This assumption made it possible to meet the
design objectives that were on top of the requirements list at the
time when ROHC was being designed, namely to improve the compression
efficiency and the tolerance to packet losses.
Since the publication of RFC 3095 in 2001, the question about ROHC
operation over channels that do not guarantee in-order delivery has
surfaced several times; arguments that ROHC cannot perform adequately
over such channels have been heard. Specifically, this has been
raised as a weakness when compared to other header compression
alternatives, as RFC 3095 explicitly states its inability to operate
if in-order delivery is not guaranteed. For those familiar with the
details of ROHC and of other header compression schemes, it is clear
that this is a misconception, but it can also be easily understood
that the wording used in RFC 3095 can lead to such interpretation.
This document discusses the various aspects of implementing ROHC over
channels that can reorder header-compressed packets. It explains
different ways of implementing the profiles found in RFC 3095, as
well as other profiles based on those profiles, over reordering
channels. This can be achieved either by ensuring that compressor
implementations use compressed headers that are sufficiently robust
to the expected possible reordering and/or by modifying decompressor
implementations to tolerate reordered packets. Ideas regarding how
existing profiles could be updated and how new profiles can be
defined to cope efficiently with reordering are also discussed.
In some scenarios, there might be external means (such as a sequence
number) to detect and potentially correct reordering. That is, for
example, the case when running compression over an IPsec
Encapsulating Security Payload (ESP) tunnel. With such external
means to detect reordering, the decompressor can be modified to make
use of the external information provided, and reordering can then be
handled. How to make use of external means to address reordering is,
however, out of scope for this document.
2. Terminology
This document uses terminology consistent with RFC 3759 [2], and is
in itself only informative. Although it does discuss technical
aspects of implementing the ROHC specifications in particular
environments, it does not specify any new technology.
ROHC
The term "ROHC" herein refers to the following profiles:
- 0x0001, 0x0002, and 0x0003 defined in RFC 3095 [1];
- 0x0004 for compression of IP-only headers [3];
- 0x0007 and 0x0008 for compression of UDP-Lite headers [4].
The term "ROHC" excludes the following profiles, which are either
not affected by reordering or have the assumption of in-order
delivery as a fundamental requirement for their proper operation:
- 0x0000 (uncompressed) [1];
- 0x0005 (Link-Layer Assisted (LLA)) [5] and 0x0105
(R-mode extension to LLA) [6];
Reordering
A type of transmission taking place between compressor and
decompressor where in-order delivery of header-compressed packets
is not guaranteed.
Reordering channel
A connection over which reordering, as defined above, can occur.
Sequentially early packet
A packet that reaches the decompressor before one or several
packets of the same context identifier (CID) that were delayed on
the link. At the time of the arrival of a sequentially early
packet, the packet(s) delayed on the link cannot be differentiated
from lost packet(s).
Sequentially late packet
A packet is late within its sequence if it reaches the
decompressor after one or several other packets belonging to the
same CID have been received, although the sequentially late packet
was sent from the compressor before the other packet(s).
Updating packet
A packet that updates the context of the decompressor, e.g., all
packets except R-0 and R-1* in RFC 3095 [1].
Non-updating packet
A packet that does not update the context of the decompressor,
e.g., only R-0 and R-1* in RFC 3095 [1].
Change packet
A packet that updates one or more fields of the context other than
the fields pertaining to the functions established with respect to
the sequence number (SN). Specifically, it is a packet that
updates fields other than the SN, the IPv4 identifier (IP-ID), the
sequence number of an extension header or the RTP timestamp (TS).
3. Applicability of This Document to ROHC Profiles
This document addresses general reordering issues for ROHC profiles.
The foremost objectives are to ensure that ROHC implementations do
not forward packets with incorrectly decompressed headers to upper
layers, as well as to limit the possible increase in the rate of
decompression failures or in events leading to context damage, when
compression is applied over reordering channels.
3.1. Profiles within Scope
The following sections outline solutions that are generally
applicable to profiles 0x0001 (RTP), 0x0002 (UDP), and 0x0003 (ESP)
defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not
affected by reordering, as the headers are sent uncompressed. The
solutions also apply to profiles for IP-only (0x0004) [3] and for
UDP-Lite (0x0007 and 0x0008) [4]. These profiles are based on the
profiles of RFC 3095 [1] and inherently make the same in-order
delivery assumption.
3.2. Profiles with Special Considerations
Special considerations are needed to make some of the implementation
solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP)
[1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4]. For these
profiles, the SN is generated at the compressor, as it is not present
in headers being compressed. For the least significant bit (LSB)
encoding method, the interpretation interval offset (p) is always
p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus
required to increase for each packet received at the decompressor,
which means that reordered packets cannot be decompressed.
3.3. Profiles Incompatible with Reordering
The ROHC LLA profiles defined in RFC 3242 [5] and RFC 3408 [6] have
been explicitly designed with in-order delivery as a fundamental
requirement to their proper operation. Profiles 0x0005 and 0x0105
can therefore not be implemented over channels where reordering can
occur; this document therefore does not apply to these profiles.
4. Background
ROHC was designed with the assumption that packets are delivered in
order from compressor to decompressor. This was considered as a
reasonable working assumption for links where it was expected that
ROHC would be used. However, many have expressed that it would be
desirable to use ROHC also over connections where in-order delivery
is not guaranteed [7].
4.1. Reordering Channels
The reordering channels that are potential candidates to use ROHC are
single-hop channels and multi-hop virtual channels.
A single-hop channel is a point-to-point link that constitutes a
single IP hop. Note that one IP hop could be one or multiple
physical links. For example, a single-hop reordering channel could
be a wireless link that applies error detection and performs
retransmissions to guarantee error-free delivery of all data.
Another example could be a wireless connection that performs
bicasting of data during a handoff procedure.
A multi-hop virtual channel is a virtual point-to-point link that
traverses multiple IP hops. A multi-hop virtual channel would
typically be an IP tunnel, where compression is applied over the
tunnel by the endpoints of the tunnel (not to be confused with single
link compression of tunneled packets).
4.2. Robustness Principles of ROHC
Robustness is based on the optimistic approach in the unidirectional
and optimistic modes of operation (U/O-mode), and on the secure
reference principle in the bidirectional reliable mode (R-mode).
Both approaches have different characteristics in the presence of
reordering between compressor and decompressor. However, in any
mode, decompression of sequentially early packets will generally be
handled quite well since they will be perceived and treated by the
decompressor as if there had been one or more packet losses.
4.2.1. Optimistic Approach (U/O-mode)
A ROHC compressor uses the optimistic approach to reduce header
overhead when performing context updates in U/O-mode. The compressor
normally repeats the same update until it is fairly confident that
the decompressor has successfully received the information. The
number of consecutive packets needed to obtain this confidence is
open to implementations, and this number is normally related to the
packet loss characteristics of the link where header compression is
used (see also [1], section 5.3.1.1.1).
All packet types used in U/O-mode are context updating.
4.2.2. Secure Reference Principle (R-mode)
A ROHC compressor uses the secure reference principle in R-mode to
ensure that context synchronization between ROHC peers cannot be lost
due to packet losses. The compressor obtains its confidence that the
decompressor has successfully updated the context from a packet
carrying a 7- or 8-bit Cyclic Redundancy Check (CRC) based on
acknowledgements received from the decompressor (see also [1],
section 5.5.1.2).
The secure reference principle makes it possible for a compressor to
use packets that do not update the context (i.e., R-0 and R-1* [1]).
5. Problem Description
5.1. ROHC and Reordering Channels
This section reviews different aspects of ROHC susceptible of being
impacted by reordering of compressed packets between ROHC peers.
5.1.1. LSB Interpretation Interval and Reordering
The least significant bit (LSB) encoding method defined in RFC 3095
([1], section 5.7) specifies the interpretation interval offset,
called p, as follows:
For profiles 0x0001, 0x0003, and 0x0007:
p = 1, when bits(SN) <= 4;
p = 2^(bits(SN)-5) - 1 otherwise.
The resulting table describing the interpretation interval is as
follows:
+-----------+--------------+--------------+
| bits (SN) | Offset p | (2^k-1) - p |
| k | (reordering) | (losses) |
+-----------+--------------+--------------+
| 4 | 1 | 14 |
| 5 | 0 | 31 |
| 6 | 1 | 62 |
| 7 | 3 | 124 |
| 8 | 7 | 248 |
| 9 | 15 | 496 |
+-----------+--------------+--------------+
As shown in the table above, the ability for ROHC to handle
sequentially late packets depends on the number of bits sent in
each packet. For example, a sequentially late packet of type 0
(with either 4 or 6 bits of SN) sets the limit to one packet out
of sequence for successful decompression to be possible.
For profiles 0x0002, 0x0004, and 0x0008:
p = - 1, independently of bits(SN).
A value of p = -1 means that the interpretation interval offset
can only take positive values and that no sequentially late packet
can be decompressed if reordering occurs over the link.
The trade-off between reordering and robustness
The ability of ROHC to handle sequentially late packets is limited
by the interpretation interval offset of the sliding window used
for LSB encoding. This offset has a very small value for packets
with a small number of sequence number (SN) bits, but grows with
the number of SN bits transmitted.
For channels where both packet losses and reordering can occur,
modifications to the interpretation interval face a trade-off
between the amount of reordering and the number of consecutive
packet losses that can be handled by the decompressor. If the
negative offset (i.e., p) is increased to handle a larger amount
of reordering, the value of the positive offset of the
interpretation interval must be decreased. This may impact the
compression efficiency when the channel has a high loss rate.
This is shown in the figure:
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
Lower v_ref Upper
Bound Bound
<--- reordering --> <--------- losses --------->
max delta(SN) = p max delta(SN) = (2^k-1) - p
where v_ref is the reference value as per [1], section 4.5.1.
In practice, the maximum variation in SN value (max delta(SN)) due
to reordering that can be handled will normally correspond to the
maximum number of packets that can be reordered. The same applies
to the maximum number of consecutive packet losses covered by the
robustness interval.
Timer-based compression of RTP TS (see [1], section 4.5.4) provides
means to reduce the number of timestamp bits needed in compressed
headers after longer gaps in the packet stream (e.g., for an audio
stream, this is typically due to silence suppression). To use
timer-based compression, an upper limit on the inter-arrival jitter
must be reliably estimated by the compressor. It should be noted
that although the risk of reordering of course means there is a more
significant jitter on the path between the compressor and the
decompressor, there are no special reordering considerations for
timer-based compression. It all still boils down to the task of
estimating the jitter, requiring channel characteristics knowledge at
the compressor, and/or jitter estimation figures received from the
decompressor.
5.1.2. Reordering of Packets in R-mode
5.1.2.1. Updating Packets
The compressor always adds references in the sliding window for all
updating packets sent. The compressor removes values older than
values for which it has received an acknowledgement to shrink the
window and thereby increase the compression efficiency.
The decompressor always updates the context when receiving an
updating packet and uses the new reference for decompression.
Acknowledgements are sent to allow the compressor to shrink its
sliding window.
Reordering between updating packets
The decompressor can update its context from the reception of a
sequentially late updating packet. The decompressor reference is
then updated with a value that is no longer in the sliding window
of the compressor. This "missing reference" can be caused by
reordering when operating in R-mode.
The result is that the compressor and the decompressor lose
synchronization with each other. When the decompressor
acknowledges the sequentially late packet, the compressor might
already have discarded the reference to this sequence number, and
continue to compress packets based on more recent references (in
packet arrival time). Decompression will then be attempted using
the wrong reference.
5.1.2.2. Non-Updating Packets
Reordering between non-updating packets only
A non-updating packet that reaches the decompressor out of
sequence only with respect to other non-updating packets can
always be decompressed properly.
Reordering between non-updating packets and updating packets
When a non-updating packet is reordered and becomes sequentially
late with respect to an updating packet, the decompressor may have
already updated the context with a new reference when the late
packet is received. It is thus possible for a non-updating packet
to be decompressed based on the wrong reference because of
reordering when operating in R-mode.
Since decompression of non-updating packets cannot be verified,
this can lead to a packet erroneously decompressed to be forwarded
to upper layers.
5.1.3. Reordering of Packets in U/O-mode
Reordering between non-change packets only
When only non-change packets are reordered with respect to each
other, decompression of sequentially late packets is limited by
the offset p of the interpretation interval (see section 5.1.1).
Decompression of a sequentially late packet with SN = x is
possible if the value of the SN of the packet that last updated
the context was less than or equal to x + p.
Problems occur if context(SN) has increased by more than p with
respect to field(SN) carried within the packet to decompress.
This means that for a well-behaved stream with a constant unit
increase in the RTP SN, a packet can arrive up to p packets out of
sequence and still be correctly decompressed. Otherwise, it
cannot be properly decompressed. It also means that if the
compressor sends two consecutive packets with SN(packet1)=100 and
SN(packet2)=108 when p=7, packet1 cannot be decompressed if it
arrives even one packet late due to reordering.
Reordering involving change packets
When a packet is reordered and becomes sequentially late with
respect to a change packet, decompression of the late packet may
eventually fail, as the context information required for
successful decompression may not be available anymore.
Decompression can always be verified since all U/O-mode packet types
are context updating. Consequently, a failure to decompress a packet
that is caused by reordering can be detected, and context