idnits 2.17.1 draft-ietf-avt-crtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 -- 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 25, 1996) is 10006 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) -- Missing reference section? '1' on line 651 looks like a reference -- Missing reference section? '2' on line 654 looks like a reference -- Missing reference section? '3' on line 657 looks like a reference -- Missing reference section? '4' on line 660 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio/Video Transport Working Group 3 INTERNET-DRAFT S. Casner / Precept Software 4 draft-ietf-avt-crtp-01.txt V. Jacobson / LBNL 5 November 25, 1996 6 Expires: 5/97 8 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document describes a method for compressing the headers of 33 IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. 34 In many cases, all three headers can be compressed to 2-4 bytes. 36 Comments are solicited and should be addressed to the working group 37 mailing list rem-conf@es.net and/or the author(s). This draft updates 38 draft-casner-jacobson-crtp-00.txt which was sent to the rem-conf list 39 but was never officially posted as an Internet-Draft due to a mail los- 40 sage that then left it out of date. At the Montreal IETF meeting in 41 June 1996, this proposal was accepted as a work item of the the 42 Audio/Video Transport working group, hence the draft name change. 44 1. Introduction 46 Since the Real-time Transport Protocol was published as an RFC [1], 47 there has been growing interest in using RTP as one step to achieve 48 interoperability among different implementations of network audio/video 49 applications. However, there is also concern that the 12-byte RTP 50 header is too large an overhead for 20-byte payloads when operating over 51 low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Existing 52 applications operating in this environment may use an application- 53 specific protocol with a header of a few bytes that has reduced func- 54 tionality relative to RTP.) 56 Header size may be reduced through compression techniques as has been 57 done with great success for TCP [2]. In this case, compression might be 58 applied to the RTP header alone, on an end-to-end basis, or to the com- 59 bination of IP, UDP and RTP headers on a link-by-link basis. Compress- 60 ing the 40 bytes of combined headers together provides substantially 61 more gain than compressing 12 bytes of RTP header alone because the 62 resulting size is approximately the same (2-4 bytes) in either case. 63 Compressing on a link-by-link basis also provides better performance 64 because the delay and loss rate are lower. Therefore, the method 65 defined here is for combined compression of IP, UDP and RTP headers on a 66 link-by-link basis. 68 This document defines a compression scheme that may be used with IPv4, 69 IPv6 or packets encapsulated with more than one IP header, though the 70 initial focus is on IPv4. It is intended that the IP/UDP/RTP compres- 71 sion defined here will fit within and be referenced by the the more com- 72 plete compression framework [3] specified by Mikael Degermark, et. al., 73 which covers both IPv6 and IPv4 with TCP and non-TCP as two classes of 74 transport above IP. IP/UDP/RTP would be extracted as a third class from 75 the non-TCP class. 77 2. Assumptions and Tradeoffs 79 The goal of this compression scheme is to reduce the IP/UDP/RTP headers 80 to two bytes for most packets in the case where no UDP checksums are 81 being sent, or four bytes with checksums. It is motivated primarily by 82 the specific problem of sending audio and video over 14.4 and 28.8 83 dialup modems. These links tend to provide full-duplex communication, 84 so the protocol takes advantage of that fact, though this constraint 85 could be removed. 87 This specification does not address segmentation and preemption of large 88 packets to reduce the delay across the slow link experienced by small 89 real-time packets, except to identify in Section 4 some interactions 90 between segmentation and compression that may occur. Segmentation 91 schemes may be defined separately and used in conjunction with the 92 compression defined here. 94 It should be noted that implementation simplicity is an important factor 95 to consider in evaluating the a compression scheme. Communications 96 servers may need to support compression over perhaps as many as 100 97 dial-up modem lines using a single processor. Therefore, it may be 98 appropriate to make some simplifications in the design at the expense of 99 generality, or to produce a flexible design that is general but can be 100 subsetted for simplicity. The next sections discuss some of the trade- 101 offs listed here. 103 2.1. Simplex vs. Full Duplex 105 In the absence of other constraints, a compression scheme that worked 106 over simplex links would be preferred over one that did not. However, 107 operation over a simplex link requires periodic refreshes with an 108 uncompressed packet header to restore compression state in case of 109 error. If an explicit error signal can be returned instead, the delay 110 to recovery may be shortened substantially. The overhead in the no- 111 error case is also reduced. Some UDP applications may require only sim- 112 plex communication, but RTP applications will frequently require full 113 duplex communication. The application may be 2-way, as in a telephone 114 conversation, but even if data flows in only one direction there is a 115 need for a return path to carry reception feedback in RTCP packets. 117 This specification includes an error indication on the reverse path, 118 however it would be possible to use a periodic refresh instead. When- 119 ever the decompressor detected an error in a particular packet stream, 120 it would simply discard all packets in that stream until an uncompressed 121 header for was received for that stream, and then resume decompression. 122 The penalty would be the potentially large number of packets discarded. 124 2.2. Segmentation and Layering 126 Delay induced by the time required to send a large packet over the slow 127 link is not a problem for one-way audio, for example, because the 128 receiver can adapt to the variance in delay. However, for interactive 129 conversations, minimizing the end-to-end delay is critical. Segmenta- 130 tion of large, none-real-time packets to allow small real-time packets 131 to be transmitted between segments can reduce the delay. 133 This specification deals only with compression and assumes segmentation, 134 if included, will be handled as a separate layer. It seems inappropri- 135 ate to integrate segmentation and compression in such a way that the 136 compression could not be used by itself in situations where segmentation 137 was deemed unnecessary or impractical. Similarly, one would like to 138 avoid any requirements for a reservation protocol. The compression 139 scheme can be applied locally on the two ends of a link independent of 140 any other mechanisms except for the requirements that the link layer 141 provide some packet type codes, a packet length indication, and good 142 error detection. 144 Conversely, separately compressing the IP/UDP and RTP layers loses too 145 much of the compression gain that is possible by treating them together. 146 Crossing these protocol layer boundaries is appropriate because the same 147 function is being applied across all layers. 149 3. The Compression Algorithm 151 The compression algorithm defined in this document draws heavily upon 152 the design of TCP/IP header compression as described in RFC 1144 [2]. 153 Readers are referred to that RFC for more information on the underlying 154 motivations and general principles of header compression. 156 3.1. The basic idea 158 In TCP header compression, the first factor of two comes from the obser- 159 vation that half of the bytes in the header remain constant over the 160 life of the connection. After sending the uncompressed header once, 161 these fields may be elided from the compressed headers that follow. The 162 remaining compression comes from differential coding on the changing 163 fields to reduce their size, and from eliminating the changing fields 164 entirely for common cases by calculating the changes from the length of 165 the packet. This length is indicated by the link-level protocol. 167 For RTP header compression, some of the same techniques may be applied. 168 However, the big gain comes from the observation that although several 169 fields change in every packet, the difference from packet to packet is 170 often constant and therefore the second-order difference is zero. By 171 maintaining both the uncompressed header and the first-order differences 172 in the session state shared between the compressor and decompressor, all 173 that must be communicated is an indication that the second-order differ- 174 ence was zero. The decompressor can reconstruct the original header 175 without any loss of information. 177 Just as TCP/IP header compression maintains shared state for multiple 178 simultaneous TCP connections, this IP/UDP/RTP compression must maintain 179 state for multiple session contexts. A session context is defined by 180 the combination of the IP source and destination addresses, the UDP 181 source and destination ports, and the RTP SSRC field. 183 Because the RTP compression is lossless, it may be applied to any UDP 184 traffic that benefits from it. Most likely, the only packets that will 185 benefit are RTP packets, but it is acceptable to use heuristics to 186 determine whether or not the packet is an RTP packet because no harm is 187 done if the heurisic gives the wrong answer. This does require 188 executing the compression algorithm for all UDP packets. Most implemen- 189 tations will need to maintain a negative cache of packet streams (iden- 190 tified by addresses and ports but not the SSRC field) that have failed 191 to compress as RTP packets for some number of attempts. Failing to 192 compress means that the fields that are expected to remain constant most 193 of the time, such as the payload type field, keep changing. Even if the 194 other fields remain constant, a packet stream with a constantly changing 195 SSRC field must be entered in the negative cache to avoid consuming all 196 of the available session contexts. When RTP compression fails, the IP 197 and UDP headers may still be compressed. 199 In order to communicate packets in the various uncompressed and 200 compressed forms, this protocol depends upon the link layer being able 201 to provide an indication of four packet types in addition to the packet 202 types that indicate IPv4 and IPv6: 204 FULL_HEADER - communicates the uncompressed IP header plus any fol- 205 lowing headers and data to establish the uncompressed header state 206 in the decompressor for a particular context. That context is 207 identified by an 8-bit session context ID. In order to carry the 208 context ID without expanding the size of the header, the ID 209 replaces the low byte of the total length field in the IPv4 header 210 or IPv6 base header. (The actual length may be inferred from the 211 length provided by the link layer.) The FULL_HEADER packet type is 212 part of the compression framework defined in [3], which describes 213 compression of protocols other than UDP/RTP and encapsulation by 214 multiple IP headers as indicated by the IPv4 protocol field or the 215 IPv6 next header field. A generation number is carried in the 216 FULL_HEADER for the COMPRESSED_NON_TCP packet type defined in [3]. 217 The 4-bit sequence number defined in Section 3.3 of this document 218 is carried in the Data field of the FULL_HEADER as defined in Sec- 219 tion 5.3.2 and 12 of [3]. 221 COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers 222 as defined in [3] without compressing the IPv4 ID field. This 223 takes one or two bytes more than the COMPRESSED_UDP form listed 224 next, but may be more resilient to packet loss. This packet type 225 can also carry in its Data field the 4-bit sequence number defined 226 in Section 3.3. 228 COMPRESSED_UDP - communicates the IP and UDP headers compressed to 229 6 or fewer bytes (often 2 if UDP checksums are disabled), followed 230 by any subsequent headers (possibly RTP) in uncompressed form, plus 231 data. This packet type is used when there are differences in the 232 usually constant fields of the (potential) RTP header. It rede- 233 fines the SSRC field of the session context. The format is shown 234 in section 3.4. 236 COMPRESSED_RTP - indicates that the RTP header is compressed along 237 with the IP and UDP headers. The result may still be just two 238 bytes. This packet type is used when the second-order difference 239 is zero and also to communicate first-order differences as delta 240 encodings. The format is shown in section 3.3. 242 CONTEXT_STATE - indicates a special packet sent from the decompres- 243 sor to the compressor to communicate a list of context IDs for 244 which synchronization has or may have been lost. This packet is 245 only sent across the single link so it requires no IP header. The 246 format is shown in section 3.6. 248 Assignment of numeric codes for these four packet types in the Point- 249 to-Point Protocol [4] will be made by the Internet Assigned Numbers 250 Authority. Section 13 of [3] specifies that the FULL_HEADER packet will 251 share the IPv6 packet type and demultiplex based on the IP version 252 field. 254 3.2. Header Compression for RTP Data Packets 256 In the IPv4 header, only the total length, packet ID, and header check- 257 sum fields will normally change. The total length is redundant with the 258 length provided by the link layer, and since this compression scheme 259 must depend upon the link layer to provide good error detection (e.g., 260 PPP's CRC), the header checksum may also be elided. This leaves only 261 the packet ID, which, assuming no IP fragmentation, would not need to be 262 communicated. However, in order to maintain lossless compression, 263 changes in the packet ID will be transmitted. In the IPv6 base header, 264 there is no packet ID nor header checksum and only the payload length 265 field changes. 267 In the UDP header, the length field is redundant with the IP total 268 length field and the length indicated by the link layer. The UDP check- 269 sum field will be a constant zero if the source elects not to generate 270 UDP checksums. Otherwise, the checksum must be communicated intact in 271 order to preserve the lossless compression. Maintaining end-to-end 272 error detection for applications that require it is an important princi- 273 ple. 275 In typical usage of the RTP header, the sequence number and the times- 276 tamp will change from packet to packet. If packets are not lost or 277 misordered, the sequence number will increment by one for each packet. 278 For audio packets of constant duration, the timestamp will increment by 279 the number of sample periods conveyed in each packet. For video, the 280 timestamp will change on the first packet of each frame, but then stay 281 constant for any additional packets in the frame. If each video frame 282 occupies only one packet, but the video frames are generated at a con- 283 stant rate, then again the change in the timestamp from frame to frame 284 is constant. Note that in each of these cases the second-order differ- 285 ence of the sequence number and timestamp fields is often zero. When 286 that's not true, the magnitude of the change is usually much smaller 287 than the full number of bits in the field, so the size can be reduced by 288 encoding the difference rather than the absolute value. 290 The M bit will be set on the first packet of a talkspurt and the last 291 packet of a video frame. If it were treated as a constant field such 292 that each change required sending the full RTP header, this would reduce 293 the compression significantly. Therefore, one bit in the compressed 294 header will carry the M bit explicitly. 296 If the packets are flowing through an RTP mixer, most commonly for 297 audio, then the CSRC list and CC count will also change. However, the 298 CSRC list will typically remain constant during a talkspurt or longer, 299 so it need be sent only when it changes. 301 3.3. The protocol 303 When the second-order difference of the RTP header is zero, all that 304 need be communicated is a small sequence number to maintain synchroniza- 305 tion and detect packet loss between the compressor and decompressor. 306 Each context has its own separate sequence number space so that a single 307 packet loss need only invalidate one context. To synchronize with the 308 decompressor, the compressor inserts the current value of the sequence 309 number into the Data field of the FULL_HEADER or COMPRESSED_NON_TCP 310 packet whenever one of those is transmitted (see Sections 5.3.2 and 6 of 311 [3]). 313 When the second-order difference of the RTP header is not zero for some 314 fields, the new first-order difference for just those fields is communi- 315 cated using a compact encoding. The new first-order difference updates 316 the uncompressed header in the decompressor's session context, and it is 317 also stored explicitly in the context to be used for updating the field 318 again on subsequent packets in which the second-order difference is 319 zero. 321 In practice, the only fields for which it is useful to store the first- 322 order difference are the IPv4 ID field and the RTP timestamp. For the 323 RTP sequence number field, the usual increment is 1. If the sequence 324 number changes by other than 1, the difference must be communicated but 325 does not set the expected difference for the next packet. Instead, the 326 expected first-order difference remains fixed at 1 so that the differ- 327 ence need not be explictly communicated on the next packet assuming it 328 is in order, 330 For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or 331 COMPRESSED_UDP packet is sent to refresh the state, the stored first- 332 order difference is initialized to zero. If the timestamp is the same 333 on the next packet (e.g., same video frame), then the second-order 334 difference is zero. Otherwise, the difference between the timestamps of 335 the two packets is transmitted as the new first-order difference. 337 Similarly, since the IPv4 ID field frequently increments by one, the 338 first-order difference for that field is initialized to one when the 339 state is refreshed. Thereafter, whenever the first-order difference 340 changes, it is transmitted and stored in the context. 342 A bit mask will be used to indicate which fields have changed by other 343 than the expected difference. In addition to the small link sequence 344 number, the list of items to be conditionally communicated in the 345 compressed IP/UDP/RTP header is as follows: 347 I = IPv4 packet ID (always 0 if no IPv4 header) 348 U = UDP checksum 349 M = RTP marker bit 350 S = RTP sequence number 351 T = RTP timestamp 352 L = RTP CSRC count and list 354 If 4 bits are needed for the link sequence number to get a reasonable 355 probability of loss detection, there are too few bits remaining to 356 assign one bit to each of these items and still fit them all into a sin- 357 gle byte to go along with the context ID. 359 It is not necessary to explicitly indicate the presence of the UDP 360 checksum because a source will typically include checksums on all pack- 361 ets of a session or none of them. When the session state is initialized 362 with an uncompressed header, if there is a nonzero checksum present, an 363 unencoded 16-bit checksum will be appended to the compressed header in 364 all subsequent packets until this setting is changed by sending another 365 uncompressed packet. 367 Of the remaining items, the CSRC list may be the one least frequently 368 used. Rather than dedicating a bit to indicate CSRC change, an unusual 369 combination of the other bits may be used instead. This bit combination 370 is denoted MSTI. If all four of the bits for the IP packet ID, RTP 371 marker bit, RTP sequence number and RTP timestamp are set, this as a 372 special case indicating an extended form of the compressed RTP header 373 will follow. That header will include an additional byte containing the 374 real values of the four bits plus the CC count. The CSRC list, of 375 length indicated by the CC count, will be included as in the 376 uncompressed header. 378 The following diagram shows the compressed IP/UDP/RTP header with dotted 379 lines indicating fields that are conditionally present. 381 0 1 2 3 4 5 6 7 382 +-------------------------------+ 383 | session context | 384 +---+---+---+---+---+---+---+---+ 385 | M | S | T | I | sequence | 386 +---+---+---+---+---+---+---+---+ 387 : : 388 + UDP checksum + (implicit) 389 : : 390 +...............................+ 391 : M'| S'| T'| I'| CC : (if MSTI) 392 +...............................+ 393 : delta IPv4 ID : (if I or I') 394 +...............................+ 395 : delta RTP sequence : (if S or S') 396 +...............................+ 397 : delta RTP timestamp : (if T or T') 398 +...............................+ 399 : : 400 : CSRC list : (if MSTI) 401 : : 402 : : 403 +...............................+ 404 : : 405 : RTP header extension : (if X set in context) 406 : : 407 : : 408 +---+---+---+---+---+---+---+---+ 409 | RTP data | 410 : : 412 The delta fields are encoded with the following variable-length mapping 413 for compactness: A change of zero through 127 is represented directly 414 in one byte. If the most significant two bits of the byte are 10 or 11, 415 this signals an extension to a two- or three-byte value, respectively. 416 The least significant six bits of the first byte are combined, in 417 decreasing order of significance, with the next one or two bytes to form 418 a 14- or 22- bit value. The encoding of decimal values to hex bytes is 419 shown in the following table: 421 Decimal Hex 423 0 00 424 : : 425 127 7F 426 128 80 80 427 : : 428 16383 BF FF 429 16384 C0 40 00 430 : : 431 4194303 FF FF FF 433 A change in the RTP timestamp value greater than 4194303 forces the RTP 434 header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP 435 or COMPRESSED_UDP packet type. 437 The context that must be maintained for each ID is as follows: 439 o The full IP, UDP and RTP headers. Multiple IP headers may be 440 included on encapsulated packets. 441 o The first difference for the IPv4 ID field, initialized to 1. 442 o The first difference for the RTP timestamp field, initialized to 0. 443 o The current 4-bit sequence number. 444 o The current generation number (see [3]). 446 3.4. Compression of non-RTP UDP Packets 448 If there is a change in any of the fields of the RTP header that are 449 normally constant (such as the payload type field), then an uncompressed 450 RTP header must be sent. This header may be carried in a COMPRESSED_UDP 451 packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has 452 the same format as the COMPRESSED_RTP packet except that the M, S and T 453 bits are always 0 and the corresponding fields are not present: 455 0 1 2 3 4 5 6 7 456 +-------------------------------+ 457 | session context | 458 +---+---+---+---+---+---+---+---+ 459 | 0 | 0 | 0 | I | sequence | 460 +---+---+---+---+---+---+---+---+ 461 : : 462 + UDP checksum + (implicit) 463 : : 464 +...............................+ 465 : delta IPv4 ID : (if I) 466 +---+---+---+---+---+---+---+---+ 467 | UDP data | 468 : (uncompressed RTP header) : 470 Note that this constitutes a form of IP/UDP header compression different 471 from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is 472 to allow reaching the target of two bytes when UDP checksums are dis- 473 abled, as IPv4 allows. The protocol in [3] does not use differential 474 coding for UDP packets, so in the IPv4 case, two bytes of IP ID, and two 475 bytes of UDP checksum if nonzero, would always be transmitted in addi- 476 tion to two bytes of compression prefix. 478 3.5. Compression of RTCP Control Packets 480 By relying on the RTP convention that data is carried on an even port 481 number and the corresponding RTCP packets are carried on the next higher 482 (odd) port number, one could tailor separate compression schemes to be 483 applied to RTP and RTCP packets. For RTCP, the compression could apply 484 not only to the header but also the "data", that is, the contents of the 485 different packet types. The numbers in Sender Report (SR) and Receiver 486 Report (RR) RTCP packets would not compress well, but the text informa- 487 tion in the Source Description (SDES) packets could be compressed down 488 to a bit mask indicating each item that was present but compressed out 489 (for timing purposes on the SDES NOTE item and to allow the end system 490 to measure the average RTCP packet size for the interval calculation). 492 However, in the compression scheme defined here, no compression will be 493 done on RTCP packets for several reasons. Since the RTP protocol 494 specification suggests that the RTCP packet interval be scaled so that 495 the aggregate RTCP bandwidth used by all participants in a session will 496 be no more than 5% of the session bandwidth, there is not much to be 497 gained from RTCP compression. Compressing out the SDES items would 498 require a significant increase in the shared state that must be stored 499 for each context ID. And, in order to allow compression when SDES 500 information for several sources was sent through an RTP "mixer", it 501 would be necessary to maintain a separate RTCP session context for each 502 SSRC identifier. In a session with more than 255 participants, this 503 would cause perfect thrashing of the context cache even when only one 504 participant was sending data. 506 3.6. Error Recovery 508 Whenever the 4-bit sequence number for a particular context increments 509 by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP 510 packet, the decompressor must invalidate that context and send a 511 CONTEXT_STATE packet back to the compressor indicating that the context 512 has been invalidated. All packets for the invalid context must be dis- 513 carded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for 514 that context. 516 When an error occurs on the link, the link layer will usually discard 517 the packet that was damaged (if any), but may provide an indication of 518 the error. Some time may elapse before another packet is delivered for 519 the same context, and then that packet would have to be discarded by the 520 decompressor when it is observed to be out of sequence, resulting in at 521 least two packets lost. To allow faster recovery if the link does pro- 522 vide an explicit error indication, the decompressor may optionally send 523 a CONTEXT_STATE packet listing the last valid sequence number and gen- 524 eration number for one or more recently active contexts. For a given 525 context, if the compressor has sent no compressed packet with a higher 526 sequence number, no corrective action is required. Otherwise, the 527 compressor may mark the context invalid so that the next packet is sent 528 in FULL_HEADER or COMPRESSED_NON_TCP mode. If the generation number 529 does not match the current generation of the COMPRESSED_NON_TCP packet, 530 then the FULL_HEADER must be sent. 532 The format of the CONTEXT_STATE packet is shown in the following 533 diagram. The first byte is a type code to allow the CONTEXT_STATE 534 packet type to be shared for compression of other protocols in the IPv6 535 scheme [3]. For this IP/UDP/RTP compression scheme, the remainder of 536 the CONTEXT_STATE packet is structured as a list of blocks to allow the 537 state for multiple contexts to be indicated, preceded by a one-byte 538 count of the number of blocks. 540 0 1 2 3 4 5 6 7 541 +---+---+---+---+---+---+---+---+ 542 | compression type = 1 * | 543 +---+---+---+---+---+---+---+---+ 544 | context count | 545 +---+---+---+---+---+---+---+---+ 546 +---+---+---+---+---+---+---+---+ 547 | session context | 548 +---+---+---+---+---+---+---+---+ 549 | I | 0 | 0 | 0 | sequence | 550 +---+---+---+---+---+---+---+---+ 551 | 0 | generation | 552 +---+---+---+---+---+---+---+---+ 553 ... 554 +---+---+---+---+---+---+---+---+ 555 | session context | 556 +---+---+---+---+---+---+---+---+ 557 | I | 0 | 0 | 0 | sequence | 558 +---+---+---+---+---+---+---+---+ 559 | 0 | generation | 560 +---+---+---+---+---+---+---+---+ 562 * Other compression types to be defined in [3]. 564 The bit labeled "I" is set to one for contexts that have been marked 565 invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be 566 transmitted. If the I bit is zero, the context state is advisory. 568 Since the CONTEXT_STATE packet itself may be lost, retransmission of one 569 or more blocks is allowed. It is expected that retransmission will be 570 triggered only by receipt of another packet, but if the line is near 571 idle, retransmission might be triggered by a relatively long timer (on 572 the order of 1 second). 574 If a CONTEXT_STATE block for a given context is retransmitted, it may 575 cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended 576 to refresh that context. In that case, the compressor may choose to 577 ignore the error indication. 579 In the case where UDP checksums are being transmitted, the decompressor 580 could attempt to use the "twice" algorithm described in section 10.1 of 581 [3]. In this algorithm, the delta is applied more than once on the 582 assumption that the delta may have been the same on the missing 583 packet(s) and the one subsequently received. For the scheme defined 584 here, the difference in the 4-bit sequence number tells number of times 585 the delta must be applied. Note, however, that there is a nontrivial 586 risk of an incorrect positive indication. It may be advisable to 587 request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the "twice" 588 algorithm succeeds. 590 Some errors may not be detected, for example if 16 packets are lost in a 591 row and the link level does not provide an error indication. In that 592 case, the decompressor will generate packets that are not valid. If UDP 593 checksums are being transmitted, the receiver will probably detect the 594 invalid packets and discard them, but the receiver does not have any 595 means to signal the decompressor. Therefore, it is recommended that the 596 decompressor verify the UDP checksum periodically, perhaps one out of 16 597 packets. If an error is detected, the decompressor would invalidate the 598 context and signal the compressor with a CONTEXT_STATE packet. 600 4. Interaction With Segmentation 602 A segmentation scheme may be used in conjunction with RTP header 603 compression to allow small, real-time packets to interrupt large, 604 presumably non-real-time packets in order to reduce delay. It is 605 assumed that the large packets bypass the compressor and decompressor 606 since the interleaving would modify the sequencing of packets at the 607 decompressor and cause the appearance of errors. Header compression 608 should be less important for large packets since the overhead ratio is 609 smaller. 611 If some packets from an RTP session context are selected for segmenta- 612 tion (perhaps based on size) and some are not, there is a possibility of 613 re-ordering. This would reduce the compression efficiency because the 614 large packets would appear as lost packets in the sequence space. How- 615 ever, this should not cause more serious problems because the RTP 616 sequence numbers should be reconstructed correctly and will allow the 617 application to correct the ordering. 619 Link errors detected by the segmentation scheme using its own sequencing 620 information may be indicated to the compressor with an advisory 621 CONTEXT_STATE message just as for link errors detected by the link layer 622 itself. 624 The context ID byte is placed first in the COMPRESSED_RTP header so that 625 this byte may be shared with the segmentation layer if such sharing is 626 feasible and has been negotiated. Since the context ID may have any 627 value, it can be set to match context information from the segmentation 628 layer. 630 5. Negotiating Compression 632 The use of IP/UDP/RTP compression over a particular link is a function 633 of the link-layer protocol. It is expected that such negotiation will 634 be defined separately for PPP [4], for example. 636 6. Acknowledgments 638 Several people have contributed to the design of this compression scheme 639 and related problems. Scott Petrack initiated discussion of RTP header 640 compression in the AVT working group at Los Angeles in March, 1996. 641 Carsten Bormann has developed an overall achitecture for compression in 642 combination with traffic control across a low-speed link, and made 643 several specific contributions to the scheme described here. David Oran 644 independently developed a note based on similar ideas, and suggested the 645 use of PPP Multilink protocol for segmentation. Mikael Degermark has 646 contributed advice on integration of this compression scheme with the 647 IPv6 compression framework. 649 7. References: 651 [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 652 A Transport Protocol for real-time applications," RFC 1889. 654 [2] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," 655 RFC 1144. 657 [3] M. Degermark, B. Nordgren, and S. Pink, "Header Compression for 658 IPv6," work in progress. 660 [4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548. 662 8. Security Considerations 664 Because encryption eliminates the redundancy that this compression 665 scheme tries to exploit, there is some inducement to forgo encryption in 666 order to achieve operation over a low-bandwidth link. However, for 667 those cases where encryption of data and not headers is satisfactory, 668 RTP does specify an alternative encryption method indicated by different 669 payload types. 671 9. Authors' Addresses 673 Stephen L. Casner 674 Precept Software, Inc. 675 1072 Arastradero Road 676 Palo Alto, CA 94304 677 United States 678 EMail: casner@precept.com 680 Van Jacobson 681 MS 46a-1121 682 Lawrence Berkeley National Laboratory 683 Berkeley, CA 94720 684 United States 685 EMail: van@ee.lbl.gov