idnits 2.17.1 draft-ietf-rohc-over-reordering-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 961. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2005) is 6913 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3242 (ref. '6') (Obsoleted by RFC 4362) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Pelletier 3 INTERNET-DRAFT L-E. Jonsson 4 Expires: November 2005 K. Sandlund 5 Ericsson 6 May 16, 2005 8 RObust Header Compression (ROHC): 9 ROHC over Channels that can Reorder Packets 10 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF ROHC WG. Comments should be 35 directed to the ROHC WG mailing list, rohc@ietf.org. 37 Abstract 39 RObust Header Compression (ROHC), RFC 3095, defines a framework for 40 header compression, along with a number of compression protocols 41 (profiles). One operating assumption for the profiles defined in RFC 42 3095 is that the channel between compressor and decompressor is 43 required to maintain packet ordering. This document discusses aspects 44 of using ROHC over channels that can reorder packets. It provides 45 guidelines on how to implement existing profiles over such channels, 46 as well as suggestions for the design of new profiles. 48 Table of Contents 50 1. Introduction.....................................................3 51 2. Terminology......................................................3 52 3. Applicability of this Document to ROHC Profiles..................5 53 3.1. Profiles within Scope.......................................5 54 3.2. Profiles with Special Considerations........................5 55 3.3. Profiles Incompatible with Reordering.......................5 56 4. Background.......................................................6 57 4.1. Reordering Channels.........................................6 58 4.2. Robustness Principles of ROHC...............................6 59 4.2.1. Optimistic Approach (U/O-mode).........................6 60 4.2.2. Secure Reference Principle (R-mode)....................7 61 5. Problem Description..............................................7 62 5.1. ROHC and Reordering Channels................................7 63 5.1.1. LSB Interpretation Interval and Reordering.............7 64 5.1.2. Reordering of Packets in R-mode........................9 65 5.1.2.1. Updating Packets..................................9 66 5.1.2.2. Non-Updating Packets..............................9 67 5.1.3. Reordering of Packets in U/O-mode.....................10 68 5.1.4. Reordering on the Feedback Channel....................10 69 5.1.5. List Compression......................................11 70 5.1.6. Reordering and Mode Transitions.......................11 71 5.2. Consequences of Reordering.................................12 72 5.2.1. Functionality Incompatible with Reordering............12 73 5.2.2. Context Damage (Loss of Synchronization)..............12 74 5.2.3. Detected Decompression Failures (U/O/R-mode)..........13 75 5.2.4. Undetected Decompression Failures (R-mode only).......13 76 6. Making ROHC Tolerant against Reordering.........................13 77 6.1. Properties of ROHC Implementations.........................13 78 6.1.1. Compressing Headers with Robustness against Reordering14 79 6.1.1.1. Reordering and the Optimistic Approach...........14 80 6.1.1.2. Reordering and the Secure Reference Principle....14 81 6.1.1.3. Robust Selection of Compressed Header............14 82 6.1.2. Implementing a Reordering Tolerant Decompressor.......15 83 6.1.2.1. Decompressor Feedback Considerations.............15 84 6.1.2.2. Considerations for Local Repair Mechanisms.......16 85 6.2. Specifying ROHC Profiles with Robustness against Reordering16 86 6.2.1. Profiles with Interpretation Interval Offset p = -1...16 87 6.2.2. Modifying the Interpretation Interval Offset..........17 88 6.2.2.1. Example profile for handling reordering..........17 89 6.2.2.2. Defining the values of p for new profiles........17 90 6.2.3. TCP Profile Considerations............................18 91 7. Security Consideration..........................................18 92 8. IANA Considerations.............................................18 93 9. Acknowledgments.................................................18 94 10. Authors' Addresses.............................................18 95 11. Informative References.........................................19 97 1. Introduction 99 RObust Header Compression (ROHC), RFC 3095 [1], defines a framework 100 for header compression, along with a number of compression protocols 101 (profiles). One operating assumption for the profiles defined in RFC 102 3095 is that the channel between compressor and decompressor is 103 required to maintain packet ordering for each compressed flow. The 104 motivation behind this assumption was that the primary candidate 105 channels considered did guarantee in-order delivery of header- 106 compressed packets; making this assumption made it possible to 107 improve the compression efficiency and the tolerance to packet loss, 108 objectives that were on top of the requirements list at the time. 110 Since the publication of RFC 3095 in 2001, the question about ROHC 111 operation over channels that do not guarantee in-order delivery has 112 surfaced several times; arguments that ROHC cannot perform adequately 113 over such channels have even been heard. Specifically, this has been 114 raised as a weakness when compared to other header compression 115 alternatives, as RFC 3095 explicitly states its inability to operate 116 if in-order delivery is not guaranteed. For those familiar with the 117 details of ROHC and of other header compression schemes, it is clear 118 that this is a misconception; but it can also be easily understood 119 that the wording used in RFC 3095 can lead to such interpretation. 121 This document discusses the various aspects of implementing ROHC over 122 channels that can reorder header-compressed packets. It explains 123 different ways of implementing the profiles found in RFC 3095, as 124 well as other profiles based on those profiles, over reordering 125 channels. This can be achieved either by ensuring that compressor 126 implementations use compressed headers that are sufficiently robust 127 to the expected possible reordering, and/or by modifying decompressor 128 implementations to tolerate reordered packets. Ideas regarding how 129 existing profiles could be updated and how new profiles can be 130 defined to cope efficiently with reordering are also discussed. 132 In some scenarios, there might be external means (such as a sequence 133 number) to detect and potentially correct reordering. That is for 134 example the case when running compression over an IPsec ESP tunnel. 135 With such external means to detect reordering, the decompressor can 136 be modified to make use of the external information provided, and 137 reordering can then be handled. How to make use of external means to 138 address reordering is, however, out of scope for this document. 140 2. Terminology 142 This document uses terminology consistent with RFC 3759 [2], and is 143 in itself only informative. Although it does discuss technical 144 aspects of implementing the ROHC specifications in particular 145 environments, it does not specify any new technology. 147 ROHC 149 The term "ROHC" herein refers to the following profiles: 151 - 0x0001, 0x0002 and 0x0003 defined in RFC 3095 [1]; 152 - 0x0004 for compression of IP-only headers [4]; 153 - 0x0007 and 0x0008 for compression of UDP-Lite headers [5]. 155 The term "ROHC" excludes the following profiles, which are either 156 not affected by reordering or that have the assumption of in-order 157 delivery as a fundamental requirement for their proper operation: 159 - 0x0000 (uncompressed) [1]; 160 - 0x0005 (LLA) [6] and 0x0105 (R-mode extension to LLA) [7]; 162 Reordering 164 A type of transmission taking place between compressor and 165 decompressor where in-order delivery of header-compressed 166 packets is not guaranteed. 168 Reordering Channel 170 A connection over which reordering, as defined above, can occur. 172 Sequentially early packet 174 A packet that reaches the decompressor before one or several 175 packets of the same CID that were delayed on the link. At the time 176 of the arrival of a sequentially early packet, the packet(s) 177 delayed on the link cannot be differentiated from lost packet(s). 179 Sequentially late packet 181 A packet is late within its sequence if it reaches the 182 decompressor after one or several other packets belonging to the 183 same CID have been received, although the sequentially late packet 184 was sent from the compressor before the other packet(s). 186 Updating packet 188 A packet that updates the context of the decompressor, e.g. all 189 packets except R-0 and R-1* in RFC 3095 [1]. 191 Non-updating packet 193 A packet that does not update the context of the decompressor, 194 e.g. only R-0 and R-1* in RFC 3095 [1]. 196 Change packet 198 A packet that updates one or more fields of the context other than 199 the fields pertaining to the functions established with respect to 200 the sequence number (SN). Specifically, it is a packet that 201 updates fields other than the SN, IP-ID or RTP timestamp (TS). 203 3. Applicability of this Document to ROHC Profiles 205 This document addresses general reordering issues for ROHC profiles. 206 The foremost objectives are to ensure that ROHC implementations will 207 not forward packets with incorrectly decompressed headers to upper 208 layers, as well as to limit the possible increase in the rate of 209 decompression failures or in events leading to context damage, when 210 compression is applied over reordering channels. 212 3.1. Profiles within Scope 214 The following sections outline solutions that are generally 215 applicable to profiles 0x0001 (RTP), 0x0002 (UDP) and 0x0003 (ESP) 216 defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not 217 affected by reordering, as the headers are sent uncompressed. The 218 solutions also apply to profiles for IP-only (0x0004) [4] and for 219 UDP-Lite (0x0007 and 0x0008) [5]. These profiles are based on the 220 profiles of RFC 3095 [1] and inherently make the same in-order 221 delivery assumption. 223 3.2. Profiles with Special Considerations 225 Special considerations are needed to make some of the implementation 226 solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) 227 [1], 0x0004 (IP-only) [4], and 0x0008 (UDP-Lite) [5]. For these 228 profiles, the SN is generated at the compressor, as it is not present 229 in headers being compressed. For the least significant bit (LSB) 230 encoding method, the interpretation interval offset (p) is always 231 p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus 232 required to increase for each packet received at the decompressor, 233 which means that reordered packets cannot be decompressed. 235 3.3. Profiles Incompatible with Reordering 237 The ROHC LLA profiles defined in RFC 3242 [6] and RFC 3408 [7] have 238 been explicitly designed with in-order delivery as a fundamental 239 requirement to their proper operation. Profiles 0x0005 and 0x0105 can 240 therefore not be implemented over channels where reordering can 241 occur; this document therefore does not apply to these profiles. 243 4. Background 245 ROHC was designed with the assumption that packets are delivered in- 246 order from compressor to decompressor. This was considered as a 247 reasonable working assumption for links where it was expected that 248 ROHC would be used. However, many have expressed that it would be 249 desirable to use ROHC also over connections where in-order delivery 250 is not guaranteed [8]. 252 4.1. Reordering Channels 254 The reordering channels that are potential candidates to use ROHC are 255 single-hop channels and multi-hop virtual channels. 257 A single-hop channel is a point-to-point link that constitutes a 258 single IP hop. Note that one IP hop could be one or multiple physical 259 links. For example, a single-hop reordering channel could be a 260 wireless link that applies error detection and performs 261 retransmissions to guarantee error-free delivery of all data. Another 262 example could be a wireless connection that performs bicasting of 263 data during a handoff procedure. 265 A multi-hop virtual channel is a virtual point-to-point link that 266 traverses multiple IP hops. A multi-hop virtual channel would 267 typically be an IP tunnel, where compression is applied over the 268 tunnel by the endpoints of the tunnel (not to be confused with single 269 link compression of tunneled packets). 271 4.2. Robustness Principles of ROHC 273 Robustness is based on the optimistic approach in the unidirectional 274 and optimistic modes of operation (U/O-mode), and on the secure 275 reference principle in the bi-directional reliable mode (R-mode). 276 Both approaches have different characteristics in the presence of 277 reordering between compressor and decompressor. However, in any mode, 278 decompression of sequentially early packets will generally be handled 279 quite well since they will be perceived and treated by the 280 decompressor as if there had been one or more packet losses. 282 4.2.1. Optimistic Approach (U/O-mode) 284 A ROHC compressor uses the optimistic approach to reduce header 285 overhead when performing context updates in U/O-mode. The compressor 286 normally repeats the same update until it is fairly confident that 287 the decompressor has successfully received the information. The 288 number of consecutive packets needed to obtain this confidence is 289 open to implementations, and this number is normally related to the 290 packet loss characteristics of the link where header compression is 291 used (see also [1], section 5.3.1.1.1). 293 All packet types used in U/O-mode are context updating. 295 4.2.2. Secure Reference Principle (R-mode) 297 A ROHC compressor uses the secure reference principle in R-mode, to 298 ensure that context synchronization between ROHC peers cannot be lost 299 due to packet losses. The compressor obtains its confidence that the 300 decompressor has successfully updated the context from a packet 301 carrying a 7- or 8-bit CRC based on acknowledgements received from 302 the decompressor (see also [1], section 5.5.1.2). 304 The secure reference principle makes it possible for a compressor to 305 use packets that do not update the context (i.e. R-0 and R-1* [1]). 307 5. Problem Description 309 5.1. ROHC and Reordering Channels 311 This section reviews different aspects of ROHC susceptible of being 312 impacted by reordering of compressed packets between ROHC peers. 314 5.1.1. LSB Interpretation Interval and Reordering 316 The LSB encoding method defined in RFC 3095 ([1], section 5.7) 317 specifies the interpretation interval offset, called p, as follow: 319 For profiles 0x0001, 0x0003 and 0x0007: 321 p = 1, when bits(SN) <= 4; 322 p = 2^(bits(SN)-5) - 1 otherwise. 324 The resulting table describing the interpretation interval is: 326 +-----------+--------------+--------------+ 327 | bits (SN) | Offset p | (2^k-1) - p | 328 | k | (reordering) | (losses) | 329 +-----------+--------------+--------------+ 330 | 4 | 1 | 14 | 331 | 5 | 0 | 31 | 332 | 6 | 1 | 62 | 333 | 7 | 3 | 124 | 334 | 8 | 7 | 248 | 335 | 9 | 15 | 496 | 336 +-----------+--------------+--------------+ 338 As shown in the table above, the ability for ROHC to handle 339 sequentially late packets depends on the number of bits sent in 340 each packet. For example, a sequentially late packet of type 0 341 (with either 4 or 6 bits of SN) sets the limit to one packet out 342 of sequence for successful decompression to be possible. 344 For profiles 0x0002, 0x0004 and 0x0008: 346 p = - 1, independently of bits(SN). 348 A value of p = -1 means that the interpretation interval offset 349 can only take positive values, and that no sequentially late 350 packet can be decompressed if reordering occurs over the link. 352 The trade-off between reordering and robustness 354 The ability of ROHC to handle sequentially late packets is limited 355 by the interpretation interval offset of the sliding window used 356 for LSB encoding. This offset has a very small value for packets 357 with a small number of sequence number (SN) bits, but grows with 358 the number of SN bits transmitted. 360 For channels where both packet losses and reordering can occur, 361 modifications to the interpretation interval faces a trade-off 362 between the amount of reordering and the number of consecutive 363 packets losses that can be handled by the decompressor. If the 364 negative offset (i.e. p) is increased to handle a larger amount of 365 reordering, the value of the positive offset of the interpretation 366 interval must be decreased. This may impact the compression 367 efficiency when the channel has a high loss rate. 369 This is shown in the figure: 371 <--- interpretation interval (size is 2^k) ----> 372 |------------------+---------------------------| 373 Lower v_ref Upper 374 Bound Bound 375 <--- reordering --> <--------- losses ---------> 376 max delta(SN) = p max delta(SN) = (2^k-1) - p 378 where v_ref is the reference value as per [2]. 380 In practice, the maximum variation in SN value (max delta(SN)) 381 due to reordering that can be handled will normally correspond to 382 the maximum number of packets that can be reordered. The same 383 applies to the maximum number of consecutive packet losses covered 384 by the robustness interval. 386 Timer-based compression of RTP TS (see [1], section 4.5.4) provides 387 means to reduce the number of timestamp bits needed in compressed 388 headers after longer gaps in the packet stream (typically due to 389 silence suppression). To use timer-based compression, an upper limit 390 on the inter-arrival jitter must be reliably estimated by the 391 compressor. It should be noted that although the risk of reordering 392 of course means there is a more significant jitter on the path 393 between the compressor and the decompressor, there are no special 394 reordering considerations for timer-based compression. It all still 395 boils down to the task of estimating the jitter, requiring channel 396 characteristics knowledge at the compressor, and/or jitter estimation 397 figures received from the decompressor. 399 5.1.2. Reordering of Packets in R-mode 401 5.1.2.1. Updating Packets 403 The compressor always adds references in the sliding window for all 404 updating packets sent. The compressor removes values older than 405 values for which it has received an acknowledgement, to shrink the 406 window and thereby increase the compression efficiency. 408 The decompressor always updates the context when receiving an 409 updating packet, and uses the new reference for decompression. 410 Acknowledgements are sent to allow the compressor to shrink its 411 sliding window. 413 Reordering between updating packets 415 The decompressor can update its context from the reception of a 416 sequentially late updating packet. The decompressor reference is 417 then updated with a value that is no longer in the sliding window 418 of the compressor. This "missing reference" can be caused by 419 reordering when operating in R-mode. 421 The result is that the compressor and the decompressor lose 422 synchronization with each other. When the decompressor 423 acknowledges the sequentially late packet, the compressor might 424 already have discarded the reference to this sequence number, and 425 continue to compress packets based on more recent references (in 426 packet arrival time). Decompression will then be attempted using 427 the wrong reference. 429 5.1.2.2. Non-Updating Packets 431 Reordering between non-updating packets only 433 A non-updating packet that reaches the decompressor out-of- 434 sequence with respect to other non-updating packets only, can 435 always be decompressed properly. 437 Reordering between non-updating packets and updating packets 439 When a non-updating packet is reordered and becomes sequentially 440 late with respect to an updating packet, the decompressor may have 441 already updated the context with a new reference when the late 442 packet is received. It is thus possible for a non-updating packet 443 to be decompressed based on the wrong reference because of 444 reordering when operating in R-mode. 446 Since decompression of non-updating packets cannot be verified, 447 this can lead to a packet erroneously decompressed being forwarded 448 to upper layers. 450 5.1.3. Reordering of Packets in U/O-mode 452 Reordering between non-change packets only 454 When only non-change packets are reordered with respect to each 455 other, decompression of sequentially late packets is limited by 456 the offset p of the interpretation interval (see section 5.1.1). 457 Decompression of a sequentially late packet with SN = x is 458 possible if the value of the SN of the packet that last updated 459 the context was less than or equal to x + p. 461 Problems occur if context(SN) has increased by more than p with 462 respect to field(SN) carried within the packet to decompress. 464 This means that for a well-behaved stream with a constant unit 465 increase in the RTP SN, a packet can arrive up to p packets out of 466 sequence and still be correctly decompressed. Otherwise, it cannot 467 be properly decompressed. It also means that if the compressor 468 sends two consecutive packets with SN(packet1)=100 and 469 SN(packet2)=108 when p=7, packet1 cannot be decompressed if it 470 arrives even one packet late due to reordering. 472 Reordering involving change packets 474 When a packet is reordered and becomes sequentially late with 475 respect to a change packet, decompression of the late packet may 476 eventually fail, as the context information required for 477 successful decompression may not be available anymore. 479 Decompression can always be verified since all U/O-mode packet types 480 are context updating. Consequently, a failure to decompress a packet 481 that is caused by reordering can be detected, and context 482 invalidation due to reordering can thus be avoided. The risk of 483 forwarding incorrectly decompressed packets to upper layers is 484 therefore small when operating in U/O-mode. For channels known to 485 reorder packets, U/O-mode should therefore be the preferred mode of 486 operation. The additional risk of losing context synchronization, or 487 for erroneous packet to be delivered to upper layers, is limited. 489 5.1.4. Reordering on the Feedback Channel 491 For R-mode, upon reception of an acknowledgement, the compressor 492 searches the sliding window to locate an updating packet with the 493 corresponding SN; if it is not found, the acknowledgement is invalid 494 and is discarded ([1], section 5.5.1.2). In other words, feedback 495 received out-of-order either is still useful or is discarded. 497 In U/O-mode, if the compressor updates its context based on feedback, 498 the same logic as for R-mode applies in practice. 500 Reordering on the feedback channel has thus no impact in either mode. 502 5.1.5. List Compression 504 ROHC list compression is an additional compression scheme for RTP 505 CSRC lists and IP extension header chains, which is almost completely 506 independent from the ordinary ROHC operation. The base is called 507 table-based item compression, and this part of the scheme does not 508 exhibit any special vulnerabilities when it comes to reordering, 509 assuming a reasonable optimistic approach is used in U/O-mode. 510 Specifically, it does not suffer significantly from the "missing 511 reference" problem when operating in R-mode. 513 On top of the table-based item compression mechanism, an additional 514 compression technique may be used, called reference based list 515 compression. Reference based list compression has a logic that is 516 similar to ordinary ROHC compression, and therefore it suffers from 517 similar reordering vulnerabilities, especially the "missing 518 reference" problem of R-mode. Note however that the generation 519 identifier used in U/O-mode makes that scheme more robust to 520 reordering. 522 When using list encoding type 1,2, or 3, which makes use of reference 523 lists, decompression will only succeed if all individual items are 524 known by the decompressor, along with the specific reference list 525 referred. List compression using the "Generic scheme", also known as 526 "Encoding type 0", is not using reference based list compression, and 527 type 0 decompression will thus succeed as long as all individual 528 items are known by the decompressor. Because of this, type 0 list 529 compression should be the preferred method used when operating over 530 reordering channels. 532 5.1.6. Reordering and Mode Transitions 534 Transition from U/O-mode to R-mode 536 This transition can be affected by reordering if a packet type 0 537 (UO-0) is reordered and delayed by at least one round-trip time 538 (RTT). If the decompressor initiates a mode change request to R- 539 mode in the meantime, the reordered UO-0 packet may be handled as 540 an R-0 packet; it can be erroneously decompressed and forwarded to 541 upper layers. This is because the decompressor can switch to 542 R-Mode as soon as it sends the acknowledgement Ack(SN, R) to the 543 compressor (see also [1], section 5.6). 545 Transition from R-mode to U/O-mode 547 A similar situation as above can occur during this transition. 548 However, because the outcome of the decompression is always 549 verified using a CRC verification in U/O-mode, the reordered 550 packet will most likely fail decompression and will be discarded. 552 The above situation, while it is not deemed to occur frequently, is 553 still possible; thus mode transitions from U/O-mode to R-mode should 554 be avoided when reordering can occur. 556 5.2. Consequences of Reordering 558 The context updating properties of the packets exchanged between ROHC 559 peers are the most important factors to consider when deriving the 560 impacts of reordering. For this reason, the robustness properties of 561 the U/O-mode and of the R-mode are affected differently. 563 The effects of reordering on ROHC can be summarized as follow: 565 - Functionality incompatible with reordering; 566 - Increased probability of context damage (loss of synchronization); 567 - Increased number of decompression failures - Detected (U/O/R-mode); 568 - Increased number of decompression failures - Undetected (R-mode). 570 5.2.1. Functionality Incompatible with Reordering 572 There is one optional ROHC function that cannot work in the presence 573 of reordering between ROHC peers. 575 The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely 576 on the in-order delivery of each segment, as there is no sequencing 577 information in the segments. A segmented packet for which one (or 578 more) segment is received out-of-order cannot be decompressed, and is 579 discarded by the decompressor. Therefore segmentation should not be 580 used if there can be reordering between the ROHC peers. 582 The use of this optional feature is open to implementations and is 583 local to the compressor only; it does not impact the decompressor. 585 5.2.2. Context Damage (Loss of Synchronization) 587 Reordering of packets between ROHC peers can impact the robustness 588 properties of the optimistic approach (U/O-mode) as well as the 589 reliability of the secure reference principle (R-mode). 591 The successful decompression of a sequentially late change packet 592 (U/O-mode) and/or updating packet (R-mode) can update the context of 593 the decompressor in a manner unexpected by the compressor. This can 594 lead to a loss of context synchronization between the ROHC peers. 596 5.2.3. Detected Decompression Failures (U/O/R-mode) 598 Reordering of packets between ROHC peers can lead to an increase in 599 the number of decompression failures for context updating packets 600 (see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the 601 decompression of updating packets can be verified, the decompressor 602 can reliably detect decompression failures, including those caused by 603 reordering, and discard the packet. Note that local repairs, subject 604 to the limitations stated in [1] section 5.3.2.2.3, can still be 605 performed. 607 5.2.4. Undetected Decompression Failures (R-mode only) 609 Reordering of packets between ROHC peers can lead to an increase in 610 the number of decompression errors for non-updating packets. For R- 611 mode, decompression of R-0 and R-1* packets cannot be verified. If 612 reordering occurs and decompression is performed using the wrong 613 secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor 614 cannot reliably detect such errors. As a result, erroneous packets 615 may be forwarded to upper layers. 617 6. Making ROHC Tolerant against Reordering 619 This chapter describes different approaches that can improve the 620 performance of ROHC when used over reordering channels and minimize 621 the effects of reordering. Examples are provided to guide 622 implementers and designers of new profiles. The solutions target 623 either the properties of ROHC implementations or the specifications 624 of profiles. This is covered by sections 6.1 and 6.2 respectively. 626 6.1. Properties of ROHC Implementations 628 Existing ROHC profiles can be implemented with the capability to 629 properly handle packet reordering. The methods described in this 630 section conform with, and thus do not require any modifications to, 631 the ROHC specifications within scope of this document (see section 632 3). Specifically, the methods presented in this section can be 633 implemented without any impairment to interoperability with other 634 ROHC implementations that do not use these methods. 636 The methods suggested here may, however, lower compression 637 efficiency, and these modifications should not be used when 638 reordering is known not to occur. Some of these methods aim to 639 increase the decompression success rate at the decompressor, while 640 others aim to avoid context damages causing loss of context 641 synchronization between compressor and decompressor. 643 The methods proposed are each addressing specific issues listed in 644 section 5, and can be combined to achieve better robustness against 645 reordering. 647 6.1.1. Compressing Headers with Robustness against Reordering 649 The methods described in this section are methods local only to the 650 compressor implementation. They can be used without modifications or 651 impact to the decompressor. 653 6.1.1.1. Reordering and the Optimistic Approach 655 The optimistic approach is affected by the reordering characteristics 656 of the channel when operating over a reordering channel. Compressor 657 implementations should therefore adjust their optimistic approach 658 strategy to match both packet loss and reordering characteristics. 660 For example, the number of repetitions for each context update can be 661 increased. The compressor should ensure that each update is repeated 662 until it is reasonably confident that a least one change packet in 663 the sequence of repetitions has reached the decompressor before the 664 first packet sent after this sequence. 666 6.1.1.2. Reordering and the Secure Reference Principle 668 Fundamental to the secure reference principle is that only values 669 acknowledged by the decompressor can be used as reference for 670 compression. In addition, some of the packet types used in R-mode do 671 not include a CRC over the original uncompressed header, and the 672 decompressor has no means to verify the outcome of the decompression. 674 Decompression of non-updating packet types thus entirely relies on 675 the cumulative effect of previous updates to the secure reference, 676 and the compressed data is based on the current value of the 677 reference. This reference must be synchronized between ROHC peers. 678 For R-0 and R-1* packets, the reception of the encoded bits applied 679 to the secure reference is sufficient for correct decompression, but 680 only when in-order delivery between ROHC peers is guaranteed. 682 Avoiding the "missing reference" problem (section 5.1.2.1) 684 A compressor implementation can delay the advance in the sliding 685 window to a reference acknowledged by the decompressor, until it 686 has confidence that no acknowledgement for any of the values that 687 could be discarded can be received. This confidence can be based 688 on the maximum delay that reordering can introduce over the 689 channel. 691 6.1.1.3. Robust Selection of Compressed Header 693 Packet formats could be chosen with an interpretation interval for 694 the LSB encoded sequence number that allow for larger negative 695 offsets (see section 5.1.1). This would provide the capability to 696 decompress sequentially late packets with a greater amount of 697 reordering. 699 To achieve this, the compressor should be implemented conservatively 700 in terms of the choice of packet types to send, by transmitting 701 packets with more sequence number bits. As shown in the table of 702 section 5.1.1, using eight bits of SN allows a packet to be 703 decompressed when the reordering leads to up to seven units in 704 sequence number variation (i.e. delta(SN)). Increasing the number of 705 SN bits (i.e. using a larger SN_k [1]) transmitted will make ROHC 706 even more tolerant to reordering. 708 For example, a conservative compressor implementation could use the 709 packet types as shown in the table below: 711 +----------------------+-------------------------+ 712 | Optimal Packet Type | Alternative Packet Type | 713 | (without reordering) | (reordering possible) | 714 +----------------------+-------------------------+ 715 | UO-0 | UOR-2*-ext0 | 716 | R-0 | R-1*-ext0 | 717 | R-0-CRC | UOR-2*-ext0 | 718 | R-1* | R-1*-ext0 | 719 | UO-1 | UOR-2-ext0 | 720 | UO-1-TS | UOR-2-TS-ext0 | 721 | UO-1-ID | UO-1-ID-ext3 (with S=1) | 722 | | UOR-2-ID-ext0 | 723 | UOR-2* | UOR-2*-ext0 | 724 +----------------------+-------------------------+ 726 Such a compressor implementation would thus always be sending at 727 least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off 728 when compared to the 1 octet that can be sent by a more aggressive 729 implementation operating on a channel with no reordering. 731 Note that since the interpretation interval for profiles 0x0002, 732 0x0004 and 0x0008 is always p = -1 independently of bits(SN), the 733 methods suggested in this section will not work for these profiles 734 unless this value is modified (section 6.2.1). 736 6.1.2. Implementing a Reordering Tolerant Decompressor 738 The methods described in this section are methods local only to the 739 decompressor implementation. They can be used without modifications 740 or impact to the compressor. 742 6.1.2.1. Decompressor Feedback Considerations 744 Reducing the feedback rate when the flow behaves linearly 746 The decompressor should reduce its feedback rate when a large 747 number of UOR-2 packets with extensions are received, when the 748 flow behaves linearly (i.e. when only fields pertaining to the 749 functions established with respect to the sequence number are 750 changing. 752 In particular, if the compressor implementation makes a more 753 conservative selection of packet types (section 6.1.1.3) in order 754 to handle reordering, the decompressor should try to avoid sending 755 more feedback than it would for the case where the more optimal 756 packet types are used. This can be useful to minimize the usage of 757 the feedback channel, thereby improving efficiency of the link. 759 Note that even if the decompressor does not make this adjustment 760 to its feedback rate, packet losses or context damages will not 761 increase. 763 Acknowledgements and sequentially late packets 765 Reordered feedback (or feedback for packets received out-of-order) 766 will not cause problems (see section 5.1.4). However, the 767 decompressor should not send acknowledging feedback for a packet 768 if it is reasonable to believe it is sequentially late (e.g. by 769 just looking at the sequence number of the packet), as the current 770 state of the context will better reflect the compressor context 771 than the content of the reordered packet. 773 6.1.2.2. Considerations for Local Repair Mechanisms 775 When decompression fails, and if reordering is believed to be cause 776 of this failure, subsequent decompressions may be attempted for 777 sequentially late packets by going backwards in the interpretation 778 interval (as opposed to moving forward for local repair). If one of 779 the decompression attempt is successful, the late packet may be 780 passed on to upper layers with or without updating the decompressor 781 context. If the subsequent decompression attempt fails, the packet 782 should be handled according to [2] section 5.3.2.2.3. 784 6.2. Specifying ROHC Profiles with Robustness against Reordering 786 6.2.1. Profiles with Interpretation Interval Offset p = -1 788 New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [4], and 789 0x0008 (UDP-Lite) [5] should redefine how the value of the offset p 790 is determined, and use the same algorithm as in profile 0x0001 [1] 791 instead of p = -1 independently of bits(SN) (section 5.1.1). 793 While such a change would make these updated profiles slightly less 794 robust to packet losses, they would still be no less robust than 795 profile 0x0001. 797 6.2.2. Modifying the Interpretation Interval Offset 799 The interpretation interval offset p could be modified for existing 800 profile to handle reordering while improving the compression 801 efficiency when compared to the solution of section 6.1.1.3. 803 6.2.2.1. Example profile for handling reordering 805 The value of the interpretation interval offset p can be adjusted to 806 achieve a robustness against reordering similar to the effect of 807 selecting packet types as suggested in section 6.1.1.3. 809 Consider a scenario where robustness against packet losses is kept a 810 priority, and for which of a value p=7 is deemed enough; in this 811 case, a ratio where the positive offset is about twice as large as 812 the negative offset can be used. This leaves a value of p = 2^k/ 3. 814 The resulting values are shown in the following table: 816 +-----------+--------------+----------------+ 817 | bits (SN) | Offset p | Positive range | 818 | k | (reordering) | (losses) | 819 +-----------+--------------+----------------+ 820 | 4 | 5 | 10 | 821 | 5 | 10 | 21 | 822 | 6 | 21 | 42 | 823 | 7 | 42 | 85 | 824 | 8 | 85 | 170 | 825 | 9 | 170 | 341 | 826 +-----------+--------------+----------------+ 828 Using this value for p, a fair amount of reordering can be handled 829 without having to send UOR-2 packets most of the time. The trade-off 830 is that this is at the expense of robustness against packet losses. 832 6.2.2.2. Defining the values of p for new profiles 834 As described in RFC3095 [1], the interpretation interval when sending 835 k bits of SN is defined as: 837 f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p] 839 The negative bound (v_ref - p) limits the ability to handle 840 reordering, while the positive bound (v_ref + (2^k - 1) - p) limits 841 the ability to handle packet losses. 843 Adjusting p will increase one of these ranges, while the other range 844 will decrease. This trade-off between the capability to handle 845 reordering and packet losses, including how these correlate with each 846 other, should be considered when a ROHC profile that is meant to 847 handle reordering. 849 For example, if it is desirable for a profile to be as robust against 850 reordering (negative range) and against packet losses (positive 851 range), this range can be made equal by setting p near (2^k / 2). 853 6.2.3. TCP Profile Considerations 855 The current draft for the ROHC TCP profile [3] contains packet 856 formats that allow sending as little as 1 bit of MSN (master sequence 857 number). Since the MSN is used in the same fashion as the sequence 858 number in profile 0x0002, it will not be possible to decompress 859 reordered packets if used over a reordering channel. 861 The work on the ROHC-TCP profile should consider using more bits of 862 MSN to enable simple implementation modifications when operating over 863 a reordering channel. 865 7. Security Consideration 867 This document does not include additional security risks to [1]. In 868 addition, it may lower risks related to context damage in R-mode with 869 injected packets when sequentially late packets do not update the 870 context (section 6.1.2.1). 872 8. IANA Considerations 874 This document does not require any IANA action. 876 9. Acknowledgments 878 Thanks to the committed WG document reviewers, Carl Knutsson and Mark 879 West, for their review efforts. Thanks also to Aniruddha Kulkarni, 880 Ramin Rezaiifar and Gorry Fairhurst for their constructive comments. 882 10. Authors' Addresses 884 Ghyslain Pelletier 885 Ericsson AB 886 Box 920 887 SE-971 28 Lulea, Sweden 888 Phone: +46 8 404 29 43 889 Fax: +46 920 996 21 890 EMail: ghyslain.pelletier@ericsson.com 892 Lars-Erik Jonsson 893 Ericsson AB 894 Box 920 895 SE-971 28 Lulea, Sweden 896 Phone: +46 8 404 29 61 897 Fax: +46 920 996 21 898 EMail: lars-erik.jonsson@ericsson.com 899 Kristofer Sandlund 900 Ericsson AB 901 Box 920 902 SE-971 28 Lulea, Sweden 903 Phone: +46 8 404 41 58 904 Fax: +46 920 996 21 905 EMail: kristofer.sandlund@ericsson.com 907 11. Informative References 909 [1] Bormann, C., et al., "RObust Header Compression (ROHC): 910 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 911 RFC 3095, July 2001. 913 [2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology 914 and Channel Mapping Examples", RFC 3759, April 2004. 916 [3] Pelletier, G., et al., "RObust Header Compression (ROHC): TCP/IP 917 Profile (ROHC-TCP)", Internet-Draft (work in progress), 918 , February 2005. 920 [4] Jonsson, L-E., and G. Pelletier, "RObust Header Compression 921 (ROHC): A compression profile for IP", RFC 3843, June 2004. 923 [5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for 924 UDP-Lite", RFC 4019, April 2005. 926 [6] Jonsson, L-E., and G. Pelletier, "RObust Header Compression 927 (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, 928 April 2002. 930 [7] Liu, Z., and K. Le, "Zero-byte Support for Bidirectional 931 Reliable Mode (R-mode) in Extended Link-Layer Assisted Profile 932 for RObust Header Compression (ROHC) Profile", RFC 3408, 933 December 2002. 935 [8] Ash, J., Goode, B., and J. Hand, "Requirements for Header 936 Compression over MPLS", Internet draft (work in progress), 937 , June 2004. 939 Intellectual Property Statement 941 The IETF takes no position regarding the validity or scope of any 942 Intellectual Property Rights or other rights that might be claimed to 943 pertain to the implementation or use of the technology described in 944 this document or the extent to which any license under such rights 945 might or might not be available; nor does it represent that it has 946 made any independent effort to identify any such rights. Information 947 on the procedures with respect to rights in RFC documents can be 948 found in BCP 78 and BCP 79. 950 Copies of IPR disclosures made to the IETF Secretariat and any 951 assurances of licenses to be made available, or the result of an 952 attempt made to obtain a general license or permission for the use of 953 such proprietary rights by implementers or users of this 954 specification can be obtained from the IETF on-line IPR repository at 955 http://www.ietf.org/ipr. 957 The IETF invites any interested party to bring to its attention any 958 copyrights, patents or patent applications, or other proprietary 959 rights that may cover technology that may be required to implement 960 this standard. Please address the information to the IETF at ietf- 961 ipr@ietf.org. 963 Copyright Statement 965 Copyright (C) The Internet Society (2005). This document is subject 966 to the rights, licenses and restrictions contained in BCP 78, and 967 except as set forth therein, the authors retain all their rights. 969 Disclaimer of Validity 971 This document and the information contained herein are provided on an 972 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 973 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 974 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 975 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 976 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 979 This Internet-Draft expires November 16, 2005.