RFC 4224
RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets
RFC 4224: ROHC over Channels That Can Reorder Packets 🎀
okay bestie, RFC 4224 is titled RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets 🦋 G. Pelletier, L-E. Jonsson, and K. Sandlund wrote it, all three from Ericsson ✨ It's Informational, dated January 2006, and the title block doesn't list anything it obsoletes or updates 💅
Status of This Memo ✨
this memo is just here to give info to the Internet community 🫶 it does NOT set an Internet standard of any kind, and it can be shared freely with no limits 🌸
Copyright Notice 💜
copyright is The Internet Society (2006) 🎀
Abstract 🌈
okay so RObust Header Compression (ROHC), which is RFC 3095, sets up a whole framework for compressing headers, plus a bunch of compression protocols called profiles 💖 the catch is that the profiles in RFC 3095 assume the channel between compressor and decompressor has to keep packets in order ⭐ this doc is about running ROHC over channels that can reorder packets, which is giving "what if the mail got shuffled" 📬 it gives guidelines for running existing profiles over those channels, and it also has ideas for designing 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 .........................................191. Introduction 🎀
so RFC 3095 [1] is the one that defines the ROHC framework and its profiles 💅 and it assumes the channel between compressor and decompressor keeps packets in order for each compressed flow 📦 why? because the main channels people had in mind back then did guarantee in-order delivery of header-compressed packets ✨ that assumption let ROHC hit its top design goals at the time, which were better compression efficiency and better tolerance to packet losses 🏆
ever since RFC 3095 came out in 2001, people keep asking whether ROHC can work over channels that don't guarantee in-order delivery 🤔 and some folks have argued it can't work well there 🙅♀️ that's been pushed as a weakness next to other header compression options, because RFC 3095 literally says it can't operate if in-order delivery isn't guaranteed 😭 if you know ROHC and other header compression schemes well, you know this is a misconception, but ngl the RFC 3095 wording makes it easy to read it that way 🙈
this document is all about running ROHC over channels that can reorder header-compressed packets 🦋 it walks through different ways to run the RFC 3095 profiles, plus other profiles built on them, over reordering channels 🧚 you can make it work by making sure compressors use compressed headers that are robust enough for the reordering you expect, by changing decompressors so they can handle reordered packets, or both ✨ it also talks about how existing profiles could be updated and how new profiles could be designed to handle reordering efficiently 💖
there might be outside tools, like a sequence number, that detect reordering and maybe fix it 🔍 an example is compression over an IPsec Encapsulating Security Payload (ESP) tunnel 🔐 with that kind of external help, the decompressor can use the extra info and deal with reordering 🫶 but how to use external tools for reordering is out of scope for this doc, so we're not covering it here 🙅♀️
2. Terminology 🌸
this doc uses terminology that matches RFC 3759 [2], and it's informative only 📚 it talks about how to implement the ROHC specs in particular environments, but it doesn't specify any new tech 💅
ROHC 🦋
in this doc, "ROHC" means these profiles:
0x0001,0x0002, and0x0003defined in RFC 3095 [1];0x0004for compression of IP-only headers [3];0x0007and0x0008for compression of UDP-Lite headers [4].
"ROHC" does NOT include these profiles, because they're either not affected by reordering or they need in-order delivery to work at all 🙅♀️
0x0000(uncompressed) [1];0x0005(Link-Layer Assisted (LLA)) [5] and0x0105(R-mode extension to LLA) [6];
Reordering 🌀
this is a kind of transmission between compressor and decompressor where in-order delivery of header-compressed packets isn't guaranteed 😵💫
Reordering channel 🛤️
a connection where reordering, like we just defined, can happen 🦋
Sequentially early packet ⏩
this is a packet that shows up at the decompressor before one or more packets with the same context identifier (CID) that got delayed on the link 💀 when a sequentially early packet arrives, you can't tell the delayed packets apart from lost ones yet 🫠
Sequentially late packet ⏪
a packet is sequentially late if it shows up at the decompressor after one or more other packets with the same CID have already come in, even though the late packet was sent from the compressor earlier than those other packets 🐢
Updating packet 🔄
this is a packet that updates the decompressor's context, for example all packets except R-0 and R-1* in RFC 3095 [1] ✨
Non-updating packet 🙅♀️
this is a packet that does NOT update the decompressor's context, for example only R-0 and R-1* in RFC 3095 [1] 🌙
Change packet 🔁
this is a packet that updates one or more context fields other than the ones tied to the sequence number (SN) 🧠 so basically it updates fields that aren't 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 doc covers the general reordering issues for ROHC profiles 🫶 the biggest goals are making sure ROHC implementations don't pass packets with incorrectly decompressed headers up to upper layers, and keeping the rise in decompression failures or context damage events as small as possible when compression runs over reordering channels 🛡️
3.1. Profiles within Scope 💅
the solutions in this section apply generally to profiles 0x0001 (RTP), 0x0002 (UDP), and 0x0003 (ESP) defined in RFC 3095 [1] ✨ profile 0x0000 (uncompressed) isn't affected by reordering, since its headers are sent uncompressed 🙌 the solutions also apply to the IP-only profile 0x0004 [3] and the UDP-Lite profiles 0x0007 and 0x0008 [4] 🦋 those profiles are based on the RFC 3095 profiles, so they inherently make the same in-order delivery assumption 😭
3.2. Profiles with Special Considerations 🌈
some of the implementation solutions in sections 6.1 and 6.2 need special handling to work for profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4] 💖 for these profiles, the SN is generated at the compressor, because it isn't actually in the headers being compressed 🧚 when using 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 📏 that means the SN has to go up by one for every packet the decompressor receives, which is why reordered packets can't be decompressed 💀
the SN has to increase for every packet the decompressor gets, so for these profiles reordered packets literally cannot be decompressed. that's the core problem this doc is trying to fix 🫶
3.3. Profiles Incompatible with Reordering 🙅♀️
okay so the ROHC LLA profiles from RFC 3242 [5] and RFC 3408 [6] were literally built around in-order delivery being a fundamental requirement 😭 they just don't work if packets get shuffled. 🫠 That means profiles 0x0005 and 0x0105 can therefore not be implemented over channels where reordering can occur, so this document doesn't apply to them. 🚫
4. Background ✨
ROHC was designed assuming packets arrive in order, from compressor to decompressor 📦➡️📦. That made sense for the links it was meant for. But lots of people have said it would be so nice to use ROHC over connections where in-order delivery isn't 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. It would typically be an IP tunnel, where compression is applied over the tunnel by the endpoints of the tunnel. This is 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 that are susceptible to 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 it 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) - pwhere 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. For example, 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 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, which requires 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 the 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 it 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 it continues 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 being forwarded to upper layers. 🚨
5.1.3. Reordering of Packets in U/O-mode ✨
Reordering between non-change packets only 🎀
okay so when only the non-change packets get shuffled around each other, a sequentially late packet can still be decompressed, but only up to the offset p of the interpretation interval (see section 5.1.1) 🧚. A late packet with SN = x works if the SN of the packet that last updated the context was less than or equal to x + p. 💅
Trouble starts when context(SN) has jumped by more than p compared to the field(SN) in the packet you're trying to decompress 😭.
So 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 decompress just fine ✨. Past that, it's cooked. For example, if the compressor sends SN(packet1)=100 and SN(packet2)=108 with p=7, then packet1 can't be decompressed if it arrives even one packet late 💀.
Reordering involving change packets 🦋
When a packet gets reordered and ends up sequentially late compared to a change packet, decompressing it might eventually fail, because the context info it needs may not be around anymore 🙈.
Okay but here's the lowkey iconic part: decompression can always be verified, since every U/O-mode packet type is context updating 👑. That means a failed decompression caused by reordering can be detected, so context invalidation from reordering can be avoided 🫶. The risk of forwarding incorrectly decompressed packets to upper layers is therefore small in U/O-mode 🌸. For channels known to reorder packets, U/O-mode should therefore be the preferred mode of operation 💜. The extra risk of losing context synchronization, or of erroneous packets reaching upper layers, is limited ✨.
5.1.4. Reordering on the Feedback Channel 💖
For R-mode, when an acknowledgement comes in, the compressor searches the sliding window for an updating packet with the matching SN 🔍. If it can't find one, the acknowledgement is invalid and gets discarded ([1], section 5.5.1.2). So basically, feedback that arrives out of order is either still useful or it's tossed 🗑️.
In U/O-mode, if the compressor updates its context based on feedback, the same logic as R-mode applies in practice 🎀.
Bottom line: reordering on the feedback channel has no impact in either mode 🌈.
5.1.5. List Compression 📝
ROHC list compression is an extra compression scheme for RTP contributing source (CSRC) lists and IP extension header chains 🧚. The base is called table-based item compression, and it's almost completely independent from the rest of the ROHC compression logic 💅. So this part of the scheme doesn't have any special vulnerabilities when it comes to reordering, as long as a reasonable optimistic approach is used in U/O-mode ✨. It also doesn't suffer much from the "missing reference" problem when you're in R-mode 🙌.
On top of table-based item compression, you can also use a technique called reference based list compression 🍓. Here's the tea though: it has logic similar to the rest of ROHC compression, so it suffers from similar reordering vulnerabilities, especially the "missing reference" problem of R-mode 😬. The good news is that the generation identifier used in U/O-mode makes that scheme more robust to reordering 🫶.
When you use list encoding type 1, 2, or 3, which relies on reference lists, decompression only succeeds if every individual item is known to the decompressor, along with the correct reference list needed to decompress the packet 📚. List compression using the "Generic scheme", also known as "Encoding type 0", doesn't use reference based list compression. So type 0 decompression succeeds as long as all the individual items are known to the decompressor 🌟. Because of this, type 0 list compression should be the preferred method when operating over reordering channels 👑.
5.1.6. Reordering and Mode Transitions 🔄
Transition from U/O-mode to R-mode 🦋
This transition can get messed up by reordering if a packet type 0 (UO-0) gets reordered and delayed by at least one round-trip time (RTT) 😵. If the decompressor starts a mode change request to R-mode in the meantime, the reordered UO-0 packet may be handled as an R-0 packet 🙈. That means it can be erroneously decompressed and forwarded to upper layers 💀. This happens 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 can happen during this transition 🙃. But because the outcome of decompression is always verified using a CRC verification in U/O-mode, the reordered packet will most likely fail decompression and get discarded 🗑️✨.
The above situation isn't deemed to happen frequently, but it's still possible 🤏. So, 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 when figuring out the impacts of reordering 📊. That's why the robustness properties of U/O-mode and R-mode get hit differently 🎀.
Here's the summary of what reordering can do to ROHC 👀:
- 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's one optional ROHC function that just can't work when reordering happens between ROHC peers 😤.
The ROHC segmentation scheme (see [1], section 5.2.5) depends entirely on in-order delivery of each segment, since the segments don't carry any sequencing info 🧩. A segmented packet where one (or more) segments arrive out of order can't be decompressed, so the decompressor discards it 🗑️. Therefore, segmentation should not be used if reordering can happen between the ROHC peers 🙅♀️.
Using this optional feature is up to implementations, and it's local to the compressor only, so it doesn't impact the decompressor 🌈.
5.2.2. Context Damage (Loss of Synchronization) 💔
Reordering between ROHC peers can mess with the robustness of the optimistic approach (U/O-mode) and with the reliability of the secure reference principle (R-mode) 😩.
A sequentially late change packet (U/O-mode) and/or updating packet (R-mode) that still decompresses successfully can update the decompressor's context in a way the compressor didn't expect 😱. And that can lead to a loss of context synchronization between the ROHC peers 💀.
5.2.3. Detected Decompression Failures (U/O/R-mode) ✅
Reordering between ROHC peers can increase the number of decompression failures for context updating packets (see sections 5.1.2.1 and 5.1.3) 📈. Thankfully, since the outcome of decompressing updating packets can be verified, the decompressor can reliably detect failures, including the ones caused by reordering, and discard the packet 🙌. 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 between ROHC peers can increase the number of decompression errors for non-updating packets 😵💫. In R-mode, decompression of R-0 and R-1* packets can't be verified 🙃. If reordering happens and decompression uses the wrong secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor can't reliably detect the error 😬. So erroneous packets may end up forwarded to upper layers 💔.
6. Making ROHC Tolerant against Reordering 🛡️
This section covers different approaches that can improve ROHC performance over reordering channels and minimise the effects of reordering 💪. Examples are included to guide implementers and designers of new profiles 🧑💻. The solutions target either the properties of ROHC implementations or the specification of profiles, which are covered by sections 6.1 and 6.2, respectively 🎀.
6.1. Properties of ROHC Implementations ✨
Existing ROHC profiles can be implemented with the ability to properly handle packet reordering 🌸. The methods in this section conform with the ROHC specifications within scope of this document (see section 3), so they don't need any modifications to those specs 🙌. They can be implemented without hurting interoperability with other ROHC implementations that don't use these methods 🫶.
Heads up though: these methods may lower compression efficiency, so they shouldn't be used when reordering is known not to occur 📉. Some 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 🦋.
Each method addresses specific issues listed in section 5, and they can be combined for better robustness against reordering 💅.
6.1.1. Compressing Headers with Robustness against Reordering 🧩
The methods in this section are local only to the compressor implementation 🏠. They can be used without any modifications to, or impact on, 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 🌪️. So compressor implementations should 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 keep repeating each update until it's reasonably confident that at least one change packet in the sequence of repetitions has reached the decompressor before the first packet sent after that sequence 🫶✨.
6.1.1.2. Reordering and the Secure Reference Principle ✨
okay so the secure reference principle is literally built on one rule: only values the decompressor has acknowledged can be used as a reference for compression 💅 and it gets extra spicy bc some R-mode packet types don't include a CRC over the original uncompressed header, so the decompressor has no way to verify how its decompression turned out 😭
non-updating packet types basically rely on the cumulative effect of all the previous updates to the secure reference, and the compressed data is based on the reference's current value 🦋 this reference must be synchronized between ROHC peers. for R-0 and R-1* packets, getting the encoded bits applied to the secure reference is enough for correct decompression, but only when in-order delivery between ROHC peers is guaranteed. no reordering allowed here, bestie 🙈
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. main character energy for the sliding window fr 👑
6.1.1.3. Robust Selection of Compressed Header 🎀
so 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 is the move that lets decompressors handle sequentially late packets when there's a bigger amount of reordering 🧚
to get there, the compressor should be implemented conservatively when it picks 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 lets a packet be decompressed when the reordering leads to up to 7 units in sequence number variation (i.e., delta(SN)). and increasing the number of SN bits (i.e., using a larger SN_k [1]) that get transmitted makes ROHC even more tolerant to reordering. it's giving protection era 🛡️
for example, a conservative compressor implementation could use the packet types 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 |
+----------------------+-------------------------+so a compressor like this would always be sending at least 3 octets (R-mode) or 4 octets (U/O-mode) 😭 that's the trade-off compared to the 1 octet a more aggressive implementation can send on a channel with no reordering. it's a vibe-check of priorities, honestly 💅
ngl there's a catch: since the interpretation interval for profiles 0x0002, 0x0004, and 0x0008 is always p = -1 independently of bits(SN), the methods suggested in this section won't work for these profiles unless this value is modified (section 6.2.1). so read the fine print, periodt 🙈
6.1.2. Implementing a Reordering-Tolerant Decompressor 🌸
the methods in this section are local only to the decompressor implementation, so they can be used without modifications or impact to the compressor. no need to tell your bestie the compressor about it, it's a solo glow-up 💖
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). the vibe is calm and steady, so the chatter can chill 🧘
and if the compressor implementation makes a more conservative selection of packet types (section 6.1.1.3) to handle reordering, the decompressor should try to avoid sending more feedback than it would if the more optimal packet types were used. this can be useful to minimize the usage of the feedback channel, which improves the efficiency of the link. efficiency is iconic 👑
note that even if the decompressor doesn't make this adjustment to its feedback rate, packet losses or context damages will not increase. so no panic, it's still safe 🫶
Acknowledgements and sequentially late packets
reordered feedback (or feedback for packets received out of order) won't cause problems (see section 5.1.4). however, the decompressor should not send acknowledging feedback for a packet that can be identified as sequentially late (e.g., based on the sequence number of the packet). the reason is that the current state of the context reflects the compressor context better than the content of the reordered packet 🦋 the late packet is giving old news, not the tea ☕
6.1.2.2. Considerations for Local Repair Mechanisms 🔥
when decompression fails, and reordering can be assumed to be the cause, subsequent decompressions may be attempted for sequentially late packets by going backward in the interpretation interval (as opposed to moving forward for local repair). this is a rewind-and-retry situation 🍓
if one of the decompression attempts succeeds, 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. the fallback is still there, no drama 🌈
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. they should use the same algorithm as profile 0x0001 [1], instead of p = -1 independently of bits(SN) (section 5.1.1). it's a glow-up era for these profiles 🦋
yes, this change would make the updated profiles slightly less robust to packet losses, but they'd still be no less robust than profile 0x0001. that's the trade-off, and it's still a W 🫶
6.2.2. Modifying the Interpretation Interval Offset 🎀
the interpretation interval offset p could be modified for existing profiles to handle reordering. the bonus is that it improves compression efficiency when compared to the solution in section 6.1.1.3. more efficiency, who dis 💖
6.2.2.1. Example Profile for Handling Reordering 🧚
the value of the interpretation interval offset p can be adjusted to get robustness against reordering that's similar to the effect of selecting packet types as suggested in section 6.1.1.3. it's the same energy, just a different outfit ✨
say robustness against packet losses is kept as the priority, and a value of p=7 is deemed enough. in that 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 math is slaying 🧮
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 it comes at the expense of robustness against packet losses. ngl that's a real choice to make 🤔
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 how well the profile can handle reordering, and the positive bound (v_ref + (2^k - 1) - p) limits how well it can handle packet losses. so the two bounds are kind of beefing with each other 😭
adjusting p will increase one of these ranges, while the other range decreases. this trade-off between handling reordering and handling packet losses, including how these correlate with each other, should be considered in a ROHC profile that's meant to handle reordering. it's a balancing act, bestie ⭐
for example, if a profile should be as robust against reordering (negative range) as it is against packet losses (positive range), the two ranges can be made equal by setting p near (2^k / 2). perfectly balanced, as all things should be 🌈
7. Security Considerations 🔥
this one is serious, bestie, so read it carefully 🙈
this document does not include additional security risks to [1]. however, 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). lowkey a security win, and we're here for it 🛡️
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. the real MVPs 👑💖
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.comLars-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.comKristofer 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.comFull Copyright Statement ✨
Okay bestie, time for the legal bit 📜 Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions in BCP 78, and unless it says otherwise there, the authors keep all their rights. 🫶
This document and the information in it 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 💅
Okay so, the IETF doesn't take a side on whether any IP rights might apply to the tech in this document, or whether you can get a license to use it. It also doesn't claim it went out and checked for those rights either 🙈 If you want the rules on RFC document rights, look in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of an attempt to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 📚
The IETF also invites anyone to tell it about copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 🦋
Acknowledgement 🫶
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you're literally holding the whole RFC world together 🌈✨
📦 where this page comes from
- ietf: rfc4224 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms