Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-avt-crtp-01.txt < prev next >

Wrap

Text File | 1996-11-27 | 37KB | 897 lines

Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT S. Casner / Precept Software draft-ietf-avt-crtp-01.txt V. Jacobson / LBNL November 25, 1996 Expires: 5/97 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). This draft updates draft-casner-jacobson-crtp-00.txt which was sent to the rem-conf list but was never officially posted as an Internet-Draft due to a mail los- sage that then left it out of date. At the Montreal IETF meeting in June 1996, this proposal was accepted as a work item of the the Audio/Video Transport working group, hence the draft name change. Expires May 1997 [Page 1] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 1. Introduction Since the Real-time Transport Protocol was published as an RFC [1], there has been growing interest in using RTP as one step to achieve interoperability among different implementations of network audio/video applications. However, there is also concern that the 12-byte RTP header is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Existing applications operating in this environment may use an application- specific protocol with a header of a few bytes that has reduced func- tionality relative to RTP.) Header size may be reduced through compression techniques as has been done with great success for TCP [2]. In this case, compression might be applied to the RTP header alone, on an end-to-end basis, or to the com- bination of IP, UDP and RTP headers on a link-by-link basis. Compress- ing the 40 bytes of combined headers together provides substantially more gain than compressing 12 bytes of RTP header alone because the resulting size is approximately the same (2-4 bytes) in either case. Compressing on a link-by-link basis also provides better performance because the delay and loss rate are lower. Therefore, the method defined here is for combined compression of IP, UDP and RTP headers on a link-by-link basis. This document defines a compression scheme that may be used with IPv4, IPv6 or packets encapsulated with more than one IP header, though the initial focus is on IPv4. It is intended that the IP/UDP/RTP compres- sion defined here will fit within and be referenced by the the more com- plete compression framework [3] specified by Mikael Degermark, et. al., which covers both IPv6 and IPv4 with TCP and non-TCP as two classes of transport above IP. IP/UDP/RTP would be extracted as a third class from the non-TCP class. 2. Assumptions and Tradeoffs The goal of this compression scheme is to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. It is motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. These links tend to provide full-duplex communication, so the protocol takes advantage of that fact, though this constraint could be removed. This specification does not address segmentation and preemption of large packets to reduce the delay across the slow link experienced by small real-time packets, except to identify in Section 4 some interactions between segmentation and compression that may occur. Segmentation schemes may be defined separately and used in conjunction with the Expires May 1997 [Page 2] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 compression defined here. It should be noted that implementation simplicity is an important factor to consider in evaluating the a compression scheme. Communications servers may need to support compression over perhaps as many as 100 dial-up modem lines using a single processor. Therefore, it may be appropriate to make some simplifications in the design at the expense of generality, or to produce a flexible design that is general but can be subsetted for simplicity. The next sections discuss some of the trade- offs listed here. 2.1. Simplex vs. Full Duplex In the absence of other constraints, a compression scheme that worked over simplex links would be preferred over one that did not. However, operation over a simplex link requires periodic refreshes with an uncompressed packet header to restore compression state in case of error. If an explicit error signal can be returned instead, the delay to recovery may be shortened substantially. The overhead in the no- error case is also reduced. Some UDP applications may require only sim- plex communication, but RTP applications will frequently require full duplex communication. The application may be 2-way, as in a telephone conversation, but even if data flows in only one direction there is a need for a return path to carry reception feedback in RTCP packets. This specification includes an error indication on the reverse path, however it would be possible to use a periodic refresh instead. When- ever the decompressor detected an error in a particular packet stream, it would simply discard all packets in that stream until an uncompressed header for was received for that stream, and then resume decompression. The penalty would be the potentially large number of packets discarded. 2.2. Segmentation and Layering Delay induced by the time required to send a large packet over the slow link is not a problem for one-way audio, for example, because the receiver can adapt to the variance in delay. However, for interactive conversations, minimizing the end-to-end delay is critical. Segmenta- tion of large, none-real-time packets to allow small real-time packets to be transmitted between segments can reduce the delay. This specification deals only with compression and assumes segmentation, if included, will be handled as a separate layer. It seems inappropri- ate to integrate segmentation and compression in such a way that the compression could not be used by itself in situations where segmentation was deemed unnecessary or impractical. Similarly, one would like to avoid any requirements for a reservation protocol. The compression scheme can be applied locally on the two ends of a link independent of Expires May 1997 [Page 3] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 any other mechanisms except for the requirements that the link layer provide some packet type codes, a packet length indication, and good error detection. Conversely, separately compressing the IP/UDP and RTP layers loses too much of the compression gain that is possible by treating them together. Crossing these protocol layer boundaries is appropriate because the same function is being applied across all layers. 3. The Compression Algorithm The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 [2]. Readers are referred to that RFC for more information on the underlying motivations and general principles of header compression. 3.1. The basic idea In TCP header compression, the first factor of two comes from the obser- vation that half of the bytes in the header remain constant over the life of the connection. After sending the uncompressed header once, these fields may be elided from the compressed headers that follow. The remaining compression comes from differential coding on the changing fields to reduce their size, and from eliminating the changing fields entirely for common cases by calculating the changes from the length of the packet. This length is indicated by the link-level protocol. For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order differ- ence was zero. The decompressor can reconstruct the original header without any loss of information. Just as TCP/IP header compression maintains shared state for multiple simultaneous TCP connections, this IP/UDP/RTP compression must maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. Because the RTP compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heurisic gives the wrong answer. This does require Expires May 1997 [Page 4] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 executing the compression algorithm for all UDP packets. Most implemen- tations will need to maintain a negative cache of packet streams (iden- tified by addresses and ports but not the SSRC field) that have failed to compress as RTP packets for some number of attempts. Failing to compress means that the fields that are expected to remain constant most of the time, such as the payload type field, keep changing. Even if the other fields remain constant, a packet stream with a constantly changing SSRC field must be entered in the negative cache to avoid consuming all of the available session contexts. When RTP compression fails, the IP and UDP headers may still be compressed. In order to communicate packets in the various uncompressed and compressed forms, this protocol depends upon the link layer being able to provide an indication of four packet types in addition to the packet types that indicate IPv4 and IPv6: FULL_HEADER - communicates the uncompressed IP header plus any fol- lowing headers and data to establish the uncompressed header state in the decompressor for a particular context. That context is identified by an 8-bit session context ID. In order to carry the context ID without expanding the size of the header, the ID replaces the low byte of the total length field in the IPv4 header or IPv6 base header. (The actual length may be inferred from the length provided by the link layer.) The FULL_HEADER packet type is part of the compression framework defined in [3], which describes compression of protocols other than UDP/RTP and encapsulation by multiple IP headers as indicated by the IPv4 protocol field or the IPv6 next header field. A generation number is carried in the FULL_HEADER for the COMPRESSED_NON_TCP packet type defined in [3]. The 4-bit sequence number defined in Section 3.3 of this document is carried in the Data field of the FULL_HEADER as defined in Sec- tion 5.3.2 and 12 of [3]. COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers as defined in [3] without compressing the IPv4 ID field. This takes one or two bytes more than the COMPRESSED_UDP form listed next, but may be more resilient to packet loss. This packet type can also carry in its Data field the 4-bit sequence number defined in Section 3.3. COMPRESSED_UDP - communicates the IP and UDP headers compressed to 6 or fewer bytes (often 2 if UDP checksums are disabled), followed by any subsequent headers (possibly RTP) in uncompressed form, plus data. This packet type is used when there are differences in the usually constant fields of the (potential) RTP header. It rede- fines the SSRC field of the session context. The format is shown in section 3.4. Expires May 1997 [Page 5] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 COMPRESSED_RTP - indicates that the RTP header is compressed along with the IP and UDP headers. The result may still be just two bytes. This packet type is used when the second-order difference is zero and also to communicate first-order differences as delta encodings. The format is shown in section 3.3. CONTEXT_STATE - indicates a special packet sent from the decompres- sor to the compressor to communicate a list of context IDs for which synchronization has or may have been lost. This packet is only sent across the single link so it requires no IP header. The format is shown in section 3.6. Assignment of numeric codes for these four packet types in the Point- to-Point Protocol [4] will be made by the Internet Assigned Numbers Authority. Section 13 of [3] specifies that the FULL_HEADER packet will share the IPv6 packet type and demultiplex based on the IP version field. 3.2. Header Compression for RTP Data Packets In the IPv4 header, only the total length, packet ID, and header check- sum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, changes in the packet ID will be transmitted. In the IPv6 base header, there is no packet ID nor header checksum and only the payload length field changes. In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check- sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated intact in order to preserve the lossless compression. Maintaining end-to-end error detection for applications that require it is an important princi- ple. In typical usage of the RTP header, the sequence number and the times- tamp will change from packet to packet. If packets are not lost or misordered, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for any additional packets in the frame. If each video frame occupies only one packet, but the video frames are generated at a con- stant rate, then again the change in the timestamp from frame to frame Expires May 1997 [Page 6] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 is constant. Note that in each of these cases the second-order differ- ence of the sequence number and timestamp fields is often zero. When that's not true, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the difference rather than the absolute value. The M bit will be set on the first packet of a talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce the compression significantly. Therefore, one bit in the compressed header will carry the M bit explicitly. If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes. 3.3. The protocol When the second-order difference of the RTP header is zero, all that need be communicated is a small sequence number to maintain synchroniza- tion and detect packet loss between the compressor and decompressor. Each context has its own separate sequence number space so that a single packet loss need only invalidate one context. To synchronize with the decompressor, the compressor inserts the current value of the sequence number into the Data field of the FULL_HEADER or COMPRESSED_NON_TCP packet whenever one of those is transmitted (see Sections 5.3.2 and 6 of [3]). When the second-order difference of the RTP header is not zero for some fields, the new first-order difference for just those fields is communi- cated using a compact encoding. The new first-order difference updates the uncompressed header in the decompressor's session context, and it is also stored explicitly in the context to be used for updating the field again on subsequent packets in which the second-order difference is zero. In practice, the only fields for which it is useful to store the first- order difference are the IPv4 ID field and the RTP timestamp. For the RTP sequence number field, the usual increment is 1. If the sequence number changes by other than 1, the difference must be communicated but does not set the expected difference for the next packet. Instead, the expected first-order difference remains fixed at 1 so that the differ- ence need not be explictly communicated on the next packet assuming it is in order, For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet is sent to refresh the state, the stored first- Expires May 1997 [Page 7] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 order difference is initialized to zero. If the timestamp is the same on the next packet (e.g., same video frame), then the second-order difference is zero. Otherwise, the difference between the timestamps of the two packets is transmitted as the new first-order difference. Similarly, since the IPv4 ID field frequently increments by one, the first-order difference for that field is initialized to one when the state is refreshed. Thereafter, whenever the first-order difference changes, it is transmitted and stored in the context. A bit mask will be used to indicate which fields have changed by other than the expected difference. In addition to the small link sequence number, the list of items to be conditionally communicated in the compressed IP/UDP/RTP header is as follows: I = IPv4 packet ID (always 0 if no IPv4 header) U = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp L = RTP CSRC count and list If 4 bits are needed for the link sequence number to get a reasonable probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into a sin- gle byte to go along with the context ID. It is not necessary to explicitly indicate the presence of the UDP checksum because a source will typically include checksums on all pack- ets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unencoded 16-bit checksum will be appended to the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet. Of the remaining items, the CSRC list may be the one least frequently used. Rather than dedicating a bit to indicate CSRC change, an unusual combination of the other bits may be used instead. This bit combination is denoted MSTI. If all four of the bits for the IP packet ID, RTP marker bit, RTP sequence number and RTP timestamp are set, this as a special case indicating an extended form of the compressed RTP header will follow. That header will include an additional byte containing the real values of the four bits plus the CC count. The CSRC list, of length indicated by the CC count, will be included as in the uncompressed header. The following diagram shows the compressed IP/UDP/RTP header with dotted lines indicating fields that are conditionally present. Expires May 1997 [Page 8] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +-------------------------------+ | session context | +---+---+---+---+---+---+---+---+ | M | S | T | I | sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (implicit) : : +...............................+ : M'| S'| T'| I'| CC : (if MSTI) +...............................+ : delta IPv4 ID : (if I or I') +...............................+ : delta RTP sequence : (if S or S') +...............................+ : delta RTP timestamp : (if T or T') +...............................+ : : : CSRC list : (if MSTI) : : : : +...............................+ : : : RTP header extension : (if X set in context) : : : : +---+---+---+---+---+---+---+---+ | RTP data | : : The delta fields are encoded with the following variable-length mapping for compactness: A change of zero through 127 is represented directly in one byte. If the most significant two bits of the byte are 10 or 11, this signals an extension to a two- or three-byte value, respectively. The least significant six bits of the first byte are combined, in decreasing order of significance, with the next one or two bytes to form a 14- or 22- bit value. The encoding of decimal values to hex bytes is shown in the following table: Expires May 1997 [Page 9] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 Decimal Hex 0 00 : : 127 7F 128 80 80 : : 16383 BF FF 16384 C0 40 00 : : 4194303 FF FF FF A change in the RTP timestamp value greater than 4194303 forces the RTP header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The context that must be maintained for each ID is as follows: o The full IP, UDP and RTP headers. Multiple IP headers may be included on encapsulated packets. o The first difference for the IPv4 ID field, initialized to 1. o The first difference for the RTP timestamp field, initialized to 0. o The current 4-bit sequence number. o The current generation number (see [3]). 3.4. Compression of non-RTP UDP Packets If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an uncompressed RTP header must be sent. This header may be carried in a COMPRESSED_UDP packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding fields are not present: Expires May 1997 [Page 10] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +-------------------------------+ | session context | +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | I | sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (implicit) : : +...............................+ : delta IPv4 ID : (if I) +---+---+---+---+---+---+---+---+ | UDP data | : (uncompressed RTP header) : Note that this constitutes a form of IP/UDP header compression different from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is to allow reaching the target of two bytes when UDP checksums are dis- abled, as IPv4 allows. The protocol in [3] does not use differential coding for UDP packets, so in the IPv4 case, two bytes of IP ID, and two bytes of UDP checksum if nonzero, would always be transmitted in addi- tion to two bytes of compression prefix. 3.5. Compression of RTCP Control Packets By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one could tailor separate compression schemes to be applied to RTP and RTCP packets. For RTCP, the compression could apply not only to the header but also the "data", that is, the contents of the different packet types. The numbers in Sender Report (SR) and Receiver Report (RR) RTCP packets would not compress well, but the text informa- tion in the Source Description (SDES) packets could be compressed down to a bit mask indicating each item that was present but compressed out (for timing purposes on the SDES NOTE item and to allow the end system to measure the average RTCP packet size for the interval calculation). However, in the compression scheme defined here, no compression will be done on RTCP packets for several reasons. Since the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all participants in a session will be no more than 5% of the session bandwidth, there is not much to be gained from RTCP compression. Compressing out the SDES items would require a significant increase in the shared state that must be stored for each context ID. And, in order to allow compression when SDES information for several sources was sent through an RTP "mixer", it would be necessary to maintain a separate RTCP session context for each Expires May 1997 [Page 11] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 SSRC identifier. In a session with more than 255 participants, this would cause perfect thrashing of the context cache even when only one participant was sending data. 3.6. Error Recovery Whenever the 4-bit sequence number for a particular context increments by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet, the decompressor must invalidate that context and send a CONTEXT_STATE packet back to the compressor indicating that the context has been invalidated. All packets for the invalid context must be dis- carded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for that context. When an error occurs on the link, the link layer will usually discard the packet that was damaged (if any), but may provide an indication of the error. Some time may elapse before another packet is delivered for the same context, and then that packet would have to be discarded by the decompressor when it is observed to be out of sequence, resulting in at least two packets lost. To allow faster recovery if the link does pro- vide an explicit error indication, the decompressor may optionally send a CONTEXT_STATE packet listing the last valid sequence number and gen- eration number for one or more recently active contexts. For a given context, if the compressor has sent no compressed packet with a higher sequence number, no corrective action is required. Otherwise, the compressor may mark the context invalid so that the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode. If the generation number does not match the current generation of the COMPRESSED_NON_TCP packet, then the FULL_HEADER must be sent. The format of the CONTEXT_STATE packet is shown in the following diagram. The first byte is a type code to allow the CONTEXT_STATE packet type to be shared for compression of other protocols in the IPv6 scheme [3]. For this IP/UDP/RTP compression scheme, the remainder of the CONTEXT_STATE packet is structured as a list of blocks to allow the state for multiple contexts to be indicated, preceded by a one-byte count of the number of blocks. Expires May 1997 [Page 12] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | compression type = 1 * | +---+---+---+---+---+---+---+---+ | context count | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | session context | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | generation | +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | session context | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | generation | +---+---+---+---+---+---+---+---+ * Other compression types to be defined in [3]. The bit labeled "I" is set to one for contexts that have been marked invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be transmitted. If the I bit is zero, the context state is advisory. Since the CONTEXT_STATE packet itself may be lost, retransmission of one or more blocks is allowed. It is expected that retransmission will be triggered only by receipt of another packet, but if the line is near idle, retransmission might be triggered by a relatively long timer (on the order of 1 second). If a CONTEXT_STATE block for a given context is retransmitted, it may cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended to refresh that context. In that case, the compressor may choose to ignore the error indication. In the case where UDP checksums are being transmitted, the decompressor could attempt to use the "twice" algorithm described in section 10.1 of [3]. In this algorithm, the delta is applied more than once on the assumption that the delta may have been the same on the missing packet(s) and the one subsequently received. For the scheme defined here, the difference in the 4-bit sequence number tells number of times the delta must be applied. Note, however, that there is a nontrivial risk of an incorrect positive indication. It may be advisable to Expires May 1997 [Page 13] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds. Some errors may not be detected, for example if 16 packets are lost in a row and the link level does not provide an error indication. In that case, the decompressor will generate packets that are not valid. If UDP checksums are being transmitted, the receiver will probably detect the invalid packets and discard them, but the receiver does not have any means to signal the decompressor. Therefore, it is recommended that the decompressor verify the UDP checksum periodically, perhaps one out of 16 packets. If an error is detected, the decompressor would invalidate the context and signal the compressor with a CONTEXT_STATE packet. 4. Interaction With Segmentation A segmentation scheme may be used in conjunction with RTP header compression to allow small, real-time packets to interrupt large, presumably non-real-time packets in order to reduce delay. It is assumed that the large packets bypass the compressor and decompressor since the interleaving would modify the sequencing of packets at the decompressor and cause the appearance of errors. Header compression should be less important for large packets since the overhead ratio is smaller. If some packets from an RTP session context are selected for segmenta- tion (perhaps based on size) and some are not, there is a possibility of re-ordering. This would reduce the compression efficiency because the large packets would appear as lost packets in the sequence space. How- ever, this should not cause more serious problems because the RTP sequence numbers should be reconstructed correctly and will allow the application to correct the ordering. Link errors detected by the segmentation scheme using its own sequencing information may be indicated to the compressor with an advisory CONTEXT_STATE message just as for link errors detected by the link layer itself. The context ID byte is placed first in the COMPRESSED_RTP header so that this byte may be shared with the segmentation layer if such sharing is feasible and has been negotiated. Since the context ID may have any value, it can be set to match context information from the segmentation layer. 5. Negotiating Compression The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol. It is expected that such negotiation will be defined separately for PPP [4], for example. Expires May 1997 [Page 14] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 6. Acknowledgments Several people have contributed to the design of this compression scheme and related problems. Scott Petrack initiated discussion of RTP header compression in the AVT working group at Los Angeles in March, 1996. Carsten Bormann has developed an overall achitecture for compression in combination with traffic control across a low-speed link, and made several specific contributions to the scheme described here. David Oran independently developed a note based on similar ideas, and suggested the use of PPP Multilink protocol for segmentation. Mikael Degermark has contributed advice on integration of this compression scheme with the IPv6 compression framework. 7. References: [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889. [2] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," RFC 1144. [3] M. Degermark, B. Nordgren, and S. Pink, "Header Compression for IPv6," work in progress. [4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548. 8. Security Considerations Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forgo encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method indicated by different payload types. 9. Authors' Addresses Stephen L. Casner Precept Software, Inc. 1072 Arastradero Road Palo Alto, CA 94304 United States EMail: casner@precept.com Van Jacobson MS 46a-1121 Expires May 1997 [Page 15] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States EMail: van@ee.lbl.gov Expires May 1997 [Page 16]