Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT Scott Petrack, IBM draft-petrack-crtp-00.txt 13 Jun 1996 Expires: December 1996 Compression of Headers in RTP Streams Status of this Memo This document is a draft of a part of an Internet-Draft. Internet-Drafts are working documents 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. Please see the acknowledgements at the end of this note for a special comment about the past, present, and future contributors to this note. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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 We analyze the requirement to compress the headers of RTP data streams. It is argued that there is a need to define two different compression schemes: an "interim solution" in which only RTP headers are compressed, and a "complete solution" which compresses the RTP/UDP/IP headers only across serial links. It is argued that the complete solution must include a new "guaranteed header compression service," if it is to be useful. The two solutions are described, along with a transition strategy which ensures that only the complete solution will be used when this is possible. 0. Introduction RTP [1] is finding acceptance as the standard means of transporting time related data over the Internet. Unfortunately, it is often impossible to use RTP/UDP/IP over a low-bitrate link - the header overhead leaves no room at all for data, or at the very least implies an unacceptable delay in the delivery of the data, because too much data must be lumped into a single packet. This paper gives two precise solutions. The central theme common to both is to compress the headers of the RTP data stream. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 2 The first solution involves compressing the RTP/UDP/IP headers within the stream. Enabling this requires specific additions to the current Internet infrastructure. We show that these are necessary to produce a "complete" solution. The modifications involved are similar in spirit to those of the general framework outlined in [2]. But we claim that something stronger is needed. Indeed, one can consider our solution as a definition of a new service to be provided in the context of Integrated Services. The second solution requires compressing only RTP itself, and can be implemented immediately. Because of its more limited nature, the second solution gives only interim relief, and it is intended that it will disappear seamlessly once the necessary Internet infrastructure has been established. That is, the interim solution has enough knowledge of the complete solution so that it can recognize the presence of the complete solution in the network, and turn itself off. We describe precisely the way in which the "interim solution" will transform into the "complete solution." This document is a submission to the IETF AVT working group. Although our solution does indeed have implications for other IETF working groups, the essential center of the work is a new algorithm for the compression of headers which include RTP headers, and how this header compression will fit into Internet infrastructure. The problem that is solved is how to enable the transport of real-time data that cannot be transported using the full RTP/UDP/IP headers as currently defined, when crossing a low bitrate link. 1. What's the matter? The smallest (and most common) size of an RTP header is 12 bytes [1]. When combined with UDP and IP, this implies at least a 40 byte per header overhead. There are many discussions available about the adverse effect of header overhead on interactivity in general. See [3] for a discussion of the particular problem of interactive telnet traffic. This was a primary motivation for TCP/IP header compression now in widespread use. When the traffic involved is interactive voice, then header compression ceases to be something extremely useful and becomes something absolutely necessary. Indeed, consider transmitting voice over a link of bandwidth b bytes/sec. Suppose that each there are: n bytes per each compressed voice-frame, f voice-frames/sec, h bytes/packet-header, and suppose one decides to lump together k voice frames into each network packet, in order to make it fit into the bandwidth b. A moment's thought shows that the bandwidth required is: b = (nk + h) * (f / k) bytes/sec; draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 3 Equivalently if we have b bandwidth available, then: k = (h * f)/(b-nf) voice-frames/network-packet. k is the measure of the delay in the voice communication, so this means that the delay will increase linearly with the total header size. There are at least two situations where the overhead is unnacceptable: a. low-bandwidth serial links The explosion of modem dial-up links to the Internet, (and the explosion in the desire of users to run audio and video over those links), makes it imperative that RTP scale down to links of bandwidth 14.4kbps and 28.8kbps. b. multiple RTP streams Some multimedia applications require several real-time streams to be running simultaneously, and each stream is a separate RTP session. Of course, "low" is a relative term: an ISDN link is certainly low bandwidth if one wishes to receive MBONE traffic. In general, the ideas here will be useful on sub-T1 links as in [2]. Also, we will restrict our attention to point-to-point links. But much of the discussion will be valid for other link technologies as well. We expect that the following technology will indeed be useful in other contexts where it makes sense. The current crop of Internet Telephone and Video applications are very sensitive to this problem. The extra 12 bytes/packet that RTP imposes has implied simply that these applications do not use RTP. Now one solution is to blame these horrible applications; but in fact with the currently common frame rate of one voice frame every 20 msecs, the 40 byte RTP/UDP/IP header per packet is already too large to send across a 14.4kbps link. The problem is a real one. Even if one excludes 14.4 kbps links (a terrible idea), one must consider the Internet version of Parkison's law: a bytestream expands to fill the bandwidth allotted to it. These internet communication applications will continue to develop, and they will continue to prefer to use the available bandwidth for tranporting their data rather than headers. Surely a decent respect for the prinicples of engineering requires that one try to compress the transport headers in a reasonable manner. Note that although RTP is not quite a third of the total RTP/UDP/IP bandwidth, it is indeed the difference between the possible and the impossible for these applications: one can send 36 bytes every 20msecs over a 14.4 link. The result is that most applications simply have not used RTP for encapsulating voice when there is a slow serial link between the two ends. They use some non- interoperable, proprietary scheme which sends at most one or two bytes in place of RTP's 12. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 4 Indeed, the problem of encapsulation overhead for real-time streams has given rise to at least two incompatible ITU-T standards for mixed voice and data over a serial link. These developments should worry anyone who shares the dream of IP and the Internet being used for multiple real-time and non-real time streams, some of which may or may not be synchronized. Excluding dial-up users from this game would be very sad, and extremely counter-productive. 2. Previous Suggestions RTP-only compression as a means of making serial-link Internet Telephony acceptable and interoperable was first proposed in [4]. It was suggested to compress only the RTP headers because not doing this is what made Internet Telephony impossible, and because anything else requires changes to the Internet infrastructure. It was immediately noticed [5] that one could combine RTP-only compression independently with the IPv6 UDP/IP compression of [6] to obtain a more useful service. And the already cited [2] argues that compressing RTP makes sense only in the framework of integrated services and compressing all the headers RTP/UDP/IP, together with a real-time multiplexing service for giving guranteed bandwidth or controlled load over a serial link. There is a fourth possibility, which is recently proposed by Casner and Jacobson in an upcoming (outcoming?) internet-draft [7], which is to perform RTP/UDP/IP similarly to the way one now performs TCP/IP header compression, according to RFC 1144. This would be simply a new elective protocol for compression of the RTP/UDP/IP headers across a point-to-point link, divorced from the ideas of Integrated Services. Indeed, it is explicitly stated in RFC 1144 that the two reasons not to compress UDP/IP traffic are that this traffic either lacks coherence from packet to packet (like DNS traffic), or that other higher level headers overwhelm the gain from UDP/IP compression (like RPC/NFS). These two arguments are clearly not valid for a typical RTP stream carrying interactive voice traffic, if one extends to compress the 40 byte RTP/UDP/IP header. In some sense these approaches are not contradictory and can co-exist. But obviously one should not waste valuble time defining and RTP-only compression scheme if indeed this is not useful, as [2] argues. And if independent RTP and IPv6 UDP/IP compression is enough, then there is no need to define a new RTP/UDP/IP standard, or to juggle the integration that is required by Integrated Services. 3. The Requirements To uncut this difficult knot, let us list the requirements at hand: a. It is a requirement to end the current chaos of non-interoperable (and non-multicast) audio and video applications. This chaos does more and more harm, and a concerted effort to tame these applications is necessary immediately. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 5 This means that an effort should be made to replace the one- (or few-) byte real time encapsulation used by current realtime non-RTP applications with some standard encapsulation which is not ruinous in overhead, and yet allows for multicast and other applications. It is certainly desireable, and probably required, that this encapsulation contain all the information that is contained in RTP. b. There is a requirement to allow these applications to become good citizens without changing the Internet Infrastructure, since these applications are not going to wait for RTP/UDP/IP compression to become widespread over dialup links, and certainly not for Integrated Services to become widely available over dial up links. This means that there must be some form of end-to-end RTP compression sanctioned. c. There is a requirement to ourselves, to truth, justice, and the Internet Way, to decide what the correct solution is, or would be, if there were no Internet Telephones that need relief right now. Such a complete solution contains the following elements: 1. no end-to-end hard state 2. special header compresssion only along hops which require it - i.e. only along "slow links." 3. along such slow links, since one must install state and new code, all headers should be compressed, not just RTP. 4. if an application requires that such compression take place, there should be some standard interface to allow it. It was argued in [2] that the PATH message of RSVP is the correct "standard interface." The word "requires" in c.4 demands special comment. The suggestions mentioned above in section 2 all have one important point in common: they assume that header compression is applied electively. Even the suggestion to use the PATH message was so that the application can inform the relevant links that compression is possible and desireable. We claim that there is an important difference between TCP/IP compression and the current situation of RTP applications over slow serial links: in the current situation, the application truly *requires* there to be header compression in order to make transmission worthwhile. It is not just a very useful - it is necessary. Using 40 byte RTP/UDP/IP headers over 14.4 modems implies delays which are measured in seconds. It is common practise to blame "the Internet" for such horrible performance, but some experimenting with two computers connected via a null modem cable (or better, a single brain connected to some paper and pencil) will convince one that a single low bandwidth link implies unacceptably large delays. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 6 For this reason, we are confronted with the need for a new service: the application must be able to ask the network for a guarantee that headers will be compressed along slow links. This is a different service from either of the two usual services of IntServ. A hard guarantee is required, but not of available bandwidth. Internet Phones can work just fine without bandwidth guarantees or even controlled load, but they cannot function with 40 byte RTP/UDP/IP headers. We have just argued that requirement c.4 implies the need for a new service of "guranteed header compression," at least across slow links. There is another more unpleasant reason that the complete solution should be careful to include giving an application the right to to require guranteed header compression, related to requirement b: The current non-RTP one-byte encapsulation schemes have the advantage that they Internet Telephone and Video applications to exist. If it can happen with the new standard that there is a slow link where RTP headers at least are not compressed, then the applications won't use the new standard. Certainly nothing is going to go to the trouble of using a new piece of internet infrastructure unless it gives them at least as good a service as it was getting with the old infrastructure. Only a "guaranteed header compression service" can give an application the piece of mind that it has now, when it uses a proprietary one-byte encapsulation. If the new extensions do not offer this much, then the internet telephone applications will at best agree among themselves on a new one or two-byte encapsulation. You might think that the guaranteed bandwidth service, when it becomes widely available, will suffice. This is unfortunately not the case. We have seen that the entire bandwidth of a slow serial link will not suffice if RTP/UDP/IP is used. In any case, it is preferable to offer a "header compression service" than to have all those applications use a guaranteed bandwidth service. The conclusion is that there is requirement for a new service, where the application can request a guarantee that the RTP/UDP/IP headers will be compressed over the slow links. More generally, one could make this service one whose parameters would be the the protocols of headers which for which one obtains a guarantee of compression, and the type of link over which the compression will occur. This service would be "XXX, YYY, ZZZ header compression over qqq-links." draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 7 The problem of dealing with header compression when using the usual guaranteed bandwidth service was mentioned in [2], but in the context of how to enable the routers to use the header compression to allow them to reserve bandwidth. This is not the same as a guaranteed header compression service, which is what is required here. A new service for "guaranteed bandwidth b for my data, which is being sent with protocols RTP/UDP/IP", although perhaps very useful, is stronger than what is required. There will be many situations where header compression is required but not guaranteed reserved bandwidth or even controlled load. Of course, one might define a "header compression requested" service to be the controlled-load analogue of the "header compression required" service considered here. There is one more feature left to consider, which we consider to be so obviously desireable as to be a fourth requirement: d. There must be a smooth transition from the end-to-end compression scheme into the new integrated service being proposed. Indeed, it should be possible for any application which can negotiate for end-to-end compression to be able to receive and understand from the network a message which instructs it "not to bother" to perform the end-to-end compression, but to send full RTP headers and let the network take care of the compression. If we can do this, there are very desireable advantages, apart from the obvious one of planning the obsolence of something disgusting. The application will be very happy to use the standard solution, because is it guaranteed that it will obtain improved performance as soon as the complete solution is in place. This is because the complete solution will compress RTP/UDP/IP and not just RTP. Also, it will allow forward compatibility with new applications which will not know about the interim end-to-end compression. We have now finished defining the task at hand. Let us list our conclusions: 1. We require an interim standard for end-to-end RTP compression. 2. We require a complete solution which uses RTP/UDP/IP compression only over the slow links. The complete solution will also include a new Integrated Service: "guaranteed RTP/UDP/IP header compression over slow serial links." 3. We require that the interim solution have enough knowledge of the complete solution that it will be able to recognize the presence of the complete solution in the network. When it does so, it will turn itself off. The rest of this paper is devoted to defining these two compression standards, "interim" and "complete." We shall also define an algorithm by which an implementation of the interim solution will detect the presence of the complete solution, and a QoS routing algorithm which is needed to deploy the new Integrated Service. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 13 Jun 1996 Page 8 Left to write up: 1. RTP/UDP/IP compression 2. algorithm for QoS routing for guaranteed header compression on slow links, links to ISSLOW (ISSLL) and IntServ. 3. RTP-only compression 4. RTCP and RTCP/UDP/IP compression 5. new RTCP message types to negotiate end-to-end RTP-only compression 6. transition from interim to complete solution: using port on local stack to request complete solution in interim-solution applications Acknowledgements: The author wishes to acknowledge useful discussions with and expressions of distaste from Steve Casner, Carsten Bormann, and Ed Ellesson. NB: Steve Casner and Van Jacobson have produced an algorithm for compression of the RTP/UDP/IP headers [7], which is being produced as a separate draft at present. The author here both hopes and plans that the two drafts will be merged into one. It is very important that no end-to-end compression scheme be allowed which does not already leave a hook for the complete solution. The two drafts are at present separate because time considerations precluded integration of any sort. References: [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: A Transport Protocol for real-time applications." RFC 1889 [2] Carsten Borman: "Providing integrated services over low-bitrate links" draft-bormann-issll-isslow-00-pre-3.txt (http://www-rn.informatik.uni-bremen.de/research/isslow.html, .txt, .ps) [3] Jacobson, "TCP/IP Compression for Low-Speed Serial Links." RFC 1144 [4] Petrack and Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression." contribution to mailing list rem-conf@es.net, Feb. 96 and talk at AVT working group, IETF March 96 [5] M. Degermark, private correspondence [6] Degermark et. al.: "Header Compression for IPv6" draft-degermark-ipv6-hc-00.txt [7] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links." draft-casner-jacobson-crtp-00.txt Author's Location Information Name=Scott Petrack Address=IBM Haifa Research Lab, Haifa 31905, Israel Email=petrack@vnet.ibm.com Telephone=+972 4 829 6290 Fax=+972 4 829 6112