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/