idnits 2.17.1 draft-putzolu-heuristic-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 1997) is 9652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-02 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) == Outdated reference: A later version (-05) exists of draft-ietf-avt-crtp-02 == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-02 == Outdated reference: A later version (-02) exists of draft-ferguson-delay-drop-00 -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-ietf-issl-isslow-svcmap - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio/Video Transport Working Group 3 INTERNET-DRAFT D. Putzolu / Intel Corporation 4 draft-putzolu-heuristic-00.txt November 21, 1997 5 Expires: 5/98 7 Heuristics for utilizing ISSL Mechanisms for A/V Streams 8 Over Low Bandwidth Links 9 in the absence of Announcement Protocols 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 "working draft" or "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 27 munnari.oz.au. 29 A revised version of this draft document will be submitted to the 30 RFC editor as an Informational RFC for the Internet Community. 31 Discussion and suggestions for improvement are requested. This 32 document will expire before May 1998. Distribution of this draft is 33 unlimited. 35 1. Abstract 37 The ISSLOW subgroup of the ISSL working group has defined a set of 38 mechanisms for providing integrated services over low bandwidth 39 links [1]. These mechanisms rely on an announcement protocol 40 (typically RSVP [2]) to determine which streams require other than 41 best-effort service and to determine what level and type of service 42 to provide for such streams. It is anticipated that at least some of 43 the mechanisms defined by the ISSLOW subgroup, specifically 44 Compressed RTP [3] (CRTP) [4] and Multi-Channel Multi-Link PPP 45 (MCML) [5], will be available well before RSVP has been widely 46 deployed. 48 Given the proliferation of applications streaming audio and video 49 using the mechanisms defined in the AVT working group (e.g., RTP), a 50 means of utilizing these mechanisms in the absence of an 51 announcement protocol would be beneficial. Such means have been 52 proposed in [6], but they require changes to applications so as to 53 be able to indicate the need for special treatment. This document 54 describes a set of heuristics for use with the mechanisms defined in 55 the ISSLOW subgroup that provide an enhanced degree of service for 56 audio/video streaming applications without requiring that changes be 57 made to applications. The approach taken is to provide a default set 58 of heuristics that implementations of MCML and CRTP can use to 59 provide enhanced service over PPP links for audio and video streams 60 without requiring any application or infrastructure changes. 62 2. Introduction 64 The Multi-Class extension to Multi-Link PPP (MCML) specifies a set 65 of classes that may be applied to the links of a ML-PPP bundle. 66 These classes are used to provide a means of differentiating streams 67 that require a particular quality of service (QoS) over the PPP 68 link. Using MCML, one line (or more) can be assigned for best-effort 69 traffic, and the remaining links can be used to provide an enhanced 70 quality of service such as controlled load or guaranteed service, as 71 specified in [7]. The Internet draft documents on the subject which 72 are being developed in the ISSLOW subgroup specify that an 73 announcement protocol such as RSVP should be used to determine which 74 streams should be assigned to each MCML class. RSVP or another 75 announcement protocol are also be used to determine what level and 76 type of QoS to assign to each class. 78 Applications that generate real time multimedia flows are one of the 79 primary candidates for benefiting from the QoS mechanisms defined in 80 the ISSLOW subgroup. The streams associated with such applications 81 have very tight latency and jitter requirements that are often 82 violated when traversing low bandwidth links such as POTS modems. 83 Furthermore, it is common for such links to simultaneously be used 84 for both multimedia (audio/video RTP) and data (TCP) streams. This 85 scenario is termed simultaneous AV and data (SAVD). SAVD often 86 results in all available bandwidth being consumed by TCP streams, 87 resulting in delivery of audio/video streams with unacceptable 88 levels of loss and jitter. 90 RSVP and other announcement protocols have not yet been fully 91 deployed across intranets and the Internet. This raises two 92 significant issues in using the mechanisms defined in the ISSLOW 93 subgroup to enhance the quality of multimedia streaming. The first 94 issue is one of determining which streams traversing a PPP link are 95 being used to carry multimedia data in the absence of an 96 announcement protocol. Once such a determination has been made, a 97 second issue arises as to what level of QoS to assign to these 98 multimedia streams in order to ensure that latency, loss, and jitter 99 requirements are met. 101 3. A/V Stream Detection and Class Assignment 103 Determining what streams over a PPP link are audio or video is a 104 relatively straightforward task as long as it can be assumed that 105 such streams are being transmitted in a standards-based manner. Most 106 audio and video streams use the RTP standard for transport. RTP, in 107 turn, is typically carried over UDP/IP. Finally, audio and video 108 streams in RTP are typically carried via separate UDP ports, and 109 audio streams typically consist of packets that are relatively small 110 _ usually less than 200 bytes in length, whereas video streams often 111 (but not always) contain significantly larger packets. Part of the 112 ISSLOW specification includes the CRTP protocol, which performs 113 link-level compression (and identification) of RTP packets. Given 114 this information, it should be possible to assign different class 115 levels to different streams using MCML according to the following 116 scheme. 118 Class Type of Data 119 0 (What appears to be) RTP audio. In order to be assigned to 120 this class, a stream must consist of UDP packets, all of 121 which are less than 200 bytes in size, that have successfully 122 compressed via CRTP. This prerequisite of successful 123 compression is necessary in order to avoid incorrectly 124 assigning non-RTP UDP streams into this class, which could 125 compromise the quality of service delivered to RTP streams. 126 1 (What appears to be) RTP video. This class will consist of 127 any streams which appear to be RTP (e.g., have successfully 128 compressed via CRTP) but which historically have contained 129 packets greater than 200 bytes in length. Such streams are 130 assumed to be RTP video streams. 131 2 Short packets _ this class will be used to transport any 132 packet that is smaller than a pre-defined length that does 133 not fall into the two classes above. This class is present as 134 a means of enabling applications that use small packets 135 (H.323 hang-up indications, telnet key-presses, etc.) to 136 receive a slightly improved level of service over bulk data 137 transfer. 100 bytes is a proposed threshold for this value, 138 although different implementations might use other values or 139 vary the value dynamically based on traffic analysis. 140 3 All other streams - this class is a catchall for any stream 141 that does not fall into one of the other three classes. This 142 class is expected to mostly consist of TCP/IP packets being 143 used for bulk data transfer. 145 Classes 0 and 1 are fixed protocol streams. As such, header elision 146 could be used on these classes to remove the PID from packets 147 assigned to these classes, resulting in a small bandwidth savings. 149 Note that this scheme assumes that the multi-class short-header 150 option of MCML is being used, resulting in four distinct classes 151 being available. MCML also supports a long-header option that 152 provides 16 distinct classes. While the heuristics presented here 153 could be extended to take advantage of such a large number of 154 classes, it is claimed that the four classes available via the 155 short-header are sufficient for low-bandwidth links when an 156 announcement protocol is not present. The presence of an 157 announcement protocol would provide further information about the 158 QoS requirements of individual streams, perhaps meriting the use of 159 the long-header option. 161 4. Class Prioritization 163 Once each stream sent over a PPP link has been assigned to a 164 particular class, what remains is to determine what level of QoS to 165 apply to each class. The most obvious assignment is for class #3, 166 which will receive best-effort service only. This assignment is done 167 because bulk data transfer is expected to primarily consist of 168 traffic using the TCP protocol, which has the ability to adapt to 169 the amount of available bandwidth. 171 Assigning a well-specified QoS to the remaining classes, either of 172 type guaranteed service or controlled load, is very difficult to 173 accomplish over modem lines. In particular, loss levels and link 174 bandwidth can both change in an unpredictable manner. This 175 variability is due to changing line conditions and to the adaptivity 176 that modems use to compensate for such conditions. Furthermore, even 177 if this link variability were compensated for, it would be necessary 178 to determine exactly what the flow characteristics are of the steams 179 assigned to these classes. While this may be possible to do, it 180 would be a complex process requiring significant processing on a 181 per-stream basis. 183 Eliminating such methods of providing QoS leaves application of 184 best-effort service to all classes. In order to provide some level 185 of improved service for multimedia flows, it is suggested that the 186 class number be treated as a priority level, with class 0 streams 187 considered as the highest priority and class 3 as the lowest. Thus, 188 fragments from RTP/Audio streams should be given precedence in 189 scheduling access to the link. Fragments from RTP/Video streams 190 would follow in precedence, after which fragments from small packets 191 would be allowed to access the link. Bulk-data transfer streams with 192 more relaxed delay and jitter requirements may utilize whatever 193 fraction of the link is left. 195 In order to ensure some level of service for all classes, it is 196 suggested that an absolute priority based scheme be avoided. Rather, 197 implementations should attempt to assure that fragments from MCML 198 classes 1, 2, and 3 be allowed to at least occasionally utilize the 199 link, even when flows in class 0 would otherwise consume 100% of the 200 available bandwidth. One example method would be a weighted round- 201 robin scheme, where fragments from each class is given access to the 202 link using a periodic schedule such as is presented below: 204 Class Segment Time Slot 205 0000000001111111111222222222233333333334444444444555555 206 1234567890123456789012345678901234567890123456789012345 207 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 208 1 X X X X X X X X X X X X X 209 2 X X X X X X X X X X 210 3 X X X X 212 Note that the actual algorithm used for scheduling is entirely 213 implementation dependent. The periodic schedule presented above was 214 chosen under the assumption that fragments from higher priority 215 classes would not utilize all available time slots. The high number 216 of time slots assigned to higher priority classes is done in order 217 to minimize jitter. An alternative fragment scheduling algorithm 218 such as deficit round-robin [8] would provide a greater degree of 219 confidence in the fairness of link utilization at a small 220 incremental cost in complexity. 222 5. Alternative Methods 224 In [6], a method of determining the relative delay sensitivity and 225 drop preferences among streams in the absence of RSVP is presented. 226 This method relies on use of the IP TOS and Precedence fields to 227 indicate how to treat streams in relation to one another. The 228 stated primary goal is to provide a ``less resource intensive 229 [method] of offering differentiated service.'' The method presented 230 in [6] is a useful means of indicating an end-to-end relative 231 priority among streams in the absence of other announcement 232 protocols. 234 The heuristic approach presented here attempts to solve a different 235 problem, that is, dealing with conditions present only on the PPP 236 link at the end of a connection. Such an approach has two primary 237 advantages. First, no modification is required to applications in 238 this approach, in contrast to [6], where application modifications 239 would be necessary, at least for outgoing streams. This allows the 240 large installed base of multimedia applications to take advantage of 241 the ISSLOW mechanisms. Second, the heuristic approach focuses on 242 just the PPP link, which often is the weakest link in the chain of 243 hops between hosts exchanging multimedia flows. Assigning 244 precedence bits can have effect across the entire connection, which 245 may be an unnecessarily broad solution when the problem may only be 246 present on a single hop of the connection. 248 6. Security Considerations 250 Without any sort of admission control for the streams being sent to 251 a host across a low-latency link, it is always possible to be 252 subject to denial-of-service attacks. Using a well-known set of 253 heuristics for prioritizing some streams over others may result in 254 enhanced vulnerability to such attacks (e.g., by sending what 255 appears to be an RTP audio stream). Avoiding the use of an absolute 256 priority based scheme for fragment scheduling lessens, but does not 257 completely alleviate, this vulnerability. 259 7. References 261 [1] C. Bormann, ``Providing integrated services over low-bitrate 262 links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May 263 1997. 265 [2] R. Braden, Ed., et. al., ``Resource Reservation Protocol (RSVP) 266 - Version 1 Functional Specification'', RFC 2205, September 1997. 268 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ``RTP: 269 A Transport Protocol for Real-Time Applications'', RFC 1889, January 270 1996. 272 [4] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 273 Low-Speed Serial Links'', Work in Progress (draft-ietf-avt-crtp- 274 02.txt), March 1997. 276 [5] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 277 Work in Progress (draft-ietf-issll-isslow-mcml-02.txt), May 1997. 279 [6] P. Ferguson, ``Simple Differential Services: IP TOS and 280 Precedence, Delay Indication, and Drop Preference'', Work in 281 Progress (draft-ferguson-delay-drop-00.txt), November 1997. 283 [7] S. Jackowski, ``Network Element Service Specification for Low 284 Speed Networks'', Work in Progress (draft-ietf-issl-isslow-svcmap- 285 01.txt), November 1997. 287 [8] M. Shreedhar, G. Varghese, ``Efficient Fair Queuing Using 288 Deficit Round-Robin'', IEEE/ACM Trans. Networking, June 1996. 290 8. Acknowledgments 291 Special thanks to Fred Burg, Stan Naudus, and numerous others for 292 their feedback and comments. 294 9. Author's Address 296 David Putzolu 297 Intel Corporation 298 2111 NE 25th Avenue, JF3-206-H10 299 Hillsboro, OR 97124 300 Phone: (503) 264-4510 301 Email: dputzolu@ibeam.jf.intel.com