idnits 2.17.1 draft-pelletier-rohc-over-reordering-00.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.5 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 917. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 14, 2004) is 7255 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. '7') (Obsoleted by RFC 4362) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ghyslain Pelletier, Ericsson 3 INTERNET-DRAFT Lars-Erik Jonsson, Ericsson 4 Expires: December 2004 Kristofer Sandlund, Effnet 5 June 14, 2004 7 RObust Header Compression (ROHC): 8 ROHC over Channels that can Reorder Packets 9 11 Status of this memo 13 By submitting this Internet-Draft, I (we) certify that any applicable 14 patent or other IPR claims of which I am (we are) aware have been 15 disclosed, and any of which I (we) become aware will be disclosed, in 16 accordance with RFC 3668 (BCP 79). 18 By submitting this Internet-Draft, I (we) accept the provisions of 19 Section 3 of RFC 3667 (BCP 78). 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Abstract 41 RObust Header Compression (ROHC), RFC 3095, defines a framework for 42 header compression, along with a number of compression protocols 43 (profiles). One operating assumption for the profiles defined in RFC 44 3095 is that the channel between compressor and decompressor is 45 required to maintain packet ordering. This document discusses aspects 46 of using ROHC over channels that can reorder packets. It provides 47 guidelines on how to implement existing profiles over such channels, 48 as well as suggestions for the design of new profiles. 50 Table of Contents 52 1. Introduction.....................................................3 53 2. Terminology......................................................3 54 3. Applicability of this Document to ROHC Profiles..................5 55 3.1. Profiles within Scope.......................................5 56 3.2. Profiles with Special Considerations........................5 57 3.3. Profiles Incompatible with Reordering.......................5 58 4. Background.......................................................6 59 4.1. Reordering Channels.........................................6 60 4.2. Robustness Principles of ROHC...............................6 61 4.2.1. Optimistic Approach (U/O-mode).........................6 62 4.2.2. Secure Reference Principle (R-mode)....................7 63 5. Problem Description..............................................7 64 5.1. ROHC and Reordering Channels................................7 65 5.1.1. LSB Interpretation Interval and Reordering.............7 66 5.1.2. Reordering of Packets in R-mode........................9 67 5.1.2.1. Updating Packets..................................9 68 5.1.2.2. Non-Updating Packets..............................9 69 5.1.3. Reordering of Packets in U/O-mode.....................10 70 5.1.4. Reordering on the Feedback Channel....................10 71 5.1.5. List Compression......................................10 72 5.1.6. Reordering and Mode Transitions.......................11 73 5.2. Consequences of Reordering.................................11 74 5.2.1. Functionality Incompatible with Reordering............11 75 5.2.2. Context Damage (Loss of Synchronization)..............12 76 5.2.3. Detected Decompression Failures (U/O/R-mode)..........12 77 5.2.4. Undetected Decompression Failures (R-mode only).......12 78 6. Making ROHC Tolerant against Reordering.........................13 79 6.1. Properties of ROHC Implementations.........................13 80 6.1.1. Compressing Headers with Robustness against Reordering13 81 6.1.1.1. Reordering and the Optimistic Approach...........13 82 6.1.1.2. Reordering and the Secure Reference Principle....14 83 6.1.1.3. Robust Selection of Compressed Header............14 84 6.1.2. Implementing a Reordering Tolerant Decompressor.......15 85 6.1.2.1. Bi-directional Reliable Mode (R-mode)............15 86 6.1.2.2. Decompressor Feedback Considerations.............16 87 6.1.2.3. Considerations for Local Repair Mechanisms.......16 88 6.2. Specifying ROHC Profiles with Robustness against Reordering16 89 6.2.1. Profiles with Interpretation Interval Offset p = -1...16 90 6.2.2. Modifying the Interpretation Interval Offset..........17 91 6.2.2.1. Example profile for handling reordering..........17 92 6.2.2.2. Defining the values of p for new profiles........17 93 6.2.3. TCP Profile Considerations............................18 94 7. Security Consideration..........................................18 95 8. IANA Considerations.............................................18 96 9. Acknowledgments.................................................18 97 10. Authors' Addresses.............................................18 98 11. Informative References.........................................19 100 1. Introduction 102 RObust Header Compression (ROHC), RFC 3095 [2], defines a framework 103 for header compression, along with a number of compression protocols 104 (profiles). One operating assumption for the profiles defined in RFC 105 3095 is that the channel between compressor and decompressor is 106 required to maintain packet ordering for each compressed flow. The 107 motivation behind this assumption was that the primary candidate 108 channels considered did guarantee in-order delivery of header- 109 compressed packets; making this assumption made it possible to 110 improve the compression efficiency and the tolerance to packet loss, 111 objectives that were on top of the requirements list at the time. 113 Since the publication of RFC 3095 in 2001, the question about ROHC 114 operation over channels that do not guarantee in-order delivery has 115 surfaced several times; arguments that ROHC cannot perform adequately 116 over such channels have even been heard. Specifically, this has been 117 raised as a weakness when compared to other header compression 118 alternatives, as RFC 3095 explicitly states its inability to operate 119 if in-order delivery is not guaranteed. For those familiar with the 120 details of ROHC and of other header compression schemes, it is clear 121 that this is a misconception; but it can also be easily understood 122 that the wording used in RFC 3095 can lead to such interpretation. 124 This document discusses the various aspects of implementing ROHC over 125 channels that can reorder header-compressed packets. It explains 126 different ways of implementing the profiles found in RFC 3095, as 127 well as other profiles based on those profiles, over reordering 128 channels. This can be achieved either by ensuring that compressor 129 implementations uses compressed headers that are sufficiently robust 130 to the expected possible reordering, and/or by modifying decompressor 131 implementations to tolerate reordered packets. Ideas regarding how 132 existing profiles could be updated and how new profiles can be 133 defined to cope efficiently with reordering are also discussed. 135 2. Terminology 137 This document uses terminology consistent with RFC 3759 [3], and is 138 in itself only informative. Although it does discuss technical 139 aspects of implementing the ROHC specifications in particular 140 environments, it does not specify any new technology. 142 However, the document discusses possible ways of modifying existing 143 ROHC implementations and/or specifications to address its objectives. 144 In those parts of the document, the key words "MUST", "MUST NOT", 145 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", 146 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 147 described in RFC 2119 [1]. 149 ROHC 151 The term "ROHC" herein refers to the following profiles: 153 - 0x0001, 0x0002 and 0x0003 defined in RFC 3095 [2]; 154 - 0x0004 for compression of IP-only headers [5]; 155 - 0x0007 and 0x0008 for compression of UDP-Lite headers [6]. 157 The term "ROHC" excludes the following profiles, that are either 158 not affected by reordering or that have the assumption of in-order 159 delivery as a fundamental requirement for their proper operation: 161 - 0x0000 (uncompressed) [2]; 162 - 0x0005 (LLA) [7] and 0x0105 (R-mode extension to LLA) [8]; 164 Reordering 166 A type of transmission taking place between compressor and 167 decompressor where in-order delivery of header-compressed 168 packets is not guaranteed. 170 Reordering Channel 172 A connection over which reordering, as defined above, can occur. 174 Sequentially early packet 176 A packet that reaches the decompressor before one or several 177 packets of the same CID that were delayed on the link. At the time 178 of the arrival of a sequentially early packet, the packet(s) 179 delayed on the link cannot be differentiated from lost packet(s). 181 Sequentially late packet 183 A packet is late within its sequence if it reaches the 184 decompressor after one or several other packets belonging to the 185 same CID have been received, although the sequentially late packet 186 was sent from the compressor before the other packet(s). 188 Updating packet 190 A packet that updates the context of the decompressor, i.e. all 191 packets carrying a CRC calculated over the uncompressed header. 193 Non-updating packet 195 A packet that carries a CRC calculated over the uncompressed 196 header updates the context of the decompressor when it is 197 successfully decompressed. A packet without such a CRC is thus 198 referred to as a non-updating packet. 200 Change packet 202 A packet that updates one or more fields of the context other than 203 the fields pertaining to the functions established with respect to 204 the sequence number (SN). Specifically, it is a packet that 205 updates fields other than the SN, IP-ID or RTP timestamp (TS). 207 3. Applicability of this Document to ROHC Profiles 209 This document addresses general reordering issues for ROHC profiles. 210 The foremost objectives are to ensure that ROHC implementations will 211 not forward packets with incorrectly decompressed headers to upper 212 layers, as well as to limit the possible increase in the rate of 213 decompression failures or in events leading to context damage, when 214 compression is applied over reordering channels. 216 3.1. Profiles within Scope 218 The solutions outlined in following sections are generally applicable 219 to profiles 0x0001 (RTP), 0x0002 (UDP) and 0x0003 (ESP) defined in 220 RFC 3095 [2]. Profile 0x0000 (uncompressed) is not affected by 221 reordering, as the headers are sent uncompressed. The solutions also 222 apply to profiles for IP-only (0x0004) [5] and for UDP-Lite (0x0007 223 and 0x0008) [6]. These profiles are based on the profiles of RFC 3095 224 [2] and inherently make the same in-order delivery assumption. 226 3.2. Profiles with Special Considerations 228 Special considerations are needed to make some of the implementation 229 solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) 230 [2], 0x0004 (IP-only) [5], and 0x0008 (UDP-Lite) [6]. For these 231 profiles, the SN is generated at the compressor, as it is not present 232 in headers being compressed. For the least significant bit (LSB) 233 encoding method, the interpretation interval offset (p) is always 234 p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus 235 required to increase for each packet received at the decompressor, 236 which means that reordered packets cannot be decompressed. 238 3.3. Profiles Incompatible with Reordering 240 The ROHC LLA profiles defined in RFC 3242 [7] and RFC 3408 [8] have 241 been explicitly designed with in-order delivery as a fundamental 242 requirement to their proper operation. Profiles 0x0005 and 0x0105 can 243 therefore not be implemented over channels where reordering can 244 occur; this document therefore does not apply to these profiles. 246 4. Background 248 ROHC was designed with the assumption that packets are delivered in- 249 order from compressor to decompressor. This was considered as a 250 reasonable working assumption for links where it was expected that 251 ROHC would be used. However, many have expressed that it would be 252 desirable to use ROHC also over connections where in-order delivery 253 is not guaranteed [9]. 255 4.1. Reordering Channels 257 The reordering channels that are potential candidates to use ROHC are 258 single-hop channels and multi-hop virtual channels. 260 A single-hop channel is a point-to-point link that constitutes a 261 single IP hop. Note that one IP hop could be one or multiple physical 262 links. For example, a single-hop reordering channel could be a 263 wireless link that applies error detection and performs 264 retransmissions to guarantee error-free delivery of all data. Another 265 example could be a wireless connection that performs bicasting of 266 data during a handoff procedure. 268 A multi-hop virtual channel is a virtual point-to-point link that 269 traverses multiple IP hops. A multi-hop virtual channel would 270 typically be an IP tunnel, where compression is applied over the 271 tunnel by the endpoints of the tunnel (not to be confused with single 272 link compression of tunneled packets). 274 4.2. Robustness Principles of ROHC 276 Robustness is based on the optimistic approach in the unidirectional 277 and optimistic modes of operation (U/O-mode), and on the secure 278 reference principle in the bi-directional reliable mode (R-mode). 280 Both approaches have different characteristics in the presence of 281 reordering between compressor and decompressor. However, in any mode, 282 decompression of sequentially early packets will generally be handled 283 quite well since they will be perceived and treated by the 284 decompressor as if there had been one or more packet losses. 286 4.2.1. Optimistic Approach (U/O-mode) 288 A ROHC compressor uses the optimistic approach to reduce header 289 overhead when performing context updates in U/O-mode. The compressor 290 normally repeats the same update until it is fairly confident that 291 the decompressor has successfully received the information. The 292 number of consecutive packets needed to obtain this confidence is 293 open to implementations, and this number is normally related to the 294 packet loss characteristics of the link where header compression is 295 used (see also [2], section 5.3.1.1.1). 297 All packet types used in U/O-mode are context updating. 299 4.2.2. Secure Reference Principle (R-mode) 301 A ROHC compressor uses the secure reference principle in R-mode, to 302 ensure that context synchronization between ROHC peers cannot be lost 303 due to packet losses. The compressor obtains its confidence that the 304 decompressor has successfully updated the context from a packet 305 carrying a 7- or 8-bit CRC based on acknowledgements received from 306 the decompressor (see also [2], section 5.5.1.2). 308 The secure reference principle makes it possible for a compressor to 309 use packets that do not update the context (i.e. R-0 and R-1* [2]). 311 5. Problem Description 313 5.1. ROHC and Reordering Channels 315 This section reviews different aspects of ROHC susceptible of being 316 impacted by reordering of compressed packets between ROHC peers. 318 5.1.1. LSB Interpretation Interval and Reordering 320 The LSB encoding method defined in RFC 3095 ([2], section 5.7) 321 specifies the interpretation interval offset, called p, as follow: 323 For profiles 0x0001, 0x0003 and 0x0007: 325 p = 1, when bits(SN) <= 4; 326 p = 2^(bits(SN)-5) - 1 otherwise. 328 The resulting table describing the interpretation interval is: 330 +-----------+--------------+--------------+ 331 | bits (SN) | Offset p | (2^k-1) - p | 332 | k | (reordering) | (losses) | 333 +-----------+--------------+--------------+ 334 | 4 | 1 | 7 | 335 | 5 | 0 | 16 | 336 | 6 | 1 | 31 | 337 | 7 | 3 | 61 | 338 | 8 | 7 | 121 | 339 | 9 | 15 | 241 | 340 +-----------+--------------+--------------+ 342 As shown in the table above, the ability for ROHC to handle 343 sequentially late packets depends on the number of bits sent in 344 each packet. For example, a sequentially late packet of type 0 345 (with either 4 or 6 bits of SN) sets the limit to one packet out 346 of sequence for successful decompression to be possible. 348 For profiles 0x0002, 0x0004 and 0x0008: 350 p = - 1, independently of bits(SN). 352 A value of p = -1 means that the interpretation interval offset 353 can only take positive values, and that no sequentially late 354 packet can be decompressed if reordering occurs over the link. 356 The trade-off between reordering and robustness 358 The ability of ROHC to handle sequentially late packets is limited 359 by the interval interpretation offset of the sliding window used 360 for LSB encoding. This offset has a very small value for packets 361 with a small number of sequence number (SN) bits, but grows with 362 the number of SN bits transmitted. 364 For channels where both packet losses and reordering can occur, 365 modifications to the interpretation interval faces a trade-off 366 between the amount of reordering and the number of consecutive 367 packets losses that can be handled by the decompressor. If the 368 negative offset (i.e. p) is increased to handle a larger amount of 369 reordering, the value of the positive offset of the interpretation 370 interval must be decreased. This may impact the compression 371 efficiency when the channel has a high loss rate. 373 This is shown in the figure: 375 <--- interpretation interval (size is 2^k) ----> 376 |------------------+---------------------------| 377 Lower v_ref Upper 378 Bound Bound 379 <--- reordering --> <--------- losses ---------> 380 max delta(SN) = p max delta(SN) = (2^k-1) - p 382 where v_ref is the reference value as per [2]. 384 In practice, the maximum variation in SN value (max delta(SN)) 385 due to reordering that can be handled will normally correspond to 386 the maximum number of packets that can be reordered. The same 387 applies to the maximum number of consecutive packet losses covered 388 by the robustness interval. 390 5.1.2. Reordering of Packets in R-mode 392 5.1.2.1. Updating Packets 394 The compressor always adds references in the sliding window for all 395 updating packets sent. The compressor removes values smaller than 396 values for which it has received an acknowledgement, to shrink the 397 window and thereby increase the compression efficiency. 399 The decompressor always updates the context when receiving an 400 updating packet, and uses the new reference for decompression. 401 Acknowledgements are sent to allow the compressor to shrink its 402 sliding window. 404 Reordering between updating packets 406 The decompressor can update its context from the reception of a 407 sequentially late updating packet. The decompressor reference is 408 then updated with a value that is no longer in the sliding window 409 of the compressor. This "missing reference" can be caused by 410 reordering when operating in R-mode. 412 The result is that the compressor and the decompressor lose 413 synchronization with each other. When the decompressor 414 acknowledges the sequentially late packet, the compressor might 415 already have discarded the reference to this sequence number, and 416 continue to compress packets based on more recent references (in 417 packet arrival time). Decompression will then be attempted using 418 the wrong reference. 420 5.1.2.2. Non-Updating Packets 422 Reordering between non-updating packets only 424 A non-updating packet that reaches the decompressor out-of- 425 sequence with respect to other non-updating packets only can 426 always be decompressed properly. 428 Reordering between non-updating packets and updating packets 430 When a non-updating packet is reordered and becomes sequentially 431 late with respect to an updating packet, the decompressor may have 432 already updated the context with a new reference when the late 433 packet is received. It is thus possible for a non-updating packet 434 to be decompressed based on the wrong reference because of 435 reordering when operating in R-mode. 437 Since decompression of non-updating packets cannot be verified, 438 this can lead to a packet erroneously decompressed being forwarded 439 to upper layers. 441 5.1.3. Reordering of Packets in U/O-mode 443 Sequentially late packets 445 The ability to decompress sequentially late packets is limited by 446 the offset p of the interpretation interval (see section 5.1.1). 447 Decompression of a sequentially late packet with SN = x is 448 possible if the value of the SN of the packet that last updated 449 the context was less than or equal to x + p. 451 Problems occur if context(SN) has increased by more than p with 452 respect to field(SN) carried within the packet to decompress. 454 This means that for a well-behaved stream with a constant unit 455 increase in the RTP SN, a packet can arrive up to p packets out of 456 sequence and still be correctly decompressed. Otherwise, it cannot 457 be properly decompressed. It also means that if the compressor 458 sends two consecutive packets with SN(packet1)=100 and 459 SN(packet2)=108 when p=7, packet1 cannot be decompressed if it 460 arrives even one packet late due to reordering. 462 Decompression can always be verified since all U/O-mode packet types 463 are context updating. Consequently, reordering of packets is not 464 deemed problematic when operating in U/O-mode. For channels known to 465 reorder packets, the U/O-mode should therefore be the preferred mode 466 of operation. The additional risk of losing context synchronization 467 or for erroneous packet to be delivered to upper layers is limited. 469 5.1.4. Reordering on the Feedback Channel 471 For R-mode, upon reception of an acknowledgement, the compressor 472 searches the sliding window to locate an updating packet with the 473 corresponding SN; if it is not found, the acknowledgement is invalid 474 and is discarded ([2], section 5.5.1.2). In other words, feedback 475 received out-of-order either is still useful or is discarded. 477 In U/O-mode, if the compressor updates its context based on feedback, 478 the same logic as for R-mode applies in practice. 480 Reordering on the feedback channel has thus no impact in either mode. 482 5.1.5. List Compression 484 <# Editor's Note: This is for further study. #> 485 <# #> 486 <# #> 487 <# #> 489 5.1.6. Reordering and Mode Transitions 491 Transition from U/O-mode to R-mode 493 This transition can be affected by reordering if a packet type 0 494 (UO-0) is reordered and delayed by at least one round-trip time 495 (RTT). If the decompressor initiates a mode change request to R- 496 mode in the meantime, the reordered UO-0 packet may be handled as 497 an R-0 packet; it can be erroneously decompressed and forwarded to 498 upper layers. This is because the decompressor can switch to 499 R-Mode as soon as it sends the acknowledgement Ack(SN, R) to the 500 compressor (see also [2], section 5.6). 502 Transition from R-mode to U/O-mode 504 A similar situation as above can occur during this transition. 505 However, because the outcome of the decompression is always 506 verified using a CRC verification in U/O-mode, the reordered 507 packet will most likely fail decompression and will be discarded. 509 The above situation, while it is not deemed to occur frequently, is 510 still possible; thus mode transitions from U/O-mode to R-mode should 511 be avoided when reordering can occur. 513 5.2. Consequences of Reordering 515 The context updating properties of the packets exchanged between ROHC 516 peers are the most important factors to consider when deriving the 517 impacts of reordering. For this reason, the robustness properties of 518 the U/O-mode and of the R-mode are affected differently. 520 The effects of reordering on ROHC can be summarized as follow: 522 - Functionality incompatible with reordering; 523 - Increased probability of context damage (loss of synchronization); 524 - Increased number of decompression failures - Detected (U/O/R-mode); 525 - Increased number of decompression failures - Undetected (R-mode). 527 5.2.1. Functionality Incompatible with Reordering 529 There are some optional ROHC functions that cannot work in the 530 presence of reordering between ROHC peers. 532 The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely 533 on the in-order delivery of each segment, as there is no sequencing 534 information in the segments. Therefore segmentation should not be 535 used if there can be reordering between the ROHC peers. 537 Timer-based compression of RTP TS (see [2], section 4.5.4) is built 538 on an assumption of timely (minimal jitter) delivery. Therefore it 539 should be used with care over links where reordering can occur, with 540 respect to the amount of jitter that can be introduced by reordering. 542 The use of these optional features is open to implementations and is 543 local to the compressor only; it does not impact the decompressor. 545 5.2.2. Context Damage (Loss of Synchronization) 547 Reordering of packets between ROHC peers can impact the robustness 548 properties of the optimistic approach (U/O-mode) as well as the 549 reliability of the secure reference principle (R-mode). 551 The successful decompression of a sequentially late change packet 552 (U/O-mode) and/or updating packet (R-mode) can update the context of 553 the decompressor in a manner unexpected by the compressor. This can 554 lead to a loss of context synchronization between the ROHC peers. 556 5.2.3. Detected Decompression Failures (U/O/R-mode) 558 Reordering of packets between ROHC peers can lead to an increase in 559 the number of decompression failures for context updating packets 560 (see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the 561 decompression of updating packets can be verified, the decompressor 562 can reliably detect decompression failures caused by reordering and 563 discard the packet. Note that local repairs, subject to the 564 limitations stated in [2] section 5.3.2.3, can still be performed. 566 5.2.4. Undetected Decompression Failures (R-mode only) 568 Reordering of packets between ROHC peers can lead to an increase in 569 the number of decompression errors for non-updating packets. For R- 570 mode, decompression of R-0 and R-1* packets cannot be verified. If 571 reordering occurs and decompression is performed using the wrong 572 secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor 573 cannot reliably detect such errors. As a result, erroneous packets 574 may be forwarded to upper layers. 576 6. Making ROHC Tolerant against Reordering 578 This chapter describes different approaches that can improve the 579 performance of ROHC when used over reordering channels and minimize 580 the effects of reordering. Examples are provided to guide 581 implementers and designers of new profiles. The solutions target 582 either the properties of ROHC implementations or the specifications 583 of profiles. This is covered by sections 6.1 and 6.2 respectively. 585 6.1. Properties of ROHC Implementations 587 Existing ROHC profiles can be implemented with the capability to 588 properly handle packet reordering. The methods described in this 589 section conform with, and thus do not require any modifications to, 590 the ROHC specifications within scope of this document (see section 591 3). Specifically, the methods presented in this section can be 592 implemented without any impairment to interoperability with other 593 ROHC implementations that do not use these methods. 595 The methods suggested here may however lower compression efficiency, 596 and these modifications should not be used when reordering is known 597 not to occur. Some of these methods aim to increase the decompression 598 success rate at the decompressor, while others aim to avoid context 599 damages causing loss of context synchronization between compressor 600 and decompressor. 602 The methods proposed are each addressing specific issues listed in 603 section 5, and can be combined to achieve better robustness against 604 reordering. 606 6.1.1. Compressing Headers with Robustness against Reordering 608 The methods described in this section are methods local only to the 609 compressor implementation. They can be used without modifications or 610 impact to the decompressor. 612 6.1.1.1. Reordering and the Optimistic Approach 614 The optimistic approach is affected by the reordering characteristics 615 of the channel when operating over a reordering channel. Compressor 616 implementations should therefore adjust their optimistic approach 617 strategy to match both packet loss and reordering characteristics. 619 For example, the number of repetitions for each context update can be 620 increased. The compressor should ensure that each update is repeated 621 until it is reasonably confident that a least one change packet in 622 the sequence of repetitions has reached the decompressor before the 623 first packet sent after this sequence. 625 6.1.1.2. Reordering and the Secure Reference Principle 627 Fundamental to the secure reference principle is that only values 628 acknowledged by the decompressor can be used as reference for 629 compression. In addition, some of the packet types used in R-mode do 630 not include a CRC over the original uncompressed header, and the 631 decompressor has no means to verify the outcome of the decompression. 633 Decompression of non-updating packet types thus entirely relies on 634 the cumulative effect of previous updates to the secure reference, 635 and the compressed data is based on the current value of the 636 reference. This reference must be synchronized between ROHC peers. 637 For R-0 and R-1* packets, the reception of the encoded bits applied 638 to the secure reference is sufficient for correct decompression, but 639 only when in-order delivery between ROHC peers is guaranteed. 641 Avoiding the "missing reference" problem (section 5.1.2.1) 643 A compressor implementation can delay the advance in the sliding 644 window to a reference acknowledged by the decompressor, until it 645 has confidence that no acknowledgement for any of the values that 646 could be discarded can be received. This confidence can be based 647 on the maximum delay that reordering can introduce over the 648 channel. It can also be based on the knowledge that the 649 decompressor implements the context updating logic of section 650 6.1.2.1 (e.g. by means of standardization). 652 6.1.1.3. Robust Selection of Compressed Header 654 The interpretation interval for the LSB encoded sequence number can 655 be adjusted to allow for larger negative offsets (see section 5.1.1). 656 This would provide the capability to decompress sequentially late 657 packets with a greater amount of reordering. 659 To achieve this, the compressor should be implemented conservatively 660 in terms of the choice of packet types to send, by transmitting 661 packets with more sequence number bits. As shown in the table of 662 section 5.1.1, using eight bits of SN allows a packet to be 663 decompressed when the reordering leads to up to seven units in 664 sequence number variation (i.e. delta(SN)). Increasing the number of 665 SN bits (i.e. using a larger SN_k [2]) transmitted will make ROHC 666 even more tolerant to reordering. 668 For example, a conservative compressor implementation could use the 669 packet types as shown in the table below: 671 +----------------------+-------------------------+ 672 | Optimal Packet Type | Alternative Packet Type | 673 | (without reordering) | (reordering possible) | 674 +----------------------+-------------------------+ 675 | UO-0 | UOR-2*-ext0 | 676 | R-0 | R-1*-ext0 | 677 | R-0-CRC | UOR-2*-ext0 | 678 | R-1* | R-1*-ext0 | 679 | UO-1 | UOR-2-ext0 | 680 | UO-1-TS | UOR-2-TS-ext0 | 681 | UO-1-ID | UO-1-ID-ext3 (with S=1) | 682 | | UOR-2-ID-ext0 | 683 | UOR-2* | UOR-2*-ext0 | 684 +----------------------+-------------------------+ 686 Such a compressor implementation would thus always be sending at 687 least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off 688 when compared to the 1 octet that can be sent by a more aggressive 689 implementation operating on a channel with no reordering. 691 Note that since the interpretation interval for profiles 0x0002, 692 0x0004 and 0x0008 is always p = -1 independently of bits(SN), the 693 methods suggested in this section will not work for these profiles 694 unless this value is modified (section 6.2.1). 696 6.1.2. Implementing a Reordering Tolerant Decompressor 698 The methods described in this section are methods local only to the 699 decompressor implementation. They can be used without modifications 700 or impact to the compressor. 702 6.1.2.1. Bi-directional Reliable Mode (R-mode) 704 The "missing reference" problem described in section 5.1.2.1 can be 705 avoided. If the decompressor can detect when two updating packets 706 (packets including CRCs) are reordered with respect to each other, it 707 should not update the context with the values of the sequentially 708 late update packet. 710 6.1.2.2. Decompressor Feedback Considerations 712 Reducing the feedback rate when the flow behaves linearly 714 The decompressor should reduce its feedback rate when a large 715 number of UOR-2 packets with extensions a received, when the flow 716 behaves linearly (i.e. when only fields pertaining to the 717 functions established with respect to the sequence number are 718 changing. 720 In particular, if the compressor implementation makes a more 721 conservative selection of packet types (section 6.1.1.3) in order 722 to handle reordering, the decompressor should try to avoid sending 723 more feedback than it would have if the more optimal packet types 724 had been used. 726 Note that if the decompressor does not make this adjustment, 727 packet losses or context damages will not increase. It might 728 however reduce link efficiency. 730 Acknowledgements and sequentially late packets 732 Reordered feedback (or feedback for packets received out-of-order) 733 will not cause problems (see section 5.1.4). However, the 734 decompressor should not send feedback for sequentially late 735 packets, as the current state of the context will better reflect 736 the compressor context than the content of the reordered packet. 738 6.1.2.3. Considerations for Local Repair Mechanisms 740 When decompression fails, and if reordering can be the cause of this 741 failure, a local repair may be attempted for the sequentially late 742 packet by going backward in the interpretation interval (as opposed 743 to moving forward as for packet losses). 745 6.2. Specifying ROHC Profiles with Robustness against Reordering 747 6.2.1. Profiles with Interpretation Interval Offset p = -1 749 New revisions of profiles 0x0002 (UDP) [2], 0x0004 (IP-only) [5], and 750 0x0008 (UDP-Lite) [6] should redefine how the value of the offset p 751 is determined, and use the same algorithm as in profile 0x0001 [2] 752 instead of p = -1 independently of bits(SN) (section 5.1.1). 754 While such a change would make these updated profiles slightly less 755 robust to packet losses, they would still be no less robust than 756 profile 0x0001. 758 6.2.2. Modifying the Interpretation Interval Offset 760 The interpretation interval offset p could be modified for existing 761 profile in order to handle reordering while improving the compression 762 efficiency when compared to the solution of section 6.1.1.3. 764 6.2.2.1. Example profile for handling reordering 766 The value of the interpretation interval offset p can be adjusted to 767 achieve a robustness against reordering similar to the effect of 768 selecting packet types as suggested in section 6.1.1.3. 770 For example, assuming that having a value p=7 is enough while still 771 considering robustness against packet losses a priority, a ratio 772 where the positive offset is about twice as large as the negative 773 offset can be used. This leaves a value of p = 2^k/ 3. 775 The resulting values are shown in the following table: 777 +-----------+--------------+----------------+ 778 | bits (SN) | Offset p | Positive range | 779 | k | (reordering) | (losses) | 780 +-----------+--------------+----------------+ 781 | 4 | 5 | 10 | 782 | 5 | 10 | 21 | 783 | 6 | 21 | 42 | 784 | 7 | 42 | 85 | 785 | 8 | 85 | 170 | 786 | 9 | 170 | 341 | 787 +-----------+--------------+----------------+ 789 Using this value for p, a fair amount of reordering can be handled 790 without having to send UOR-2 packets most of the time. The trade-off 791 is that this is at the expense of robustness against packet losses. 793 6.2.2.2. Defining the values of p for new profiles 795 As described in RFC3095, the interpretation interval when sending k 796 bits of SN is defined as: 798 f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p] 800 The negative bound (v_ref - p) limits the ability to handle 801 reordering, while the positive bound (v_ref + (2^k - 1) - p) limits 802 the ability to handle packet losses. 804 Adjusting p will increase one of these ranges, while the other range 805 will decrease. When designing ROHC profiles, considerations on how 806 these correlate with each other should be taken. 808 For example, if it is desirable for a profile to be as robust against 809 reordering (negative range) and against packet losses (positive 810 range), these range can be made equal by setting p near (2^k / 2). 812 6.2.3. TCP Profile Considerations 814 The current draft for the ROHC TCP profile [4] contains packet 815 formats that allow sending as little as 1 bit of MSN (master sequence 816 number). Since the MSN is used in the same fashion as the sequence 817 number in profile 0x0002, it will not be possible to decompress 818 reordered packets if used over a reordering channel. 820 The work on the ROHC-TCP profile should consider using more bits of 821 MSN to enable simple implementation modifications when operating over 822 a reordering channel. 824 7. Security Consideration 826 This document does not include additional security risks to [2]. In 827 addition, it may lower risks related to context damage in R-mode with 828 injected packets when sequentially late packets do not update the 829 context (section 6.1.2.1). 831 8. IANA Considerations 833 This document does not require any IANA action. 835 9. Acknowledgments 837 The authors would appreciate feedback on this document, as input from 838 others would certainly help us improve it significantly. 840 10. Authors' Addresses 842 Ghyslain Pelletier Tel: +46 920 20 24 32 843 Ericsson AB EMail: ghyslain.pelletier@ericsson.com 844 Box 920 845 S-971 28 Lulea 846 Sweden 848 Lars-Erik Jonsson Tel: +46 920 20 21 07 849 Ericsson AB EMail: lars-erik.jonsson@ericsson.com 850 Box 920 851 S-971 28 Lulea 852 Sweden 853 Kristofer Sandlund Tel: +46 920 609 17 854 Effnet AB EMail: kristofer.sandlund@effnet.com 855 Stationsgatan 69 856 S-972 34 Lulea 857 Sweden 859 11. Informative References 861 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 862 Levels", RFC 2119, March 1997. 864 [2] C. Bormann, et. al, "RObust Header Compression (ROHC): Framework 865 and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 866 July 2001. 868 [3] Jonsson, L-E., " RObust Header Compression (ROHC): Terminology 869 and Channel Mapping Examples", RFC 3759, April 2004. 871 [4] G. Pelletier, et. al, "RObust Header Compression (ROHC): TCP/IP 872 Profile (ROHC-TCP)", Internet-Draft (work in progress), 873 , April 2004. 875 [5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 876 (ROHC): A compression profile for IP", Internet draft (work in 877 progress), , October 2003. 879 [6] G. Pelletier, "RObust Header Compression (ROHC): Profiles for 880 UDP-Lite", Internet draft (work in progress), , June 2004. 883 [7] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 884 (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, 885 April 2002. 887 [8] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional Reliable 888 More (R-mode) in Extended Link-Layer Assisted Profile for RObust 889 Header Compression (ROHC) Profile", RFC 3408, December 2002. 891 [9] Ash, J., Goode B. and J. Hand, "Requirements for Header 892 Compression over MPLS", Internet draft (work in progress), 893 , June 2004. 895 Intellectual Property Statement 897 The IETF takes no position regarding the validity or scope of any 898 Intellectual Property Rights or other rights that might be claimed to 899 pertain to the implementation or use of the technology described in 900 this document or the extent to which any license under such rights 901 might or might not be available; nor does it represent that it has 902 made any independent effort to identify any such rights. Information 903 on the IETF's procedures with respect to rights in IETF Documents can 904 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 906 Copies of IPR disclosures made to the IETF Secretariat and any 907 assurances of licenses to be made available, or the result of an 908 attempt made to obtain a general license or permission for the use of 909 such proprietary rights by implementers or users of this 910 specification can be obtained from the IETF on-line IPR repository at 911 http://www.ietf.org/ipr. 913 The IETF invites any interested party to bring to its attention any 914 copyrights, patents or patent applications, or other proprietary 915 rights that may cover technology that may be required to implement 916 this standard. Please address the information to the IETF at ietf- 917 ipr@ietf.org. 919 Copyright Statement 921 Copyright (C) The Internet Society (2004). This document is subject 922 to the rights, licenses and restrictions contained in BCP 78, and 923 except as set forth therein, the authors retain all their rights. 925 Disclaimer of Validity 927 This document and the information contained herein are provided on an 928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 935 This Internet-Draft expires December 14, 2004.