idnits 2.17.00 (12 Aug 2021) /tmp/idnits32209/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 15, 2013) is 3225 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) ** Downref: Normative reference to an Informational RFC: RFC 4594 -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-4594bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-AVT-CB' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Toerless Eckert 4 Intended status: PS Cisco Systems 5 Expires: January 15, 2014 July 15, 2013 7 Differentiated Services Delay-and-Loss vs. Loss-Rate-Adaptive 8 Service Classes 9 draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt 11 Abstract 13 This document discusses how RTCWeb/RMCAT applications could best 14 leverage existing and new DiffServ assignments and why we think it 15 is necessary to differentiate the assignments of delay-and-loss- 16 based vs. just-loss-based rate-adaptive video applications. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 15, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 1. Introduction 52 The current guidelines for DSCP assignments of traffic in the IETF 53 is the informational RFC 4594 [RFC4594]. The TSV Working Group is 54 currently reviewing how to update these assignments with one 55 proposal being [ID-4594bis]. 57 This document discusses how RTCWeb/RMCAT applications could best 58 leverage [RFC4594] & [ID-4594bis] assignments and why we think it is 59 necessary to differentiate the assignments of video for these type 60 of applications from non-rate adaptive video flows (i.e., MPEG2). 62 The current text of [ID-4594bis] has audio flows within an 63 interactive communication assigned to EF. The current text of 64 [RFC4594] has interactive video flows would be assigned to AF4x. 66 The definition of AF4x directly matches the requirements for delay 67 and loss-based rate-adaptive, self-friendly video traffic as 68 targeted by RTCWeb applications and RMCAT congestion mechanisms. 69 Splitting audio and video this way into separate traffic classes 70 would specifically provide the benefit of guaranteeing no 71 congestion/loss for the audio part while allowing congestion in 72 video to cause rate adaptation where there is contention in the 73 network. Unfortunately, the reality of deployments of AF4x in 74 network in the last decade or longer does not match this original 75 target of [RFC4594], instead relying only on loss in the network to 76 indicate congestion. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119] when they 83 appear in ALL CAPS. These words may also appear in this document in 84 lower case as plain English words, absent their normative meanings. 86 3. Rate-Adaptive Traffic is Inelastic (and often badly provisioned) 88 Because delay-based rate-adaptive video for conferencing has for the 89 most part been a fairly recent development, the majority of video 90 traffic deployed in many networks into AF41 or AF4x in general has 91 been inelastic, highly loss-sensitive video traffic at fixed 92 bitrates. This type of video deployment is accompanied by some form 93 of either 95 o a vendor specific "Locations CAC" (LCAC) mechanism, 97 o an on-path RSVP based CAC or 98 o a much more commonly what is perceived to be sufficient 99 overprovisioning. 101 This is because LCAC is often considered to be too provisioning 102 intense and RSVP CAC is not supported on a critical mass of 103 application/devices to be deployable in most networks. 105 In addition to Video, AF4x often also carries in practice, the 106 (non-rate adaptive) voice part of collaborative sessions, primarily 107 because creating lip-sync between EF audio and AF4x video traffic 108 when they experiences differing jitter and latency in the network 109 was seen as a complexity that especially lower end hardware based 110 video endpoints wanted to avoid implementing. Additional reasons for 111 this: 113 o Endpoints are too lazy to mark, so network devices mark and cannot 114 tell what flow is video vs. audio; 116 o Implementers simply did not give the option to mark voice or video 117 differently; 119 o People want the same per-hop behavior for audio and video. After 120 all, getting one type of media there faster is of little value 121 since it just has to be put in a buffer and queued, waiting for 122 the other flow. 124 Alas, what might have been sufficient overprovisioning often turns 125 out to be "pray and suffer" in the face of often badly controllable 126 addition of new applications, devices, users or increased in 127 utilization. For example, the busy hour in large enterprises often 128 shrinks and becomes even more busy when expanding operations across 129 multiple time zones. All these problems are the primary reason to 130 propose the move to rate adaptive video, as seen in many recent 131 products and IETF RTCweb/RMCAT work, but with the often long-term 132 investments in a lot of this equipment in enterprises and cost of 133 migrating deployment designs, the issues with this current use of 134 AF4x is not going to go away for a long time. The recent interest in 135 more application or network based circuit-breaker methods 136 [ID-AVT-CB] for this type of inelastic traffic is also a good proof 137 for this pain point (including the demands within the IETF to 138 support them on any inelastic solution (i.e,. RTCWeb & RMCAT 139 efforts)). 141 Because of these fairly widespread deployments of AF4x and their 142 issues, these flows make for a fairly bad PHB to put RMCAT/RTCweb 143 traffic into. Rate adaptive traffic will always come up short 144 against non-rate adaptive, incongestible traffic when being put into 145 the same queue. This is especially true when provisioning for AF4x 146 is leveraging the above "pray and suffer + circuit breaker" 147 approach. 149 4. Jitter from Non-Rate Adaptive Video Traffic is Bad 151 Even if the existing non-rate-adaptive traffic was correctly 152 provisioned such that there is no congestion, and even if all that 153 traffic is known in a particular deployment to only use AF41, it 154 would still not be a good idea to put rate-adaptive RTCweb/RMCAT 155 traffic into AF42/AF43. 157 The reason is that according to the definition of these traffic 158 classes, all AF4x traffic should be in a single queue because there 159 must be no reordering between AF4x packets. The permissible 160 differentiation between AF41/AF42/AF43 therefore are differential 161 drop profiles via WRED or other methods. This means that even if 162 there is never ongoing congestion caused by badly behaving legacy 163 non-rate adaptive traffic, the new rate-adaptive video traffic would 164 still suffer from the jitter introduced by that old video traffic 165 because it has to share a queue. And it would suffer proportional to 166 the amount of traffic in the queue, aka: it would suffer most during 167 the busy hours. 169 This jitter from unknown/legacy/bad video traffic is especially 170 troublesome because delay variation schemes considered for 171 rate-control in RMCAT will be conscious of that jitter and likely 172 work less well when exposed to it. 174 It is hard enough - even unavoidable - for RMCAT to figure out how 175 deal with competing TCP traffic on a single BE "Internet Queue". It 176 is a total waste of effort and easily avoidable for RMCAT having to 177 figure out how to deal with the jitter and loss introduced by legacy 178 non-rate-adaptive video traffic in controlled environments where 179 traffic can be separated by DSCP. 181 5. Suggested Behavior in the Network 183 5.1 CS4 and CS4-Discardable for rate-adaptive video 185 This document is therefore asking to assign a Service Class to delay 186 and loss-based rate-adaptive, self-friendly conversational video 187 traffic that is separate from AF4x. 189 We think that CS4 has been a traffic class that so far has seen 190 little use and most likely is the easiest traffic class to use for 191 this traffic. 193 In addition, it would be very helpful for future improvements in 194 delay and loss-based rate-adaptive video traffic in the network if 195 there is a second traffic class, e.g., "CS4-Discardable", for 196 lower-priority packets within video flows that can easily be 197 dropped. 199 Given how rate-adaptive video will not always be able to avoid all 200 packet drops, video codecs can improve the visual quality in 201 conjunction with the network by creating discardable P-frames (e.g., 202 P-frames not referenced by other P-frames) and having the network 203 preferentially drop those frames. This can easily achieved with two 204 DSCP assigned values, where one has a higher drop priority that the 205 other. This, of course, is exactly the logic also designated for 206 AF41/AF42/AF43, in other words we are simply asking for a new PHB be 207 assigned to the existing AF41 (suggest: CS4) and a new AF42 208 (suggested: CS4-Discardable). 210 5.2 AF4x for Non-Rate-Adaptive Video 212 To represent the reality of deployments in the IETF guidelines, AF41 213 should be re-designated for non-rate adaptive conversational video 214 with explicit admission control (off-path or non-path). AF42 should 215 be re-designated for non-rate-adaptive conversational video without 216 explicit admission control (e.g., relying solely on circuit 217 breakers). 219 This proposal, in effect, is suggesting the text in RFC 4594 220 regarding AF4X, as written, be ported/moved over to replace the text 221 in that same RFC that was for CS4 PHB. New text will need to be 222 written in the RFC4594bis document addressing AF4X taking over the 223 more legacy traffic behaviors from non-adaptive (based on loss) 224 video traffic. 226 6. Additional Recommendations for Other PHBs Affected 228 Specifying that delay and loss-based rate-adaptive video use CS4 229 (and 'CS4+' or 'CS4-Discardable' or 'CS4-D') means the current RFC 230 4594 assignment of CS4 to the Realtime-Interactive (RTI) service 231 class needs modification. Rather than create new definitions for 232 CS4, currently occupied with the Realtime Interactive (RTI) PHB 233 traffic according to RFC 4594, our proposal is to move the RTI 234 service class definitions to CS5 (as is the case in [ID-4594bis] - 235 where the RTI will have a minimal effect on the existing installed 236 base of implementations because it has few. 238 The CS5 PHB, which is assigned for H.323 and SIP signaling, would be 239 then moved to another DSCP. Perhaps near Low-Latency Data (CS2) 240 according to [ID-4594bis]. 242 7. Acknowledgements 244 The authors would like to thank Paul Jones, Charles Eckel, Charles 245 Ganzhorn, Fred Baker, Mo Zanaty, Michael Ramalho for their active 246 participation in this effort. 248 8. IANA Considerations 250 If the WG agrees with this effort, then there will need to be a 251 reassignment of AF4X and CS4, as well as the new assignment of an 252 additional CS4+ or CS4-discardable PHB. 254 9. Security Considerations 256 TBW 258 10. References 260 10.1 Normative References 262 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 263 Requirement Levels", RFC 2119, March 1997 265 [RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for 266 Diffserv Service Classes", RFC 4594, August 2006 268 [ID-4594bis] J. Polk, "Standard Configuration of DiffServ Service 269 Classes", "work in progress", March 2012 271 [ID-AVT-CB] C. Perkins, V. Singh, "Multimedia Congestion Control: 272 Circuit Breakers for Unicast RTP Sessions", work in 273 progress, July 2013 275 10.2 Informative References 277 none at this time 279 Author's Addresses 281 James Polk 282 Cisco Systems, Inc. 283 8017 Hallmark Dr. 284 North Richland Hills, TX 76182 285 USA 287 Phone: +1 817 271 3552 288 Email: jmpolk@cisco.com 290 Toerless Eckert 291 Cisco Systems, Inc. 292 San Jose 293 US 295 Email: eckert@cisco.com