| < draft-ietf-tsvwg-l4sops-02.txt | draft-ietf-tsvwg-l4sops-03.txt > | |||
|---|---|---|---|---|
| Transport Area Working Group G. White, Ed. | Transport Area Working Group G. White, Ed. | |||
| Internet-Draft CableLabs | Internet-Draft CableLabs | |||
| Intended status: Informational 25 October 2021 | Intended status: Informational 28 April 2022 | |||
| Expires: 28 April 2022 | Expires: 30 October 2022 | |||
| Operational Guidance for Deployment of L4S in the Internet | Operational Guidance for Deployment of L4S in the Internet | |||
| draft-ietf-tsvwg-l4sops-02 | draft-ietf-tsvwg-l4sops-03 | |||
| Abstract | Abstract | |||
| This document is intended to provide guidance in order to ensure | This document is intended to provide guidance in order to ensure | |||
| successful deployment of Low Latency Low Loss Scalable throughput | successful deployment of Low Latency Low Loss Scalable throughput | |||
| (L4S) in the Internet. Other L4S documents provide guidance for | (L4S) in the Internet. Other L4S documents provide guidance for | |||
| running an L4S experiment, but this document is focused solely on | running an L4S experiment, but this document is focused solely on | |||
| potential interactions between L4S flows and flows using the original | potential interactions between L4S flows and flows using the original | |||
| ('Classic') ECN over a Classic ECN bottleneck link. The document | ('Classic') ECN over a Classic ECN bottleneck link. The document | |||
| discusses the potential outcomes of these interactions, describes | discusses the potential outcomes of these interactions, describes | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | 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 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. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Per-Flow Fairness . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Per-Flow Fairness . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Flow Queuing Systems . . . . . . . . . . . . . . . . . . . . 7 | 3. Flow Queuing Systems . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Detection of Classic ECN Bottlenecks . . . . . . . . . . . . 7 | 4. Detection of Classic ECN Bottlenecks . . . . . . . . . . . . 7 | |||
| 4.1. Recent Studies . . . . . . . . . . . . . . . . . . . . . 7 | 4.1. Recent Studies . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.2. Future Experiments . . . . . . . . . . . . . . . . . . . 9 | 4.2. Future Experiments . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. Operator of an L4S host . . . . . . . . . . . . . . . . . . . 9 | 5. Operator of an L4S host . . . . . . . . . . . . . . . . . . . 9 | |||
| skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
| 6.1. Preferred Options . . . . . . . . . . . . . . . . . . . . 13 | 6.1. Preferred Options . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1.1. Upgrade AQMs to an L4S-aware AQM . . . . . . . . . . 14 | 6.1.1. Upgrade AQMs to an L4S-aware AQM . . . . . . . . . . 14 | |||
| 6.1.2. Configure Non-Coupled Dual Queue with Shallow | 6.1.2. Configure Non-Coupled Dual Queue with Shallow | |||
| Target . . . . . . . . . . . . . . . . . . . . . . . 14 | Target . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.1.3. Approximate Fair Dropping . . . . . . . . . . . . . . 15 | 6.1.3. Approximate Fair Dropping . . . . . . . . . . . . . . 15 | |||
| 6.1.4. Replace RFC3168 FIFO with RFC3168 FQ . . . . . . . . 15 | 6.1.4. Replace RFC3168 FIFO with RFC3168 FQ . . . . . . . . 15 | |||
| 6.1.5. Do Nothing . . . . . . . . . . . . . . . . . . . . . 15 | 6.1.5. Do Nothing . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 6.2. Non-Preferred Options . . . . . . . . . . . . . . . . . . 15 | 6.2. Non-Preferred Options . . . . . . . . . . . . . . . . . . 15 | |||
| 6.2.1. Configure Non-Coupled Dual Queue Treating ECT(1) as | 6.2.1. Configure Non-Coupled Dual Queue Treating ECT(1) as | |||
| NotECT . . . . . . . . . . . . . . . . . . . . . . . 16 | 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.3. Configure AQM to treat ECT(1) as NotECT . . . . . . . 16 | |||
| 6.2.4. ECT(1) Tunnel Bypass . . . . . . . . . . . . . . . . 16 | 6.2.4. ECT(1) Tunnel Bypass . . . . . . . . . . . . . . . . 16 | |||
| 6.3. Last Resort Options . . . . . . . . . . . . . . . . . . . 17 | 6.3. Last Resort Options . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.3.1. Disable RFC3168 Support . . . . . . . . . . . . . . . 17 | 6.3.1. Disable RFC3168 Support . . . . . . . . . . . . . . . 17 | |||
| 6.3.2. Re-mark ECT(1) to NotECT Prior to AQM . . . . . . . . 17 | 6.3.2. Re-mark ECT(1) to NotECT Prior to AQM . . . . . . . . 17 | |||
| 7. Operator of a Network Employing RFC3168 FQ Bottlenecks . . . 17 | 7. Operator of a Network Employing RFC3168 FQ Bottlenecks . . . 17 | |||
| 8. Conclusion of the L4S experiment . . . . . . . . . . . . . . 18 | 8. Conclusion of the L4S experiment . . . . . . . . . . . . . . 18 | |||
| 8.1. Termination of a successful L4S experiment . . . . . . . 19 | 8.1. Termination of a successful L4S experiment . . . . . . . 19 | |||
| 8.2. Termination of an unsuccessful L4S experiment . . . . . . 19 | 8.2. Termination of an unsuccessful L4S experiment . . . . . . 19 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| skipping to change at page 7, line 36 ¶ | skipping to change at page 7, line 36 ¶ | |||
| unfairness properties as single queue AQMs. Section 7 discusses some | unfairness properties as single queue AQMs. Section 7 discusses some | |||
| remedies that can be implemented by operators of FQ equipment in | remedies that can be implemented by operators of FQ equipment in | |||
| order to minimize this risk. Additionally, end-host mitigations such | order to minimize this risk. Additionally, end-host mitigations such | |||
| as separating L4S and Classic traffic into distinct VPN tunnels could | as separating L4S and Classic traffic into distinct VPN tunnels could | |||
| be employed. | be employed. | |||
| 4. Detection of Classic ECN Bottlenecks | 4. Detection of Classic ECN Bottlenecks | |||
| The IETF encourages researchers, end system deployers and network | The IETF encourages researchers, end system deployers and network | |||
| operators to conduct experiments to identify to what degree RFC3168 | 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 | even if each is conducted over a limited set of paths, could be | |||
| useful to further understand the scope of any potential issues, to | useful to further understand the scope of any potential issues, to | |||
| guide end system deployers on where to examine performance more | guide end system deployers on where to examine performance more | |||
| closely (or possibly delay L4S deployment), and to help network | closely (or possibly delay L4S deployment), and to help network | |||
| operators identify nodes where remediation may be necessary to | operators identify nodes where remediation may be necessary to | |||
| provide the best performance. | provide the best performance. | |||
| 4.1. Recent Studies | 4.1. Recent Studies | |||
| A small number of recent studies have attempted to gauge the level of | A small number of recent studies have attempted to gauge the level of | |||
| skipping to change at page 10, line 43 ¶ | skipping to change at page 10, line 43 ¶ | |||
| especially sensitive to latency, latency variation and loss. | especially sensitive to latency, latency variation and loss. | |||
| 5.1. Server Type | 5.1. Server Type | |||
| If pre-deployment testing raises concerns about issues with RFC3168 | If pre-deployment testing raises concerns about issues with RFC3168 | |||
| bottlenecks, the actions taken may depend on the server type. | bottlenecks, the actions taken may depend on the server type. | |||
| 5.1.1. General purpose servers (e.g. web servers) | 5.1.1. General purpose servers (e.g. web servers) | |||
| * Out-of-band active testing could be performed by the server. For | * 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 | (i.e. with and without L4S) during page reading time in order to | |||
| survey for presence of RFC3168 FIFO bottlenecks on paths to users | survey for presence of RFC3168 FIFO bottlenecks on paths to users | |||
| (e.g. as described in Section 4 of [Briscoe]). | (e.g. as described in Section 4 of [Briscoe]). | |||
| * In-band testing could be built in to the transport protocol | * In-band testing could be built in to the transport protocol | |||
| implementation at the sender in order to perform detection (see | implementation at the sender in order to perform detection (see | |||
| Section 5 of [Briscoe], though note that this mechanism does not | Section 5 of [Briscoe], though note that this mechanism does not | |||
| differentiate between FIFO and FQ). | differentiate between FIFO and FQ). | |||
| * Depending on the details of the L4S congestion control | * Depending on the details of the L4S congestion control | |||
| skipping to change at page 12, line 40 ¶ | skipping to change at page 12, line 40 ¶ | |||
| While this doesn't completely eliminate the possibility that a legacy | While this doesn't completely eliminate the possibility that a legacy | |||
| [RFC3168] FIFO bottleneck could exist, it nonetheless provides useful | [RFC3168] FIFO bottleneck could exist, it nonetheless provides useful | |||
| information that can be utilized in the decision making around the | information that can be utilized in the decision making around the | |||
| potential risk for any unfairness to be experienced by end users. | potential risk for any unfairness to be experienced by end users. | |||
| 5.2.2. Other hosts | 5.2.2. Other hosts | |||
| Hosts that are deployed in locations that serve a wide variety of | Hosts that are deployed in locations that serve a wide variety of | |||
| networks face a more difficult prospect in terms of handling the | networks face a more difficult prospect in terms of handling the | |||
| potential presence of RFC3168 FIFO bottlenecks. Nonetheless, 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. | taken to minimize the risk of unfairness. | |||
| It is recommended that operators of such hosts consider carefully | It is recommended that operators of such hosts consider carefully | |||
| whether these hosts are appropriate for early experimentation with | whether these hosts are appropriate for early experimentation with | |||
| L4S. | L4S. | |||
| The interpretation of studies on ECN usage and their deployment | The interpretation of studies on ECN usage and their deployment | |||
| context (see Section 4.1) has so far concluded that RFC3168 FIFO | context (see Section 4.1) has so far concluded that RFC3168 FIFO | |||
| bottlenecks are likely to be rare, and so detections using these | bottlenecks are likely to be rare, and so detections using these | |||
| techniques may also prove to be rare. Additionally, the most recent | techniques may also prove to be rare. Additionally, the most recent | |||
| skipping to change at page 15, line 5 ¶ | skipping to change at page 15, line 5 ¶ | |||
| risk or very low risk. | risk or very low risk. | |||
| If classification based on the ECN field isn't possible in the | If classification based on the ECN field isn't possible in the | |||
| bottleneck, this option may still be useful if an external system can | bottleneck, this option may still be useful if an external system can | |||
| be configured to reflect the ECN codepoint to another field that | be configured to reflect the ECN codepoint to another field that | |||
| could then be used as an alternative identifier to classify traffic | could then be used as an alternative identifier to classify traffic | |||
| into Queue #1. For example, if at network ingress an edge router can | 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 | apply a local-use DSCP to ECT(1) & CE packets, the bottleneck can | |||
| then utilize a DSCP classifier. Similarly, in MPLS networks, ECT(1) | then utilize a DSCP classifier. Similarly, in MPLS networks, ECT(1) | |||
| & CE packets could use a different EXP value [RFC5129] than classic | & CE packets could use a different EXP value [RFC5129] than classic | |||
| packets. More generally, any tunnelling protocol can be used to | packets. More generally, any tunneling protocol can be used to proxy | |||
| proxy the ECN value of the encapsulated packet to its outer header, | the ECN value of the encapsulated packet to its outer header, | |||
| enabling bottlenecks to classify packets based on their input virtual | enabling bottlenecks to classify packets based on their input virtual | |||
| interface. | interface. | |||
| 6.1.3. Approximate Fair Dropping | 6.1.3. Approximate Fair Dropping | |||
| The Approximate Fair Dropping ([AFD]) algorithm tracks individual | The Approximate Fair Dropping ([AFD]) algorithm tracks individual | |||
| flow rates and introduces either packet drops or CE-marks to each | 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 | 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 | computed per-flow fair-share rate. Where an implementation of AFD or | |||
| an equivalent algorithm is available, it could be enabled on an | an equivalent algorithm is available, it could be enabled on an | |||
| skipping to change at page 16, line 22 ¶ | skipping to change at page 16, line 22 ¶ | |||
| * Outcome | * Outcome | |||
| - ECT(1) treated as NotECT | - ECT(1) treated as NotECT | |||
| - Flow balance for the 2 queues is the same as in Section 6.1.2 | - Flow balance for the 2 queues is the same as in Section 6.1.2 | |||
| This option could potentially be implemented using an identifier | This option could potentially be implemented using an identifier | |||
| other than the ECN field, as discussed in Section 6.1.2. | 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 | This configuration is similar to the option described in | |||
| Section 6.2.1, but uses a single queue with WRED functionality. | Section 6.2.1, but uses a single queue with WRED functionality. | |||
| * Configure the queue with two WRED classes | * Configure the queue with two WRED classes | |||
| - Class #1: ECT(1) & NotECT packets - ECN disabled | - Class #1: ECT(1) & NotECT packets - ECN disabled | |||
| - Class #2: ECT(0) & CE packets - ECN enabled | - Class #2: ECT(0) & CE packets - ECN enabled | |||
| skipping to change at page 17, line 18 ¶ | skipping to change at page 17, line 18 ¶ | |||
| If serious issues are detected, where the presence of L4S flows is | 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 | determined to be the likely cause, and none of the above options are | |||
| implementable, the options in this section can be considered as a | implementable, the options in this section can be considered as a | |||
| last resort. These options are not recommended. | last resort. These options are not recommended. | |||
| 6.3.1. Disable RFC3168 Support | 6.3.1. Disable RFC3168 Support | |||
| Disabling an [RFC3168] AQM from CE marking both ECT(0) traffic and | Disabling an [RFC3168] AQM from CE marking both ECT(0) traffic and | |||
| ECT(1) traffic eliminates the unfairness issue. A downside to this | ECT(1) traffic eliminates the unfairness issue. A downside to this | |||
| approach is that classic senders will no longer get the benefits of | approach is that classic senders will no longer get the benefits of | |||
| Explict Congestion Notification at this bottleneck link either. This | Explicit Congestion Notification at this bottleneck link either. | |||
| alternative is only mentioned in case there is no other way to | This alternative is only mentioned in case there is no other way to | |||
| reconfigure an RFC3168 AQM. | reconfigure an RFC3168 AQM. | |||
| 6.3.2. Re-mark ECT(1) to NotECT Prior to 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 | Remarking ECT(1) packets as NotECT (i.e. bleaching ECT(1)) ensures | |||
| that they are treated identically to classic NotECT senders. | that they are treated identically to classic NotECT senders. | |||
| However, this action is not recommended because a) it would also | However, this action is not recommended because a) it would also | |||
| prevent downstream L4S bottlenecks from providing high fidelity | prevent downstream L4S bottlenecks from providing high fidelity | |||
| congestion signals; b) it could lead to problems with future | congestion signals; b) it could lead to problems with future | |||
| experiments that use ECT(1) in alternative ways to L4S; and c) it | experiments that use ECT(1) in alternative ways to L4S; and c) it | |||
| End of changes. 12 change blocks. | ||||
| 17 lines changed or deleted | 17 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||