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]