invalidation due to reordering can thus be avoided. The risk of
forwarding incorrectly decompressed packets to upper layers is
therefore small when operating in U/O-mode. For channels known to
reorder packets, U/O-mode should therefore be the preferred mode of
operation. The additional risk of losing context synchronization, or
for erroneous packet to be delivered to upper layers, is limited.
5.1.4. Reordering on the Feedback Channel
For R-mode, upon reception of an acknowledgement, the compressor
searches the sliding window to locate an updating packet with the
corresponding SN; if it is not found, the acknowledgement is invalid
and is discarded ([1], section 5.5.1.2). In other words, feedback
received out of order either is still useful or is discarded.
In U/O-mode, if the compressor updates its context based on feedback,
the same logic as for R-mode applies in practice.
Reordering on the feedback channel has thus no impact in either mode.
5.1.5. List Compression
ROHC list compression is an additional compression scheme for RTP
contributing source (CSRC) lists and IP extension header chains. The
base is called table-based item compression, and it is almost
completely independent from the rest of the ROHC compression logic.
Therefore, this part of the scheme does not exhibit any special
vulnerabilities when it comes to reordering, assuming a reasonable
optimistic approach is used in U/O-mode. Specifically, it does not
suffer significantly from the "missing reference" problem when
operating in R-mode.
On top of the table-based item compression mechanism, an additional
compression technique may be used, called reference based list
compression. Reference based list compression however has a logic
that is similar to the rest of the ROHC compression logic, and
therefore it suffers from similar reordering vulnerabilities,
especially the "missing reference" problem of R-mode. Note, however,
that the generation identifier used in U/O-mode makes that scheme
more robust to reordering.
When using list encoding type 1, 2, or 3, which makes use of
reference lists, decompression will succeed only if all individual
items are known by the decompressor, along with the correct reference
list required to properly decompress the packet. List compression
using the "Generic scheme", also known as "Encoding type 0", is not
using reference based list compression, and type 0 decompression will
thus succeed as long as all individual items are known by the
decompressor. Because of this, type 0 list compression should be the
preferred method used when operating over reordering channels.
5.1.6. Reordering and Mode Transitions
Transition from U/O-mode to R-mode
This transition can be affected by reordering if a packet type 0
(UO-0) is reordered and delayed by at least one round-trip time
(RTT). If the decompressor initiates a mode change request to
R-mode in the meantime, the reordered UO-0 packet may be handled
as an R-0 packet; it can be erroneously decompressed and forwarded
to upper layers. This is because the decompressor can switch to
R-mode as soon as it sends the acknowledgement Ack(SN, R) to the
compressor (see also [1], section 5.6).
Transition from R-mode to U/O-mode
A similar situation as above can occur during this transition.
However, because the outcome of the decompression is always
verified using a CRC verification in U/O-mode, the reordered
packet will most likely fail decompression and will be discarded.
The above situation, although it is not deemed to occur frequently,
is still possible; thus, mode transitions from U/O-mode to R-mode
should be avoided when reordering can occur.
5.2. Consequences of Reordering
The context updating properties of the packets exchanged between ROHC
peers are the most important factors to consider when deriving the
impacts of reordering. For this reason, the robustness properties of
the U/O-mode and of the R-mode are affected differently.
The effects of reordering on ROHC can be summarized as follows:
- Functionality incompatible with reordering;
- Increased probability of context damage (loss of synchronization);
- Increased number of decompression failures - Detected (U/O/R-mode);
- Increased number of decompression failures - Undetected (R-mode).
5.2.1. Functionality Incompatible with Reordering
There is one optional ROHC function that cannot work in the presence
of reordering between ROHC peers.
The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely
on the in-order delivery of each segment, as there is no sequencing
information in the segments. A segmented packet for which one (or
more) segment is received out of order cannot be decompressed, and it
is discarded by the decompressor. Therefore, segmentation should not
be used if there can be reordering between the ROHC peers.
The use of this optional feature is open to implementations and is
local to the compressor only; it does not impact the decompressor.
5.2.2. Context Damage (Loss of Synchronization)
Reordering of packets between ROHC peers can impact the robustness
properties of the optimistic approach (U/O-mode) as well as the
reliability of the secure reference principle (R-mode).
The successful decompression of a sequentially late change packet
(U/O-mode) and/or updating packet (R-mode) can update the context of
the decompressor in a manner unexpected by the compressor. This can
lead to a loss of context synchronization between the ROHC peers.
5.2.3. Detected Decompression Failures (U/O/R-mode)
Reordering of packets between ROHC peers can lead to an increase in
the number of decompression failures for context updating packets
(see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the
decompression of updating packets can be verified, the decompressor
can reliably detect decompression failures, including those caused by
reordering, and discard the packet. Note that local repairs, subject
to the limitations stated in [1] section 5.3.2.2.3, can still be
performed.
5.2.4. Undetected Decompression Failures (R-mode only)
Reordering of packets between ROHC peers can lead to an increase in
the number of decompression errors for non-updating packets. For
R-mode, decompression of R-0 and R-1* packets cannot be verified. If
reordering occurs and decompression is performed using the wrong
secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor
cannot reliably detect such errors. As a result, erroneous packets
may be forwarded to upper layers.
6. Making ROHC Tolerant against Reordering
This section describes different approaches that can improve the
performance of ROHC when used over reordering channels and minimize
the effects of reordering. Examples are provided to guide
implementers and designers of new profiles. The solutions target
either the properties of ROHC implementations or the specification of
profiles. This is covered by sections 6.1 and 6.2, respectively.
6.1. Properties of ROHC Implementations
Existing ROHC profiles can be implemented with the capability to
properly handle packet reordering. The methods described in this
section conform with, and thus do not require any modifications to,
the ROHC specifications within scope of this document (see section
3). Specifically, the methods presented in this section can be
implemented without any impairment to interoperability with other
ROHC implementations that do not use these methods.
The methods suggested here may, however, lower the compression
efficiency, and these modifications should not be used when
reordering is known not to occur. Some of these methods aim to
increase the decompression success rate at the decompressor, while
others aim to avoid context damage that would cause a loss of context
synchronization between compressor and decompressor.
The methods proposed are each addressing specific issues listed in
section 5 and can be combined to achieve better robustness against
reordering.
6.1.1. Compressing Headers with Robustness against Reordering
The methods described in this section are methods local only to the
compressor implementation. They can be used without modifications or
impact to the decompressor.
6.1.1.1. Reordering and the Optimistic Approach
The optimistic approach is affected by the reordering characteristics
of the channel when operating over a reordering channel. Compressor
implementations should therefore adjust their optimistic approach
strategy to match both packet loss and reordering characteristics.
For example, the number of repetitions for each context update can be
increased. The compressor should ensure that each update is repeated
until it is reasonably confident that at least one change packet in
the sequence of repetitions has reached the decompressor before the
first packet sent after this sequence.
6.1.1.2. Reordering and the Secure Reference Principle
Fundamental to the secure reference principle is that only values
acknowledged by the decompressor can be used as reference for
compression. In addition, some of the packet types used in R-mode do
not include a CRC over the original uncompressed header, and the
decompressor has no means to verify the outcome of the decompression.
Decompression of non-updating packet types thus entirely relies on
the cumulative effect of previous updates to the secure reference,
and the compressed data is based on the current value of the
reference. This reference must be synchronized between ROHC peers.
For R-0 and R-1* packets, the reception of the encoded bits applied
to the secure reference is sufficient for correct decompression, but
only when in-order delivery between ROHC peers is guaranteed.
Avoiding the "missing reference" problem (section 5.1.2.1)
A compressor implementation can delay the advance in the sliding
window to a reference acknowledged by the decompressor, until it
has confidence that no acknowledgement for any of the values that
could be discarded can be received. This confidence can be based
on the maximum delay that reordering can introduce over the
channel.
6.1.1.3. Robust Selection of Compressed Header
Packet formats can be chosen with an interpretation interval for the
LSB encoded sequence number that allows for larger negative offsets
(see section 5.1.1). This provides the capability to decompress
sequentially late packets with a greater amount of reordering.
To achieve this, the compressor should be implemented conservatively
in terms of the choice of packet types to send, by transmitting
packets with more sequence number bits. As shown in the table in
section 5.1.1, using 8 bits of SN allows a packet to be decompressed
when the reordering leads to up to 7 units in sequence number
variation (i.e., delta(SN)). Increasing the number of SN bits (i.e.,
using a larger SN_k [1]) transmitted will make ROHC even more
tolerant to reordering.
For example, a conservative compressor implementation could use the
packet types as shown in the table below:
+----------------------+-------------------------+
| Optimal Packet Type | Alternative Packet Type |
| (without reordering) | (reordering possible) |
+----------------------+-------------------------+
| UO-0 | UOR-2*-ext0 |
| R-0 | R-1*-ext0 |
| R-0-CRC | UOR-2*-ext0 |
| R-1* | R-1*-ext0 |
| UO-1 | UOR-2-ext0 |
| UO-1-TS | UOR-2-TS-ext0 |
| UO-1-ID | UO-1-ID-ext3 (with S=1) |
| | UOR-2-ID-ext0 |
| UOR-2* | UOR-2*-ext0 |
+----------------------+-------------------------+
Such a compressor implementation would thus always be sending at
least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off
when compared to the 1 octet that can be sent by a more aggressive
implementation operating on a channel with no reordering.
Note that since the interpretation interval for profiles 0x0002,
0x0004, and 0x0008 is always p = -1 independently of bits(SN), the
methods suggested in this section will not work for these profiles
unless this value is modified (section 6.2.1).
6.1.2. Implementing a Reordering-Tolerant Decompressor
The methods described in this section are methods local only to the
decompressor implementation. They can be used without modifications
or impact to the compressor.
6.1.2.1. Decompressor Feedback Considerations
Reducing the feedback rate when the flow behaves linearly
The decompressor should reduce its feedback rate when a large
number of UOR-2 packets with extensions are received, when the
flow behaves linearly (i.e., when only fields pertaining to the
functions established with respect to the sequence number are
changing).
In particular, if the compressor implementation makes a more
conservative selection of packet types (section 6.1.1.3) in order
to handle reordering, the decompressor should try to avoid sending
more feedback than it would for the case where the more optimal
packet types are used. This can be useful to minimize the usage
of the feedback channel, thereby improving efficiency of the link.
Note that even if the decompressor does not make this adjustment
to its feedback rate, packet losses or context damages will not
increase.
Acknowledgements and sequentially late packets
Reordered feedback (or feedback for packets received out of order)
will not cause problems (see section 5.1.4). However, the
decompressor should not send acknowledging feedback for a packet
that can be identified as being sequentially late (e.g., based on
the sequence number of the packet), as the current state of the
context will better reflect the compressor context than the
content of the reordered packet.
6.1.2.2. Considerations for Local Repair Mechanisms
When decompression fails, and if reordering can be assumed to be the
cause of this failure, subsequent decompressions may be attempted for
sequentially late packets by going backward in the interpretation
interval (as opposed to moving forward for local repair). If one of
the decompression attempts is successful, the late packet may be
passed on to upper layers with or without updating the decompressor
context. If the subsequent decompression attempt fails, the packet
should be handled according to [1] section 5.3.2.2.3.
6.2. Specifying ROHC Profiles with Robustness against Reordering
6.2.1. Profiles with Interpretation Interval Offset p = -1
New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and
0x0008 (UDP-Lite) [4] should redefine how the value of the offset p
is determined, and use the same algorithm as in profile 0x0001 [1]
instead of p = -1 independently of bits(SN) (section 5.1.1).
While such a change would make these updated profiles slightly less
robust to packet losses, they would still be no less robust than
profile 0x0001.
6.2.2. Modifying the Interpretation Interval Offset
The interpretation interval offset p could be modified for existing
profiles to handle reordering while improving the compression
efficiency when compared to the solution in section 6.1.1.3.
6.2.2.1. Example Profile for Handling Reordering
The value of the interpretation interval offset p can be adjusted to
achieve a robustness against reordering similar to the effect of
selecting packet types as suggested in section 6.1.1.3.
Consider a scenario where robustness against packet losses is kept a
priority, and for which of a value p=7 is deemed enough. In this
case, a ratio where the positive offset is about twice as large as
the negative offset can be used. This leaves a value of p = 2^k/ 3.
The resulting values are shown in the following table:
+-----------+--------------+----------------+
| bits (SN) | Offset p | Positive range |
| k | (reordering) | (losses) |
+-----------+--------------+----------------+
| 4 | 5 | 10 |
| 5 | 10 | 21 |
| 6 | 21 | 42 |
| 7 | 42 | 85 |
| 8 | 85 | 170 |
| 9 | 170 | 341 |
+-----------+--------------+----------------+
Using this value for p, a fair amount of reordering can be handled
without having to send UOR-2 packets most of the time. The trade-off
is that this is at the expense of robustness against packet losses.
6.2.2.2. Defining the Values of p for New Profiles
As described in RFC 3095 [1], the interpretation interval when
sending k bits of SN is defined as follows:
f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p]
The negative bound (v_ref - p) limits the ability to handle
reordering, and the positive bound (v_ref + (2^k - 1) - p) limits the
ability to handle packet losses.
Adjusting p will increase one of these ranges, while the other range
will decrease. This trade-off between the capability to handle
reordering and packet losses, including how these correlate with each
other, should be considered in a ROHC profile that is meant to handle
reordering.
For example, if it is desirable for a profile to be as robust against
reordering (negative range) and against packet losses (positive
range), this range can be made equal by setting p near (2^k / 2).
7. Security Considerations
This document does not include additional security risks to [1]. In
addition, it may lower risks related to context damage in R-mode with
injected packets when sequentially late packets do not update the
context (section 6.1.2.1).
8. Acknowledgements
Thanks to the committed WG document reviewers, Carl Knutsson and Mark
West, for their review efforts. Thanks also to Aniruddha Kulkarni,
Ramin Rezaiifar, and Gorry Fairhurst for their constructive comments.
9. Informative References
[1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
and Channel Mapping Examples", RFC 3759, April 2004.
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242,
April 2002.
[6] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional Reliable
Mode (R-mode) in Extended Link-Layer Assisted RObust Header
Compression (ROHC) Profile", RFC 3408, December 2002.
[7] Ash, J., Goode, B., Hand, J., and R. Zhang, "Requirements for
Header Compression over MPLS", RFC 4247, November 2005.
Authors’ Addresses
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).