idnits 2.17.1 draft-ietf-tsvwg-nqb-01.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 (March 9, 2020) is 1508 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-10 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-05 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 10, 2020 ARM 6 March 9, 2020 8 A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated 9 Services 10 draft-ietf-tsvwg-nqb-01 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 September 10, 2020. 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 5. Non-Queue-Building PHB Requirements . . . . . . . . . . . . . 5 68 6. Relationship to L4S . . . . . . . . . . . . . . . . . . . . . 6 69 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. DOCSIS Access Networks . . . . . . . . . . . . . . . . . 6 71 7.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 6 72 7.3. WiFi Networks . . . . . . . . . . . . . . . . . . . . . . 7 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 11. Informative References . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 This document defines a Differentiated Services (DS) per-hop behavior 82 (PHB) called "Non-Queue-Building Per-Hop Behavior" (NQB PHB), which 83 is intended to enable networks to provide low latency and low loss 84 for traffic flows that are relatively low data rate and that do not 85 themselves materially contribute to queueing delay and loss. Such 86 Non-Queue-Building flows (for example: interactive voice and video, 87 gaming, machine to machine applications) are application limited 88 flows that are distinguished from traffic flows managed by an end-to- 89 end congestion control algorithm. 91 The vast majority of packets that are carried by broadband access 92 networks are, in fact, managed by an end-to-end congestion control 93 algorithm, such as Reno, Cubic or BBR. These congestion control 94 algorithms attempt to seek the available capacity of the end-to-end 95 path (which can frequently be the access network link capacity), and 96 in doing so generally overshoot the available capacity, causing a 97 queue to build-up at the bottleneck link. This queue build up 98 results in queuing delay (variable latency) and possibly packet loss 99 that affects all of the applications that are sharing the bottleneck 100 link. 102 In contrast to traditional congestion-controlled applications, there 103 are a variety of relatively low data rate applications that do not 104 materially contribute to queueing delay and loss, but are nonetheless 105 subjected to it by sharing the same bottleneck link in the access 106 network. Many of these applications may be sensitive to latency or 107 latency variation, as well as packet loss, and thus produce a poor 108 quality of experience in such conditions. 110 Active Queue Management (AQM) mechanisms (such as PIE [RFC8033], 111 DOCSIS-PIE [RFC8034], or CoDel [RFC8289]) can improve the quality of 112 experience for latency sensitive applications, but there are 113 practical limits to the amount of improvement that can be achieved 114 without impacting the throughput of capacity-seeking applications, 115 particularly when only a few of such flows are present. 117 The NQB PHB supports differentiating between these two classes of 118 traffic in bottleneck links and queuing them separately in order that 119 both classes can deliver satisfactory quality of experience for their 120 applications. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Overview: Non-Queue-Building Flows 132 There are many applications that send traffic at relatively low data 133 rates and/or in a fairly smooth and consistent manner such that they 134 are highly unlikely to exceed the available capacity of the network 135 path between source and sink. These applications do not cause queues 136 to form in network buffers, but nonetheless can be subjected to 137 packet delay and delay variation as a result of sharing a network 138 buffer with applications that do cause queues. Many of these 139 applications are negatively affected by excessive packet delay and 140 delay variation. Such applications are ideal candidates to be queued 141 separately from the capacity-seeking applications that are the cause 142 of queue buildup, latency and loss. 144 These Non-queue-building (NQB) flows are typically UDP flows that 145 don't seek the capacity of the link (examples: online games, voice 146 chat, DNS lookups, real-time IoT analytics data). Here the data rate 147 is limited by the Application itself rather than by network capacity 148 - in many cases these applications only send a few packets per RTT. 149 In contrast, Queue-building (QB) flows include traffic which uses the 150 Traditional TCP or QUIC, with BBR or other TCP congestion 151 controllers. 153 4. DSCP Marking of NQB Traffic 155 Applications that align with the above description of NQB behavior 156 SHOULD identify themselves to the network using a DiffServ Code Point 157 (DSCP) so that their packets can be queued separately from QB flows. 159 There are many application flows that fall very neatly into one or 160 the other of these categories, but there are also application flows 161 that may be in a gray area in between (e.g. they are NQB on higher- 162 speed links, but QB on lower-speed links). 164 If there is uncertainty as to whether an application's traffic aligns 165 with the description of NQB behavior in the preceding section, the 166 application SHOULD NOT mark its traffic with the NQB DSCP. In such a 167 case, the application SHOULD instead implement a congestion control 168 mechanism, for example as described in [RFC8085]. 170 This document recommends a DSCP of 0x2A to identify packets of NQB 171 flows. (editor's note: this value is subject to change) 173 It is worthwhile to note that the NQB designation and marking is 174 intended to convey verifiable traffic behavior, not needs or wants. 175 Also, it is important that incentives are aligned correctly, i.e. 176 that there is a benefit to the application in marking its packets 177 correctly, and no benefit to an application in intentionally 178 mismarking its traffic. Thus, a useful property of nodes that 179 support separate queues for NQB and QB flows would be that for NQB 180 flows, the NQB queue provides better performance than the QB queue; 181 and for QB flows, the QB queue provides better performance than the 182 NQB queue. By adhering to these principles, there is no incentive 183 for senders to mismark their traffic as NQB, and further, any 184 mismarking can be identified by the network. 186 In contrast to the existing standard DSCPs, which are typically only 187 meaningful within a DiffServ Domain (e.g. an AS or an enterprise 188 network), this DSCP is expected to be used end-to-end across the 189 Internet. Some network operators typically bleach (zero out) the 190 DiffServ field on ingress into their network [Custura], and in some 191 cases apply their own DSCP for internal usage. Networks that support 192 the NQB PHB SHOULD preserve the NQB DSCP when forwarding via an 193 interconnect from or to another network. 195 5. Non-Queue-Building PHB Requirements 197 A node supporting the NQB PHB makes no guarantees on latency or data 198 rate for NQB marked flows, but instead aims to provide a bound on 199 queuing delay for as many such marked flows as it can, and shed load 200 when needed. 202 A node supporting the NQB PHB MUST provide a queue for non-queue- 203 building traffic separate from the queue used for queue-building 204 traffic. 206 NQB traffic SHOULD NOT be rate limited or rate policed separately 207 from queue-building traffic of equivalent importance. 209 The NQB queue SHOULD be given equal priority compared to queue- 210 building traffic of equivalent importance. The node SHOULD provide a 211 scheduler that allows QB and NQB traffic of equivalent importance to 212 share the link in a fair manner, e.g. a deficit round-robin scheduler 213 with equal weights. 215 A node supporting the NQB PHB SHOULD treat traffic marked as Default 216 (DSCP=0x00) as QB traffic having equivalent importance to the NQB 217 marked traffic. 219 The NQB queue SHOULD have a buffer size that is significantly smaller 220 than the buffer provided for QB traffic. 222 It is possible that due to an implementation error or 223 misconfiguration, a QB flow would end up getting mismarked as NQB, or 224 vice versa. In the case of an NQB flow that isn't marked as NQB and 225 ends up in the QB queue, it would only impact its own quality of 226 service, and so it seems to be of lesser concern. However, a QB flow 227 that is mismarked as NQB would cause queuing delays and/or loss for 228 all of the other flows that are sharing the NQB queue. 230 To prevent this situation from harming the performance of the real 231 NQB flows, network elements that support differentiating NQB traffic 232 SHOULD (editor's note: SHOULD vs MUST is TBD) support a "traffic 233 protection" function that can identify QB flows that are mismarked as 234 NQB, and reclassify those flows/packets to the QB queue. Such a 235 function SHOULD be implemented in an objective and verifiable manner, 236 basing its decisions upon the behavior of the flow rather than on 237 application-layer constructs. One example algorithm can be found in 238 [I-D.briscoe-docsis-q-protection]. 240 6. Relationship to L4S 242 Traffic flows marked with the NQB DSCP as described in this draft are 243 intended to be compatible with [I-D.ietf-tsvwg-l4s-arch], with the 244 result being that NQB traffic and L4S traffic can share the low- 245 latency queue in an L4S dual-queue node 246 [I-D.ietf-tsvwg-aqm-dualq-coupled]. 248 7. Use Cases 250 7.1. DOCSIS Access Networks 252 Residential cable broadband Internet services are commonly configured 253 with a single bottleneck link (the access network link) upon which 254 the service definition is applied. The service definition, typically 255 an upstream/downstream data rate tuple, is implemented as a 256 configured pair of rate shapers that are applied to the user's 257 traffic. In such networks, the quality of service that each 258 application receives, and as a result, the quality of experience that 259 it generates for the user is influenced by the characteristics of the 260 access network link. 262 To support the NQB PHB, cable broadband services MUST be configured 263 to provide a separate queue for NQB marked traffic. The NQB queue 264 MUST be configured to share the service's rate shaping bandwidth with 265 the queue for QB traffic. 267 7.2. Mobile Networks 269 Historically, mobile networks have been configured to bundle all 270 flows to and from the Internet into a single "default" EPS bearer 271 whose buffering characteristics are not compatible with low-latency 272 traffic. The established behaviour is rooted partly in the desire to 273 prioritise operators' voice services over competing over-the-top 274 services and partly in the fact that the addition of bearers was 275 prohibitive due to expense. Of late, said consideration seems to 276 have lost momentum (e.g., with the rise in Multi-RAB (Radio Access 277 Bearer) devices) and the incentives might now be aligned towards 278 allowing a more suitable treatment of Internet real-time flows. 280 To support the NQB PHB, the mobile network SHOULD be configured to 281 give UEs a dedicated, low-latency, non-GBR, EPS bearer, e.g. one with 282 QCI 7, in addition to the default EPS bearer; or a Data Radio Bearer 283 with 5QI 7 in a 5G system (see Table 5.7.4-1: Standardized 5QI to QoS 284 characteristics mapping in [SA-5G]). 286 A packet carrying the NQB DSCP SHOULD be routed through the dedicated 287 low-latency EPS bearer. A packet that has no associated NQB marking 288 SHOULD be routed through the default EPS bearer. 290 7.3. WiFi Networks 292 WiFi networking equipment compliant with 802.11e generally supports 293 either four or eight transmit queues and four sets of associated 294 Enhanced Multimedia Distributed Control Access (EDCA) parameters 295 (corresponding to the four WiFi Multimedia (WMM) Access Categories) 296 that are used to enable differentiated media access characteristics. 297 Implementations typically utilize the IP DSCP field to select a 298 transmit queue, but should be considered as Non-Differentiated 299 Services-Compliant Nodes as described in Section 4 of [RFC2475] 300 because this transmit queue selection is a local implementation 301 characteristic that is not part of a consistently operated DiffServ 302 domain or region. As a result this document discusses 303 interoperability with WiFi networks, as opposed to PHB compliance. 305 As discussed in [RFC8325], most existing WiFi implementations use a 306 default DSCP to User Priority mapping that utilizes the most 307 significant three bits of the DiffServ Field to select "User 308 Priority" which is then mapped to the four WMM Access Categories. In 309 order to increase the likelihood that NQB traffic is provided a 310 separate queue from QB traffic in existing WiFi equipment, the 0x2A 311 codepoint is preferred for NQB. This would map NQB to UP_5 which is 312 in the "Video" Access Category. Similarly, systems that utilize 313 [RFC8325], SHOULD map the NQB codepoint to UP_5 in the "Video" Access 314 Category. 316 While the DSCP to User Priority mapping can enable WiFi systems to 317 support the NQB PHB requirement for segregated queuing, many 318 currently deployed WiFi systems may not be capable of supporting the 319 remaining NQB PHB requirements in Section 5. This is discussed 320 further below. 322 Existing WiFi devices are unlikely to support a traffic protection 323 algorithm, so traffic mismarked as NQB is not likely to be detected 324 and remedied by such devices. 326 Furthermore, in their default configuration, existing WiFi devices 327 utilize EDCA parameters that result in statistical prioritization of 328 the "Video" Access Category above the "Best Effort" Access Category. 329 If left unchanged, this would violate the NQB PHB requirement for 330 equal prioritization, and could erode the principle of alignment of 331 incentives. In order to preserve the incentives principle, WiFi 332 systems SHOULD configure the EDCA parameters for the Video Access 333 Category to match those of the Best Effort Access Category. 335 In cases where a network operator is delivering traffic into an 336 unmanaged WiFi network outside of their control (e.g. a residential 337 ISP delivering traffic to a customer's home network), the network 338 operator should presume that the existing WiFi equipment does not 339 support the safeguards that are provided by the NQB PHB requirements, 340 and thus should take precautions to prevent issues. In these 341 situations, the operator SHOULD deploy a policing function on NQB 342 marked traffic that minimizes the potential for starvation of traffic 343 marked Default, for example by limiting the rate of such traffic to a 344 set fraction of the customer's service rate. 346 As an additional safeguard, and to prevent the inadvertent 347 introduction of problematic traffic into unmanaged WiFi networks, 348 network equipment that is intended to deliver traffic into unmanaged 349 WiFi networks (e.g. an access network gateway for a residential ISP) 350 MUST by default remap the NQB DSCP to Default. Such equipment MUST 351 support the ability to configure the remapping, so that (when 352 appropriate safeguards are in place) traffic can be delivered as NQB- 353 marked. 355 8. Acknowledgements 357 Thanks to Bob Briscoe, Greg Skinner, Toke Hoeiland-Joergensen, Luca 358 Muscariello, David Black, Sebastian Moeller, Ruediger Geib, Jerome 359 Henry, Steven Blake, Jonathan Morton, Roland Bless, Kevin Smith, 360 Martin Dolly, and Kyle Rose for their review comments. 362 9. IANA Considerations 364 This draft proposes the registration of a standardized DSCP = 0x2A to 365 denote Non-Queue-Building behavior. 367 10. Security Considerations 369 There is no incentive for an application to mismark its packets as 370 NQB (or vice versa). If a queue-building flow were to mark its 371 packets as NQB, it could experience excessive packet loss (in the 372 case that traffic protection is not supported by a node) or it could 373 receive no benefit (in the case that traffic protection is 374 supported). If a non-queue-building flow were to fail to mark its 375 packets as NQB, it could suffer the latency and loss typical of 376 sharing a queue with capacity seeking traffic. 378 The NQB signal is not integrity protected and could be flipped by an 379 on-path attacker. This might negatively affect the QoS of the 380 tampered flow. 382 11. Informative References 384 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 385 modification pathologies in mobile edge networks", TMA , 386 2017. 388 [I-D.briscoe-docsis-q-protection] 389 Briscoe, B. and G. White, "Queue Protection to Preserve 390 Low Latency", draft-briscoe-docsis-q-protection-00 (work 391 in progress), July 2019. 393 [I-D.ietf-tsvwg-aqm-dualq-coupled] 394 Schepper, K., Briscoe, B., and G. White, "DualQ Coupled 395 AQMs for Low Latency, Low Loss and Scalable Throughput 396 (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-10 (work in 397 progress), July 2019. 399 [I-D.ietf-tsvwg-l4s-arch] 400 Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low 401 Latency, Low Loss, Scalable Throughput (L4S) Internet 402 Service: Architecture", draft-ietf-tsvwg-l4s-arch-05 (work 403 in progress), February 2020. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 411 and W. Weiss, "An Architecture for Differentiated 412 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 413 . 415 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 416 "Proportional Integral Controller Enhanced (PIE): A 417 Lightweight Control Scheme to Address the Bufferbloat 418 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 419 . 421 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 422 on Proportional Integral Controller Enhanced PIE) for 423 Data-Over-Cable Service Interface Specifications (DOCSIS) 424 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 425 2017, . 427 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 428 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 429 March 2017, . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 436 Iyengar, Ed., "Controlled Delay Active Queue Management", 437 RFC 8289, DOI 10.17487/RFC8289, January 2018, 438 . 440 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 441 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 442 2018, . 444 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 446 Authors' Addresses 448 Greg White 449 CableLabs 451 Email: g.white@cablelabs.com 453 Thomas Fossati 454 ARM 456 Email: Thomas.Fossati@arm.com