--- 1/draft-ietf-tsvwg-aqm-dualq-coupled-05.txt 2018-07-18 09:13:13.543471629 -0700 +++ 2/draft-ietf-tsvwg-aqm-dualq-coupled-06.txt 2018-07-18 09:13:13.623473555 -0700 @@ -1,24 +1,24 @@ Transport Area working group (tsvwg) K. De Schepper Internet-Draft Nokia Bell Labs Intended status: Experimental B. Briscoe, Ed. -Expires: January 3, 2019 CableLabs +Expires: January 19, 2019 CableLabs O. Bondarenko Simula Research Lab I. Tsang Nokia - July 2, 2018 + July 18, 2018 DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) - draft-ietf-tsvwg-aqm-dualq-coupled-05 + draft-ietf-tsvwg-aqm-dualq-coupled-06 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 January 3, 2019. + This Internet-Draft will expire on January 19, 2019. 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 @@ -83,30 +83,30 @@ 2.5.2. Management Requirements . . . . . . . . . . . . . . . 13 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.1. Overload Handling . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Avoiding Classic Starvation: Sacrifice L4S Throughput or Delay? . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. Congestion Signal Saturation: Introduce L4S Drop or Delay? . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Protecting against Unresponsive ECN-Capable Traffic . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Example DualQ Coupled PI2 Algorithm . . . . . . . . 21 A.1. Pass #1: Core Concepts . . . . . . . . . . . . . . . . . 21 A.2. Pass #2: Overload Details . . . . . . . . . . . . . . . . 27 - Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 29 - Appendix C. Guidance on Controlling Throughput Equivalence . . . 35 - Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + Appendix B. Example DualQ Coupled Curvy RED Algorithm . . . . . 30 + Appendix C. Guidance on Controlling Throughput Equivalence . . . 36 + Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction 1.1. Problem and Scope Latency is becoming the critical performance factor for many (most?) applications on the public Internet, e.g. interactive Web, Web services, voice, conversational video, interactive video, interactive remote presence, instant messaging, online gaming, remote desktop, cloud-based applications, and video-assisted remote control of @@ -563,51 +563,57 @@ leads to the need to specify what the AQM in each queue ought to do with packets that do not carry the ECN field expected for that queue. It is recommended that the AQM in each queue inspects the ECN field to determine what sort of congestion notification to signal, then decides whether to apply congestion notification to this particular packet, as follows: o If a packet that does not carry an ECT(1) or CE codepoint is classified into the L queue: - * if the packet is ECT(0), the L AQM SHOULD apply CE-marking as - if the packet were ECT(1) + * if the packet is ECT(0), the L AQM SHOULD apply drop using a + drop probability appropriate to Classic congestion control and + appropriate to the target delay in the L queue * if the packet is Not-ECT, the appropriate action depends on whether some other function is protecting the L queue from - misbehaving flows (e.g. per-flow queue protection or policing): + misbehaving flows (e.g. per-flow queue protection or latency + policing): + If separate queue protection is provided, the L AQM SHOULD ignore the packet and forward it unchanged, meaning it should not calculate whether to apply congestion notification and it should neither drop nor CE-mark the packet (for instance, the operator might classify EF traffic that is unresponsive to drop into the L queue, alongside responsive L4S-ECN traffic) - + if separate queue protection is not provided, the L AQM MUST - apply drop using the drop probability appropriate to the C - queue + + if separate queue protection is not provided, the L AQM + SHOULD apply drop using a drop probability appropriate to + Classic congestion control and appropriate to the target + delay in the L queue - o If a packet that carries an ECT(1) or CE codepoint is classified - into the C queue: + o If a packet that carries an ECT(1) codepoint is classified into + the C queue: - * the C AQM SHOULD apply CE-marking as if the packet were ECT(0). + * the C AQM SHOULD apply CE-marking using the coupled AQM + probability p_CL (= k*p'). If the DualQ Coupled AQM has detected overload, it will signal congestion solely using drop, irrespective of the ECN field. - Most of 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. + 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. 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 (see Section 2.3);