idnits 2.17.1 draft-ietf-tsvwg-nqb-02.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: ---------------------------------------------------------------------------- No issues found here. 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 date (September 22, 2020) is 1304 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 (-07) exists of draft-briscoe-docsis-q-protection-00 == Outdated reference: A later version (-25) exists of draft-ietf-tsvwg-aqm-dualq-coupled-12 == Outdated reference: A later version (-29) exists of draft-ietf-tsvwg-ecn-l4s-id-10 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group G. White 3 Internet-Draft CableLabs 4 Intended status: Standards Track T. Fossati 5 Expires: March 26, 2021 ARM 6 September 22, 2020 8 A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated 9 Services 10 draft-ietf-tsvwg-nqb-02 12 Abstract 14 This document specifies properties and characteristics of a Non- 15 Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB 16 PHB is to provide a separate queue that enables low latency and, when 17 possible, low loss for application-limited traffic flows that would 18 ordinarily share a queue with capacity-seeking traffic. This PHB is 19 implemented without prioritization and without rate policing, making 20 it suitable for environments where the use of either these features 21 may be restricted. The NQB PHB has been developed primarily for use 22 by access network segments, where queuing delays and queuing loss 23 caused by Queue-Building protocols are manifested, but its use is not 24 limited to such segments. In particular, applications to cable 25 broadband links and mobile network radio and core segments are 26 discussed. This document defines a standard Differentiated Services 27 Code Point (DSCP) to identify Non-Queue-Building flows. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 26, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview: Non-Queue-Building Flows . . . . . . . . . . . . . 3 66 4. DSCP Marking of NQB Traffic . . . . . . . . . . . . . . . . . 4 67 4.1. End-to-end usage and DSCP Re-marking . . . . . . . . . . 5 68 5. Non-Queue-Building PHB Requirements . . . . . . . . . . . . . 6 69 6. Impact on Higher Layer Protocols . . . . . . . . . . . . . . 7 70 7. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 7 71 8. Configuration and Management . . . . . . . . . . . . . . . . 8 72 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 8 74 9.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 8 75 9.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . . 9 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 13. Informative References . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This document defines a Differentiated Services (DS) per-hop behavior 85 (PHB) called "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which 86 is intended to enable networks to provide low latency and low loss 87 for traffic flows that are relatively low data rate and that do not 88 themselves materially contribute to queueing delay and loss. Such 89 Non-Queue-Building flows (for example: interactive voice and video, 90 gaming, machine to machine applications) are application limited 91 flows that are distinguished from traffic flows managed by an end-to- 92 end congestion control algorithm. 94 The vast majority of packets that are carried by broadband access 95 networks are, in fact, managed by an end-to-end congestion control 96 algorithm, such as Reno, Cubic or BBR. These congestion control 97 algorithms attempt to seek the available capacity of the end-to-end 98 path (which can frequently be the access network link capacity), and 99 in doing so generally overshoot the available capacity, causing a 100 queue to build-up at the bottleneck link. This queue build up 101 results in queuing delay (variable latency) and possibly packet loss 102 that affects all of the applications that are sharing the bottleneck 103 link. 105 In contrast to traditional congestion-controlled applications, there 106 are a variety of relatively low data rate applications that do not 107 materially contribute to queueing delay and loss, but are nonetheless 108 subjected to it by sharing the same bottleneck link in the access 109 network. Many of these applications may be sensitive to latency or 110 latency variation, as well as packet loss, and thus produce a poor 111 quality of experience in such conditions. 113 Active Queue Management (AQM) mechanisms (such as PIE [RFC8033], 114 DOCSIS-PIE [RFC8034], or CoDel [RFC8289]) can improve the quality of 115 experience for latency sensitive applications, but there are 116 practical limits to the amount of improvement that can be achieved 117 without impacting the throughput of capacity-seeking applications, 118 particularly when only a few of such flows are present. 120 The NQB PHB supports differentiating between these two classes of 121 traffic in bottleneck links and queuing them separately in order that 122 both classes can deliver satisfactory quality of experience for their 123 applications. 125 2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Overview: Non-Queue-Building Flows 135 There are many applications that send traffic at relatively low data 136 rates and/or in a fairly smooth and consistent manner such that they 137 are highly unlikely to exceed the available capacity of the network 138 path between source and sink. These applications do not cause queues 139 to form in network buffers, but nonetheless can be subjected to 140 packet delay and delay variation as a result of sharing a network 141 buffer with applications that do cause queues. Many of these 142 applications are negatively affected by excessive packet delay and 143 delay variation. Such applications are ideal candidates to be queued 144 separately from the capacity-seeking applications that are the cause 145 of queue buildup, latency and loss. 147 These Non-queue-building (NQB) flows are typically UDP flows that 148 don't seek the capacity of the link (examples: online games, voice 149 chat, DNS lookups, real-time IoT analytics data). Here the data rate 150 is limited by the Application itself rather than by network capacity 151 - in many cases these applications only send a few packets per RTT. 152 In contrast, Queue-building (QB) flows include traffic which uses the 153 Traditional TCP or QUIC, with BBR or other TCP congestion 154 controllers. 156 4. DSCP Marking of NQB Traffic 158 Applications that align with the above description of NQB behavior 159 SHOULD identify themselves to the network using a DiffServ Code Point 160 (DSCP) so that their packets can be queued separately from QB flows. 162 There are many application flows that fall very neatly into one or 163 the other of these categories, but there are also application flows 164 that may be in a gray area in between (e.g. they are NQB on higher- 165 speed links, but QB on lower-speed links). 167 If there is uncertainty as to whether an application's traffic aligns 168 with the description of NQB behavior in the preceding section, the 169 application SHOULD NOT mark its traffic with the NQB DSCP. In such a 170 case, the application SHOULD instead implement a congestion control 171 mechanism, for example as described in [RFC8085] or 172 [I-D.ietf-tsvwg-ecn-l4s-id]. 174 This document recommends a DSCP of 42 (0x2A) to identify packets of 175 NQB flows. 177 It is worthwhile to note that the NQB designation and marking is 178 intended to convey verifiable traffic behavior, not needs or wants. 179 Also, it is important that incentives are aligned correctly, i.e. 180 that there is a benefit to the application in marking its packets 181 correctly, and no benefit to an application in intentionally 182 mismarking its traffic. Thus, a useful property of nodes that 183 support separate queues for NQB and QB flows would be that for NQB 184 flows, the NQB queue provides better performance than the QB queue; 185 and for QB flows, the QB queue provides better performance than the 186 NQB queue. By adhering to these principles, there is no incentive 187 for senders to mismark their traffic as NQB, and further, any 188 mismarking can be identified by the network. 190 4.1. End-to-end usage and DSCP Re-marking 192 In contrast to the existing standard DSCPs, many of which are 193 typically only meaningful within a DiffServ Domain (e.g. an AS or an 194 enterprise network), this DSCP is expected to be used end-to-end 195 across the Internet. Some network operators typically bleach (zero 196 out) the DiffServ field on ingress into their network 197 [Custura][Barik], and in some cases apply their own DSCP for internal 198 usage. Networks that support the NQB PHB SHOULD preserve the NQB 199 DSCP when forwarding via an interconnect from or to another network. 200 Bleaching the NQB DSCP is not expected to cause harm to default 201 traffic, but it will severely limit the ability to provide NQB 202 treatment end-to-end. 204 Reports on existing deployments of DSCP manipulation [Custura][Barik] 205 categorize the remarking behaviors into the following six policies: 206 bleach all traffic (set DSCP to zero), set the top three bits (the 207 former Precedence bits) on all traffic to 0b000, 0b001, or 0b010, set 208 the low three bits on all traffic to 0b000, or remark all traffic to 209 a particular (non-zero) DSCP value. There were no observations 210 reported in which traffic was marked 42 by any of these policies. 211 Thus it appears that these remarking policies would be unlikely to 212 result in QB traffic being marked as NQB. In terms of the fate of 213 NQB-marked traffic that is subjected to one of these policies, the 214 result would be that NQB marked traffic would be indistinguishable 215 from some subset (possibly all) of other traffic. In the policies 216 where all traffic is remarked using the same (zero or non-zero) DSCP, 217 the ability for a subsequent network hop to differentiate NQB traffic 218 via DSCP would clearly be lost entirely. In the policies where the 219 top three bits are overwritten, NQB would receive the same marking as 220 AF41, AF31, AF21, AF11 (as well as the currently unassigned DSCPs 2, 221 50, 58), with all of these codepoints getting mapped to DSCP=2, AF11 222 or AF21 (depending on the overwrite value used). Since the 223 recommended usage of the standardized codepoints in that list include 224 high throughput data for store and forward applications (and it is 225 impossible to predict what future use would be assigned to the 226 currently unassigned values) it would seem inadvisable for a node to 227 attempt to treat all such traffic as if it were NQB marked. For the 228 policy in which the low three bits are set to 0b000, the NQB value 229 would be mapped to CS5 and would be indistinguishable from CS5, VA, 230 EF (and the unassigned DSCPs 41, 43, 45). Traffic marked using the 231 existing standardized DSCPs in this list are likely to share the same 232 general properties as NQB traffic (non capacity-seeking, very low 233 data rate or relatively low and consistent data rate). Furthermore, 234 as this remarking policy results in an overt enforcement of the IP 235 Precedence compatibility configuration discussed in [RFC4594] 236 Section 1.5.4, and to the extent that this compatibility is 237 maintained in the future, any future recommended usages of the 238 currently unassigned DSCPs in that list would be likely to similarly 239 be somewhat compatible with NQB treatment. Here there may be an 240 opportunity for a node to provide the NQB PHB or the CS5 PHB and 241 retain some of the benefits of NQB marking. As a result, nodes 242 supporting the NQB PHB MAY additionally classify CS5 marked traffic 243 into the NQB queue. 245 5. Non-Queue-Building PHB Requirements 247 A node supporting the NQB PHB makes no guarantees on latency or data 248 rate for NQB marked flows, but instead aims to provide a bound on 249 queuing delay for as many such marked flows as it can, and shed load 250 when needed. 252 A node supporting the NQB PHB MUST provide a queue for non-queue- 253 building traffic separate from the queue used for queue-building 254 traffic. 256 NQB traffic, in aggregate, SHOULD NOT be rate limited or rate policed 257 separately from queue-building traffic of equivalent importance. 259 The NQB queue SHOULD be given equal priority compared to queue- 260 building traffic of equivalent importance. The node SHOULD provide a 261 scheduler that allows QB and NQB traffic of equivalent importance to 262 share the link in a fair manner, e.g. a deficit round-robin scheduler 263 with equal weights. 265 A node supporting the NQB PHB SHOULD treat traffic marked as Default 266 (DSCP=0) as QB traffic having equivalent importance to the NQB marked 267 traffic. A node supporting the NQB DSCP MUST support the ability to 268 configure the classification criteria that are used to identify QB 269 and NQB traffic having equivalent importance. 271 The NQB queue SHOULD have a buffer size that is significantly smaller 272 than the buffer provided for QB traffic. It is expected that most QB 273 traffic is optimized to make use of a relatively deep buffer (e.g. on 274 the order of tens or hundreds of ms) in nodes where support for the 275 NQB PHB is advantageous (i.e. bottleneck nodes). Providing a 276 similarly deep buffer for the NQB queue would be at cross purposes to 277 providing very low queueing delay, and would erode the incentives for 278 QB traffic to be marked correctly. 280 It is possible that due to an implementation error or 281 misconfiguration, a QB flow would end up getting mismarked as NQB, or 282 vice versa. In the case of an NQB flow that isn't marked as NQB and 283 ends up in the QB queue, it would only impact its own quality of 284 service, and so it seems to be of lesser concern. However, a QB flow 285 that is mismarked as NQB would cause queuing delays and/or loss for 286 all of the other flows that are sharing the NQB queue. 288 To prevent this situation from harming the performance of the real 289 NQB flows, network elements that support differentiating NQB traffic 290 SHOULD support a "traffic protection" function that can identify QB 291 flows that are mismarked as NQB, and reclassify those flows/packets 292 to the QB queue. Such a function SHOULD be implemented in an 293 objective and verifiable manner, basing its decisions upon the 294 behavior of the flow rather than on application-layer constructs. 295 One example algorithm can be found in 296 [I-D.briscoe-docsis-q-protection]. There are some situations where 297 such function may not be necessary. For example, a network element 298 designed for use in controlled environments, e.g. enterprise LAN may 299 not require a traffic protection function. Similarly, flow queueing 300 systems obviate the need for an explicit traffic protection function. 301 Additionally, some networks may prefer to police the application of 302 the NQB DSCP at the ingress edge, so that in-network traffic 303 protection is not needed. 305 6. Impact on Higher Layer Protocols 307 Network elements that support the NQB PHB and that support traffic 308 protection as discussed in the previous section introduce the 309 possibility that flows classified into the NQB queue could experience 310 out of order delivery. This is particularly true if the traffic 311 protection algorithm makes decisions on a packet-by-packet basis. In 312 this scenario, a flow that is (mis)marked as NQB and that causes a 313 queue to form in this bottleneck link could see some of its packets 314 forwarded by the NQB queue, and some of them redirected to the QB 315 queue. Depending on the queueing latency and scheduling within the 316 network element, this could result in packets being delivered out of 317 order. As a result, the use of the NQB DSCP by a higher layer 318 protocol carries some risk that out of order delivery will be 319 experienced. 321 7. Relationship to L4S 323 Traffic flows marked with the NQB DSCP as described in this draft are 324 intended to be compatible with [I-D.ietf-tsvwg-l4s-arch], with the 325 result being that NQB traffic and L4S traffic can share the low- 326 latency queue in an L4S dual-queue node 327 [I-D.ietf-tsvwg-aqm-dualq-coupled]. Compliance with the DualQ 328 coupled AQM requirements is considered sufficient to enable fair 329 allocation of bandwidth between the QB and NQB queues. 331 8. Configuration and Management 333 As required above, nodes supporting the NQB PHB provide for the 334 configuration of classifiers that can be used to differentiate 335 between QB and NQB traffic of equivalent importance. The default for 336 such classifiers is recommended to be the assigned NQB DSCP (to 337 identify NQB traffic) and the Default (0) DSCP (to identify QB 338 traffic). 340 9. Use Cases 342 9.1. DOCSIS Access Networks 344 Residential cable broadband Internet services are commonly configured 345 with a single bottleneck link (the access network link) upon which 346 the service definition is applied. The service definition, typically 347 an upstream/downstream data rate tuple, is implemented as a 348 configured pair of rate shapers that are applied to the user's 349 traffic. In such networks, the quality of service that each 350 application receives, and as a result, the quality of experience that 351 it generates for the user is influenced by the characteristics of the 352 access network link. 354 To support the NQB PHB, cable broadband services MUST be configured 355 to provide a separate queue for NQB marked traffic. The NQB queue 356 MUST be configured to share the service's rate shaping bandwidth with 357 the queue for QB traffic. 359 9.2. Mobile Networks 361 Historically, mobile networks have been configured to bundle all 362 flows to and from the Internet into a single "default" EPS bearer 363 whose buffering characteristics are not compatible with low-latency 364 traffic. The established behaviour is rooted partly in the desire to 365 prioritise operators' voice services over competing over-the-top 366 services and partly in the fact that the addition of bearers was 367 prohibitive due to expense. Of late, said consideration seems to 368 have lost momentum (e.g., with the rise in Multi-RAB (Radio Access 369 Bearer) devices) and the incentives might now be aligned towards 370 allowing a more suitable treatment of Internet real-time flows. 372 To support the NQB PHB, the mobile network SHOULD be configured to 373 give UEs a dedicated, low-latency, non-GBR, EPS bearer, e.g. one with 374 QCI 7, in addition to the default EPS bearer; or a Data Radio Bearer 375 with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS 376 characteristics mapping in [SA-5G]). 378 A packet carrying the NQB DSCP SHOULD be routed through the dedicated 379 low-latency EPS bearer. A packet that has no associated NQB marking 380 SHOULD be routed through the default EPS bearer. 382 9.3. WiFi Networks 384 WiFi networking equipment compliant with 802.11e generally supports 385 either four or eight transmit queues and four sets of associated 386 Enhanced Multimedia Distributed Control Access (EDCA) parameters 387 (corresponding to the four WiFi Multimedia (WMM) Access Categories) 388 that are used to enable differentiated media access characteristics. 389 Implementations typically utilize the IP DSCP field to select a 390 transmit queue, but should be considered as Non-Differentiated 391 Services-Compliant Nodes as described in Section 4 of [RFC2475] 392 because this transmit queue selection is a local implementation 393 characteristic that is not part of a consistently operated DiffServ 394 domain or region. As a result this document discusses 395 interoperability with WiFi networks, as opposed to PHB compliance. 397 As discussed in [RFC8325], most existing WiFi implementations use a 398 default DSCP to User Priority mapping that utilizes the most 399 significant three bits of the DiffServ Field to select "User 400 Priority" which is then mapped to the four WMM Access Categories. In 401 order to increase the likelihood that NQB traffic is provided a 402 separate queue from QB traffic in existing WiFi equipment, the 42 403 codepoint is preferred for NQB. This would map NQB to UP_5 which is 404 in the "Video" Access Category. Similarly, systems that utilize 405 [RFC8325], SHOULD map the NQB codepoint to UP_5 in the "Video" Access 406 Category. 408 While the DSCP to User Priority mapping can enable WiFi systems to 409 support the NQB PHB requirement for segregated queuing, many 410 currently deployed WiFi systems may not be capable of supporting the 411 remaining NQB PHB requirements in Section 5. This is discussed 412 further below. 414 Existing WiFi devices are unlikely to support a traffic protection 415 algorithm, so traffic mismarked as NQB is not likely to be detected 416 and remedied by such devices. 418 Furthermore, in their default configuration, existing WiFi devices 419 utilize EDCA parameters that result in statistical prioritization of 420 the "Video" Access Category above the "Best Effort" Access Category. 421 If left unchanged, this would violate the NQB PHB requirement for 422 equal prioritization, and could erode the principle of alignment of 423 incentives. In order to preserve the incentives principle, WiFi 424 systems SHOULD configure the EDCA parameters for the Video Access 425 Category to match those of the Best Effort Access Category. 427 In cases where a network operator is delivering traffic into an 428 unmanaged WiFi network outside of their control (e.g. a residential 429 ISP delivering traffic to a customer's home network), the network 430 operator should presume that the existing WiFi equipment does not 431 support the safeguards that are provided by the NQB PHB requirements, 432 and thus should take precautions to prevent issues. In these 433 situations, the operator SHOULD deploy a policing function on NQB 434 marked traffic that minimizes the potential for starvation of traffic 435 marked Default, for example by limiting the rate of such traffic to a 436 set fraction of the customer's service rate. 438 As an additional safeguard, and to prevent the inadvertent 439 introduction of problematic traffic into unmanaged WiFi networks, 440 network equipment that is intended to deliver traffic into unmanaged 441 WiFi networks (e.g. an access network gateway for a residential ISP) 442 MUST by default remap the NQB DSCP to Default. Such equipment MUST 443 support the ability to configure the remapping, so that (when 444 appropriate safeguards are in place) traffic can be delivered as NQB- 445 marked. 447 10. Acknowledgements 449 Thanks to Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca 450 Muscariello, David Black, Sebastian Moeller, Ruediger Geib, Jerome 451 Henry, Steven Blake, Jonathan Morton, Roland Bless, Kevin Smith, 452 Martin Dolly, and Kyle Rose for their review comments. 454 11. IANA Considerations 456 This document assigns the Differentiated Services Field Codepoint 457 (DSCP) 42 ('0b101010', 0x2A) from the "Differentiated Services Field 458 Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp- 459 registry/) ("DSCP Pool 1 Codepoints", Codepoint Space xxxxx0, 460 Standards Action) to denote Non-Queue-Building behavior. 462 12. Security Considerations 464 There is no incentive for an application to mismark its packets as 465 NQB (or vice versa). If a queue-building flow were to mark its 466 packets as NQB, it could experience excessive packet loss (in the 467 case that traffic protection is not supported by a node) or it could 468 receive no benefit (in the case that traffic protection is 469 supported). If a non-queue-building flow were to fail to mark its 470 packets as NQB, it could suffer the latency and loss typical of 471 sharing a queue with capacity seeking traffic. 473 In order to preserve low latency performance for NQB traffic, 474 networks that support the NQB PHB will need to ensure that mechanisms 475 are in place to prevent malicious NQB-marked traffic from causing 476 excessive queue delays. This document recommends the implementation 477 of a traffic protection mechanism to achieve this goal, but 478 recognizes that other options may be more desirable in certain 479 situations. 481 The NQB signal is not integrity protected and could be flipped by an 482 on-path attacker. This might negatively affect the QoS of the 483 tampered flow. 485 13. Informative References 487 [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and 488 S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement 489 Study", ITC 30, September 2018. 491 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 492 modification pathologies in mobile edge networks", TMA , 493 2017. 495 [I-D.briscoe-docsis-q-protection] 496 Briscoe, B. and G. White, "Queue Protection to Preserve 497 Low Latency", draft-briscoe-docsis-q-protection-00 (work 498 in progress), July 2019. 500 [I-D.ietf-tsvwg-aqm-dualq-coupled] 501 Schepper, K., Briscoe, B., and G. White, "DualQ Coupled 502 AQMs for Low Latency, Low Loss and Scalable Throughput 503 (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-12 (work in 504 progress), July 2020. 506 [I-D.ietf-tsvwg-ecn-l4s-id] 507 Schepper, K. and B. Briscoe, "Identifying Modified 508 Explicit Congestion Notification (ECN) Semantics for 509 Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- 510 id-10 (work in progress), March 2020. 512 [I-D.ietf-tsvwg-l4s-arch] 513 Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low 514 Latency, Low Loss, Scalable Throughput (L4S) Internet 515 Service: Architecture", draft-ietf-tsvwg-l4s-arch-06 (work 516 in progress), March 2020. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 524 and W. Weiss, "An Architecture for Differentiated 525 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 526 . 528 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 529 Guidelines for DiffServ Service Classes", RFC 4594, 530 DOI 10.17487/RFC4594, August 2006, 531 . 533 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 534 "Proportional Integral Controller Enhanced (PIE): A 535 Lightweight Control Scheme to Address the Bufferbloat 536 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 537 . 539 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 540 on Proportional Integral Controller Enhanced PIE) for 541 Data-Over-Cable Service Interface Specifications (DOCSIS) 542 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 543 2017, . 545 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 546 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 547 March 2017, . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 554 Iyengar, Ed., "Controlled Delay Active Queue Management", 555 RFC 8289, DOI 10.17487/RFC8289, January 2018, 556 . 558 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 559 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 560 2018, . 562 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 564 Authors' Addresses 566 Greg White 567 CableLabs 569 Email: g.white@cablelabs.com 570 Thomas Fossati 571 ARM 573 Email: Thomas.Fossati@arm.com