idnits 2.17.1 draft-ietf-avt-crtp-enhance-00.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 1028 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2508]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 606 has weird spacing: '...e field must ...' == Line 661 has weird spacing: '...# Time pkt t...' == Line 681 has weird spacing: '...# Time pkt t...' == Line 710 has weird spacing: '...# Time pkt t...' == Line 724 has weird spacing: '...# Time pkt t...' == (2 more instances...) -- 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. 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: 'RFC2508' is mentioned on line 47, but not defined == Missing Reference: 'RFC2119' is mentioned on line 83, but not defined == Missing Reference: 'IPCPHP' is mentioned on line 804, but not defined == Unused Reference: 'CRTP' is defined on line 829, but no explicit reference was found in the text == Unused Reference: 'IPHCOMP' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'IPCPHC' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'KEYW' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 841, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2509 (ref. 'IPCPHC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 2 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 July 12, 2000 Stephen Casner 4 Expires March 2001 Packet Design 5 draft-ietf-avt-crtp-enhance-00.txt John Geevarghese 6 Telseon 7 Bruce Thompson 8 Dan Wing 9 Patrick Ruddy 10 Alex Tweedly 11 Cisco Systems 13 Enhancements to IP/UDP/RTP Header Compression 15 Status of this memo 17 This document is an Internet Draft and is in full conformance with all 18 provisions of Section 10 of RFC 2026. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its Areas, and 20 its Working Groups. Note that other groups may also distribute working 21 documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six months. 24 Internet Drafts may be updated, replaced, or obsolete by other 25 documents at any time. It is not appropriate to use Internet Drafts as 26 reference 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/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 being submitted as a possible work item to the IETF 35 Audio/Video Transport working group. To subscribe to the mailing list 36 send a message to rem-conf-request@es.net with the line "subscribe" in 37 the body of the message. Archives are available from: 38 ftp://ftp.es.net/pub/mail-archive/rem-conf 40 Copyright Notice 42 Copyright (C) The Internet Society (1999-2000). All Rights Reserved. 44 Abstract 46 This document describes enhancements to CRTP, the header compression 47 algorithm for RTP streams described in [RFC2508]. Each enhancement 48 addresses issues with RFC2508 in different deployment scenarios. Each 49 section below provides a description of the proposed enhancement, the 50 scenario where it is useful and the justification for its use. 52 Each of these enhancements could be evaluated separately. 53 The enhancements are applicable both for IPv4 and IPv6. 55 The IPCP option 'IP header compression' (described in RFC2509) is also 56 extended to negotiate using the CRTP enhancements. 58 1.0 Introduction 60 As IP/UDP/RTP header compression becomes more widely deployed, it is 61 being used in scenarios where a compressed link could extend over a 62 long physical distance and involve multiple layer-2 switching points. 63 An example of such a link is RTP transport over ATM AAL-5, where the 64 "link" would actually traverse through multiple layer-2 switching 65 points on the path from the CRTP transmitter (compressor) to the CRTP 66 receiver (decompressor). Another example is a wireless link. Such links 67 may experience significant packet loss and/or long round trip delays. 68 Contexts get invalidated due to packet loss, but the CRTP error 69 recovery mechanism using CONTEXT_STATE messages is not efficient due to 70 the long round trip delay. 72 In scenarios such as this, it is desirable to minimize context 73 invalidation. This document suggests several methods of error 74 prevention and recovery. The suggested enhancements make CRTP more 75 robust and resilient to packet loss, which in turn will reduce context 76 invalidation. 78 1.1 Specification of Requirements 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. CRTP Enhancements 86 2.1 The negative cache stream flag 88 Certain streams, known or suspected to not be RTP, can be placed in a 89 "negative cache" at the compressor, so only the IP and UDP headers are 90 compressed. It is beneficial to notify the decompressor that the 91 compressed stream is in the negative cache: for such streams the 92 context is shorter - there is no need to include the RTP header, and 93 all RTP-related calculations can be avoided. 95 In this enhancement, a new flag bit "N" is added to the FULL_HEADER 96 packet that initializes a context at the decompressor. The bit 97 occupied by the new flag was previously always set to zero. If the N 98 flag is set to 1, this indicates that no COMPRESSED_RTP packets will be 99 transmitted in this context. This flag is only an optimization and the 100 decompressor may choose to ignore it. 102 Format of the FULL_HEADER length fields with the negative cache flag: 104 For 8-bit context ID: 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 |0|1| Generation| CID | First length field 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | 0 |N| seq | Second length field 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream 114 For 16-bit context ID: 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 |1|1| Generation| 0 |N| seq | First length field 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N=1: negative cache stream 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | CID | Second length field 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 2.2 Reject a new compressed stream 126 In a point to point link the two nodes can agree on the number of 127 compressed sessions they are prepared to support for this link. In an 128 end-to-end scheme a host may have compressed sessions with many hosts 129 and eventually may run out of resources. When the end-to-end tunnel is 130 negotiated, the number of contexts needed may not be predictable. This 131 enhancement allows the negotiated number of contexts to be larger than 132 could be accommodated if many tunnels are established. Then, as 133 context resources are consumed, an attempt to set up a new context may 134 be rejected. 135 The compressor initiates a compression of a stream by sending a 136 FULL_HEADER packet. Currently if the decompressor has insufficient 137 resources to decompress the new stream, it can send a CONTEXT_STATE 138 packet to invalidate the newly compressed stream. The compressor does 139 not know the reason for the invalidation: usually this happens when the 140 decompressor gets out of synchronization due to packet loss. The 141 compressor will most likely reattempt to compress this stream by 142 sending another FULL_HEADER. 143 This enhancement specifies that the decompressor may reject the 144 compression of a stream by sending a REJECT message to the compressor. 145 A REJECT message tells the compressor to stop compressing this stream. 146 The REJECT message is a CONTEXT_STATE message with an additional flag: 148 Type code = 1 :CONTEXT_STATE for 8-bit CID streams 149 Type code = 2 : CONTEXT_STATE for16-bit CID streams 151 Here is the format of CONTEXT_STATE packets with REJECT flags: 153 0 1 2 3 4 5 6 7 154 +---+---+---+---+---+---+---+---+ 155 |Type code=1: CS, 8-bit CID | 156 +---+---+---+---+---+---+---+---+ 157 | context count | 158 +---+---+---+---+---+---+---+---+ 159 | session context ID | 160 +---+---+---+---+---+---+---+---+ 161 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 162 +---+---+---+---+---+---+---+---+ 163 | 0 | 0 | generation | 164 +---+---+---+---+---+---+---+---+ 165 . . . 166 +---+---+---+---+---+---+---+---+ 167 | session context ID | 168 +---+---+---+---+---+---+---+---+ 169 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 170 +---+---+---+---+---+---+---+---+ 171 | 0 | 0 | generation | 172 +---+---+---+---+---+---+---+---+ 174 0 1 2 3 4 5 6 7 175 +---+---+---+---+---+---+---+---+ 176 |Type code=2: CS, 16-bit CID| 177 +---+---+---+---+---+---+---+---+ 178 | context count | 179 +---+---+---+---+---+---+---+---+ 180 | | 181 + session context ID + 182 | | 183 +---+---+---+---+---+---+---+---+ 184 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 185 +---+---+---+---+---+---+---+---+ 186 | 0 | 0 | generation | 187 +---+---+---+---+---+---+---+---+ 188 . . . 189 +---+---+---+---+---+---+---+---+ 190 | | 191 + session context ID + 192 | | 193 +---+---+---+---+---+---+---+---+ 194 | 1 |R=1| 0 | 0 | sequence | R is the REJECT flag 195 +---+---+---+---+---+---+---+---+ 196 | 0 | 0 | generation | 197 +---+---+---+---+---+---+---+---+ 199 The session CID, sequence and generation are taken from the 200 FULL_HEADER. 202 The compressor may decide to wait for a while before attempting to 203 compress additional streams destined to the rejecting host. 205 2.3 Including IP ID in the UDP checksum 207 A UDP checksum can be used by the decompressor to verify validity of 208 the packet it reconstructed, especially when the 'twice' algorithm is 209 used. When the 'twice' algorithm was defined in RFC 2507 and 210 subsequently incorporated into RFC 2508, the fact that the IP ID field 211 is not included in the checksum was overlooked. Since the IP ID field 212 is conveyed with a delta value, accurate reconstruction of the IP ID 213 field cannot be verified using the current specifications. 215 This enhancement modifies the function of the UDP checksum to include 216 the IP ID value, but only between the compressor and decompressor. That 217 is, when a UDP checksum is present (nonzero), the compressor will 1's 218 complement subtract the IP ID value from the UDP checksum before 219 compression and the decompressor will 1's complement add the IP ID 220 value to the UDP checksum after any validation operations and before 221 delivering the packet further downstream. 223 2.4 CRTP Headers Checksum 225 When a UDP checksum is not present (has value zero) in a stream, the 226 compressor MAY replace it with a 16-bit headers checksum (HDRCKSUM). 227 The HDRCKSUM can be used to validate the IP ID and all the headers in 228 the reconstructed packet. Hence it can be used by the decompressor to 229 validate reconstructed packets when 'twice' is used, and to validate 230 every 16'th packet as recommended in RFC2508, Section 3.3.5. 232 A new flag in the FULL_HEADER packet, as specified below, indicates 233 when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in 234 that context will have HDRCKSUM inserted. If a packet in the same 235 stream subsequently arrives at the compressor with a UDP checksum 236 present, then a new FULL_HEADER packet must be sent with the flag 237 cleared to re-establish the context. 239 The HDRCKSUM is calculated in the same way as a UDP checksum, but 240 includes only the pseudo-IP header (as defined for UDP), the IP ID (as 241 in Section 2.3), the UDP header and for COMPRESSED_RTP packets, the 242 fixed part of the RTP header (first 12 bytes). The extended part of the 243 RTP header and the RTP data will not be included in the HDRCKSUM. The 244 HDRCKSUM is placed in the COMPRESSED_UDP or COMPRESSED_RTP packets 245 where a UDP checksum would have been. 246 The decompressor MUST zero out the UDP checksum field in the 247 reconstructed packets. 249 The HDRCKSUM does not validate the RTP data. If the link layer is 250 configured to deliver packets without checking for errors, errors in 251 the RTP data will not be detected. Over such links, the compressor 252 SHOULD add the HDRCKSUM if a UDP checksum is not present, and the 253 decompressor SHOULD validate each reconstructed packet to make sure 254 that at least the headers are correct. This ensures that the packet 255 will be delivered to the right destination. If only HDRCKSUM is 256 available, the RTP data will be delivered even if it includes errors. 257 This might be a desirable feature for applications that can tolerate 258 errors in the RTP data. Same holds for the extended part of the RTP 259 header. 261 Here is the format of the FULL_HEADER length fields with the new flag 262 that indicates that a header checksum will be added in COMPRESSED_UDP 263 and COMPRESSED_RTP packets: 265 For 8-bit context ID: 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |0|1| Generation| CID | First length field 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | 0 |C|N| seq | Second length field 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 275 For 16-bit context ID: 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |1|1| Generation| 0 |C|N| seq | First length field 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | CID | Second length field 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 2.5 Enhancement to COMPRESSED_UDP packet format (CU*) 287 The COMPRESSED_UDP packet includes the whole RTP header, so it can 288 restore all RTP-related parameters at the decompressor. It is also 289 specified to reset the delta RTP timestamp to zero and the delta RTP 290 sequence number to zero.It can also convey a new value for the delta IP 291 ID. 293 It is possible to accommodate some packet loss between the compressor 294 and decompressor using the "twice" algorithm in RFC 2508, but this 295 requires reliably communicating the absolute values and the deltas for 296 the differential fields. The reliability of communication of the 297 absolute values in the RTP header can be increased by sending a 298 COMPRESSED_UDP packet repeatedly, but this resets the delta timestamp. 299 RFC 2508 describes the format of COMPRESSED_UDP as being the same as 300 COMPRESSED_RTP except that the M, S and T bits are always 0 and the 301 corresponding delta fields are never included. This enhancement 302 changes that specification to say that the T bit may be nonzero to 303 indicate that the RTP timestamp delta is included explicitly rather 304 than being reset to zero. 306 Sometimes it is necessary to change just a few fields of the RTP 307 header. A second part of this enhancement adds more flag bits to the 308 COMPRESSED_UDP packet to select individual uncompressed fields of the 309 RTP header to be included in the packet. Since there are flag bits to 310 indicate inclusion of both delta values and absolute values, the flag 311 nomenclature is changed. The original S,T,I bits which indicate the 312 inclusion of deltas are renamed dS, dT, dI, and the inclusion of 313 absolute values is indicated by S,T,I. The M bit is absolute as 314 before. 316 The format of the flags/sequence byte for the original COMPRESSED_UDP 317 packet is shown here for reference: 319 +---+---+---+---+---+---+---+---+ 320 | 0 | 0 | 0 |dI | link sequence | 321 +---+---+---+---+---+---+---+---+ 323 The new definition of the flags/sequence byte plus an extension flags 324 byte is as follows, where the new F flag indicates the inclusion of the 325 extension flags byte: 327 +---+---+---+---+---+---+---+---+ 328 | F | I |dT |dI | link sequence | 329 +---+---+---+---+---+---+---+---+ 330 : M : S : T :pt : CC : (if F = 1) 331 +...+...+...+...+...............+ 333 dI = delta IP ID 334 dT = delta RTP timestamp 335 I = absolute IP ID 336 F = additional flags byte 337 M = marker bit 338 S = absolute RTP sequence number 339 T = absolute RTP timestamp 340 pt = RTP payload type 341 CC = number of CSRC identifiers 343 Some short notations: 345 FH FULL_HEADER 346 CR COMPRESSED_RTP 347 CR+ COMPRESSED_RTP with delta fields 348 CU COMPRESSED_UDP 349 CU* enhanced COMPRESSED_UDP 351 When F=0, there is only one flags byte, and the only available flags 352 are: dI, dT and I. 353 In this case the packet includes the full RTP header 354 If dT=0, the decompressor sets deltaT to 0 355 If dI=0, the decompressor sets deltaI to 1 357 Some example packet formats will illustrate the use of the new flags. 358 First, a 'traditional' COMPRESSED_UDP with full RTP header, when F=0: 360 0 1 2 3 4 5 6 7 361 +...............................+ 362 : msb of session context ID : (if 16-bit CID) 363 +-------------------------------+ 364 | lsb of session context ID | 365 +---+---+---+---+---+---+---+---+ 366 |F=0| I |dT |dI | link sequence | 367 +---+---+---+---+---+---+---+---+ 368 : : 369 + UDP checksum + (if nonzero in context) 370 : : 371 +...............................+ 372 : : 373 + "RANDOM" fields + (if encapsulated) 374 : : 375 +...............................+ 376 : delta IPv4 ID : (if dI = 1) 377 +...............................+ 378 : delta RTP timestamp : (if dT = 1) 379 +...............................+ 380 : : 381 + IPv4 ID + (if I = 1) 382 : : 383 +...............................+ 384 | UDP data | 385 : (uncompressed RTP header) : 387 When F=1, there is an additional flags byte and the available flags 388 are: dI, dT, I, M, S, T, pt, CC. In this case the packet does not 389 include the full RTP header, but includes selected fields from the RTP 390 header as specified by the flags. The delta values of the context are 391 not reset even if they are not specified in the packet: 392 If dT=0, the decompressor KEEPS THE CURRENT deltaT 393 (and DOES NOT set the deltaT to 0) 394 If dI=0, the decompressor KEEPS THE CURRENT deltaI 395 (and DOES NOT set the the deltaI to 1) 397 A CU* packet is similar in contents and behavior to a CR packet, but it 398 has more flag bits, some of which correspond to absolute values for RTP 399 header fields. 401 COMPRESSED_UDP with individual RTP fields, when F=1 : 403 0 1 2 3 4 5 6 7 404 +...............................+ 405 : msb of session context ID : (if 16-bit CID) 406 +-------------------------------+ 407 | lsb of session context ID | 408 +---+---+---+---+---+---+---+---+ 409 |F=1| I |dT |dI | link sequence | 410 +---+---+---+---+---+---+---+---+ 411 : M : S : T :pt : CC : 412 +...+...+...+...+...............+ 413 : : 414 + UDP checksum + (if nonzero in context) 415 : : 416 +...............................+ 417 : : 418 : "RANDOM" fields : (if encapsulated) 419 : : 420 +...............................+ 421 : delta IPv4 ID : (if dI = 1) 422 +...............................+ 423 : delta RTP timestamp : (if dT = 1) 424 +...............................+ 425 : : 426 + IPv4 ID + (if I = 1) 427 : : 428 +...............................+ 429 : : 430 + RTP sequence number + (if S = 1) 431 : : 432 +...............................+ 433 : : 434 + + 435 : : 436 + RTP timestamp + (if T = 1) 437 : : 438 + + 439 : : 440 +...............................+ 441 : RTP payload type : (if pt = 1) 442 +...............................+ 443 : : 444 : CSRC list : (if CC > 0) 445 : : 446 +...............................+ 447 : : 448 : RTP header extension : (if X set in context) 449 : : 450 +-------------------------------+ 451 | | 452 / RTP data / 453 / / 454 | | 455 +-------------------------------+ 456 : padding : (if P set in context) 457 +...............................+ 459 Usage for the CU* packet: 461 It is useful for the compressor to periodically refresh the state of 462 the decompressor to avoid having the decompressor send CONTEXT_STATE 463 messages in the case of unrecoverable packet loss. 464 Using the flags F=0 I dI dT, this CU* packet refreshes all the context 465 parameters. 467 When compression is done over a lossy link with a long round trip 468 delay, we want to minimize context invalidation. If the delta values 469 are changing frequently, the context might get invalidated often. In 470 such cases the compressor may choose to include absolute values in the 471 CRTP packets instead of delta values, using CU* packets with the flags: 472 F=1, and any of S, T, I as necessary. 474 2.6 Acknowledgement packet (ACK packet) 476 The ACK packet will be sent from decompressor to compressor to indicate 477 receipt of a compressed packet with the ACK'd RTP sequence number. 478 It's a CONTEXT_STATE packet with type codes 4 and 5. The ACK packet is 479 to be used in a separately negotiated mode of operation as described in 480 the next section. 482 Type code = 4 : ACK a packet of a context with 8-bit CID 483 Type code = 5 : ACK a packet of a context with 16-bit CID 485 The format for the ACK packet is: 487 0 1 2 3 4 5 6 7 488 +---+---+---+---+---+---+---+---+ 489 | Type code=4: ACK, 8-bit CID | 490 +---+---+---+---+---+---+---+---+ 491 | context count | 492 +---+---+---+---+---+---+---+---+ 493 | session context ID | 494 +---+---+---+---+---+---+---+---+ 496 | | 497 + RTP sequence number + 498 | | 499 +---+---+---+---+---+---+---+---+ 500 . . . 501 +---+---+---+---+---+---+---+---+ 502 | session context ID | 503 +---+---+---+---+---+---+---+---+ 505 | | 506 + RTP sequence number + 507 | | 508 +---+---+---+---+---+---+---+---+ 510 0 1 2 3 4 5 6 7 511 +---+---+---+---+---+---+---+---+ 512 | Type code=5: ACK, 16-bit CID | 513 +---+---+---+---+---+---+---+---+ 514 | context count | 515 +---+---+---+---+---+---+---+---+ 516 | | 517 + session context ID + 518 | | 519 +---+---+---+---+---+---+---+---+ 521 | | 522 + RTP sequence number + 523 | | 524 +---+---+---+---+---+---+---+---+ 525 . . . 526 +---+---+---+---+---+---+---+---+ 527 | | 528 + session context ID + 529 | | 530 +---+---+---+---+---+---+---+---+ 532 | | 533 + RTP sequence number + 534 | | 535 +---+---+---+---+---+---+---+---+ 537 2.6.1 CRTP operation in ACK mode 539 This mode of operation is optional and must be negotiated per link. 541 2.6.1.1 Description of the ACK mode 543 The ACK mode is a mode of operation in which the compressor and 544 decompressor continuously verify that their context states are 545 synchronized. The compressor repeatedly notifies the decompressor about 546 changes in the context state, until the decompressor acknowledges 547 reception of the changes by sending ACK packets to the decompressor. 548 This effort of synchronizing the context states helps minimize context 549 invalidation. 551 The context state shared between the compressor and decompressor 552 includes all the fields of the uncompressed headers and the first order 553 differences (delta fields) of the fields that change by a constant 554 value from packet to packet. Each field follows its known change 555 pattern: either stays constant or is incremented by its corresponding 556 delta field. Fields that follow their change pattern are compressed. 557 They are reconstructed by the decompresor from the context state at the 558 decompressor. Correct decompression of a packet depends on whether the 559 context state at the compressor when the packet is compressed and sent 560 is identical to the context state at the decompressor when that packet 561 is received and decompressed. 563 When a field changes in a way that is different from its change 564 pattern, the compressor assigns a new value to the field, and stores it 565 in the context state at the compressor side. The decompressor must be 566 informed about the change so that it can update the state on its side 567 to match the state at the compressor. The compressor notifies the 568 decompressor about such changes by including information about the 569 changed field in the compressed packet. (for example if dT was assigned 570 a new value, the compressor can send a CR+ packet that includes dT). 571 The context is not synchronized until the decompressor receives the 572 packet that includes the changed field and updates its state 573 accordingly. 575 The decompressor indicates reception of the change by sending an ACK 576 packet to the compressor. The ACK packet includes the RTP sequence 577 number of the packet that it is ACK'ing, so the compressor can identify 578 which packet is ACK'd. The compressor can't assume that the 579 decompressor received the change until the ACK packet is received. 581 Depending on the round trip delay of the link, the compressor might 582 have to send a few more packets before the ACK from the decompressor 583 arrives. In this case the compressor must repeat the change in all 584 subsequent packets. Reception of the ACK is an indication that the 585 decompressor updated its context with the changed value. Now that their 586 contexts are synchronized again, the compressor can stop including the 587 changed field in the compressed packets. 589 The decompressor must be able to recognize the repeat packets (the 590 packets that repeat the same change and were sent while the compressor 591 was waiting for the ACK packet). Those repeat packets don't require an 592 ACK. 594 If in the process of changing some fields additional changes are 595 required, the compressor will switch to send packets that include all 596 changes. The decompressor must ACK one of the packets that include all 597 the changes. 599 The compressor and decompressor must be in full agreement about which 600 packets must be ACK'd: packets that include changes are larger in size, 601 and if they are not ACK'd, the changes are repeated in all subsequent 602 packets, and bandwidth is wasted. 604 Let's summarize which packets require an ACK: 606 1. A Packet that assigns a value to any context state field must be 607 ACK'd. This includes FH and CU packets because they initialize 608 fields in the context state. 609 2. Repeat packets don't require an ACK 611 How are repeat packets identified? 613 A packet is considered to be a repeat packet if: 614 1. It updates the same fields as the previous packet 615 2. Each field is updated by a value that is equal to the one assigned 616 to this field in the previous packet plus the corresponding delta 617 for this field, when applicable. 619 2.6.1.2 The Random IP ID 621 The IP ID change pattern is to be incremented by dI. In some 622 implementations, the IP ID counter is shared across multiple streams, 623 so as a result of the varying mix of packets the increment for any 624 particular stream is not constant. When compressing such a stream, the 625 compressor must include in each packet either dI or I. It is 626 recommended to include I rather then dI because a loss of a packet that 627 includes a new delta value dI will invalidate the context. 628 According to the rules set above, each packet will have to be ACK'd. 630 To correct this we'll define a new change pattern for the IP ID: random 631 value. The IP ID assumes this change pattern when dI is set to be 0. 633 We add a rule to the ACK rules: 634 3. When the value of dI is 0, packets that update only the IP ID field 635 don't require an ACK. 637 And add to rule 2 of the repeat packet rules: 638 2. Each field is updated by a value that is equal to the one assigned 639 to this field in the previous packet plus the corresponding delta for 640 this field, when applicable. An exception to this rule is the IP ID 641 field: if the value of dI is 0, the IP ID may be assigned any value. 643 2.6.1.3 Implementation hints when using the ACK scheme 645 1. When a delta field is updated, add the matching absolute field too 646 (dT and T, dI and I). Loss of a packet that updates only the delta 647 value can easily cause context invalidation. 648 2. Set dI=0 when the IP ID is changing randomly, and include I in all 649 packets. 650 3. If you ACK'd a packet, but the number of repeat packets exceed your 651 estimate, ACK again (your previous ACK was probably lost) 653 Here is an example to demonstrate the usage of the ACK scheme. 654 In this stream the audio codec sends a sample every 10 msec 655 The first talk spurt is 1 second long. Then there are 2 seconds 656 silence, then another talk spurt. 658 When there is no loss on the link, we can use the following sequence: 659 (The deltaID is not constant so we send deltaID in each packet) 661 seq# Time pkt type 662 1 10 FH 663 2 20 CR+ dI dT=10 664 3 30 CR+ dI 665 4 40 CR+ dI 666 ... 667 100 1000 CR+ dI 669 101 3010 CR+ dI dT=2010 670 102 3020 CR+ dI dT=10 671 103 3030 CR+ dI 672 104 3040 CR+ dI 673 ... 675 In the above sequence if a packet is lost, we cannot recover ('twice' 676 will not work due to the random IP ID) and the context must be 677 invalidated. 679 Here is the same sequence using the ACK scheme(CU* is the enhanced CU): 681 seq# Time pkt type flags 682 1 10 FH FH must be ACK'd 683 2 20 FH repeat 684 ACK 1 685 3 30 CU* 1 I dT dI M 0 T 0 I T=30 dT=10 dI=0 dI,dT changed 686 (packet 3 was lost) (I and T sent too) 687 4 40 CU* 1 I dT dI M 0 T 0 I T=40 dT=10 dI=0 repeat 688 5 50 CU* 1 I dT dI M 0 T 0 I T=50 dT=10 dI=0 repeat 689 6 60 CU* 1 I dT dI M 0 T 0 I T=60 dT=10 dI=0 repeat 690 ACK 4 == got new dI=0 and dT=10 at T=40. 691 dI was set to 0, so I does not require an ACK. 692 No need to ACK 5 and 6: repeat packets 693 7 70 CU* 1 I 0 0 M 0 0 0 I 694 8 80 CU* 1 I 0 0 M 0 0 0 I 695 ... 696 100 1000 CU* 1 I 0 0 M 0 0 0 I 698 101 3010 CU* 1 I 0 0 M 0 T 0 I T=3010 T changed, keep 699 deltas! 700 102 3020 CU* 1 I 0 0 M 0 T 0 I T=3020 repeat 701 ACK 101 == got new T at sequence 101 702 No need to ACK packet 102 because 3010 + dT = 3020 703 If 101 is lost, 102 will be ACK'd 704 103 3030 CU* 1 I 0 0 M 0 0 0 I 705 104 3040 CU* 1 I 0 0 M 0 0 0 I 706 ... 708 The same sequences, when delta IP ID is constant: 710 seq# Time pkt type 711 1 10 FH 712 2 20 CR+ dI dT=10 713 3 30 CR 714 4 40 CR 715 ... 716 100 1000 CR 718 101 3010 CR+ dT=2010 719 102 3020 CR+ dT=10 720 103 3030 CR 721 104 3040 CR 722 ... 724 seq# Time pkt type flags 725 1 10 FH FH must be ACK'd 726 2 20 FH repeat 727 ACK 1 728 3 30 CU* 1 I dT dI M 0 T 0 I dI T=30 dT=10 dI,dT changed 729 (packet 3 was lost) (I and T sent 730 too) 731 4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 repeat 732 5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat 733 6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat 734 ACK 4 == got new dI and dT=10 at T=40. 735 No need to ACK 5 and 6: no changes 736 7 70 CR 737 8 80 CR 738 ... 739 100 1000 CR 741 101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas! 742 102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat 743 ACK 101 == got new T at sequence 101 744 No need to ACK packet 102 because 3010 + dT = 3020 745 If 101 is lost, 102 will be ACK'd 746 103 3030 CR 747 104 3040 CR 748 ... 750 2.7 Accept a new compressed stream 752 Lack of any feedback from the decompressor might indicate either that 753 everything goes well (the stream is decompressed successfully), or that 754 nothing goes well (the link is down, the decompressor is not 755 functioning, the decompressor is out of sync but there is no back 756 channel). The compressor initiates a compression of a stream by sending 757 a FULL_HEADER packet. This enhancement specifies that the decompressor 758 SHOULD acknowledge the reception of the FULL_HEADER packet by sending 759 an ACK packet (see 2.6) with the sequence number of the FULL_HEADER 760 packet. This reassures the compressor that the new compressed stream is 761 received and decompressed. It also indicates that a back channel 762 exists. 764 2.8 CRTP operation in 'N' mode 766 This scheme is similar to the ACK scheme in that the compressor tries 767 to keep the decompressor in sync by sending changes multiple times. The 768 'N' is a number that represents the quality of the link between the 769 hosts, and it means that the probability of more than 'N' adjacent 770 packets getting lost on this link is small. For every change in a base 771 value or a delta value, if the compressor includes the change in N+1 772 consecutive packets, there is a very good chance that the compressor 773 and decompressor can stay in sync using the 'twice' algorithm. 774 CONTEXT_STATE packets should also be repeated N+1 times (using the same 775 sequence number). 776 It is up to the implementation to find a scheme to derive an 777 appropriate N for a link. 779 This scheme may be used at any time and does not require negotiation. 781 Here is the same example in 'N' mode, when N=2 and deltaID is constant: 783 seq# Time pkt type flags 784 1 10 FH 785 2 20 FH repeat constant fields 786 3 30 FH repeat constant fields 787 4 40 CU* 1 I dT dI M 0 T 0 I dI T=40 dT=10 788 5 50 CU* 1 I dT dI M 0 T 0 I dI T=50 dT=10 repeat delta 789 6 60 CU* 1 I dT dI M 0 T 0 I dI T=60 dT=10 repeat delta 790 7 70 CR 791 8 80 CR 792 ... 793 100 1000 CR 795 101 3010 CU* 1 0 0 0 M 0 T 0 T=3010 T changed, keep deltas! 796 102 3020 CU* 1 0 0 0 M 0 T 0 T=3020 repeat updated T 797 103 3030 CU* 1 0 0 0 M 0 T 0 T=3030 repeat updated T 798 104 3040 CR 799 105 3050 CR 800 ... 802 2.9 Negotiating usage of enhanced-CRTP and ACK scheme 804 RFC 2509 [IPCPHP] specifies how the use of CRTP is negotiated on PPP 805 links using the IP Compression Protocol option of IPCP: 807 IPCP option 2: IP compression protocol 808 protocol 0x61 indicates RFC 2507 header compression 809 sub-option 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and 810 CONTEXT_STATE as specified in RFC 2508 812 For the enhancements defined in this document, two new sub-options are 813 added: 815 sub-option 2 (length=2) : enables use of CRTP with 816 enhancements 2.1 - 2.5 and 2.7 817 sub-option 3 (length=2) : enables use of CRTP with 818 enhancements 2.1 - 2.7 (ACK scheme) 820 3. Acknowledgements 821 The authors would like to thank Van Jacobson, co-author of RFC2508, 822 and the authors of RFC2507, Mikael Degermark, Bjorn Nordgren, and 823 Stephen Pink. The authors would also like to thank Dana Blair, Francois 824 Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik 825 Tatipamula, Mike Thomas, and Herb Wildfeuer. 827 4. References 829 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 830 Low-Speed Serial Links", RFC2508, February 1999. 832 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, 833 "IP Header Compression", RFC2507, February 1999. 835 [IPCPHC] M. Engan, S. Casner, C. Bormann, 836 "IP Header Compression over PPP", RFC2509, February 1999. 838 [KEYW] S. Bradner, "Key words for use in RFCs to Indicate 839 Requirement Levels", RFC2119, BCP 14, March 1997. 841 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 842 "RTP: A Transport Protocol for Real-Time Applications", RFC1889, 843 January 1996. 845 5. Authors' Addresses 847 Tmima Koren 848 Cisco Systems, Inc. 849 170 West Tasman Drive 850 San Jose, CA 95134-1706 851 United States of America 853 Email: tmima@cisco.com 855 Stephen L. Casner 856 Packet Design, Inc. 857 66 Willow Place 858 Menlo Park, CA 94025 859 United States of America 861 Email: casner@acm.org 863 John Geevarghese 864 Telseon Inc, 865 480 S. California 866 Palo-Alto, CA-94306 868 Email: geevjohn@hotmail.com 870 Bruce Thompson 871 Cisco Systems, Inc. 872 170 West Tasman Drive 873 San Jose, CA 95134-1706 874 United States of America 876 Email: brucet@cisco.com 878 Dan Wing 879 Cisco Systems, Inc. 880 170 West Tasman Drive 881 San Jose, CA 95134-1706 882 United States of America 884 Email: dwing@cisco.com 886 Patrick Ruddy 887 Cisco Systems, Inc. 888 3rd Floor, 96 Commercial Street 889 Edinburgh 890 EH6 6LX 891 Scotland 893 Email: pruddy@cisco.com 895 Alex Tweedly 896 Cisco Systems, Inc. 897 3 The Square, Stockley Park 898 Uxbridge, Middlesex 899 UB11 1BN 900 United Kingdom 902 Email: agt@cisco.com 904 6. Copyright 905 Copyright (C) The Internet Society 1999-2000. All Rights Reserved. 906 This document and translations of it may be copied and furnished to 907 others, and derivative works that comment on or otherwise explain it or 908 assist in its implementation may be prepared, copied, published and 909 distributed, in whole or in part, without restriction of any kind, 910 provided that the above copyright notice and this paragraph are 911 included on all such copies and derivative works. However, this 912 document itself may not be modified in any way, such as by removing the 913 copyright notice or references to the Internet Society or other 914 Internet organizations, except as needed for the purpose of developing 915 Internet standards in which case the procedures for copyrights defined 916 in the Internet Standards process must be followed, or as required to 917 translate it into languages other than English. 919 The limited permissions granted above are perpetual and will not be 920 revoked by the Internet Society or its successors or assigns. 922 This document and the information contained herein is provided on an 923 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 924 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 925 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 926 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 927 FITNESS FOR A PARTICULAR PURPOSE. 929 Casner, Geevarghese, Koren, Ruddy, Thompson, Tweedly, Wing 930 Expires Feb 2001