Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT D. Putzolu / Intel Corporation draft-putzolu-heuristic-00.txt November 21, 1997 Expires: 5/98 Heuristics for utilizing ISSL Mechanisms for A/V Streams Over Low Bandwidth Links in the absence of Announcement Protocols Status of this Memo This document is 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. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as an Informational RFC for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before May 1998. Distribution of this draft is unlimited. 1. Abstract The ISSLOW subgroup of the ISSL working group has defined a set of mechanisms for providing integrated services over low bandwidth links [1]. These mechanisms rely on an announcement protocol (typically RSVP [2]) to determine which streams require other than best-effort service and to determine what level and type of service to provide for such streams. It is anticipated that at least some of the mechanisms defined by the ISSLOW subgroup, specifically Compressed RTP [3] (CRTP) [4] and Multi-Channel Multi-Link PPP (MCML) [5], will be available well before RSVP has been widely deployed. Given the proliferation of applications streaming audio and video using the mechanisms defined in the AVT working group (e.g., RTP), a means of utilizing these mechanisms in the absence of an Putzolu Expires May 1998 [Page 1] Internet Draft draft-putzolu-heuristic-00.txt November 1997 announcement protocol would be beneficial. Such means have been proposed in [6], but they require changes to applications so as to be able to indicate the need for special treatment. This document describes a set of heuristics for use with the mechanisms defined in the ISSLOW subgroup that provide an enhanced degree of service for audio/video streaming applications without requiring that changes be made to applications. The approach taken is to provide a default set of heuristics that implementations of MCML and CRTP can use to provide enhanced service over PPP links for audio and video streams without requiring any application or infrastructure changes. 2. Introduction The Multi-Class extension to Multi-Link PPP (MCML) specifies a set of classes that may be applied to the links of a ML-PPP bundle. These classes are used to provide a means of differentiating streams that require a particular quality of service (QoS) over the PPP link. Using MCML, one line (or more) can be assigned for best-effort traffic, and the remaining links can be used to provide an enhanced quality of service such as controlled load or guaranteed service, as specified in [7]. The Internet draft documents on the subject which are being developed in the ISSLOW subgroup specify that an announcement protocol such as RSVP should be used to determine which streams should be assigned to each MCML class. RSVP or another announcement protocol are also be used to determine what level and type of QoS to assign to each class. Applications that generate real time multimedia flows are one of the primary candidates for benefiting from the QoS mechanisms defined in the ISSLOW subgroup. The streams associated with such applications have very tight latency and jitter requirements that are often violated when traversing low bandwidth links such as POTS modems. Furthermore, it is common for such links to simultaneously be used for both multimedia (audio/video RTP) and data (TCP) streams. This scenario is termed simultaneous AV and data (SAVD). SAVD often results in all available bandwidth being consumed by TCP streams, resulting in delivery of audio/video streams with unacceptable levels of loss and jitter. RSVP and other announcement protocols have not yet been fully deployed across intranets and the Internet. This raises two significant issues in using the mechanisms defined in the ISSLOW subgroup to enhance the quality of multimedia streaming. The first issue is one of determining which streams traversing a PPP link are being used to carry multimedia data in the absence of an announcement protocol. Once such a determination has been made, a second issue arises as to what level of QoS to assign to these multimedia streams in order to ensure that latency, loss, and jitter requirements are met. Putzolu Expires May 1998 [Page 2] Internet Draft draft-putzolu-heuristic-00.txt November 1997 3. A/V Stream Detection and Class Assignment Determining what streams over a PPP link are audio or video is a relatively straightforward task as long as it can be assumed that such streams are being transmitted in a standards-based manner. Most audio and video streams use the RTP standard for transport. RTP, in turn, is typically carried over UDP/IP. Finally, audio and video streams in RTP are typically carried via separate UDP ports, and audio streams typically consist of packets that are relatively small _ usually less than 200 bytes in length, whereas video streams often (but not always) contain significantly larger packets. Part of the ISSLOW specification includes the CRTP protocol, which performs link-level compression (and identification) of RTP packets. Given this information, it should be possible to assign different class levels to different streams using MCML according to the following scheme. Class Type of Data 0 (What appears to be) RTP audio. In order to be assigned to this class, a stream must consist of UDP packets, all of which are less than 200 bytes in size, that have successfully compressed via CRTP. This prerequisite of successful compression is necessary in order to avoid incorrectly assigning non-RTP UDP streams into this class, which could compromise the quality of service delivered to RTP streams. 1 (What appears to be) RTP video. This class will consist of any streams which appear to be RTP (e.g., have successfully compressed via CRTP) but which historically have contained packets greater than 200 bytes in length. Such streams are assumed to be RTP video streams. 2 Short packets _ this class will be used to transport any packet that is smaller than a pre-defined length that does not fall into the two classes above. This class is present as a means of enabling applications that use small packets (H.323 hang-up indications, telnet key-presses, etc.) to receive a slightly improved level of service over bulk data transfer. 100 bytes is a proposed threshold for this value, although different implementations might use other values or vary the value dynamically based on traffic analysis. 3 All other streams - this class is a catchall for any stream that does not fall into one of the other three classes. This class is expected to mostly consist of TCP/IP packets being used for bulk data transfer. Classes 0 and 1 are fixed protocol streams. As such, header elision could be used on these classes to remove the PID from packets assigned to these classes, resulting in a small bandwidth savings. Putzolu Expires May 1998 [Page 3] Internet Draft draft-putzolu-heuristic-00.txt November 1997 Note that this scheme assumes that the multi-class short-header option of MCML is being used, resulting in four distinct classes being available. MCML also supports a long-header option that provides 16 distinct classes. While the heuristics presented here could be extended to take advantage of such a large number of classes, it is claimed that the four classes available via the short-header are sufficient for low-bandwidth links when an announcement protocol is not present. The presence of an announcement protocol would provide further information about the QoS requirements of individual streams, perhaps meriting the use of the long-header option. 4. Class Prioritization Once each stream sent over a PPP link has been assigned to a particular class, what remains is to determine what level of QoS to apply to each class. The most obvious assignment is for class #3, which will receive best-effort service only. This assignment is done because bulk data transfer is expected to primarily consist of traffic using the TCP protocol, which has the ability to adapt to the amount of available bandwidth. Assigning a well-specified QoS to the remaining classes, either of type guaranteed service or controlled load, is very difficult to accomplish over modem lines. In particular, loss levels and link bandwidth can both change in an unpredictable manner. This variability is due to changing line conditions and to the adaptivity that modems use to compensate for such conditions. Furthermore, even if this link variability were compensated for, it would be necessary to determine exactly what the flow characteristics are of the steams assigned to these classes. While this may be possible to do, it would be a complex process requiring significant processing on a per-stream basis. Eliminating such methods of providing QoS leaves application of best-effort service to all classes. In order to provide some level of improved service for multimedia flows, it is suggested that the class number be treated as a priority level, with class 0 streams considered as the highest priority and class 3 as the lowest. Thus, fragments from RTP/Audio streams should be given precedence in scheduling access to the link. Fragments from RTP/Video streams would follow in precedence, after which fragments from small packets would be allowed to access the link. Bulk-data transfer streams with more relaxed delay and jitter requirements may utilize whatever fraction of the link is left. In order to ensure some level of service for all classes, it is suggested that an absolute priority based scheme be avoided. Rather, implementations should attempt to assure that fragments from MCML Putzolu Expires May 1998 [Page 4] Internet Draft draft-putzolu-heuristic-00.txt November 1997 classes 1, 2, and 3 be allowed to at least occasionally utilize the link, even when flows in class 0 would otherwise consume 100% of the available bandwidth. One example method would be a weighted round- robin scheme, where fragments from each class is given access to the link using a periodic schedule such as is presented below: Class Segment Time Slot 0000000001111111111222222222233333333334444444444555555 1234567890123456789012345678901234567890123456789012345 0 X X X X X X X X X X X X X X X X X X X X X X X X X X X X 1 X X X X X X X X X X X X X 2 X X X X X X X X X X 3 X X X X Note that the actual algorithm used for scheduling is entirely implementation dependent. The periodic schedule presented above was chosen under the assumption that fragments from higher priority classes would not utilize all available time slots. The high number of time slots assigned to higher priority classes is done in order to minimize jitter. An alternative fragment scheduling algorithm such as deficit round-robin [8] would provide a greater degree of confidence in the fairness of link utilization at a small incremental cost in complexity. 5. Alternative Methods In [6], a method of determining the relative delay sensitivity and drop preferences among streams in the absence of RSVP is presented. This method relies on use of the IP TOS and Precedence fields to indicate how to treat streams in relation to one another. The stated primary goal is to provide a ``less resource intensive [method] of offering differentiated service.'' The method presented in [6] is a useful means of indicating an end-to-end relative priority among streams in the absence of other announcement protocols. The heuristic approach presented here attempts to solve a different problem, that is, dealing with conditions present only on the PPP link at the end of a connection. Such an approach has two primary advantages. First, no modification is required to applications in this approach, in contrast to [6], where application modifications would be necessary, at least for outgoing streams. This allows the large installed base of multimedia applications to take advantage of the ISSLOW mechanisms. Second, the heuristic approach focuses on just the PPP link, which often is the weakest link in the chain of hops between hosts exchanging multimedia flows. Assigning precedence bits can have effect across the entire connection, which may be an unnecessarily broad solution when the problem may only be present on a single hop of the connection. Putzolu Expires May 1998 [Page 5] Internet Draft draft-putzolu-heuristic-00.txt November 1997 6. Security Considerations Without any sort of admission control for the streams being sent to a host across a low-latency link, it is always possible to be subject to denial-of-service attacks. Using a well-known set of heuristics for prioritizing some streams over others may result in enhanced vulnerability to such attacks (e.g., by sending what appears to be an RTP audio stream). Avoiding the use of an absolute priority based scheme for fragment scheduling lessens, but does not completely alleviate, this vulnerability. 7. References [1] C. Bormann, ``Providing integrated services over low-bitrate links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May 1997. [2] R. Braden, Ed., et. al., ``Resource Reservation Protocol (RSVP) - Version 1 Functional Specification'', RFC 2205, September 1997. [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ``RTP: A Transport Protocol for Real-Time Applications'', RFC 1889, January 1996. [4] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for Low-Speed Serial Links'', Work in Progress (draft-ietf-avt-crtp- 02.txt), March 1997. [5] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', Work in Progress (draft-ietf-issll-isslow-mcml-02.txt), May 1997. [6] P. Ferguson, ``Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference'', Work in Progress (draft-ferguson-delay-drop-00.txt), November 1997. [7] S. Jackowski, ``Network Element Service Specification for Low Speed Networks'', Work in Progress (draft-ietf-issl-isslow-svcmap- 01.txt), November 1997. [8] M. Shreedhar, G. Varghese, ``Efficient Fair Queuing Using Deficit Round-Robin'', IEEE/ACM Trans. Networking, June 1996. 8. Acknowledgments Special thanks to Fred Burg, Stan Naudus, and numerous others for their feedback and comments. Putzolu Expires May 1998 [Page 6] Internet Draft draft-putzolu-heuristic-00.txt November 1997 9. Author's Address David Putzolu Intel Corporation 2111 NE 25th Avenue, JF3-206-H10 Hillsboro, OR 97124 Phone: (503) 264-4510 Email: dputzolu@ibeam.jf.intel.com Putzolu Expires May 1998 [Page 7]