--- 1/draft-ietf-tsvwg-aqm-dualq-coupled-03.txt 2018-03-05 16:16:08.248360918 -0800 +++ 2/draft-ietf-tsvwg-aqm-dualq-coupled-04.txt 2018-03-05 16:16:08.324362750 -0800 @@ -1,24 +1,24 @@ Transport Area working group (tsvwg) K. De Schepper Internet-Draft Nokia Bell Labs Intended status: Experimental B. Briscoe, Ed. -Expires: July 28, 2018 CableLabs +Expires: September 6, 2018 CableLabs O. Bondarenko Simula Research Lab I. Tsang Nokia - January 24, 2018 + March 5, 2018 DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) - draft-ietf-tsvwg-aqm-dualq-coupled-03 + draft-ietf-tsvwg-aqm-dualq-coupled-04 Abstract Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---DCTCP is so aggressive that existing TCP algorithms approach starvation. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as @@ -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 July 28, 2018. + This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 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 @@ -69,39 +69,39 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem and Scope . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 6 2. DualQ Coupled AQM . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Coupled AQM . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Dual Queue . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Traffic Classification . . . . . . . . . . . . . . . . . 8 - 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 8 + 2.4. Overall DualQ Coupled AQM Structure . . . . . . . . . . . 9 2.5. Normative Requirements for a DualQ Coupled AQM . . . . . 11 2.5.1. Functional Requirements . . . . . . . . . . . . . . . 11 2.5.2. Management Requirements . . . . . . . . . . . . . . . 12 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput or Delay? . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Congestion Signal Saturation: Introduce L4S Drop or Delay? . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 20 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 20 - A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 25 + A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 26 Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 28 Appendix C. Guidance on Controlling Throughput Equivalence . . . 34 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction 1.1. Problem and Scope Latency is becoming the critical performance factor for many (most?) @@ -357,20 +357,34 @@ 2.3. Traffic Classification Both the Coupled AQM and DualQ mechanisms need an identifier to distinguish L and C packets. A separate draft [I-D.ietf-tsvwg-ecn-l4s-id] recommends using the ECT(1) codepoint of the ECN field as this identifier, having assessed various alternatives. An additional process document has proved necessary to make the ECT(1) codepoint available for experimentation [RFC8311]. + In addition (not instead), other identifiers could be used to + classify certain additional packet types into the L queue, that are + deemed not to risk harming the L4S service. For instance addresses + of specific applications or hosts (see [I-D.ietf-tsvwg-ecn-l4s-id]), + specific Diffserv codepoints such as EF (Expedited Forwarding), CS5 + (Application Signalling) and Voice-Admit service classes (see + [I-D.briscoe-tsvwg-l4s-diffserv]) or certain protocols (e.g. ARP, + DNS). + + Note that the DualQ Coupled AQM only reads these classifiers, it MUST + NOT re-mark or alter these identifiers (except for marking the ECN + field with the CE codepoint - with increasing frequency to indicate + increasing congestion). + 2.4. Overall DualQ Coupled AQM Structure Figure 1 shows the overall structure that any DualQ Coupled AQM is likely to have. This schematic is intended to aid understanding of the current designs of DualQ Coupled AQMs. However, it is not intended to preclude other innovative ways of satisfying the normative requirements in Section 2.5 that minimally define a DualQ Coupled AQM. The classifier on the left separates incoming traffic between the two @@ -536,21 +550,21 @@ affect small flows. 2.5.2. Management Requirements 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: o Optional packet classifier(s) to use in addition to the ECN field - {ToDo: e.g. ARP}; + (see Section 2.3); o Expected typical RTT (a parameter for typical or target queuing delay in each queue might be configurable instead); o Expected maximum RTT (a stability parameter that depends on maximum RTT might be configurable instead); o Coupling factor, k; o The limit to the conditional priority of L4S (scheduler-dependent, @@ -767,37 +781,43 @@ All", 2015, . (Under submission) [DualQ-Test] Steen, H., "Destruction Testing: Ultra-Low Delay using Dual Queue Coupled Active Queue Management", Masters Thesis, Dept of Informatics, Uni Oslo , May 2017. + [I-D.briscoe-tsvwg-l4s-diffserv] + Briscoe, B., "Interactions between Low Latency, Low Loss, + Scalable Throughput (L4S) and Differentiated Services", + draft-briscoe-tsvwg-l4s-diffserv-00 (work in progress), + March 2018. + [I-D.ietf-tcpm-cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", draft-ietf-tcpm-cubic-07 (work in progress), November 2017. [I-D.ietf-tsvwg-ecn-l4s-id] Schepper, K., Briscoe, B., and I. Tsang, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s- - id-00 (work in progress), November 2016. + id-02 (work in progress), March 2018. [I-D.ietf-tsvwg-l4s-arch] Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: - Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in - progress), November 2016. + Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in + progress), March 2018. [I-D.sridharan-tcpm-ctcp] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 (work in progress), November 2008. [Mathis09] Mathis, M., "Relentless Congestion Control", PFLDNeT'09 , May 2009, 0) 19: maxr = max(maxr, rand()) % 0 <= rand() < 1 20: return(maxr) 21: } Figure 8: Example Dequeue Pseudocode for DualQ Coupled Curvy RED AQM Packet classification code is not shown, as it is no different from Figure 3. Potential classification schemes are discussed in - Section 2. The Curvy RED algorithm has not been maintained to the + Section 2.3. The Curvy RED algorithm has not been maintained to the same degree as the DualPI2 algorithm. Some ideas used in DualPI2 would need to be translated into Curvy RED, such as i) the conditional priority scheduler instead of strict priority ii) the time-based L4S threshold; iii) turning off ECN as overload protection; iv) Classic ECN support. These are not shown in the Curvy RED pseudocode, but would need to be implemented for production. {ToDo} At the outer level, the structure of dualq_dequeue() implements strict priority scheduling. The code is written assuming the AQM is @@ -1620,26 +1641,24 @@ general Internet, a value of k'=1 (equivalent to k=2) is recommended as a good workable compromise. Appendix D. Open Issues Most of the following open issues are also tagged '{ToDo}' at the appropriate point in the document: Operational guidance to monitor L4S experiment - Interaction between Diffserv & L4S - Define additional classifier flexibility more clearly + PI2 appendix: scaling of alpha & beta, esp. dependence of beta_U on Tupdate - Curvy RED appendix: complete the unfinished parts Authors' Addresses Koen De Schepper Nokia Bell Labs Antwerp Belgium Email: koen.de_schepper@nokia.com