idnits 2.17.1 draft-ietf-tsvwg-nqb-06.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 (12 July 2021) is 1017 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 2983 == 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-13 == Outdated reference: A later version (-29) exists of draft-ietf-tsvwg-ecn-l4s-id-12 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-08 Summary: 1 error (**), 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: 13 January 2022 ARM 6 12 July 2021 8 A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated 9 Services 10 draft-ietf-tsvwg-nqb-06 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 smooth, low-data- 17 rate, application-limited traffic flows, which would ordinarily share 18 a queue with bursty and capacity-seeking traffic, to avoid the 19 latency, latency variation and loss caused by such traffic. This PHB 20 is implemented without prioritization and without rate policing, 21 making it suitable for environments where the use of either these 22 features may be restricted. The NQB PHB has been developed primarily 23 for use by access network segments, where queuing delays and queuing 24 loss caused by Queue-Building protocols are manifested, but its use 25 is not limited to such segments. In particular, applications to 26 cable broadband links, Wi-Fi links, and mobile network radio and core 27 segments are discussed. This document recommends a specific 28 Differentiated Services Code Point (DSCP) to identify Non-Queue- 29 Building flows. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 13 January 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Non-Queue-Building Behavior . . . . . . . . . . . . . . . . . 4 67 4. The NQB PHB and its Relationship to the Diffserv 68 Architecture . . . . . . . . . . . . . . . . . . . . . . 5 69 5. DSCP Marking of NQB Traffic . . . . . . . . . . . . . . . . . 6 70 5.1. End-to-end usage and DSCP Re-marking . . . . . . . . . . 7 71 5.2. Aggregation of the NQB PHB with other Diffserv PHBs . . . 8 72 6. Non-Queue-Building PHB Requirements . . . . . . . . . . . . . 8 73 7. Impact on Higher Layer Protocols . . . . . . . . . . . . . . 9 74 8. The NQB PHB and Tunnels . . . . . . . . . . . . . . . . . . . 10 75 9. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 10 76 10. Configuration and Management . . . . . . . . . . . . . . . . 11 77 11. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 11 79 11.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . 11 80 11.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . 12 81 11.3.1. Interoperability with Existing WiFi Networks . . . . 12 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 15.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Appendix A. DSCP Remarking Pathologies . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 This document defines a Differentiated Services per-hop behavior 94 (PHB) called "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which 95 isolates traffic flows that are relatively low data rate and that do 96 not themselves materially contribute to queueing delay and loss, 97 allowing them to avoid the queuing delays and losses caused by other 98 traffic. Such Non-Queue-Building flows (for example: interactive 99 voice, gaming, machine-to-machine applications) are application 100 limited flows that are distinguished from traffic flows managed by an 101 end-to-end congestion control algorithm. 103 The vast majority of packets that are carried by broadband access 104 networks are managed by an end-to-end congestion control algorithm, 105 such as Reno, Cubic or BBR. These congestion control algorithms 106 attempt to seek the available capacity of the end-to-end path (which 107 can frequently be the access network link capacity), and in doing so 108 generally overshoot the available capacity, causing a queue to build- 109 up at the bottleneck link. This queue build up results in queuing 110 delay (variable latency) and possibly packet loss that affects all of 111 the applications that are sharing the bottleneck link. 113 In contrast to traditional congestion-controlled applications, there 114 are a variety of relatively low data rate applications that do not 115 materially contribute to queueing delay and loss, but are nonetheless 116 subjected to it by sharing the same bottleneck link in the access 117 network. Many of these applications may be sensitive to latency or 118 latency variation, as well as packet loss, and thus produce a poor 119 quality of experience in such conditions. 121 Active Queue Management (AQM) mechanisms (such as PIE [RFC8033], 122 DOCSIS-PIE [RFC8034], or CoDel [RFC8289]) can improve the quality of 123 experience for latency sensitive applications, but there are 124 practical limits to the amount of improvement that can be achieved 125 without impacting the throughput of capacity-seeking applications, 126 particularly when only a few of such flows are present. 128 The NQB PHB supports differentiating between these two classes of 129 traffic in bottleneck links and queuing them separately in order that 130 both classes can deliver satisfactory quality of experience for their 131 applications. 133 To be clear, a network implementing the NQB PHB solely provides 134 isolation for traffic classified as behaving in conformance with the 135 NQB DSCP (and optionally enforces that behavior). It is the NQB 136 senders' behavior itself which results in low latency and low loss. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Non-Queue-Building Behavior 148 There are many applications that send traffic at relatively low data 149 rates and/or in a fairly smooth and consistent manner such that they 150 are highly unlikely to exceed the available capacity of the network 151 path between source and sink. These applications do not on their own 152 cause queues to form in network buffers, but nonetheless can be 153 subjected to packet delay and delay variation as a result of sharing 154 a network buffer with applications that do cause queues to form. 155 Many of these applications are negatively affected by excessive 156 packet delay and delay variation. Such applications are ideal 157 candidates to be queued separately from the applications that are the 158 cause of queue buildup, latency and loss. 160 These Non-queue-building (NQB) flows are typically UDP flows that 161 don't seek the maximum capacity of the link (examples: online games, 162 voice chat, DNS lookups, real-time IoT analytics data). Here the 163 data rate is limited by the application itself rather than by network 164 capacity - these applications send, at most, the equivalent of a few 165 well-spaced packets per RTT, even if the packets are not actually 166 RTT-clocked. In today's network this corresponds to an instantaneous 167 data rate (packet size divided by packet inter-arrival time) of no 168 more than about 1 Mbps (e.g. no more than one 1250 B packet every 10 169 ms), but there is no precise bound since it depends on the conditions 170 in which the application is operating. 172 Note that, while such flows ordinarily don't implement a traditional 173 congestion control mechanism, they nonetheless are expected to comply 174 with existing guidance for safe deployment on the Internet, for 175 example the requirements in [RFC8085] and Section 2 of [RFC3551] 176 (also see the circuit breaker limits in Section 4.3 of [RFC8083] and 177 the description of inelastic pseudowires in Section 4 of [RFC7893]). 178 To be clear, the description of NQB flows in this document should not 179 be interpreted as suggesting that such flows are in any way exempt 180 from this responsibility. 182 In contrast, Queue-building (QB) flows include traffic which uses TCP 183 or QUIC, with Cubic, Reno or other TCP congestion control algorithms 184 that probe for the link capacity and induce latency and loss as a 185 result. Other types of QB flows include those that frequently send 186 at a high burst rate (e.g. several consecutive packets sent well in 187 excess of 1 Mbps) even if the long-term average data rate is much 188 lower. 190 4. The NQB PHB and its Relationship to the Diffserv Architecture 192 The IETF has defined the Differentiated Services architecture 193 [RFC2475] with the intention that it allows traffic to be marked in a 194 manner that conveys the performance requirements of that traffic 195 either quantitatively or in a relative sense (i.e. priority). The 196 architecture defines the use of the Diffserv field [RFC2474] for this 197 purpose, and numerous RFCs have been written that describe 198 recommended interpretations of the values (Diffserv Code Points) of 199 the field, and standardized treatments (traffic conditioning and per- 200 hop-behaviors) that can be implemented to satisfy the performance 201 requirements of traffic so marked. 203 While this architecture is powerful, and can be configured to meet 204 the performance requirements of a variety of applications and traffic 205 categories, or to achieve differentiated service offerings, it has 206 proven problematic to enable its use for these purposes end-to-end 207 across the Internet. 209 This difficulty is in part due to the fact that meeting (in an end- 210 to-end context) the performance requirements of an application 211 involves all of the networks in the path agreeing on what those 212 requirements are, and sharing an interest in meeting them. In many 213 cases this is made more difficult due to the fact that the 214 performance "requirements" are not strict ones (e.g. applications 215 will degrade in some manner as loss/latency/jitter increase), so the 216 importance of meeting them for any particular application in some 217 cases involves a judgment as to the value of avoiding some amount of 218 degradation in quality for that application in exchange for an 219 increase in the degradation of another application. 221 Further, in many cases the implementation of Diffserv PHBs has 222 historically involved prioritization of service classes with respect 223 to one another, which sets up the zero-sum game alluded to in the 224 previous paragraph, and results in the need to limit access to higher 225 priority classes via mechanisms such as access control, admission 226 control, traffic conditioning and rate policing, and/or to meter and 227 bill for carriage of such traffic. These mechanisms can be difficult 228 or impossible to implement in an end-to-end context. 230 Finally, some jurisdictions impose regulations that limit the ability 231 of networks to provide differentiation of services, in large part 232 based on the belief that doing so necessarily involves prioritization 233 or privileged access to bandwidth, and thus a benefit to one class of 234 traffic always comes at the expense of another. 236 In contrast, the NQB PHB has been designed with the goal that it 237 avoids many of these issues, and thus could conceivably be deployed 238 end-to-end across the Internet. The intent of the NQB DSCP is that 239 it signals verifiable behavior as opposed to wants and needs. Also, 240 the NQB traffic is to be given a separate queue with priority equal 241 to default traffic, and given no reserved bandwidth other than the 242 bandwidth that it shares with default traffic. As a result, the NQB 243 PHB does not aim to meet specific application performance 244 requirements. Instead the goal of the NQB PHB is to provide 245 statistically better loss, latency, and jitter performance for 246 traffic that is itself only an insignificant contributor to those 247 degradations. These attributes eliminate many of the tradeoffs that 248 underlie the handling of differentiated service classes in the 249 Diffserv architecture as it has traditionally been defined. They 250 also significantly simplify access control and admission control 251 functions, reducing them to simple verification of behavior. 253 5. DSCP Marking of NQB Traffic 255 Applications that align with the description of NQB behavior in the 256 preceding section SHOULD identify themselves to the network using a 257 Diffserv Code Point (DSCP) of 45 (decimal) so that their packets can 258 be queued separately from QB flows. If the application's traffic 259 exceeds more than a few packets per RTT, or exceeds approximately 1 260 Mbps on an instantaneous (inter-packet) basis, the application SHOULD 261 NOT mark its traffic with the NQB DSCP. In such a case, the 262 application SHOULD instead implement a congestion control mechanism, 263 for example as described in Section 3.1 of [RFC8085] or 264 [I-D.ietf-tsvwg-ecn-l4s-id]. 266 The choice of the value 45 is motivated in part by the desire to 267 achieve separate queuing in existing WiFi networks (see 268 Section 11.3). 270 It is worthwhile to note again that the NQB designation and marking 271 is intended to convey verifiable traffic behavior, not needs or 272 wants. Also, it is important that incentives are aligned correctly, 273 i.e. that there is a benefit to the application in marking its 274 packets correctly, and a disadvantage (or at least no benefit) to an 275 application in intentionally mismarking its traffic. Thus, a useful 276 property of nodes (i.e. network switches and routers) that support 277 separate queues for NQB and QB flows would be that for NQB flows, the 278 NQB queue provides better performance than the QB queue; and for QB 279 flows, the QB queue provides better performance than the NQB queue 280 (this is discussed further in Section 6 and Section 14). By adhering 281 to these principles, there is no incentive for senders to mismark 282 their traffic as NQB, and further, any mismarking can be identified 283 by the network. 285 Along these lines, nodes that do not support the NQB PHB SHOULD treat 286 NQB marked traffic the same as traffic marked "Default", and SHOULD 287 preserve the NQB marking. In backbone and core network switches 288 (particularly if shallow-buffered), and nodes that do not typically 289 experience congestion, treating NQB marked traffic the same as 290 "Default" may be sufficient to preserve latency performance for NQB 291 traffic. 293 5.1. End-to-end usage and DSCP Re-marking 295 In contrast to some existing standard PHBs, many of which are 296 typically only meaningful within a Diffserv Domain (e.g. an AS or an 297 enterprise network), this PHB is expected to be used end-to-end 298 across the Internet, wherever suitable operator agreements apply. 299 Under the [RFC2474] model, this requires that the corresponding DSCP 300 is recognized by all operators and mapped across their boundaries 301 accordingly. 303 Absent an explicit agreement to the contrary, networks that support 304 the NQB PHB SHOULD preserve a DSCP marking distinction between NQB 305 traffic and Default traffic when forwarding via an interconnect from 306 or to another network. To facilitate the default treatment of NQB 307 traffic in backbones and core networks, networks SHOULD remap NQB 308 traffic (DSCP 45) to DSCP 5 prior to interconnection, unless agreed 309 otherwise between the interconnecting partners. The fact that this 310 PHB is intended for end-to-end usage does not preclude networks from 311 mapping the NQB DSCP to a value other than 45 or 5 for internal 312 usage, as long as the appropriate NQB DSCP is restored when 313 forwarding to another network. Additionally, interconnecting 314 networks are not precluded from negotiating (via an SLA or some other 315 agreement) a different DSCP to use to signal NQB across the 316 interconnect. 318 In order to enable interoperability with WiFi equipment, networks 319 SHOULD remap NQB traffic (e.g. DSCP 5) to DSCP 45 prior to a 320 customer access link, subject to the safeguards described in 321 Section 11.3. 323 Thus, this document recommends two DSCPs to designate NQB, the value 324 45 for use by hosts and in WiFi networks, and the value 5 for use 325 across network interconnections. 327 5.2. Aggregation of the NQB PHB with other Diffserv PHBs 329 Networks and nodes that aggregate service classes as discussed in 330 [RFC5127] and [RFC8100] may not be able to provide a PDB/PHB that 331 meets the requirements of this document. In these cases it is 332 recommended that NQB-marked traffic be aggregated into the Elastic 333 Treatment Aggregate (for [RFC5127] networks) or the Default / Elastic 334 Treatment Aggregate (for [RFC8100] networks), although in some cases 335 a network operator may instead choose to aggregate NQB traffic into 336 the (Bulk) Real-Time Treatment Aggregate. Either approach comes with 337 trade-offs: aggregating with Default/Elastic traffic could result in 338 a degradation of loss/latency/jitter performance for NQB traffic, 339 while aggregating with Real-Time risks creating an incentive for 340 mismarking of non-compliant traffic as NQB. In either case, the NQB 341 DSCP SHOULD be preserved in order to limit the negative impact that 342 such networks would have on end-to-end performance for NQB traffic. 343 This aligns with recommendations in [RFC5127]. 345 Nodes that support the NQB PHB may choose to aggregate other service 346 classes into the NQB queue. Candidate service classes for this 347 aggregation would include those that carry inelastic traffic that has 348 low to very-low tolerance for loss, latency and/or jitter as 349 discussed in [RFC4594]. These could include Telephony (EF/VA), 350 Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video 351 (CS3). 353 6. Non-Queue-Building PHB Requirements 355 A node supporting the NQB PHB makes no guarantees on latency or data 356 rate for NQB marked flows, but instead aims to provide a bound on 357 queuing delay for as many such marked flows as it can, and shed load 358 when needed. 360 A node supporting the NQB PHB MUST provide a queue for non-queue- 361 building traffic separate from any queue used for queue-building 362 traffic. 364 NQB traffic, in aggregate, SHOULD NOT be rate limited or rate policed 365 separately from queue-building traffic of equivalent importance. 367 The NQB queue SHOULD be given equivalent forwarding preference 368 compared to queue-building traffic of equivalent importance. The 369 node SHOULD provide a scheduler that allows QB and NQB traffic of 370 equivalent importance to share the link in a fair manner, e.g. a 371 deficit round-robin scheduler with equal weights. Compliance with 372 these recommendations helps to ensure that there are no incentives 373 for QB traffic to be mismarked as NQB. 375 A node supporting the NQB PHB SHOULD treat traffic marked as Default 376 (DSCP=0) as QB traffic having equivalent importance to the NQB marked 377 traffic. A node supporting the NQB DSCP MUST support the ability to 378 configure the classification criteria that are used to identify QB 379 and NQB traffic of equivalent importance. 381 The NQB queue SHOULD have a buffer size that is significantly smaller 382 than the buffer provided for QB traffic (e.g. single-digit 383 milliseconds). It is expected that most QB traffic is engineered to 384 work well when the network provides a relatively deep buffer (e.g. on 385 the order of tens or hundreds of ms) in nodes where support for the 386 NQB PHB is advantageous (i.e. bottleneck nodes). Providing a 387 similarly deep buffer for the NQB queue would be at cross purposes to 388 providing very low queueing delay, and would erode the incentives for 389 QB traffic to be marked correctly. 391 It is possible that due to an implementation error or 392 misconfiguration, a QB flow would end up getting mismarked as NQB, or 393 vice versa. In the case of an NQB flow that isn't marked as NQB and 394 ends up in the QB queue, it would only impact its own quality of 395 service, and so it seems to be of lesser concern. However, a QB flow 396 that is mismarked as NQB would cause queuing delays and/or loss for 397 all of the other flows that are sharing the NQB queue. 399 To prevent this situation from harming the performance of the real 400 NQB flows, network elements that support differentiating NQB traffic 401 SHOULD support a "traffic protection" function that can identify QB 402 flows that are mismarked as NQB, and either reclassify those flows/ 403 packets to the QB queue or discard the offending traffic. Such a 404 function SHOULD be implemented in an objective and verifiable manner, 405 basing its decisions upon the behavior of the flow rather than on 406 application-layer constructs. One example algorithm can be found in 407 [I-D.briscoe-docsis-q-protection]. There are some situations where 408 such function may not be necessary. For example, a network element 409 designed for use in controlled environments (e.g. enterprise LAN) may 410 not require a traffic protection function. Additionally, some 411 networks may prefer to police the application of the NQB DSCP at the 412 ingress edge, so that in-network traffic protection is not needed. 414 7. Impact on Higher Layer Protocols 416 Network elements that support the NQB PHB and that support traffic 417 protection as discussed in the previous section introduce the 418 possibility that flows classified into the NQB queue could experience 419 out of order delivery or packet loss if their behavior is not 420 consistent with NQB. This is particularly true if the traffic 421 protection algorithm makes decisions on a packet-by-packet basis. In 422 this scenario, a flow that is (mis)marked as NQB and that causes a 423 queue to form in this bottleneck link could see some of its packets 424 forwarded by the NQB queue, and some of them either discarded or 425 redirected to the QB queue. In the case of redirection, depending on 426 the queueing latency and scheduling within the network element, this 427 could result in packets being delivered out of order. As a result, 428 the use of the NQB DSCP by a higher layer protocol carries some risk 429 that an increased amount of out of order delivery or packet loss will 430 be experienced. This characteristic provides one disincentive for 431 mis-marking of traffic. 433 8. The NQB PHB and Tunnels 435 [RFC2983] discusses tunnel models that support Diffserv. It 436 describes a "uniform model" in which the inner DSCP is copied to the 437 outer header at encapsulation, and the outer DSCP is copied to the 438 inner header at decapsulation. It also describes a "pipe model" in 439 which the outer DSCP is not copied to the inner header at 440 decapsulation. Both models can be used in conjunction with the NQB 441 PHB. In the case of the pipe model, any DSCP manipulation (re- 442 marking) of the outer header by intermediate nodes would be discarded 443 at tunnel egress, potentially improving the possibility of achieving 444 NQB treatment in subsequent nodes. 446 As is discussed in [RFC2983], tunnel protocols that are sensitive to 447 reordering can result in undesirable interactions if multiple DSCP 448 PHBs are signaled for traffic within a tunnel instance. This is true 449 for NQB marked traffic as well. If a tunnel contains a mix of QB and 450 NQB traffic, and this is reflected in the outer DSCP in a network 451 that supports the NQB PHB, it would be necessary to avoid a 452 reordering-sensitive tunnel protocol. 454 9. Relationship to L4S 456 Traffic flows marked with the NQB DSCP as described in this draft are 457 intended to be compatible with [I-D.ietf-tsvwg-l4s-arch], with the 458 result being that NQB traffic and L4S traffic can share the low- 459 latency queue in an L4S DualQ node 460 [I-D.ietf-tsvwg-aqm-dualq-coupled]. Compliance with the DualQ 461 Coupled AQM requirements (Section 2.5 of 462 [I-D.ietf-tsvwg-aqm-dualq-coupled]) is considered sufficient to 463 enable fair allocation of bandwidth between the QB and NQB queues. 465 10. Configuration and Management 467 As required above, nodes supporting the NQB PHB provide for the 468 configuration of classifiers that can be used to differentiate 469 between QB and NQB traffic of equivalent importance. The default for 470 such classifiers is recommended to be the assigned NQB DSCP (to 471 identify NQB traffic) and the Default (0) DSCP (to identify QB 472 traffic). 474 11. Example Use Cases 476 11.1. DOCSIS Access Networks 478 Residential cable broadband Internet services are commonly configured 479 with a single bottleneck link (the access network link) upon which 480 the service definition is applied. The service definition, typically 481 an upstream/downstream data rate tuple, is implemented as a 482 configured pair of rate shapers that are applied to the user's 483 traffic. In such networks, the quality of service that each 484 application receives, and as a result, the quality of experience that 485 it generates for the user is influenced by the characteristics of the 486 access network link. 488 To support the NQB PHB, cable broadband services MUST be configured 489 to provide a separate queue for NQB marked traffic. The NQB queue 490 MUST be configured to share the service's rate shaped bandwidth with 491 the queue for QB traffic. 493 11.2. Mobile Networks 495 Historically, mobile networks have been configured to bundle all 496 flows to and from the Internet into a single "default" EPS bearer 497 whose buffering characteristics are not compatible with low-latency 498 traffic. The established behaviour is rooted partly in the desire to 499 prioritise operators' voice services over competing over-the-top 500 services and partly in the fact that the addition of bearers was 501 prohibitive due to expense. Of late, said consideration seems to 502 have lost momentum (e.g., with the rise in Multi-RAB (Radio Access 503 Bearer) devices) and the incentives might now be aligned towards 504 allowing a more suitable treatment of Internet real-time flows. 506 To support the NQB PHB, the mobile network SHOULD be configured to 507 give UEs a dedicated, low-latency, non-GBR, EPS bearer, e.g. one with 508 QCI 7, in addition to the default EPS bearer; or a Data Radio Bearer 509 with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS 510 characteristics mapping in [SA-5G]). 512 A packet carrying the NQB DSCP SHOULD be routed through the dedicated 513 low-latency EPS bearer. A packet that has no associated NQB marking 514 SHOULD NOT be routed through the dedicated low-latency EPS bearer. 516 11.3. WiFi Networks 518 WiFi networking equipment compliant with 802.11e/n/ac/ax [IEEE802-11] 519 generally supports either four or eight transmit queues and four sets 520 of associated Enhanced Multimedia Distributed Control Access (EDCA) 521 parameters (corresponding to the four WiFi Multimedia (WMM) Access 522 Categories) that are used to enable differentiated media access 523 characteristics. As discussed in [RFC8325], most existing WiFi 524 implementations use a default DSCP to User Priority mapping that 525 utilizes the most significant three bits of the Diffserv Field to 526 select "User Priority" which is then mapped to the four WMM Access 527 Categories. [RFC8325] also provides an alternative mapping that more 528 closely aligns with the DSCP recommendations provided by the IETF. 530 In addition to the requirements provided in other sections of this 531 document, to support the NQB PHB, WiFi equipment SHOULD map the NQB 532 codepoint 45 into a separate queue that shares an Access Category 533 with default traffic (i.e. the Best Effort Access Category). 535 11.3.1. Interoperability with Existing WiFi Networks 537 While some existing WiFi equipment may be capable (in some cases via 538 firmware update) of supporting the NQB PHB requirements, many 539 currently deployed devices cannot be configured in this way. As a 540 result the remainder of this section discusses interoperability with 541 these existing WiFi networks, as opposed to PHB compliance. 543 In order to increase the likelihood that NQB traffic is provided a 544 separate queue from QB traffic in existing WiFi equipment that uses 545 the default mapping, the 45 code point is recommended for NQB. This 546 maps NQB to UP_5 which is in the "Video" Access Category. While this 547 DSCP to User Priority mapping enables these WiFi systems to support 548 the NQB PHB requirement for segregated queuing, it does not support 549 the remaining NQB PHB requirements in Section 6. The ramifications 550 of, and remedies for this are discussed further below. 552 Existing WiFi devices are unlikely to support a traffic protection 553 algorithm, so traffic mismarked as NQB is not likely to be detected 554 and remedied by such devices. 556 Furthermore, in their default configuration, existing WiFi devices 557 utilize EDCA parameters that result in statistical prioritization of 558 the "Video" Access Category above the "Best Effort" Access Category. 559 If left unchanged, this would violate the NQB PHB requirement for 560 equal prioritization, and could erode the principle of alignment of 561 incentives. In order to preserve the incentives principle for NQB, 562 WiFi systems SHOULD configure the EDCA parameters for the Video 563 Access Category to match those of the Best Effort Access Category. 565 In cases where a network operator is delivering traffic into an 566 unmanaged WiFi network outside of their control (e.g. a residential 567 ISP delivering traffic to a customer's home network), the network 568 operator should presume that the existing WiFi equipment does not 569 support the safeguards that are provided by the NQB PHB requirements, 570 and thus should take precautions to prevent issues. When the data 571 rate of the access network segment is less than the expected data 572 rate of the WiFi network, this is unlikely to be an issue. However, 573 if the access network rate exceeds the expected rate of the WiFi 574 network, the operator SHOULD deploy a policing function on NQB marked 575 traffic that minimizes the potential for negative impacts on traffic 576 marked Default, for example by limiting the rate of such traffic to a 577 set fraction of the customer's service rate, with excess traffic 578 either dropped or re-marked as Default. 580 As an additional safeguard, and to prevent the inadvertent 581 introduction of problematic traffic into unmanaged WiFi networks, 582 network equipment that is intended to deliver traffic into unmanaged 583 WiFi networks (e.g. an access network gateway for a residential ISP) 584 MUST by default ensure that NQB traffic is marked with a DSCP that 585 selects the "Best Effort" Access Category. Such equipment MUST 586 support the ability to configure the remapping, so that (when 587 appropriate safeguards are in place) traffic can be delivered as NQB- 588 marked. 590 Similarly, systems that utilize [RFC8325] but that are unable to 591 fully support the PHB requirements, SHOULD map the recommended NQB 592 code point 45 (or the locally determined alternative) to UP_5 in the 593 "Video" Access Category. 595 12. Acknowledgements 597 Thanks to Stuart Cheshire, Brian Carpenter, Bob Briscoe, Greg 598 Skinner, Toke Hoeiland-Joergensen, Luca Muscariello, David Black, 599 Sebastian Moeller, Ruediger Geib, Jerome Henry, Steven Blake, 600 Jonathan Morton, Roland Bless, Kevin Smith, Martin Dolly, and Kyle 601 Rose for their review comments. Thanks also to Gorry Fairhurst, Ana 602 Custura, and Ruediger Geib for their input on selection of 603 appropriate DSCPs. 605 13. IANA Considerations 607 This document requests that IANA assign the Differentiated Services 608 Field Codepoints (DSCP) 5 ('0b000101', 0x05) and 45 ('0b101101', 609 0x2D) from the "Differentiated Services Field Codepoints (DSCP)" 610 registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP 611 Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action) as the 612 RECOMMENDED codepoints for Non-Queue-Building behavior. 614 14. Security Considerations 616 When the NQB PHB is fully supported in bottleneck links, there is no 617 incentive for an application to mismark its packets as NQB (or vice 618 versa). If a queue-building flow were to mark its packets as NQB, it 619 would be unlikely to receive a benefit by doing so, and it could 620 experience excessive packet loss, excessive latency variation and/or 621 excessive out-of-order delivery (depending on the nature of the 622 traffic protection function). If a non-queue-building flow were to 623 fail to mark its packets as NQB, it could suffer the latency and loss 624 typical of sharing a queue with capacity seeking traffic. 626 In order to preserve low latency performance for NQB traffic, 627 networks that support the NQB PHB will need to ensure that mechanisms 628 are in place to prevent malicious NQB-marked traffic from causing 629 excessive queue delays. This document recommends the implementation 630 of a traffic protection mechanism to achieve this goal, but 631 recognizes that other options may be more desirable in certain 632 situations. 634 Notwithstanding the above, the choice of DSCP for NQB does allow 635 existing WiFi networks to readily (and by default) support some of 636 the PHB requirements, but without a traffic protection function, and 637 (when left in the default state) by giving NQB traffic higher 638 priority than QB traffic. This does open up the NQB marking to 639 potential abuse on these WiFi links, but since these existing WiFi 640 networks already give one quarter of the DSCP space this same 641 treatment, and further they give another quarter of the DSCP space 642 even higher priority, the NQB DSCP does not seem to be of any greater 643 risk for abuse than these others. 645 The NQB signal is not integrity protected and could be flipped by an 646 on-path attacker. This might negatively affect the QoS of the 647 tampered flow. 649 15. References 651 15.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 659 "Definition of the Differentiated Services Field (DS 660 Field) in the IPv4 and IPv6 Headers", RFC 2474, 661 DOI 10.17487/RFC2474, December 1998, 662 . 664 [RFC2983] Black, D., "Differentiated Services and Tunnels", 665 RFC 2983, DOI 10.17487/RFC2983, October 2000, 666 . 668 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 669 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 670 March 2017, . 672 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 673 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 674 May 2017, . 676 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 677 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 678 2018, . 680 15.2. Informative References 682 [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and 683 S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement 684 Study", ITC 30, September 2018. 686 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 687 modification pathologies in mobile edge networks", TMA , 688 2017. 690 [I-D.briscoe-docsis-q-protection] 691 Briscoe, B. and G. White, "Queue Protection to Preserve 692 Low Latency", Work in Progress, Internet-Draft, draft- 693 briscoe-docsis-q-protection-00, 8 July 2019, 694 . 697 [I-D.ietf-tsvwg-aqm-dualq-coupled] 698 Schepper, K., Briscoe, B., and G. White, "DualQ Coupled 699 AQMs for Low Latency, Low Loss and Scalable Throughput 700 (L4S)", Work in Progress, Internet-Draft, draft-ietf- 701 tsvwg-aqm-dualq-coupled-13, 15 November 2020, 702 . 705 [I-D.ietf-tsvwg-ecn-l4s-id] 706 Schepper, K. and B. Briscoe, "Identifying Modified 707 Explicit Congestion Notification (ECN) Semantics for 708 Ultra-Low Queuing Delay (L4S)", Work in Progress, 709 Internet-Draft, draft-ietf-tsvwg-ecn-l4s-id-12, 15 710 November 2020, . 713 [I-D.ietf-tsvwg-l4s-arch] 714 Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low 715 Latency, Low Loss, Scalable Throughput (L4S) Internet 716 Service: Architecture", Work in Progress, Internet-Draft, 717 draft-ietf-tsvwg-l4s-arch-08, 15 November 2020, 718 . 721 [IEEE802-11] 722 IEEE-SA, "IEEE 802.11-2020", IEEE 802, December 2020, 723 . 725 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 726 and W. Weiss, "An Architecture for Differentiated 727 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 728 . 730 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 731 Video Conferences with Minimal Control", RFC 3551, July 732 2003, . 734 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 735 Guidelines for Diffserv Service Classes", RFC 4594, 736 DOI 10.17487/RFC4594, August 2006, 737 . 739 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 740 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 741 February 2008, . 743 [RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, "Pseudowire 744 Congestion Considerations", RFC 7893, June 2016, 745 . 747 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 748 "Proportional Integral Controller Enhanced (PIE): A 749 Lightweight Control Scheme to Address the Bufferbloat 750 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 751 . 753 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 754 on Proportional Integral Controller Enhanced PIE) for 755 Data-Over-Cable Service Interface Specifications (DOCSIS) 756 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 757 2017, . 759 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 760 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 761 March 2017, . 763 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 764 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 765 March 2017, . 767 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 768 Iyengar, Ed., "Controlled Delay Active Queue Management", 769 RFC 8289, DOI 10.17487/RFC8289, January 2018, 770 . 772 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 774 Appendix A. DSCP Remarking Pathologies 776 Some network operators typically bleach (zero out) the Diffserv field 777 on ingress into their network [Custura][Barik], and in some cases 778 apply their own DSCP for internal usage. Bleaching the NQB DSCP is 779 not expected to cause harm to default traffic, but it will severely 780 limit the ability to provide NQB treatment end-to-end. Reports on 781 existing deployments of DSCP manipulation [Custura][Barik] categorize 782 the re-marking behaviors into the following six policies: bleach all 783 traffic (set DSCP to zero), set the top three bits (the former 784 Precedence bits) on all traffic to 0b000, 0b001, or 0b010, set the 785 low three bits on all traffic to 0b000, or remark all traffic to a 786 particular (non-zero) DSCP value. 788 Regarding the DSCP values of 5 & 45, there were no observations of 789 DSCP manipulation reported in which traffic was marked 5 or 45 by any 790 of these policies. Thus it appears that these re-marking policies 791 would be unlikely to result in QB traffic being marked as NQB (45). 792 In terms of the fate of NQB-marked traffic that is subjected to one 793 of these policies, the result would be that NQB marked traffic would 794 be indistinguishable from some subset (possibly all) of other 795 traffic. In the policies where all traffic is remarked using the 796 same (zero or non-zero) DSCP, the ability for a subsequent network 797 hop to differentiate NQB traffic via DSCP would clearly be lost 798 entirely. 800 In the policies where the top three bits are overwritten, both NQB 801 values (5 & 45) would receive the same marking as would the currently 802 unassigned Pool 3 DSCPs 13,21,29,37,53,61, with all of these code 803 points getting mapped to DSCP=5, 13 or 21 (depending on the overwrite 804 value used). Since none of the DSCPs in the preceding lists are 805 currently assigned by IANA, and they all are set aside for Standards 806 Action, it is believed that they are not widely used currently, but 807 this may vary based on local-usage. 809 For the policy in which the low three bits are set to 0b000, the NQB 810 (45) value would be mapped to CS5 and would be indistinguishable from 811 CS5, VA, EF (and the unassigned DSCPs 41, 42, 43). Traffic marked 812 using the existing standardized DSCPs in this list are likely to 813 share the same general properties as NQB traffic (non capacity- 814 seeking, very low data rate or relatively low and consistent data 815 rate). Similarly, any future recommended usage for DSCPs 41, 42, 43 816 would likely be somewhat compatible with NQB treatment, assuming that 817 IP Precedence compatibility (see Section 1.5.4 of [RFC4594]) is 818 maintained in the future. Here there may be an opportunity for a 819 node to provide the NQB PHB or the CS5 PHB to CS5-marked traffic and 820 retain some of the benefits of NQB marking. This could be another 821 motivation to (as discussed in Section 5.2) classify CS5-marked 822 traffic into NQB queue. For this same re-marking policy, the NQB (5) 823 value would be mapped to CS0/default and would be indistinguishable 824 from CS0, LE (and the unassigned DSCPs 2,3,4,6,7). In this case, NQB 825 traffic is likely to be given default treatment in all subsequent 826 nodes, which would eliminate the ability to provide NQB treatment in 827 those nodes, but would be relatively harmless otherwise. 829 Authors' Addresses 831 Greg White 832 CableLabs 834 Email: g.white@cablelabs.com 836 Thomas Fossati 837 ARM 839 Email: Thomas.Fossati@arm.com