--- 1/draft-ietf-tsvwg-aqm-dualq-coupled-19.txt 2021-12-24 06:14:51.576114487 -0800 +++ 2/draft-ietf-tsvwg-aqm-dualq-coupled-20.txt 2021-12-24 06:14:51.700117585 -0800 @@ -1,22 +1,22 @@ Transport Area working group (tsvwg) K. De Schepper Internet-Draft Nokia Bell Labs Intended status: Experimental B. Briscoe, Ed. -Expires: 7 May 2022 Independent +Expires: 27 June 2022 Independent G. White CableLabs - 3 November 2021 + 24 December 2021 DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) - draft-ietf-tsvwg-aqm-dualq-coupled-19 + draft-ietf-tsvwg-aqm-dualq-coupled-20 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,47 +42,47 @@ 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 7 May 2022. + This Internet-Draft will expire on 27 June 2022. Copyright Notice Copyright (c) 2021 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 and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Outline of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Features . . . . . . . . . . . . . . . . . . . . . . . . 9 2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 13 + 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 12 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 13 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.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 @@ -718,23 +717,23 @@ DualPI2 uses a Proportional-Integral (PI) controller as the Base AQM. Indeed, this Base AQM with just the squared output and no L4S queue can be used as a drop-in replacement for PIE [RFC8033], in which case it is just called PI2 [PI2]. PI2 is a principled simplification of PIE that is both more responsive and more stable in the face of dynamically varying load. Curvy RED is derived from RED [RFC2309], except its configuration parameters are delay-based to make them insensitive to link rate and - it requires less operations per packet. However, DualPI2 is more - responsive and stable over a wider range of RTTs than Curvy RED. As - a consequence, at the time of writing, DualPI2 has attracted more + it requires less operations per packet than RED. However, DualPI2 is + more responsive and stable over a wider range of RTTs than Curvy RED. + As a consequence, at the time of writing, DualPI2 has attracted more development and evaluation attention than Curvy RED, leaving the Curvy RED design not so fully evaluated. Both AQMs regulate their queue in units of time rather than bytes. As already explained, this ensures configuration can be invariant for different drain rates. With AQMs in a dualQ structure this is particularly important because the drain rate of each queue can vary rapidly as flows for the two queues arrive and depart, even if the combined link rate is constant. @@ -863,21 +862,21 @@ The above requirements are worded as "SHOULDs", because operator- specific classifiers are for flexibility, by definition. Therefore, alternative actions might be appropriate in the operator's specific circumstances. An example would be where the operator knows that certain legacy traffic marked with one codepoint actually has a congestion response associated with another codepoint. If the DualQ Coupled AQM has detected overload, it MUST begin using Classic drop, and continue until the overload episode has subsided. - Switching to drop if ECN marking is persistently high is required by + Introducing drop if ECN marking is persistently high is required by Section 7 of [RFC3168] and Section 4.2.1 of [RFC7567]. 2.5.2. Management Requirements 2.5.2.1. Configuration By default, a DualQ Coupled AQM SHOULD NOT need any configuration for use at a bottleneck on the public Internet [RFC7567]. The following parameters MAY be operator-configurable, e.g. to tune for non- Internet settings: @@ -1148,23 +1147,23 @@ target delay of the C queue. 4.1.3. Protecting against Unresponsive ECN-Capable Traffic Unresponsive traffic has a greater advantage if it is also ECN- capable. The advantage is undetectable at normal low levels of drop/ marking, but it becomes significant with the higher levels of drop/ marking typical during overload. This is an issue whether the ECN- capable traffic is L4S or Classic. - This raises the question of whether and when to switch off ECN - marking and use solely drop instead, as required by both Section 7 of - [RFC3168] and Section 4.2.1 of [RFC7567]. + This raises the question of whether and when to introduce drop of + ECN-capable traffic, as required by both Section 7 of [RFC3168] and + Section 4.2.1 of [RFC7567]. Experiments with the DualPI2 AQM (Appendix A) have shown that introducing 'drop on saturation' at 100% L4S marking addresses this problem with unresponsive ECN as well as addressing the saturation problem. It leaves only a small range of congestion levels where unresponsive traffic gains any advantage from using the ECN capability (relative to being unresponsive without ECN), and the advantage is hardly detectable [DualQ-Test]. 5. Acknowledgements @@ -1211,23 +1210,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-19, 26 July 2021, + tsvwg-ecn-l4s-id-22, 8 November 2021, . + ecn-l4s-id-22>. [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, . @@ -1308,55 +1307,56 @@ Dual Queue Coupled Active Queue Management", Masters Thesis, Dept of Informatics, Uni Oslo , May 2017, . [Heist21] Heist, P. and J. Morton, "L4S Tests", github README, August 2021, . [I-D.briscoe-docsis-q-protection] - Briscoe, B. and G. White, "Queue Protection to Preserve - Low Latency", Work in Progress, Internet-Draft, draft- - briscoe-docsis-q-protection-00, 8 July 2019, - . + 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-01, 17 + December 2021, . [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., and V. Jacobson, - "BBR Congestion Control", Work in Progress, Internet- - Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 - July 2017, . + 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, + . [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-10, 1 July 2021, + draft-ietf-tsvwg-l4s-arch-14, 8 November 2021, . + l4s-arch-14>. [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.,