idnits 2.17.1 draft-ietf-avt-crtp-enhance-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 888 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 620 has weird spacing: '...ime pkt upd...' == Line 666 has weird spacing: '...ime pkt upd...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 208, but not defined == Unused Reference: 'CRTP' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'IPCPHC' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'KEYW' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 777, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-koren-pppext-rfc2509bis-01 ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Working Group Tmima Koren 2 Internet Draft Cisco Systems 3 January 28, 2003 Stephen Casner 4 Expires August 2003 Packet Design 5 draft-ietf-avt-crtp-enhance-06.txt John Geevarghese 6 Telseon 7 Bruce Thompson 8 Patrick Ruddy 9 Cisco Systems 11 Compressing IP/UDP/RTP headers on links with high delay, 12 packet loss and reordering 14 Status of this memo 16 This document is an Internet Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 Areas, and its Working Groups. Note that other groups may also 20 distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsolete by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as "work in 26 progress". 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.txt 34 This draft is a work item of the IETF Audio/Video Transport working 35 group. The working group mailing list is avt@ietf.org. Subscribe via 36 the web at http://www.ietf.org/mailman/listinfo/avt. 38 Copyright Notice 40 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 42 Abstract 44 This document describes a header compression scheme for point to 45 point links with packet loss and long delays. It is based on 46 Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP 47 header compression described in RFC 2508. CRTP does not perform well 48 on such links: packet loss results in context corruption and due to 49 the long delay, many more packets are discarded before the context 50 is repaired. To correct the behavior of CRTP over such links, a few 51 extensions to the protocol are specified here. The extensions aim to 52 reduce context corruption by changing the way the compressor updates 53 the context at the decompressor: updates are repeated and include 54 updates to full and differential context parameters. With these 55 extensions, CRTP performs well over links with packet loss, packet 56 reordering and long delays. 58 1.0 Introduction 60 RTP header compression (CRTP) as described in RFC 2508 was designed 61 to reduce the header overhead of IP/UDP/RTP datagrams by compressing 62 the three headers. The IP/UDP/RTP headers are compressed to 2-4 63 bytes most of the time. 65 CRTP was designed for reliable point to point links with short 66 delays. It does not perform well over links with high rate of packet 67 loss, packet reordering and long delays. 69 An example of such a link is a PPP session that is tunneled using an 70 IP level tunneling protocol such as L2TP. Packets within the tunnel 71 are carried by an IP network and hence may get lost and reordered. 72 The longer the tunnel, the longer the round trip time. 74 Another example is an IP network that uses layer 2 technologies such 75 as ATM and Frame Relay for the access portion of the network. Layer 76 2 transport networks such as ATM and Frame Relay behave like point 77 to point serial links in that they do not reorder packets. In 78 addition, Frame Relay and ATM virtual circuits used as IP access 79 technologies often have a low bit rate associated with them. These 80 virtual circuits differ from low speed serial links in that they may 81 span a larger physical distance than a point to point serial link. 82 Speed of light delays within the layer 2 transport network will 83 result in higher round trip delays between the endpoints of the 84 circuit. In addition, congestion within the layer 2 transport 85 network may result in an effective drop rate for the virtual circuit 86 which is significantly higher than error rates typically experienced 87 on point to point serial links. 89 It may be desirable to extend existing CRTP implementations for use 90 also over IP tunnels and other virtual circuits, where packet 91 losses, reordering, and long delays are common characteristics. To 92 address these scenarios, this document defines modifications and 93 extensions to CRTP to increase robustness to both packet loss and 94 misordering between the compressor and the decompressor. This is 95 achieved by repeating updates and allowing the sending of absolute 96 (uncompressed) values in addition to delta values for selected 97 context parameters. Although these new mechanisms impose some 98 additional overhead, the overall compression is still substantial. 99 The enhanced CRTP, as defined in this document, is thus suitable for 100 many applications in the scenarios discussed above, e.g. tunneling 101 and other virtual circuits. 103 RFC 3095 defines another RTP header compression scheme called Robust 104 Header Compression [ROHC]. ROHC was developed with wireless links 105 as the main target, and introduced new compression mechanisms with 106 the primary objective to achieve the combination of robustness 107 against packet loss and maximal compression efficiency. ROHC is 108 expected to be the preferred compression mechanism over links where 109 compression efficiency is important. However, ROHC was designed 110 with the same link assumptions as CRTP, e.g. that the compression 111 scheme should not have to tolerate misordering of compressed packets 112 between the compressor and decompressor, which may occur when 113 packets are carried in an IP tunnel across multiple hops. 115 At some time in the future, enhancements may be defined for ROHC to 116 allow it to perform well in the presence of misordering of 117 compressed packets. The result might be more efficient than the 118 compression protocol specified in this document. However, there are 119 many environments for which the enhanced CRTP defined here may be 120 the preferred choice. In particular, for those environments where 121 CRTP is already implemented, the additional effort required to 122 implement the extensions defined here is expected to be small. 123 There are also cases where the implementation simplicity of this 124 enhanced CRTP relative to ROHC is more important than the 125 performance advantages of ROHC. 127 1.1 CRTP Operation 129 During compression of an RTP stream, a session context is defined. 130 For each context, the session state is established and shared 131 between the compressor and the decompressor. Once the context state 132 is established, compressed packets may be sent. 134 The context state consists of the full IP/UDP/RTP headers, a few 135 first order differential values, a link sequence number, a 136 generation number and a delta encoding table. 138 The headers part of the context is set by the FULL_HEADER packet 139 that always starts a compression session. The first order 140 differential values (delta values) are set by sending COMPRESSED_RTP 141 packets that include updates to the delta values. 143 The context state must be synchronized between compressor and 144 decompressor for successful decompression to take place. If the 145 context gets out of sync, the decompressor is not able to restore 146 the compressed headers accurately. The decompressor invalidates the 147 context and sends a CONTEXT_STATE packet to the compressor 148 indicating that the context has been corrupted. To resume 149 compression, the compressor must reestablish the context. 151 During the time the context is corrupted, the decompressor discards 152 all the packets received for that context. Since the context repair 153 mechanism in CRTP involves feedback from the decompressor, context 154 repair takes at least as much time as the round trip time of the 155 link. If the round trip time of the link is long, and especially if 156 the link bandwidth is high, many packets will be discarded before 157 the context is repaired. On such links it is desirable to minimize 158 context invalidation. 160 1.2 How do contexts get corrupted? 162 As long as the fields in the combined IP/UDP/RTP headers change as 163 expected for the sequence of packets in a session, those headers can 164 be compressed, and the decompressor can fully restore the compressed 165 headers using the context state. When the headers don't change as 166 expected it's necessary to update some of the full or the delta 167 values of the context. For example, the RTP timestamp is expected to 168 increment by delta RTP timestamp (dT). If silence suppression is 169 used, packets are not sent during silence periods. Then when voice 170 activity resumes, packets are sent again, but the RTP timestamp is 171 incremented by a large value and not by dT. In this case an update 172 must be sent. 174 If a packet that includes an update to some context state values is 175 lost, the state at the decompressor is not updated. The shared state 176 is now different at the compressor and decompressor. When the next 177 packet arrives at the decompressor, the decompressor will fail to 178 restore the compressed headers accurately since the context state at 179 the decompressor is different than the state at the compressor. 181 1.3 Preventing context corruption 183 Note that the decompressor fails not when a packet is lost, but when 184 the next compressed packet arrives. If the next packet happens to 185 include the same context update as in the lost packet, the context 186 at the decompressor may be updated successfully and decompression 187 may continue uninterrupted. If the lost packet included an update to 188 a delta field such as the delta RTP timestamp (dT), the next packet 189 can't compensate for the loss since the update of a delta value is 190 relative to the previous packet which was lost. But if the update is 191 for an absolute value such as the full RTP timestamp or the RTP 192 payload type, this update can be repeated in the next packet 193 independently of the lost packet. Hence it is useful to be able to 194 update the absolute values of the context. 196 The next chapter describes several extensions to CRTP that add the 197 capability to selectively update absolute values of the context, 198 rather than sending a FULL_HEADER packet, in addition to the 199 existing updates of the delta values. This enhanced version of CRTP 200 is intended to minimize context invalidation and thus improve the 201 performance over lossy links with a long round trip time. 203 1.4 Specification of Requirements 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 2. Enhanced CRTP 211 This chapter specifies the changes in this enhanced version of CRTP. 212 They are: 214 - Extensions to the COMPRESSED_UDP packet to allow updating the 215 differential RTP values in the decompressor context and to 216 selectively update the absolute IP ID and the following RTP 217 values: sequence number, timestamp, payload type, and CSRC 218 count. This allows context sync to be maintained even with 219 some packet loss. 221 - A "headers checksum" to be inserted by the compressor and 222 removed by the decompressor when the UDP checksum is not 223 present so that validation of the decompressed headers is 224 still possible. This allows the decompressor to verify that 225 context sync has not been lost after a packet loss. 227 An algorithm is then described to use these changes with repeated 228 updates to achieve robust operation over links with packet loss and 229 long delay. 231 2.1 Extended COMPRESSED_UDP packet 233 It is possible to accommodate some packet loss between the 234 compressor and decompressor using the "twice" algorithm in RFC 2508 235 so long as the context remains in sync. In that algorithm, the delta 236 values are added to the previous context twice (or more) to effect 237 the change that would have occurred if the missing packets had 238 arrived. The result is verified with the UDP checksum. Keeping the 239 context in sync requires reliably communicating both the absolute 240 value and the delta value whenever the delta value changes. For many 241 environments, sufficient reliability can be achieved by repeating 242 the update with each of several successive packets. 244 The COMPRESSED_UDP packet satisfies the need to communicate the 245 absolute values of the differential RTP fields, but it is specified 246 in RFC 2508 to reset the delta RTP timestamp. That limitation can be 247 removed with the following simple change: RFC 2508 describes the 248 format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except 249 that the M, S and T bits are always 0 and the corresponding delta 250 fields are never included. This enhanced version of CRTP changes 251 that specification to say that the T bit MAY be nonzero to indicate 252 that the delta RTP timestamp is included explicitly rather than 253 being reset to zero. 255 A second change adds another byte of flag bits to the COMPRESSED_UDP 256 packet to allow only selected individual uncompressed fields of the 257 RTP header to be included in the packet rather than carrying the 258 full RTP header as part of the UDP data. The additional flags do 259 increase computational complexity somewhat, but the corresponding 260 increase in bit efficiency is important when the differential field 261 updates are communicated multiple times in successive COMPRESSED_UDP 262 packets. With this change, there are flag bits to indicate 263 inclusion of both delta values and absolute values, so the flag 264 nomenclature is changed. The original S, T, I bits which indicate 265 the inclusion of deltas are renamed dS, dT, dI, and the inclusion of 266 absolute values is indicated by S, T, I. The M bit is absolute as 267 before. A new flag P indicates inclusion of the absolute RTP payload 268 type value and, as in the COMPRESSED_RTP packet, a four-bit CC field 269 copies the absolute value of the CC field in the RTP header. 271 The last of the three changes to the COMPRESSED_UDP packet deals 272 with updating the IP ID field. For this field, the COMPRESSED_UDP 273 packet as specified in RFC 2508 can already convey a new value for 274 the delta IP ID, but not the absolute value which is only conveyed 275 by the FULL_HEADER packet. Therefore, a new flag I is added to the 276 COMPRESSED_UDP packet to indicate inclusion of the absolute IP ID 277 value. The I flag replaces the dS flag which is not needed in the 278 COMPRESSED_UDP packet since the delta RTP sequence number always 279 remains 1 in the decompressor context and hence does not need to be 280 updated. 282 The format of the flags/sequence byte for the original 283 COMPRESSED_UDP packet is shown here for reference: 285 +---+---+---+---+---+---+---+---+ 286 | 0 | 0 | 0 |dI | link sequence | 287 +---+---+---+---+---+---+---+---+ 289 The new definition of the flags/sequence byte plus an extension 290 flags byte for the COMPRESSED_UDP packet is as follows, where the 291 new F flag indicates the inclusion of the extension flags byte: 293 +---+---+---+---+---+---+---+---+ 294 | F | I |dT |dI | link sequence | 295 +---+---+---+---+---+---+---+---+ 296 : M : S : T : P : CC : (if F = 1) 297 +...+...+...+...+...............+ 299 dI = delta IP ID 300 dT = delta RTP timestamp 301 I = absolute IP ID 302 F = additional flags byte 303 M = marker bit 304 S = absolute RTP sequence number 305 T = absolute RTP timestamp 306 P = RTP payload type 307 CC = number of CSRC identifiers 309 When F=0, there is only one flags byte, and the only available flags 310 are: dI, dT and I. In this case the packet includes the full RTP 311 header. As in RFC 2508, if dI=0, the decompressor does not change 312 deltaI. If dT=0, the decompressor sets deltaT to 0. 314 Some example packet formats will illustrate the use of the new 315 flags. First, when F=0, the "traditional" COMPRESSED_UDP packet 316 which carries the full RTP header as part of the UDP data: 318 0 1 2 3 4 5 6 7 319 +...............................+ 320 : msb of session context ID : (if 16-bit CID) 321 +-------------------------------+ 322 | lsb of session context ID | 323 +---+---+---+---+---+---+---+---+ 324 |F=0| I |dT |dI | link sequence | 325 +---+---+---+---+---+---+---+---+ 326 : : 327 + UDP checksum + (if nonzero in context) 328 : : 329 +...............................+ 330 : : 331 + "RANDOM" fields + (if encapsulated) 332 : : 333 +...............................+ 334 : delta IPv4 ID : (if dI = 1) 335 +...............................+ 336 : delta RTP timestamp : (if dT = 1) 337 +...............................+ 338 : : 339 + IPv4 ID + (if I = 1) 340 : : 341 +...............................+ 342 | UDP data | 343 : (uncompressed RTP header) : 345 When F=1, there is an additional flags byte and the available flags 346 are: dI, dT, I, M, S, T, P, CC. In this case the packet does not 347 include the full RTP header, but includes selected fields from the 348 RTP header as specified by the flags. As in RFC 2508, if dI=0 the 349 decompressor does not change deltaI. However, in contrast to RFC 350 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the 351 context (DOES NOT set deltaT to 0). 353 An enhanced COMPRESSED_UDP packet is similar in contents and 354 behavior to a COMPRESSED_RTP packet, but it has more flag bits, some 355 of which correspond to absolute values for RTP header fields. 357 COMPRESSED_UDP with individual RTP fields, when F=1: 359 0 1 2 3 4 5 6 7 360 +...............................+ 361 : msb of session context ID : (if 16-bit CID) 362 +-------------------------------+ 363 | lsb of session context ID | 364 +---+---+---+---+---+---+---+---+ 365 |F=1| I |dT |dI | link sequence | 366 +---+---+---+---+---+---+---+---+ 367 | M | S | T | P | CC | 368 +---+---+---+---+---------------+ 369 : : 370 + UDP checksum + (if nonzero in context) 371 : : 372 +...............................+ 373 : : 374 : "RANDOM" fields : (if encapsulated) 375 : : 376 +...............................+ 377 : delta IPv4 ID : (if dI = 1) 378 +...............................+ 379 : delta RTP timestamp : (if dT = 1) 380 +...............................+ 381 : : 382 + IPv4 ID + (if I = 1) 383 : : 384 +...............................+ 385 : : 386 + RTP sequence number + (if S = 1) 387 : : 388 +...............................+ 389 : : 390 + + 391 : : 392 + RTP timestamp + (if T = 1) 393 : : 394 + + 395 : : 396 +...............................+ 397 : RTP payload type : (if P = 1) 398 +...............................+ 399 : : 400 : CSRC list : (if CC > 0) 401 : : 402 +...............................+ 403 : : 404 : RTP header extension : (if X set in context) 405 : : 406 +-------------------------------+ 407 | | 408 / RTP data / 409 / / 410 | | 411 +-------------------------------+ 412 : padding : (if P set in context) 413 +...............................+ 415 Usage for the enhanced COMPRESSED_UDP packet: 417 It is useful for the compressor to periodically refresh the state of 418 the decompressor to avoid having the decompressor send CONTEXT_STATE 419 messages in the case of unrecoverable packet loss. Using the flags 420 F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the 421 context parameters. 423 When compression is done over a lossy link with a long round trip 424 delay, we want to minimize context invalidation. If the delta values 425 are changing frequently, the context might get invalidated often. In 426 such cases the compressor MAY choose to always send absolute values 427 and never delta values, using COMPRESSED_UDP packets with the flags 428 F=1, and any of S, T, I as necessary. 430 2.2 CRTP Headers Checksum 432 RFC 2508, in Section 3.3.5, describes how the UDP checksum may be 433 used to validate header reconstruction periodically or when the 434 "twice" algorithm is used. When a UDP checksum is not present (has 435 value zero) in a stream, such validation would not be possible. To 436 cover that case, this enhanced CRTP provides an option whereby the 437 compressor MAY replace the null UDP checksum with a 16-bit headers 438 checksum (HDRCKSUM) which is subsequently removed by the 439 decompressor after validation. Note that this option is never used 440 with IPv6 since a null UDP checksum is not allowed. 442 A new flag C in the FULL_HEADER packet, as specified below, 443 indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP 444 packets sent in that context will have HDRCKSUM inserted. The 445 compressor MAY set the C flag when UDP packet carried in the 446 FULL_HEADER packet originally contained a checksum value of zero. 447 If the C flag is set, the FULL_HEADER packet itself MUST also have 448 the HDRCKSUM inserted. If a packet in the same stream subsequently 449 arrives at the compressor with a UDP checksum present, then a new 450 FULL_HEADER packet MUST be sent with the flag cleared to re- 451 establish the context. 453 The HDRCKSUM is calculated in the same way as a UDP checksum except 454 that it does not cover all of the UDP data. That is, the HDRCKSUM is 455 the 16-bit one's complement of the one's complement sum of the 456 pseudo-IP header (as defined for UDP), the UDP header, and the first 457 12 bytes of the UDP data which are assumed to hold the fixed part of 458 an RTP header. The extended part of the RTP header and the RTP data 459 will not be included in the HDRCKSUM. The HDRCKSUM is placed in the 460 COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would 461 have been. The decompressor MUST zero out the UDP checksum field in 462 the reconstructed packets. 464 For a non-RTP context, there may be fewer than 12 UDP data bytes 465 present. The IP and UDP headers can still be compressed into a 466 COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated 467 over the pseudo-IP header, the UDP header, and the UDP data bytes 468 that are present. If the number of data bytes is odd, then a zero 469 padding byte is appended for the purpose of calculating the 470 checksum, but not transmitted. 472 The HDRCKSUM does not validate the RTP data. If the link layer is 473 configured to deliver packets without checking for errors, then 474 errors in the RTP data will not be detected. Over such links, the 475 compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, 476 and the decompressor SHOULD validate each reconstructed packet to 477 make sure that at least the headers are correct. This ensures that 478 the packet will be delivered to the right destination. If only 479 HDRCKSUM is available, the RTP data will be delivered even if it 480 includes errors. This might be a desirable feature for applications 481 that can tolerate errors in the RTP data. The same holds for the 482 extended part of the RTP header. 484 Here is the format of the FULL_HEADER length fields with the new 485 flag C to indicate that a header checksum will be added in 486 COMPRESSED_UDP and COMPRESSED_RTP packets: 488 For 8-bit context ID: 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |0|1| Generation| CID | First length field 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | 0 |C| seq | Second length field 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 498 For 16-bit context ID: 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |1|1| Generation| 0 |C| seq | First length field 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | CID | Second length field 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 2.3 Achieving robust operation 510 Enhanced CRTP achieves robust operation by sending changes multiple 511 times to keep the compressor and decompressor in sync. This method 512 is characterized by a number "N" that represents the quality of the 513 link between the hosts. What it means is that the probability of 514 more than N adjacent packets getting lost on this link is small. For 515 every change in a full value or a delta value, if the compressor 516 includes the change in N+1 consecutive packets, then the 517 decompressor can keep its context state in sync with the compressor 518 using the "twice" algorithm so long as no more than N adjacent 519 packets are lost. 521 Since updates are repeated in N+1 packets, if at least one of these 522 N+1 update packets is received by the decompressor, both the full 523 and delta values in the context at the decompressor will get updated 524 and its context will stay synchronized with the context at the 525 compressor. We can conclude that as long as less than N+1 adjacent 526 packets are lost, the context at the decompressor is guaranteed to 527 be synchronized with the context at the compressor, and use of the 528 "twice" algorithm to recover from packet loss will successfully 529 update the context and restore the compressed packets. 531 The link sequence number cycles in 16 packets, so it's not always 532 clear how many packets were lost. For example, if the previous link 533 sequence number was 5 and the current number is 4, one possibility 534 is that 15 packets were lost, but another possibility is that due to 535 misordering packet 5 arrived before packet 4 and they are really 536 adjacent. If there is an interpretation of the link sequence numbers 537 that could be a gap of less than N+1, the "twice" algorithm may be 538 applied that many times and verified with the UDP checksum (or the 539 HDRCKSUM). 541 When more than N packets are lost, all of the repetitions of an 542 update might have been lost. The context state may then be different 543 at the compressor and decompressor. The decompressor can still try 544 to recover by making one or more guesses for how many packets were 545 lost and then applying the "twice" algorithm that many times. 546 However, since the IPv4 ID field is not included in the checksum, 547 this does not validate the IPv4 ID. 549 The conclusion is that for IPv4 if more than N packets were lost, 550 the decompressor SHOULD NOT try to recover using the "twice" 551 algorithm and instead SHOULD invalidate the context and send a 552 CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to 553 recover from packet loss by using the "twice" algorithm and 554 verifying the result with the UDP checksum. 556 It is up to the implementation to derive an appropriate N for a 557 link. The value is maintained independently for each context and is 558 not required to be the same for all contexts. When compressing a new 559 stream, the compressor sets a value of N for that context and sends 560 N+1 FULL_HEADER packets. The compressor MUST also repeat each 561 subsequent COMPRESSED_UDP update N+1 times. The value of N may be 562 changed for an existing context by sending a new sequence of 563 FULL_HEADER packets. 565 The decompressor learns the value of N by counting the number of 566 times the FULL_HEADER packet is repeated and storing the resulting 567 value in the corresponding context. If some of the FULL_HEADER 568 packets are lost, the decompressor may still be able to determine 569 the correct value of N by observing the change in the 4-bit sequence 570 number carried in the FULL_HEADER packets. Any inaccuracy in the 571 counting will lead the decompressor to assume a smaller value of N 572 than the compressor is sending. This is safe in that the only 573 negative consequence is that the decompressor might send a 574 CONTEXT_STATE packet when it was not really necessary to do so. In 575 response, the compressor will send FULL_HEADER packets again, 576 providing another opportunity for the decompressor to count the 577 correct N. 579 The sending of FULL_HEADER packets is also triggered by a change in 580 one of the fields held constant in the context, such as the IP TOS. 581 If such a change should occur while the compressor is in the middle 582 of sending the N+1 FULL_HEADER packets, then the compressor MUST 583 send N+1 FULL_HEADER packets after making the change. This could 584 cause the decompressor to receive more than N+1 FULL_HEADER packets 585 in a row with the result that it assumes a larger value for N than 586 is correct. That could lead to an undetected loss of context 587 synchronization. Therefore, the compressor MUST change the 588 "generation" number in the context and in the FULL_HEADER packet 589 when it begins sending the sequence of N+1 FULL_HEADER packets so 590 the decompressor can detect the new sequence. For IPv4, this is a 591 change in behavior relative to RFC 2508. 593 CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the 594 same sequence number for each context) to provide a similar measure 595 of robustness against packet loss. Here N can be the largest N of 596 all contexts included in the CONTEXT_STATE packet, or any number the 597 decompressor finds necessary in order to ensure robustness. 599 2.3.1 Examples 601 Here are some examples to demonstrate the robust operation of 602 enhanced CRTP using N+1 repetitions of updates. In this stream the 603 audio codec sends a sample every 10 milliseconds. The first 604 talkspurt is 1 second long. Then there are 2 seconds of silence, 605 then another talkspurt. We also assume in this first example that 606 the IPv4 ID field does not increment at a constant rate because the 607 host is generating other uncorrelated traffic streams at the same 608 time and therefore the delta IP ID changes for each packet. 610 In these examples, we will use some short notations: 612 FH FULL_HEADER 613 CR COMPRESSED_RTP 614 CU COMPRESSED_UDP 616 When operating on a link with low loss, we can just use 617 COMPRESSED_RTP packets in the basic CRTP method specified in RFC 618 2508. We might have the following packet sequence: 620 seq Time pkt updates and comments 621 # type 622 1 10 FH 623 2 20 CR dI dT=10 624 3 30 CR dI 625 4 40 CR dI 626 ... 627 100 1000 CR dI 629 101 3010 CR dI dT=2010 630 102 3020 CR dI dT=10 631 103 3030 CR dI 632 104 3040 CR dI 633 ... 635 In the above sequence, if a packet is lost we cannot recover 636 ("twice" will not work due to the unpredictable IP ID) and the 637 context must be invalidated. 639 Here is the same example using the enhanced CRTP method specified in 640 this document, when N=2. Note that the compressor only sends the 641 absolute IP ID (I) and not the delta IP ID (dI). 643 seq Time pkt CU flags updates and comments 644 # type F I dT dI M S T P 645 1 10 FH 646 2 20 FH repeat constant fields 647 3 30 FH repeat constant fields 648 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 649 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT 650 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT 651 7 70 CU 1 1 0 0 M 0 0 0 I 652 8 80 CU 1 1 0 0 M 0 0 0 I 653 ... 654 100 1000 CU 1 1 0 0 M 0 0 0 I 656 101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas 657 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T 658 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T 659 104 3040 CU 1 1 0 0 M 0 0 0 I 660 105 3050 CU 1 1 0 0 M 0 0 0 I 661 ... 663 This second example is the same sequence, but assuming the delta IP 664 ID is constant. First the basic CRTP for a lossless link: 666 seq Time pkt updates and comments 667 # type 668 1 10 FH 669 2 20 CR dI dT=10 670 3 30 CR 671 4 40 CR 672 ... 673 100 1000 CR 675 101 3010 CR dT=2010 676 102 3020 CR dT=10 677 103 3030 CR 678 104 3040 CR 679 ... 681 For the equivalent sequence in enhanced CRTP, the more efficient 682 COMPRESSED_RTP packet can still be used once the deltas are all 683 established: 685 seq Time pkt CU flags updates and comments 686 # type F I dT dI M S T P 687 1 10 FH 688 2 20 FH repeat constant fields 689 3 30 FH repeat constant fields 690 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 691 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates 692 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates 693 7 70 CR 694 8 80 CR 695 ... 696 100 1000 CR 698 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 699 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 700 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 701 104 3040 CR 702 105 3050 CR 703 ... 705 3. Negotiating usage of enhanced-CRTP 707 The use of IP/UDP/RTP compression (CRTP) over a particular link is 708 a function of the link-layer protocol. It is expected that 709 negotiation of the use of CRTP will be defined separately 710 for each link layer. 712 For link layers that already have defined a negotiation for the use 713 of CRTP as specified in RFC 2508, an extension to that negotiation 714 will be required to indicate use of the enhanced CRTP defined in 715 this document since the syntax of the existing packet formats has 716 been extended. 718 4. Security Considerations 720 Because encryption eliminates the redundancy that this compression 721 scheme tries to exploit, there is some inducement to forego 722 encryption in order to achieve operation over a low-bandwidth link. 723 However, for those cases where encryption of data and not headers is 724 satisfactory, RTP does specify an alternative encryption method in 725 which only the RTP payload is encrypted and the headers are left in 726 the clear. That would allow compression to still be applied. 728 A malfunctioning or malicious compressor could cause the 729 decompressor to reconstitute packets that do not match the original 730 packets but still have valid IP, UDP and RTP headers and possibly 731 even valid UDP check-sums. Such corruption may be detected with 732 end-to-end authentication and integrity mechanisms which will not be 733 affected by the compression. Constant portions of authentication 734 headers will be compressed as described in [IPHCOMP]. 736 No authentication is performed on the CONTEXT_STATE control packet 737 sent by this protocol. An attacker with access to the link between 738 the decompressor and compressor could inject false CONTEXT_STATE 739 packets and cause compression efficiency to be reduced, probably 740 resulting in congestion on the link. However, an attacker with 741 access to the link could also disrupt the traffic in many other 742 ways. 744 A potential denial-of-service threat exists when using compression 745 techniques that have non-uniform receiver-end computational load. 746 The attacker can inject pathological datagrams into the stream which 747 are complex to decompress and cause the receiver to be overloaded 748 and degrading processing of other streams. However, this 749 compression does not exhibit any significant non-uniformity. 751 5. Acknowledgements 753 The authors would like to thank Van Jacobson, co-author of RFC 2508, 754 and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and 755 Stephen Pink. The authors would also like to thank Dana Blair, 756 Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, 757 Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, and 758 Dan Wing. 760 6. References 762 Normative References 764 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 765 Low-Speed Serial Links", RFC2508, February 1999. 767 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, 768 "IP Header Compression", RFC2507, February 1999. 770 [IPCPHC] M. Engan, S. Casner, C. Bormann, T. Koren, 771 "IP Header Compression over PPP", 772 draft-koren-pppext-rfc2509bis-01.txt, February 2002. 774 [KEYW] S. Bradner, "Key words for use in RFCs to Indicate 775 Requirement Levels", RFC2119, BCP 14, March 1997. 777 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 778 "RTP: A Transport Protocol for Real-Time Applications", RFC1889, 779 January 1996. 781 Informative References 783 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 784 H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, 785 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 786 Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header 787 Compression (ROHC): Framework and four profiles: RTP, 788 UDP, ESP, and uncompressed", RFC 3095, July 2001. 790 7. Authors' Addresses 792 Tmima Koren 793 Cisco Systems, Inc. 794 170 West Tasman Drive 795 San Jose, CA 95134-1706 796 United States of America 798 Email: tmima@cisco.com 800 Stephen L. Casner 801 Packet Design 802 2465 Latham Street, Third Floor 803 Mountain View, CA 94040 804 United States of America 806 Email: casner@acm.org 808 John Geevarghese 809 Telseon Inc. 810 480 S. California 811 Palo Alto, CA 94306 812 United States of America 814 Email: geevjohn@hotmail.com 816 Bruce Thompson 817 Cisco Systems, Inc. 818 170 West Tasman Drive 819 San Jose, CA 95134-1706 820 United States of America 822 Email: brucet@cisco.com 824 Patrick Ruddy 825 Cisco Systems, Inc. 826 3rd Floor 827 96 Commercial Street 828 Leith, Edinburgh EH6 6LX 829 Scotland 831 Email: pruddy@cisco.com 833 8. Copyright 835 Copyright (C) The Internet Society 1999-2003. All Rights Reserved. 836 This document and translations of it may be copied and furnished to 837 others, and derivative works that comment on or otherwise explain it 838 or assist in its implementation may be prepared, copied, published 839 and distributed, in whole or in part, without restriction of any 840 kind, provided that the above copyright notice and this paragraph 841 are included on all such copies and derivative works. However, this 842 document itself may not be modified in any way, such as by removing 843 the copyright notice or references to the Internet Society or other 844 Internet organizations, except as needed for the purpose of 845 developing Internet standards in which case the procedures for 846 copyrights defined in the Internet Standards process must be 847 followed, or as required to translate it into languages other than 848 English. 850 The limited permissions granted above are perpetual and will not be 851 revoked by the Internet Society or its successors or assigns. 853 This document and the information contained herein is provided on an 854 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 855 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 856 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 857 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 858 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.