--- 1/draft-ietf-tsvwg-aqm-dualq-coupled-13.txt 2021-03-22 13:42:13.728907550 -0700 +++ 2/draft-ietf-tsvwg-aqm-dualq-coupled-14.txt 2021-03-22 13:42:13.844910436 -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: May 19, 2021 Independent +Expires: September 11, 2021 Independent G. White CableLabs - November 15, 2020 + March 10, 2021 DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) - draft-ietf-tsvwg-aqm-dualq-coupled-13 + draft-ietf-tsvwg-aqm-dualq-coupled-14 Abstract The Low Latency Low Loss Scalable Throughput (L4S) architecture allows data flows over the public Internet to achieve consistent low queuing latency, generally zero congestion loss and scaling of per- flow throughput without the scaling problems of standard TCP Reno- friendly congestion controls. To achieve this, L4S data flows have to use one of the family of 'Scalable' congestion controls (TCP Prague and Data Center TCP are examples) and a form of Explicit @@ -51,25 +51,25 @@ 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 May 19, 2021. + This Internet-Draft will expire on September 11, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + 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 @@ -452,25 +452,25 @@ Classic traffic, The L4S queue has latency priority, but the coupling from the Classic to the L4S AQM (explained below) ensures that it does not have bandwidth priority over the Classic queue. 2. DualQ Coupled AQM There are two main aspects to the approach: - o the Coupled AQM that addresses throughput equivalence between + o The Coupled AQM that addresses throughput equivalence between Classic (e.g. Reno, Cubic) flows and L4S flows (that satisfy the Prague L4S requirements). - o the Dual Queue structure that provides latency separation for L4S + o The Dual Queue structure that provides latency separation for L4S flows to isolate them from the typically large Classic queue. 2.1. Coupled AQM In the 1990s, the `TCP formula' was derived for the relationship between the steady-state congestion window, cwnd, and the drop probability, p of standard Reno congestion control [RFC5681] . To a first order approximation, the steady-state cwnd of Reno is inversely proportional to the square root of p. @@ -692,43 +692,51 @@ 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], but its configuration parameters are 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, - DualPI2 has attracted more development and evaluation attention than - Curvy RED, leaving the Curvy RED design incomplete and not so fully - evaluated. + at the time of writing, DualPI2 has attracted more development and + evaluation attention than Curvy RED, leaving the Curvy RED design + incomplete and 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. It would be possible to control the queues with other alternative AQMs, as long as the normative requirements (those expressed in capitals) in Section 2.5 are observed. 2.5. Normative Requirements for a DualQ Coupled AQM The following requirements are intended to capture only the essential aspects of a DualQ Coupled AQM. They are intended to be independent of the particular AQMs used for each queue. 2.5.1. Functional Requirements + A Dual Queue Coupled AQM implementation MUST comply with the + prerequisite L4S behaviours for any L4S network node (not just a + DualQ) as specified in section 5 of [I-D.ietf-tsvwg-ecn-l4s-id]. + These primarily concern classification and remarking as briefly + summarized in Section 2.3 earlier. But there is also a subsection + (5.5) giving guidance on reducing the burstiness of the link + technology underlying any L4S AQM. + A Dual Queue Coupled AQM implementation MUST utilize two queues, each with an AQM algorithm. The two queues can be part of a larger queuing hierarchy [I-D.briscoe-tsvwg-l4s-diffserv]. The AQM algorithm for the low latency (L) queue MUST be able to apply ECN marking to ECN-capable packets. The scheduler draining the two queues MUST give L4S packets priority over Classic, although priority MUST be bounded in order not to starve Classic traffic. The scheduler SHOULD be work-conserving. @@ -1166,21 +1176,21 @@ implementations were tested. 7. References 7.1. Normative References [I-D.ietf-tsvwg-ecn-l4s-id] Schepper, K. and B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- - id-11 (work in progress), November 2020. + id-12 (work in progress), November 2020. [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, . @@ -1262,22 +1272,22 @@ November 2018. [I-D.cardwell-iccrg-bbr-congestion-control] Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, "BBR Congestion Control", draft-cardwell-iccrg-bbr- congestion-control-00 (work in progress), July 2017. [I-D.ietf-tsvwg-l4s-arch] Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, Scalable Throughput (L4S) Internet - Service: Architecture", draft-ietf-tsvwg-l4s-arch-07 (work - in progress), October 2020. + Service: Architecture", draft-ietf-tsvwg-l4s-arch-08 (work + in progress), November 2020. [I-D.ietf-tsvwg-nqb] White, G. and T. Fossati, "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services", draft- ietf-tsvwg-nqb-03 (work in progress), November 2020. [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, @@ -1429,35 +1439,35 @@ [DualPI2Linux]. The specification of the DualQ Coupled AQM for DOCSIS cable modems and CMTSs is available in [DOCSIS3.1] and explained in [LLD]. A.1. Pass #1: Core Concepts The pseudocode manipulates three main structures of variables: the packet (pkt), the L4S queue (lq) and the Classic queue (cq). The pseudocode consists of the following six functions: - o the initialization function dualpi2_params_init(...) (Figure 2) + o The initialization function dualpi2_params_init(...) (Figure 2) that sets parameter defaults (the API for setting non-default values is omitted for brevity) - o the enqueue function dualpi2_enqueue(lq, cq, pkt) (Figure 3) + o The enqueue function dualpi2_enqueue(lq, cq, pkt) (Figure 3) - o the dequeue function dualpi2_dequeue(lq, cq, pkt) (Figure 4) + o The dequeue function dualpi2_dequeue(lq, cq, pkt) (Figure 4) - o recur(q, likelihood) for de-randomized ECN marking (shown at the - end of Figure 4). + o The recurrence function recur(q, likelihood) for de-randomized ECN + marking (shown at the end of Figure 4). - o the L4S AQM function laqm(qdelay) (Figure 5) used to calculate the + o The L4S AQM function laqm(qdelay) (Figure 5) used to calculate the ECN-marking probability for the L4S queue - o the base AQM function that implements the PI algorithm + o The base AQM function that implements the PI algorithm dualpi2_update(lq, cq) (Figure 6) used to regularly update the base probability (p'), which is squared for the Classic AQM as well as being coupled across to the L4S queue. It also uses the following functions that are not shown in full here: o scheduler(), which selects between the head packets of the two queues; the choice of scheduler technology is discussed later; o cq.len() or lq.len() returns the current length (aka. backlog) of @@ -1614,21 +1624,21 @@ signals, but it still desynchronizes the saw-teeth of the flows. Line 6 calculates p_L as the maximum of the coupled L4S probability p_CL and the probability from the native L4S AQM p'_L. This implements the max() function shown in Figure 1 to couple the outputs of the two AQMs together. Of the two probabilities input to p_L in line 6: * p'_L is calculated per packet in line 5 by the laqm() function (see Figure 5), - * whereas p_CL is maintained by the dualpi2_update() function + * Whereas p_CL is maintained by the dualpi2_update() function which runs every Tupdate (Tupdate is set in line 13 of Figure 2. It defaults to 16 ms in the reference Linux implementation because it has to be rounded to a multiple of 4 ms). o If a Classic packet is scheduled, lines 10 to 17 drop or mark the packet with probability p_C. The Native L4S AQM algorithm (Figure 5) is a ramp function, similar to the RED algorithm, but simplified as follows: @@ -1996,33 +2006,33 @@ pseudocode (Figure 11). To aid comparison, the line numbers are kept in step between the two by using letter suffixes where the longer code needs extra lines. B.1. Curvy RED in Pseudocode The pseudocode manipulates three main structures of variables: the packet (pkt), the L4S queue (lq) and the Classic queue (cq) and consists of the following five functions: - o the initialization function cred_params_init(...) (Figure 2) that + o The initialization function cred_params_init(...) (Figure 2) that sets parameter defaults (the API for setting non-default values is omitted for brevity); - o the dequeue function cred_dequeue(lq, cq, pkt) (Figure 4); + o The dequeue function cred_dequeue(lq, cq, pkt) (Figure 4); - o the scheduling function scheduler(), which selects between the + o The scheduling function scheduler(), which selects between the head packets of the two queues. It also uses the following functions that are either shown elsewhere, or not shown in full here: - o the enqueue function, which is identical to that used for DualPI2, + o The enqueue function, which is identical to that used for DualPI2, dualpi2_enqueue(lq, cq, pkt) in Figure 3; o mark(pkt) and drop(pkt) for ECN-marking and dropping a packet; o cq.len() or lq.len() returns the current length (aka. backlog) of the relevant queue in bytes; o cq.time() or lq.time() returns the current queuing delay (aka. sojourn time or service time) of the relevant queue in units of time (see Note a in Appendix A.1).