One document matched: draft-putzolu-heuristic-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:22:23 |