--- 1/draft-ietf-tsvwg-l4sops-02.txt 2022-04-28 15:13:11.033769282 -0700 +++ 2/draft-ietf-tsvwg-l4sops-03.txt 2022-04-28 15:13:11.081770506 -0700 @@ -1,18 +1,18 @@ Transport Area Working Group G. White, Ed. Internet-Draft CableLabs -Intended status: Informational 25 October 2021 -Expires: 28 April 2022 +Intended status: Informational 28 April 2022 +Expires: 30 October 2022 Operational Guidance for Deployment of L4S in the Internet - draft-ietf-tsvwg-l4sops-02 + draft-ietf-tsvwg-l4sops-03 Abstract This document is intended to provide guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes @@ -29,36 +29,36 @@ 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 28 April 2022. + This Internet-Draft will expire on 30 October 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + 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 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 2. Per-Flow Fairness . . . . . . . . . . . . . . . . . . . . . . 5 3. Flow Queuing Systems . . . . . . . . . . . . . . . . . . . . 7 4. Detection of Classic ECN Bottlenecks . . . . . . . . . . . . 7 4.1. Recent Studies . . . . . . . . . . . . . . . . . . . . . 7 4.2. Future Experiments . . . . . . . . . . . . . . . . . . . 9 5. Operator of an L4S host . . . . . . . . . . . . . . . . . . . 9 @@ -73,21 +73,21 @@ 6.1. Preferred Options . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Upgrade AQMs to an L4S-aware AQM . . . . . . . . . . 14 6.1.2. Configure Non-Coupled Dual Queue with Shallow Target . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Approximate Fair Dropping . . . . . . . . . . . . . . 15 6.1.4. Replace RFC3168 FIFO with RFC3168 FQ . . . . . . . . 15 6.1.5. Do Nothing . . . . . . . . . . . . . . . . . . . . . 15 6.2. Non-Preferred Options . . . . . . . . . . . . . . . . . . 15 6.2.1. Configure Non-Coupled Dual Queue Treating ECT(1) as NotECT . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.2.2. WRED with ECT(1) Differentation . . . . . . . . . . . 16 + 6.2.2. WRED with ECT(1) Differentiation . . . . . . . . . . 16 6.2.3. Configure AQM to treat ECT(1) as NotECT . . . . . . . 16 6.2.4. ECT(1) Tunnel Bypass . . . . . . . . . . . . . . . . 16 6.3. Last Resort Options . . . . . . . . . . . . . . . . . . . 17 6.3.1. Disable RFC3168 Support . . . . . . . . . . . . . . . 17 6.3.2. Re-mark ECT(1) to NotECT Prior to AQM . . . . . . . . 17 7. Operator of a Network Employing RFC3168 FQ Bottlenecks . . . 17 8. Conclusion of the L4S experiment . . . . . . . . . . . . . . 18 8.1. Termination of a successful L4S experiment . . . . . . . 19 8.2. Termination of an unsuccessful L4S experiment . . . . . . 19 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 @@ -297,21 +297,21 @@ unfairness properties as single queue AQMs. Section 7 discusses some remedies that can be implemented by operators of FQ equipment in order to minimize this risk. Additionally, end-host mitigations such as separating L4S and Classic traffic into distinct VPN tunnels could be employed. 4. Detection of Classic ECN Bottlenecks The IETF encourages researchers, end system deployers and network operators to conduct experiments to identify to what degree RFC3168 - bottlecks exist in networks. These types of measurement campaigns, + bottlenecks exist in networks. These types of measurement campaigns, even if each is conducted over a limited set of paths, could be useful to further understand the scope of any potential issues, to guide end system deployers on where to examine performance more closely (or possibly delay L4S deployment), and to help network operators identify nodes where remediation may be necessary to provide the best performance. 4.1. Recent Studies A small number of recent studies have attempted to gauge the level of @@ -436,21 +436,21 @@ especially sensitive to latency, latency variation and loss. 5.1. Server Type If pre-deployment testing raises concerns about issues with RFC3168 bottlenecks, the actions taken may depend on the server type. 5.1.1. General purpose servers (e.g. web servers) * Out-of-band active testing could be performed by the server. For - example, a javascript application could run simultaneous downloads + example, a JavaScript application could run simultaneous downloads (i.e. with and without L4S) during page reading time in order to survey for presence of RFC3168 FIFO bottlenecks on paths to users (e.g. as described in Section 4 of [Briscoe]). * In-band testing could be built in to the transport protocol implementation at the sender in order to perform detection (see Section 5 of [Briscoe], though note that this mechanism does not differentiate between FIFO and FQ). * Depending on the details of the L4S congestion control @@ -529,21 +529,21 @@ While this doesn't completely eliminate the possibility that a legacy [RFC3168] FIFO bottleneck could exist, it nonetheless provides useful information that can be utilized in the decision making around the potential risk for any unfairness to be experienced by end users. 5.2.2. Other hosts Hosts that are deployed in locations that serve a wide variety of networks face a more difficult prospect in terms of handling the potential presence of RFC3168 FIFO bottlenecks. Nonetheless, the - steps listed in the ealier section (based on server type) can be + steps listed in the earlier section (based on server type) can be taken to minimize the risk of unfairness. It is recommended that operators of such hosts consider carefully whether these hosts are appropriate for early experimentation with L4S. The interpretation of studies on ECN usage and their deployment context (see Section 4.1) has so far concluded that RFC3168 FIFO bottlenecks are likely to be rare, and so detections using these techniques may also prove to be rare. Additionally, the most recent @@ -637,22 +637,22 @@ risk or very low risk. If classification based on the ECN field isn't possible in the bottleneck, this option may still be useful if an external system can be configured to reflect the ECN codepoint to another field that could then be used as an alternative identifier to classify traffic into Queue #1. For example, if at network ingress an edge router can apply a local-use DSCP to ECT(1) & CE packets, the bottleneck can then utilize a DSCP classifier. Similarly, in MPLS networks, ECT(1) & CE packets could use a different EXP value [RFC5129] than classic - packets. More generally, any tunnelling protocol can be used to - proxy the ECN value of the encapsulated packet to its outer header, + packets. More generally, any tunneling protocol can be used to proxy + the ECN value of the encapsulated packet to its outer header, enabling bottlenecks to classify packets based on their input virtual interface. 6.1.3. Approximate Fair Dropping The Approximate Fair Dropping ([AFD]) algorithm tracks individual flow rates and introduces either packet drops or CE-marks to each flow in proportion to the amount by which the flow rate exceeds a computed per-flow fair-share rate. Where an implementation of AFD or an equivalent algorithm is available, it could be enabled on an @@ -699,21 +699,21 @@ * Outcome - ECT(1) treated as NotECT - Flow balance for the 2 queues is the same as in Section 6.1.2 This option could potentially be implemented using an identifier other than the ECN field, as discussed in Section 6.1.2. -6.2.2. WRED with ECT(1) Differentation +6.2.2. WRED with ECT(1) Differentiation This configuration is similar to the option described in Section 6.2.1, but uses a single queue with WRED functionality. * Configure the queue with two WRED classes - Class #1: ECT(1) & NotECT packets - ECN disabled - Class #2: ECT(0) & CE packets - ECN enabled @@ -744,22 +744,22 @@ If serious issues are detected, where the presence of L4S flows is determined to be the likely cause, and none of the above options are implementable, the options in this section can be considered as a last resort. These options are not recommended. 6.3.1. Disable RFC3168 Support Disabling an [RFC3168] AQM from CE marking both ECT(0) traffic and ECT(1) traffic eliminates the unfairness issue. A downside to this approach is that classic senders will no longer get the benefits of - Explict Congestion Notification at this bottleneck link either. This - alternative is only mentioned in case there is no other way to + Explicit Congestion Notification at this bottleneck link either. + This alternative is only mentioned in case there is no other way to reconfigure an RFC3168 AQM. 6.3.2. Re-mark ECT(1) to NotECT Prior to AQM Remarking ECT(1) packets as NotECT (i.e. bleaching ECT(1)) ensures that they are treated identically to classic NotECT senders. However, this action is not recommended because a) it would also prevent downstream L4S bottlenecks from providing high fidelity congestion signals; b) it could lead to problems with future experiments that use ECT(1) in alternative ways to L4S; and c) it