--- 1/draft-ietf-tsvwg-aqm-dualq-coupled-22.txt 2022-05-04 10:13:17.069057870 -0700 +++ 2/draft-ietf-tsvwg-aqm-dualq-coupled-23.txt 2022-05-04 10:13:17.197061103 -0700 @@ -1,22 +1,22 @@ Transport Area working group (tsvwg) K. De Schepper Internet-Draft Nokia Bell Labs Intended status: Experimental B. Briscoe, Ed. -Expires: 5 September 2022 Independent +Expires: 5 November 2022 Independent G. White CableLabs - 4 March 2022 + 4 May 2022 DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) - draft-ietf-tsvwg-aqm-dualq-coupled-22 + draft-ietf-tsvwg-aqm-dualq-coupled-23 Abstract This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very Low queuing Latency, very Low congestion Loss and Scaling of @@ -42,21 +42,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 5 September 2022. + This Internet-Draft will expire on 5 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -67,28 +67,28 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Outline of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Features . . . . . . . . . . . . . . . . . . . . . . . . 9 2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 12 + 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 13 - 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 13 + 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 14 2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 17 2.5.1. Functional Requirements . . . . . . . . . . . . . . . 17 2.5.1.1. Requirements in Unexpected Cases . . . . . . . . 18 2.5.2. Management Requirements . . . . . . . . . . . . . . . 19 - 2.5.2.1. Configuration . . . . . . . . . . . . . . . . . . 19 + 2.5.2.1. Configuration . . . . . . . . . . . . . . . . . . 20 2.5.2.2. Monitoring . . . . . . . . . . . . . . . . . . . 21 2.5.2.3. Anomaly Detection . . . . . . . . . . . . . . . . 22 2.5.2.4. Deployment, Coexistence and Scaling . . . . . . . 22 3. IANA Considerations (to be removed by RFC Editor) . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4.1. Low Delay without Requiring Per-Flow Processing . . . . . 22 4.2. Handling Unresponsive Flows and Overload . . . . . . . . 23 4.2.1. Unresponsive Traffic without Overload . . . . . . . . 24 4.2.2. Avoiding Short-Term Classic Starvation: Sacrifice L4S Throughput or Delay? . . . . . . . . . . . . . . . . 25 @@ -96,21 +96,21 @@ 4.2.3. L4S ECN Saturation: Introduce Drop or Delay? . . . . 26 4.2.3.1. Protecting against Overload by Unresponsive ECN-Capable Traffic . . . . . . . . . . . . . . . . 28 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 35 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 36 - A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 46 + A.2. Pass #2: Edge-Case Details . . . . . . . . . . . . . . . 47 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 51 B.1. Curvy RED in Pseudocode . . . . . . . . . . . . . . . . . 51 B.2. Efficient Implementation of Curvy RED . . . . . . . . . . 57 Appendix C. Choice of Coupling Factor, k . . . . . . . . . . . . 59 C.1. RTT-Dependence . . . . . . . . . . . . . . . . . . . . . 59 C.2. Guidance on Controlling Throughput Equivalence . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 1. Introduction @@ -300,20 +300,25 @@ outside the scope of this AQM document, even though the AQM is an enabler. The overall L4S architecture [I-D.ietf-tsvwg-l4s-arch] gives more detail, including on wider deployment aspects such as backwards compatibility of Scalable congestion controls in bottlenecks where a DualQ Coupled AQM has not been deployed. The supporting papers [DualPI2Linux], [PI2], [DCttH19] and [PI2param] give the full rationale for the AQM's design, both discursively and in more precise mathematical form, as well as the results of performance evaluations. + The main results have been validated independently when using the + Prague congestion control [Boru20] (experiments are run using Prague + and DCTCP, but only the former are relevant for validation, because + Prague fixes a number of problems with the Linux DCTCP code that make + it unsuitable for the public Internet). 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when, and only when, they appear in all capitals, as shown here. The DualQ Coupled AQM uses two queues for two services. Each of the following terms identifies both the service and the queue that @@ -1327,23 +1331,23 @@ implementations were tested. 7. References 7.1. Normative References [I-D.ietf-tsvwg-ecn-l4s-id] Schepper, K. D. and B. Briscoe, "Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)", Work in Progress, Internet-Draft, draft-ietf- - tsvwg-ecn-l4s-id-24, 1 February 2022, + tsvwg-ecn-l4s-id-25, 4 March 2022, . + ecn-l4s-id-25>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . @@ -1370,20 +1374,26 @@ [ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An Algorithm for Increasing the Robustness of RED's Active Queue Management", ACIRI Technical Report , August 2001, . [BBRv2] Cardwell, N., "BRTCP BBR v2 Alpha/Preview Release", github repository; Linux congestion control module, . + [Boru20] Boru Oljira, D., Grinnemo, K-J., Brunstrom, A., and J. + Taheri, "Validating the Sharing Behavior and Latency + Characteristics of the L4S Architecture", ACM CCR + 50(2):37--44, May 2020, + . + [CCcensus19] Mishra, A., Sun, X., Jain, A., Pande, S., Joshi, R., and B. Leong, "The Great Internet TCP Congestion Control Census", Proc. ACM on Measurement and Analysis of Computing Systems 3(3), December 2019, . [CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM Queue 10(5), May 2012, . @@ -1420,54 +1430,54 @@ . [Heist21] Heist, P. and J. Morton, "L4S Tests", github README, August 2021, . [I-D.briscoe-docsis-q-protection] Briscoe, B. and G. White, "The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency", Work in Progress, - Internet-Draft, draft-briscoe-docsis-q-protection-02, 31 - January 2022, . + Internet-Draft, draft-briscoe-docsis-q-protection-03, 7 + March 2022, . [I-D.briscoe-iccrg-prague-congestion-control] Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague Congestion Control", Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-00, 9 March 2021, . [I-D.briscoe-tsvwg-l4s-diffserv] Briscoe, B., "Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services", Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s- diffserv-02, 4 November 2018, . [I-D.cardwell-iccrg-bbr-congestion-control] Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. Jacobson, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion- - control-01, 7 November 2021, + control-02, 7 March 2022, . + iccrg-bbr-congestion-control-02>. [I-D.ietf-tsvwg-l4s-arch] Briscoe, B., Schepper, K. D., Bagnulo, M., and G. White, "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture", Work in Progress, Internet-Draft, - draft-ietf-tsvwg-l4s-arch-16, 1 February 2022, + draft-ietf-tsvwg-l4s-arch-17, 4 March 2022, . + l4s-arch-17>. [L4Sdemo16] Bondarenko, O., De Schepper, K., Tsang, I., and B. Briscoe, "Ultra-Low Delay for All: Live Experience, Live Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016, . [L4S_5G] Willars, P., Wittenmark, E., Ronkainen, H., Östberg, C., @@ -2063,23 +2073,23 @@ tunes them inherently. This is explained in [PI2], which also explains why this more principled approach removes the need for most of the heuristics that had to be added to PIE. Nonetheless, an implementer might wish to add selected details to either AQM. For instance the Linux reference DualPI2 implementation includes the following (not shown in the pseudocode above): * Classic and coupled marking or dropping (i.e. based on p_C and p_CL from the PI controller) is not applied to a packet if the - respective queue length in bytes is < 2 MTU (prior to enqueuing - the packet or dequeuing it, depending on whether the AQM is - configured to be applied at enqueue or dequeue); + aggregate queue length in bytes is < 2 MTU (prior to enqueuing the + packet or dequeuing it, depending on whether the AQM is configured + to be applied at enqueue or dequeue); * In the WRR scheduler, the 'credit' indicating which queue should transmit is only changed if there are packets in both queues (i.e. if there is actual resource contention). This means that a properly paced L flow might never be delayed by the WRR. The WRR credit is reset in favour of the L queue when the link is idle. An implementer might also wish to add other heuristics, e.g. burst protection [RFC8033] or enhanced burst protection [RFC8034].