idnits 2.17.1 draft-white-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 (June 28, 2019) is 1763 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 (-20) exists of draft-ietf-tsvwg-l4s-arch-03 Summary: 0 errors (**), 0 flaws (~~), 2 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: December 30, 2019 ARM 6 June 28, 2019 8 Identifying and Handling Non Queue Building Flows in a Bottleneck Link 9 draft-white-tsvwg-nqb-02 11 Abstract 13 This draft proposes the definition of a standardized DiffServ code 14 point (DSCP) to identify Non-Queue-Building flows (for example: 15 interactive voice and video, gaming, machine to machine 16 applications), along with a Per-Hop-Behavior (PHB) that provides a 17 separate queue for such flows. 19 The purpose of such a marking scheme is to enable networks to provide 20 and utilize queues that are optimized to provide low latency and low 21 loss for such Non-Queue-Building flows (e.g. shallow buffers, 22 optimized media access parameters, etc.). 24 This marking scheme and PHB has been developed primarily for use by 25 access network segments, where queuing delays and queuing loss caused 26 by Queue-Building protocols are manifested. In particular, 27 applications to cable broadband links and mobile network radio and 28 core segments are discussed. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 30, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Non-Queue Building Flows . . . . . . . . . . . . . . . . . . 3 67 4. Endpoint Marking and Queue Protection . . . . . . . . . . . . 4 68 5. Non Queue Building PHB and DSCP . . . . . . . . . . . . . . . 5 69 6. End-to-end Support . . . . . . . . . . . . . . . . . . . . . 6 70 7. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 6 71 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 6 73 8.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 6 74 8.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . . 7 75 9. Comparison to Existing Approaches . . . . . . . . . . . . . . 7 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 13. Informative References . . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The vast majority of packets that are carried by broadband access 85 networks are managed by an end-to-end congestion control algorithm, 86 such as Reno, Cubic or BBR. These congestion control algorithms 87 attempt to seek the available capacity of the end-to-end path (which 88 can frequently be the access network link capacity), and in doing so 89 generally overshoot the available capacity, causing a queue to build- 90 up at the bottleneck link. This queue build up results in queuing 91 delay that the application experiences as variable latency, and 92 commonly results in packet loss as well. 94 In contrast to traditional congestion-controlled applications, there 95 are a variety of relatively low data rate applications that do not 96 materially contribute to queueing delay and loss, but are nonetheless 97 subjected to it by sharing the same bottleneck link in the access 98 network. Many of these applications may be sensitive to latency or 99 latency variation, as well as packet loss, and thus produce a poor 100 quality of experience in such conditions. 102 Active Queue Management (AQM) mechanisms (such as PIE [RFC8033], 103 DOCSIS-PIE [RFC8034], or CoDel [RFC8289]) can improve the quality of 104 experience for latency sensitive applications, but there are 105 practical limits to the amount of improvement that can be achieved 106 without impacting the throughput of capacity-seeking applications. 108 This document considers differentiating between these two classes of 109 traffic in bottleneck links and queuing them separately in order that 110 both classes can deliver optimal quality of experience for their 111 applications. 113 A couple of preconditions need to be satisfied before we can move on 114 from the status quo. First, the packets must be efficiently 115 identified so that they can be quickly assigned to the "right" queue. 116 This is especially important with the rising popularity of encrypted 117 and multiplexed transports, which has the potential of making deep 118 inspection infeasible. Second, the signal must be such that 119 malicious or badly configured nodes can't abuse it. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 3. Non-Queue Building Flows 129 There are many applications that send traffic at relatively low data 130 rates and/or in a fairly smooth and consistent manner such that they 131 are highly unlikely to exceed the available capacity of the network 132 path between source and sink. These applications do not make use of 133 network buffers, but nonetheless can be subjected to packet delay and 134 delay variation as a result of sharing a network buffer with those 135 that do make use of them. Many of these applications are negatively 136 affected by excessive packet delay and delay variation. Such 137 applications are ideal candidates to be queued separately from the 138 capacity-seeking applications that are the cause of queue buildup, 139 latency and loss. 141 These Non-queue-building (NQB) flows are typically UDP flows that 142 send traffic at a lower data rate and don't seek the capacity of the 143 link (examples: online games, voice chat, DNS lookups). Here the 144 data rate is essentially limited by the Application itself. In 145 contrast, Queue-building (QB) flows include traffic which uses the 146 Traditional TCP or QUIC, with BBR or other TCP congestion 147 controllers. 149 There are a lot of great examples of applications that fall very 150 neatly into these two categories, but there are also application 151 flows that may be in a gray area in between (e.g. they are NQB on 152 higher-speed links, but QB on lower-speed links). 154 4. Endpoint Marking and Queue Protection 156 This memo proposes that application endpoints apply a marking, 157 utilizing the Diffserv field of the IP header, to packets of NQB 158 flows that could then be used by the network to differentiate between 159 QB and NQB flows. It is important for such a marking to be 160 universally agreed upon, rather than being locally defined by the 161 network operator, such that applications could be written to apply 162 the marking without regard to local network policies. 164 Some questions that arise when considering endpoint marking are: How 165 can an application determine whether it is queue building or not, 166 given that the sending application is generally not aware of the 167 available capacity of the path to the receiving endpoint? Even in 168 cases where an application is aware of the capacity of the path, how 169 can it be sure that the available capacity (considering other flows 170 that may be sharing the path) would be sufficient to result in the 171 application's traffic not causing a queue to form? In an unmanaged 172 environment, how can networks trust endpoint marking, and why 173 wouldn't all applications mark their packets as NQB? 175 As an answer the last question, it is worthwhile to note that the NQB 176 designation and marking would be intended to convey verifiable 177 traffic behavior, not needs or wants. Also, it would be important 178 that incentives are aligned correctly, i.e. that there is a benefit 179 to the application in marking its packets correctly, and no benefit 180 for an application in intentionally mismarking its traffic. Thus, a 181 useful property of nodes that support separate queues for NQB and QB 182 flows would be that for NQB flows, the NQB queue provides better 183 performance (considering latency, loss and throughput) than the QB 184 queue; and for QB flows, the QB queue provides better performance 185 (considering latency, loss and throughput) than the NQB queue. 187 Even so, it is possible that due to an implementation error or 188 misconfiguration, a QB flow would end up getting mismarked as NQB, or 189 vice versa. In the case of an NQB flow that isn't marked as NQB and 190 ends up in the QB queue, it would only impact its own quality of 191 service, and so it seems to be of lesser concern. However, a QB flow 192 that is mismarked as NQB would cause queuing delays for all of the 193 other flows that are sharing the NQB queue. 195 To prevent this situation from harming the performance of the real 196 NQB flows, network elements that support differentiating NQB traffic 197 SHOULD support a "queue protection" function that can identify QB 198 flows that are mismarked as NQB, and reclassify those flows/packets 199 to the QB queue. This benefits the reclassified flow by giving it 200 access to a large buffer (and thus lower packet loss rate), and 201 benefits the actual NQB flows by preventing harm (increased latency 202 variability) to them. Such a function SHOULD be implemented in an 203 objective and verifiable manner, basing its decisions upon the 204 behavior of the flow rather than on application-layer constructs. 206 5. Non Queue Building PHB and DSCP 208 This section uses the DiffServ nomenclature of per-hop-behavior (PHB) 209 to describe how a network node could provide better quality of 210 service for NQB flows without reducing performance of QB flows. 212 A node supporting the NQB PHB MUST provide a queue for non-queue- 213 building traffic separate from the queue used for queue-building 214 traffic. This queue SHOULD support a latency-based queue protection 215 mechanism that is able to identify queue-building behavior in flows 216 that are classified into the queue, and to redirect flows causing 217 queue build-up to a different queue. One example algorithm can be 218 found in Annex P of [DOCSIS-MULPIv3.1]. 220 While there may be some similarities between the characteristics of 221 NQB flows and flows marked with the Expedited Forwarding (EF) DSCP, 222 the NQB PHB would differ from the Expedited Forwarding PHB in several 223 important ways. 225 o NQB traffic is not rate limited or rate policed. Rather, the NQB 226 queue would be expected to support a latency-based queue 227 protection mechanism that identifies NQB marked flows that are 228 beginning to cause latency, and redirects packets from those flows 229 to the queue for QB flows. 231 o The node supporting the NQB PHB makes no guarantees on latency or 232 data rate for NQB marked flows, but instead aims to provide a 233 bound on queuing delay for as many such marked flows as it can, 234 and shed load when needed. 236 o EF is commonly used exclusively for voice traffic, for which 237 additional functions are applied, such as admission control, 238 accounting, prioritized delivery, etc. 240 In networks that support the NQB PHB, it may be preferred to also 241 include traffic marked EF (0b101110) in the NQB queue. The choice of 242 the 0x2A codepoint (0b101010) for NQB would conveniently allow a node 243 to select these two codepoints using a single mask pattern of 244 0b101x10. 246 6. End-to-end Support 248 In contrast to the existing standard DSCPs, which are typically only 249 meaningful within a DiffServ Domain (e.g. an AS), this DSCP would be 250 intended for end-to-end usage across the Internet. Some network 251 operators bleach the Diffserv field on ingress into their network 252 [Custura], and in some cases apply their own DSCP for internal usage. 253 Networks that support the NQB PHB SHOULD preserve the NQB DSCP when 254 forwarding via an interconnect. 256 7. Relationship to L4S 258 The dual-queue mechanism described in this draft is intended to be 259 compatible with [I-D.ietf-tsvwg-l4s-arch]. 261 8. Use Cases 263 8.1. DOCSIS Access Networks 265 Residential cable broadband Internet services are commonly configured 266 with a single bottleneck link (the access network link) upon which 267 the service definition is applied. The service definition, typically 268 an upstream/downstream data rate tuple, is implemented as a 269 configured pair of rate shapers that are applied to the user's 270 traffic. In such networks, the quality of service that each 271 application receives, and as a result, the quality of experience that 272 it generates for the user is influenced by the characteristics of the 273 access network link. 275 To support the NQB PHB, cable broadband services MUST be configured 276 to provide a separate queue for NQB traffic that shares the service 277 rate shaping configuration with the queue for QB traffic. 279 8.2. Mobile Networks 281 Today's mobile networks are configured to bundle all flows to and 282 from the Internet into a single "default" EPS bearer whose buffering 283 characteristics are not compatible with low-latency traffic. The 284 established behaviour is partly rooted in the desire to prioritise 285 operators' voice services over competing over-the-top services. Of 286 late, said business consideration seems to have lost momentum and the 287 incentives might now be aligned towards allowing a more suitable 288 treatment of Internet real-time flows. 290 To support the NQB PHB, the mobile network MUST be configured to give 291 UEs a dedicated, low-latency, non-GBR, EPS bearer with QCI 7 in 292 addition to the default EPS bearer. 294 A packet carrying the NQB DSCP SHOULD be routed through the dedicated 295 low-latency EPS bearer. A packet that has no associated NQB marking 296 SHOULD be routed through the default EPS bearer. 298 8.3. WiFi Networks 300 WiFi networking equipment compliant with 802.11e generally supports 301 either four or eight transmit queues and four sets of associated CSMA 302 parameters that are used to enable differentiated media access 303 characteristics. Implementations typically utilize the IP DSCP field 304 to select a transmit queue. 306 As discussed in [RFC8325], most implementations use a default DSCP to 307 User Priority mapping that utilizes the most significant three bits 308 of the DiffServ Field to select User Priority. In the case of the 309 0x2A codepoint, this would map to UP_5 which is in the "Video" Access 310 Category (one level above "Best Effort"). 312 Systems that utilize [RFC8325], SHOULD map the 0x2A codepoint to UP_6 313 in the "Voice" Access Category. 315 9. Comparison to Existing Approaches 317 Traditional QoS mechanisms focus on prioritization in an attempt to 318 achieve two goals: reduced latency for "latency-sensitive" traffic, 319 and increased bandwidth availability for "important" applications. 320 Applications are generally given priority in proportion to some 321 combination of latency-sensitivity and importance. 323 Downsides to this approach include the difficulties in sorting out 324 what priority level each application should get (making the value 325 judgement as to relative latency-sensitivity and importance), 326 associating packets to priority levels (configuring and maintaining 327 lots of classifier state, or trusting endpoint markings and the value 328 judgements that they convey), ensuring that high priority traffic 329 doesn't starve lower priority traffic (admission control, weighted 330 scheduling, etc. are possible solutions). This solution can work in 331 a managed network, where the network operator can control the usage 332 of the QoS mechanisms, but has not been adopted end-to-end across the 333 Internet. See also [Claffy] for an exhaustive treatment of the 334 argument. 336 Flow queueing (FQ) approaches (such as fq_codel [RFC8290]), on the 337 other hand, achieve latency improvements by associating packets into 338 "flow" queues and then prioritizing "sparse flows", i.e. packets that 339 arrive to an empty flow queue. Flow queueing does not attempt to 340 differentiate between flows on the basis of value (importance or 341 latency-sensitivity), it simply gives preference to sparse flows, and 342 tries to guarantee that the non-sparse flows all get an equal share 343 of the remaining channel capacity and are interleaved with one 344 another. As a result, FQ mechanisms could be considered more 345 appropriate for unmanaged environments and general Internet traffic. 347 Downsides to this approach include loss of low latency performance 348 due to the possibility of hash collisions (where a sparse flow shares 349 a queue with a bulk data flow), complexity in managing a large number 350 of queues in certain implementations, and some undesirable effects of 351 the Deficit Round Robin (DRR) scheduling. The DRR scheduler enforces 352 that each non-sparse flow gets an equal fraction of link bandwidth, 353 which causes problems with VPNs and other tunnels, exhibits poor 354 behavior with less-aggressive congestion control algorithms, e.g. 355 LEDBAT [RFC6817], and could exhibit poor behavior with RTP Media 356 Congestion Avoidance Techniques (RMCAT) 357 [I-D.ietf-rmcat-cc-requirements]. In effect, the network element is 358 making a decision as to what constitutes a flow, and then forcing all 359 such flows to take equal bandwidth at every instant. 361 The Dual-queue approach defined in this document achieves the main 362 benefit of fq_codel: latency improvement without value judgements, 363 without the downsides. 365 The distinction between NQB flows and QB flows is similar to the 366 distinction made between "sparse flow queues" and "non-sparse flow 367 queues" in fq_codel. In fq_codel, a flow queue is considered sparse 368 if it is drained completely by each packet transmission, and remains 369 empty for at least one cycle of the round robin over the active flows 370 (this is approximately equivalent to saying that it utilizes less 371 than its fair share of capacity). While this definition is 372 convenient to implement in fq_codel, it isn't the only useful 373 definition of sparse flows. 375 The Linux Heavy-Hitter Filter [HHF][Estan] qdisc and the Cisco 376 Dynamic Packet Prioritization [DPP] feature both categorize 377 application flows into "mice" and "elephants", and provide a separate 378 queue that gives high priority to the "mice" flows. In both of these 379 implementations, the definition of a mice flow is one that falls 380 below a defined number of bytes or packets (respectively). In 381 essence, the first N bytes or packets of every new flow are queued 382 separately, and given priority over other traffic. The HHF 383 implementation defaults to using 128KB for N, whereas the DPP 384 documentation discusses using 120 packets. 386 This approach is relatively simple to implement, but it is making the 387 wrong distinction between flows. To illustrate, an hour-long 60 kbps 388 multiplayer online gaming flow sending 60 packets per second would be 389 classified as an elephant after the first 17 seconds using HFF or 2 390 seconds using DPP, whereas it should be considered as NQB for the 391 entire duration. 393 Other dual-queue approaches have been proposed, including some that 394 pair a shallow buffer with a deep buffer, similar to what is 395 described in this draft. One such design is the "RD" mechanism in 396 [Podlesny] which proposes that applications select either high rate 397 or low delay, with one queue (the high-rate queue) being given a 398 large buffer and a higher scheduling weight, and the other queue (the 399 low-delay queue) being given a short buffer and lower scheduling 400 weight. This approach is somewhat similar to the NQB PHB, in regards 401 to allowing the application to select between a deep buffer and a 402 shallow one, but it places unnecessary restrictions on the scheduling 403 between the two queues, and doesn't differentiate traffic based on 404 behavior. Further, the approach doesn't provide any safety valve to 405 prevent malicious or misconfigured flows from causing excessive 406 packet loss in the low delay queue. Similarly, the "Loss-Latency 407 Tradeoff" approach described in [I-D.fossati-tsvwg-lola] posits that 408 applications should choose between a queue that provides low latency 409 and potentially high loss (i.e. a shallow buffer), and one that 410 provides low loss and potentially high latency (i.e. a deep buffer). 411 This approach misses that both queuing latency and queuing loss are 412 primarily byproducts of application sending behavior, and by properly 413 segregating applications, no trade-off needs to be made. 415 10. Acknowledgements 417 Thanks to Bob Briscoe, Greg Skinner, Dave Taht, Toke Hoeiland- 418 Joergensen and Luca Muscariello for their review comments. 420 11. IANA Considerations 422 This draft proposes the registration of a standardized DSCP = 0x2A to 423 denote Non-Queue-Building behavior. 425 12. Security Considerations 427 There is no incentive for an application to mismark its packets as 428 NQB (or vice versa). If a queue-building flow were to mark its 429 packets as NQB, it could experience excessive packet loss (in the 430 case that queue-protection is not supported by a node) or it could 431 receive no benefit (in the case that queue-protection is supported). 432 If a non-queue-building flow were to fail to mark its packets as NQB, 433 it could suffer the latency and loss typical of sharing a queue with 434 capacity seeking traffic. 436 The NQB signal is not integrity protected and could be flipped by an 437 on-path attacker. This might negatively affect the QoS of the 438 tampered flow. 440 13. Informative References 442 [Claffy] Claffy, KC. and D. Clark, "Adding Enhanced Services to the 443 Internet: Lessons from History", TPRC , 2015, 444 . 447 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 448 modification pathologies in mobile edge networks", TMA , 449 2017. 451 [DOCSIS-MULPIv3.1] 452 Cable Television Laboratories, Inc., "MAC and Upper Layer 453 Protocols Interface Specification, CM-SP- 454 MULPIv3.1-I18-190422", April 22, 2019, 455 . 458 [DPP] Cisco, "Intelligent Buffer Management on Cisco Nexus 9000 459 Series Switches White Paper", June 2017, 460 . 464 [Estan] Estan, C. and G. Varghese, "New directions in traffic 465 measurement and accounting: Focusing on the elephants, 466 ignoring the mice", ACM Transactions on Computer 467 Systems Vol.23, Iss.3, August 2003, 468 . 470 [HHF] Lam, T., "net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc", 471 December 2013, . 473 [I-D.fossati-tsvwg-lola] 474 Fossati, T., Fairhurst, G., Gutierrez, P., and M. 475 Kuehlewind, "A Loss-Latency Trade-off Signal for the 476 Mobile Network", draft-fossati-tsvwg-lola-00 (work in 477 progress), December 2018. 479 [I-D.ietf-rmcat-cc-requirements] 480 Jesup, R. and Z. Sarker, "Congestion Control Requirements 481 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 482 requirements-09 (work in progress), December 2014. 484 [I-D.ietf-tsvwg-l4s-arch] 485 Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, 486 Low Loss, Scalable Throughput (L4S) Internet Service: 487 Architecture", draft-ietf-tsvwg-l4s-arch-03 (work in 488 progress), October 2018. 490 [Podlesny] 491 Podlesny, M. and S. Gorinsky, "Rd Network Services: 492 Differentiation Through Performance Incentives", SIGCOMM , 493 2008, 494 . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 503 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 504 DOI 10.17487/RFC6817, December 2012, 505 . 507 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 508 "Proportional Integral Controller Enhanced (PIE): A 509 Lightweight Control Scheme to Address the Bufferbloat 510 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 511 . 513 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 514 on Proportional Integral Controller Enhanced PIE) for 515 Data-Over-Cable Service Interface Specifications (DOCSIS) 516 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 517 2017, . 519 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 520 Iyengar, Ed., "Controlled Delay Active Queue Management", 521 RFC 8289, DOI 10.17487/RFC8289, January 2018, 522 . 524 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 525 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 526 and Active Queue Management Algorithm", RFC 8290, 527 DOI 10.17487/RFC8290, January 2018, 528 . 530 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 531 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 532 2018, . 534 Authors' Addresses 536 Greg White 537 CableLabs 539 Email: g.white@cablelabs.com 541 Thomas Fossati 542 ARM 544 Email: Thomas.Fossati@arm.com