< draft-ietf-tsvwg-ecn-l4s-id-28.txt   draft-ietf-tsvwg-ecn-l4s-id-29a.txt >
Transport Services (tsv) K. De Schepper Transport Services (tsv) K. De Schepper
Internet-Draft Nokia Bell Labs Internet-Draft Nokia Bell Labs
Intended status: Experimental B. Briscoe, Ed. Intended status: Experimental B. Briscoe, Ed.
Expires: 9 February 2023 Independent Expires: 26 February 2023 Independent
8 August 2022 25 August 2022
Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Explicit Congestion Notification (ECN) Protocol for Very Low Queuing
Delay (L4S) Delay (L4S)
draft-ietf-tsvwg-ecn-l4s-id-28 draft-ietf-tsvwg-ecn-l4s-id-29
Abstract Abstract
This specification defines the protocol to be used for a new network This specification defines the protocol to be used for a new network
service called low latency, low loss and scalable throughput (L4S). service called low latency, low loss and scalable throughput (L4S).
L4S uses an Explicit Congestion Notification (ECN) scheme at the IP L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
layer that is similar to the original (or 'Classic') ECN approach, layer that is similar to the original (or 'Classic') ECN approach,
except as specified within. L4S uses 'scalable' congestion control, except as specified within. L4S uses 'scalable' congestion control,
which induces much more frequent control signals from the network and which induces much more frequent control signals from the network and
it responds to them with much more fine-grained adjustments, so that it responds to them with much more fine-grained adjustments, so that
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 9 February 2023. This Internet-Draft will expire on 26 February 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5. Network Node Behaviour . . . . . . . . . . . . . . . . . . . 20 5. Network Node Behaviour . . . . . . . . . . . . . . . . . . . 20
5.1. Classification and Re-Marking Behaviour . . . . . . . . . 20 5.1. Classification and Re-Marking Behaviour . . . . . . . . . 20
5.2. The Strength of L4S CE Marking Relative to Drop . . . . . 22 5.2. The Strength of L4S CE Marking Relative to Drop . . . . . 22
5.3. Exception for L4S Packet Identification by Network Nodes 5.3. Exception for L4S Packet Identification by Network Nodes
with Transport-Layer Awareness . . . . . . . . . . . . . 23 with Transport-Layer Awareness . . . . . . . . . . . . . 23
5.4. Interaction of the L4S Identifier with other 5.4. Interaction of the L4S Identifier with other
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 23 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.1. DualQ Examples of Other Identifiers Complementing L4S 5.4.1. DualQ Examples of Other Identifiers Complementing L4S
Identifiers . . . . . . . . . . . . . . . . . . . . . 23 Identifiers . . . . . . . . . . . . . . . . . . . . . 23
5.4.1.1. Inclusion of Additional Traffic with L4S . . . . 23 5.4.1.1. Inclusion of Additional Traffic with L4S . . . . 23
5.4.1.2. Exclusion of Traffic From L4S Treatment . . . . . 25 5.4.1.2. Exclusion of Traffic From L4S Treatment . . . . . 26
5.4.1.3. Generalized Combination of L4S and Other 5.4.1.3. Generalized Combination of L4S and Other
Identifiers . . . . . . . . . . . . . . . . . . . . 26 Identifiers . . . . . . . . . . . . . . . . . . . . 26
5.4.2. Per-Flow Queuing Examples of Other Identifiers 5.4.2. Per-Flow Queuing Examples of Other Identifiers
Complementing L4S Identifiers . . . . . . . . . . . . 28 Complementing L4S Identifiers . . . . . . . . . . . . 28
5.5. Limiting Packet Bursts from Links . . . . . . . . . . . . 28 5.5. Limiting Packet Bursts from Links . . . . . . . . . . . . 28
5.5.1. Limiting Packet Bursts from Links Fed by an L4S 5.5.1. Limiting Packet Bursts from Links Fed by an L4S
AQM . . . . . . . . . . . . . . . . . . . . . . . . . 28 AQM . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.2. Limiting Packet Bursts from Links Upstream of an L4S 5.5.2. Limiting Packet Bursts from Links Upstream of an L4S
AQM . . . . . . . . . . . . . . . . . . . . . . . . . 29 AQM . . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Behaviour of Tunnels and Encapsulations . . . . . . . . . . . 29 6. Behaviour of Tunnels and Encapsulations . . . . . . . . . . . 29
6.1. No Change to ECN Tunnels and Encapsulations in General . 29 6.1. No Change to ECN Tunnels and Encapsulations in General . 29
6.2. VPN Behaviour to Avoid Limitations of Anti-Replay . . . . 30 6.2. VPN Behaviour to Avoid Limitations of Anti-Replay . . . . 30
7. L4S Experiments . . . . . . . . . . . . . . . . . . . . . . . 31 7. L4S Experiments . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 31 7.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 32
7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 33 7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 33
7.3. Future Potential . . . . . . . . . . . . . . . . . . . . 33 7.3. Future Potential . . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Rationale for the 'Prague L4S Requirements' . . . . 45 Appendix A. Rationale for the 'Prague L4S Requirements' . . . . 46
A.1. Rationale for the Requirements for Scalable Transport A.1. Rationale for the Requirements for Scalable Transport
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 46 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 47
A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 46 A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 47
A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 46 A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 47
A.1.3. Capable of Replacement by Classic Congestion A.1.3. Capable of Replacement by Classic Congestion
Control . . . . . . . . . . . . . . . . . . . . . . . 47 Control . . . . . . . . . . . . . . . . . . . . . . . 47
A.1.4. Fall back to Classic Congestion Control on Packet A.1.4. Fall back to Classic Congestion Control on Packet
Loss . . . . . . . . . . . . . . . . . . . . . . . . 47 Loss . . . . . . . . . . . . . . . . . . . . . . . . 48
A.1.5. Coexistence with Classic Congestion Control at Classic A.1.5. Coexistence with Classic Congestion Control at Classic
ECN bottlenecks . . . . . . . . . . . . . . . . . . . 48 ECN bottlenecks . . . . . . . . . . . . . . . . . . . 49
A.1.6. Reduce RTT dependence . . . . . . . . . . . . . . . . 51 A.1.6. Reduce RTT dependence . . . . . . . . . . . . . . . . 52
A.1.7. Scaling down to fractional congestion windows . . . . 53 A.1.7. Scaling down to fractional congestion windows . . . . 53
A.1.8. Measuring Reordering Tolerance in Time Units . . . . 54 A.1.8. Measuring Reordering Tolerance in Time Units . . . . 54
A.2. Scalable Transport Protocol Optimizations . . . . . . . . 57 A.2. Scalable Transport Protocol Optimizations . . . . . . . . 57
A.2.1. Setting ECT in Control Packets and Retransmissions . 57 A.2.1. Setting ECT in Control Packets and Retransmissions . 57
A.2.2. Faster than Additive Increase . . . . . . . . . . . . 57 A.2.2. Faster than Additive Increase . . . . . . . . . . . . 58
A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 58 A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 58
Appendix B. Compromises in the Choice of L4S Identifier . . . . 58 Appendix B. Compromises in the Choice of L4S Identifier . . . . 59
Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 63 Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 64
C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 63 C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 64
C.2. Notification of Less Severe Congestion than CE . . . . . 65 C.2. Notification of Less Severe Congestion than CE . . . . . 65
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
This experimental track specification defines the protocol to be used This experimental track specification defines the protocol to be used
for a new network service called low latency, low loss and scalable for a new network service called low latency, low loss and scalable
throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) throughput (L4S). L4S uses an Explicit Congestion Notification (ECN)
scheme at the IP layer with the same set of codepoint transitions as scheme at the IP layer with the same set of codepoint transitions as
the original (or 'Classic') Explicit Congestion Notification the original (or 'Classic') Explicit Congestion Notification
(ECN [RFC3168]). RFC 3168 required an ECN mark to be equivalent to a (ECN [RFC3168]). RFC 3168 required an ECN mark to be equivalent to a
skipping to change at page 6, line 35 skipping to change at page 6, line 35
PIE [RFC8033] or Adaptive RED [ARED01], are easier to configure, PIE [RFC8033] or Adaptive RED [ARED01], are easier to configure,
because they define the queuing threshold in time not bytes, so because they define the queuing threshold in time not bytes, so
configuration is invariant whatever the link rate. However, the configuration is invariant whatever the link rate. However, the
sawtoothing window of a Classic congestion control creates a dilemma sawtoothing window of a Classic congestion control creates a dilemma
for the operator: i) either configure a shallow AQM operating point, for the operator: i) either configure a shallow AQM operating point,
so the tips of the sawteeth cause minimal queue delay but the troughs so the tips of the sawteeth cause minimal queue delay but the troughs
underutilize the link, or ii) configure the operating point deeper underutilize the link, or ii) configure the operating point deeper
into the buffer, so the troughs utilize the link better but then the into the buffer, so the troughs utilize the link better but then the
tips cause more delay variation. Even with a perfectly tuned AQM, tips cause more delay variation. Even with a perfectly tuned AQM,
the additional queuing delay at the tips of the sawteeth will be of the additional queuing delay at the tips of the sawteeth will be of
the same order as the underlying speed-of-light delay across the the same order as the underlying base round trip time (RTT), thereby
network, thereby roughly doubling the total round-trip time. roughly doubling the total round-trip time.
If a sender's own behaviour is introducing queuing delay variation, If a sender's own behaviour is introducing queuing delay variation,
no AQM in the network can 'un-vary' the delay without significantly no AQM in the network can 'un-vary' the delay without significantly
compromising link utilization. Even flow-queuing (e.g. [RFC8290]), compromising link utilization. Even flow-queuing (e.g. [RFC8290]),
which isolates one flow from another, cannot isolate a flow from the which isolates one flow from another, cannot isolate a flow from the
delay variations it inflicts on itself. Therefore those applications delay variations it inflicts on itself. Therefore those applications
that need to seek out high bandwidth but also need low latency will that need to seek out high bandwidth but also need low latency will
have to migrate to scalable congestion control, which uses much have to migrate to scalable congestion control, which uses much
smaller sawtooth variations. smaller sawtooth variations.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
to saying that the number of ECN CE marks per round trip remains to saying that the number of ECN CE marks per round trip remains
invariant as flow rate scales, all other factors being equal. For invariant as flow rate scales, all other factors being equal. For
instance, an average recovery time of half of 1 RTT is equivalent to instance, an average recovery time of half of 1 RTT is equivalent to
2 ECN marks per round trip. For those familiar with steady-state 2 ECN marks per round trip. For those familiar with steady-state
congestion response functions, it is also equivalent to say that the congestion response functions, it is also equivalent to say that the
congestion window is inversely proportional to the proportion of congestion window is inversely proportional to the proportion of
bytes in packets marked with the CE codepoint (see section 2 of bytes in packets marked with the CE codepoint (see section 2 of
[PI2]). [PI2]).
In order to coexist safely with other Internet traffic, a scalable In order to coexist safely with other Internet traffic, a scalable
congestion control MUST NOT tag its packets with the ECT(1) codepoint congestion control is not allowed to tag its packets with the ECT(1)
unless it complies with the following bulleted requirements: codepoint unless it complies with the following numbered requirements
and recommendations:
1. A scalable congestion control MUST be capable of being replaced 1. A scalable congestion control MUST be capable of being replaced
by a Classic congestion control (by application and/or by by a Classic congestion control (by application and/or by
administrative control). If a Classic congestion control is administrative control). If a Classic congestion control is
activated, it will not tag its packets with the ECT(1) codepoint activated, it will not tag its packets with the ECT(1) codepoint
(see Appendix A.1.3 for rationale). (see Appendix A.1.3 for rationale).
2. As well as responding to ECN markings, a scalable congestion 2. As well as responding to ECN markings, a scalable congestion
control MUST react to packet loss in a way that will coexist control MUST react to packet loss in a way that will coexist
safely with Classic congestion controls such as standard safely with Classic congestion controls such as standard
Reno [RFC5681], as required by [RFC5033] (see Appendix A.1.4 for Reno [RFC5681], as required by [RFC5033] (see Appendix A.1.4 for
rationale). rationale).
3. In uncontrolled environments, monitoring MUST be implemented to 3. In uncontrolled environments, monitoring MUST be implemented to
support detection of problems with an ECN-capable AQM at the path support detection of problems with an ECN-capable AQM at the path
bottleneck that appears not to support L4S and might be in a bottleneck that appears not to support L4S and might be in a
shared queue. Such monitoring SHOULD be applied to live traffic shared queue. Such monitoring SHOULD be applied to live traffic
that is using Scalable congestion control. Alternatively, that is using Scalable congestion control. Alternatively,
monitoring need not be applied to live traffic, if monitoring has monitoring need not be applied to live traffic, if monitoring
been arranged to cover the paths that live traffic takes through with test traffic has been arranged to cover the paths that live
uncontrolled environments. traffic takes through uncontrolled environments. An uncontrolled
environment, for example the public Internet, is where upgrades
of hosts and the network elements they use are largely
uncoordinated.
A function to detect the above problems with an ECN-capable AQM A function to detect the above problems with an ECN-capable AQM
MUST also be implemented and used. The detection function SHOULD MUST also be implemented and used. The detection function SHOULD
be capable of making the congestion control adapt its ECN-marking be capable of making the congestion control adapt its ECN-marking
response in real-time to coexist safely with Classic congestion response in real-time to coexist safely with Classic congestion
controls such as standard Reno [RFC5681], as required by controls such as standard Reno [RFC5681], as required by
[RFC5033]. This could be complemented by more detailed offline [RFC5033]. This could be complemented by more detailed offline
detection of potential problems. If only offline detection is detection of potential problems. If only offline detection is
used and potential problems with such an AQM are detected on used and potential problems with such an AQM are detected on
certain paths, the scalable congestion control MUST be replaced certain paths, the scalable congestion control MUST be replaced
skipping to change at page 24, line 28 skipping to change at page 24, line 28
intensity traffic; intensity traffic;
* certain low data-volume applications or protocols (e.g. ARP, DNS); * certain low data-volume applications or protocols (e.g. ARP, DNS);
* specific Diffserv codepoints that indicate traffic with limited * specific Diffserv codepoints that indicate traffic with limited
burstiness such as the EF (Expedited Forwarding [RFC3246]), Voice- burstiness such as the EF (Expedited Forwarding [RFC3246]), Voice-
Admit [RFC5865] or proposed NQB (Non-Queue- Admit [RFC5865] or proposed NQB (Non-Queue-
Building [I-D.ietf-tsvwg-nqb]) service classes or equivalent Building [I-D.ietf-tsvwg-nqb]) service classes or equivalent
local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]). local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).
To be clear, classifying into the L queue based on application layer
identification (e.g. DNS) is an example of a local optimization, not
a recommendation. Applications will not be able to rely on such
unsolicited optimization. A more reliable approach would be for the
sender to set an appropriate IP layer identifier, such as an NQB
Diffserv codepoint.
In summary, a network element that implements L4S in a shared queue In summary, a network element that implements L4S in a shared queue
MAY classify additional types of packets into the L queue based on MAY classify additional types of packets into the L queue based on
identifiers other than the ECN field, but the types SHOULD be 'safe' identifiers other than the ECN field, but the types SHOULD be 'safe'
to mix with L4S traffic, where 'safe' is explained in to mix with L4S traffic, where 'safe' is explained in
Section 5.4.1.1.1. Section 5.4.1.1.1.
A packet that carries one of these non-ECN identifiers to classify it A packet that carries one of these non-ECN identifiers to classify it
into the L queue would not be subject to the L4S ECN marking into the L queue would not be subject to the L4S ECN marking
treatment, unless it also carried an ECT(1) or CE codepoint. The treatment, unless it also carried an ECT(1) or CE codepoint. The
specification of an L4S AQM MUST define the behaviour for packets specification of an L4S AQM MUST define the behaviour for packets
skipping to change at page 37, line 41 skipping to change at page 38, line 9
Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague
Congestion Control", Work in Progress, Internet-Draft, Congestion Control", Work in Progress, Internet-Draft,
draft-briscoe-iccrg-prague-congestion-control-01, 11 July draft-briscoe-iccrg-prague-congestion-control-01, 11 July
2022, <https://www.ietf.org/archive/id/draft-briscoe- 2022, <https://www.ietf.org/archive/id/draft-briscoe-
iccrg-prague-congestion-control-01.txt>. iccrg-prague-congestion-control-01.txt>.
[I-D.briscoe-tsvwg-l4s-diffserv] [I-D.briscoe-tsvwg-l4s-diffserv]
Briscoe, B., "Interactions between Low Latency, Low Loss, Briscoe, B., "Interactions between Low Latency, Low Loss,
Scalable Throughput (L4S) and Differentiated Services", Scalable Throughput (L4S) and Differentiated Services",
Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s- Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-
diffserv-02, November 2018, diffserv-02, 4 November 2018,
<https://www.ietf.org/archive/id/draft-briscoe-tsvwg-l4s- <https://www.ietf.org/archive/id/draft-briscoe-tsvwg-l4s-
diffserv-02.txt>. diffserv-02.txt>.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress, Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion- Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, March 2022, <https://www.ietf.org/archive/id/ control-02, 7 March 2022,
draft-cardwell-iccrg-bbr-congestion-control-02.txt>. <https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-
congestion-control-02.txt>.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", Work in Progress, Internet- Accurate ECN Feedback in TCP", Work in Progress, Internet-
Draft, draft-ietf-tcpm-accurate-ecn-20, 25 July 2022, Draft, draft-ietf-tcpm-accurate-ecn-20, 25 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate- <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-
ecn-20.txt>. ecn-20.txt>.
[I-D.ietf-tcpm-generalized-ecn] [I-D.ietf-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
Congestion Notification (ECN) to TCP Control Packets", Congestion Notification (ECN) to TCP Control Packets",
Work in Progress, Internet-Draft, draft-ietf-tcpm- Work in Progress, Internet-Draft, draft-ietf-tcpm-
generalized-ecn-10, 27 July 2022, generalized-ecn-10, 27 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tcpm- <https://datatracker.ietf.org/api/v1/doc/document/draft-
generalized-ecn-10.txt>. ietf-tcpm-generalized-ecn/>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://datatracker.ietf.org/api/v1/doc/document/draft-
dtls13-43.txt>. ietf-tls-dtls13/>.
[I-D.ietf-trill-ecn-support] [I-D.ietf-trill-ecn-support]
Eastlake, D. E. and B. Briscoe, "TRILL (TRansparent Eastlake, D. E. and B. Briscoe, "TRILL (TRansparent
Interconnection of Lots of Links): ECN (Explicit Interconnection of Lots of Links): ECN (Explicit
Congestion Notification) Support", Work in Progress, Congestion Notification) Support", Work in Progress,
Internet-Draft, draft-ietf-trill-ecn-support-07, 25 Internet-Draft, draft-ietf-trill-ecn-support-07, 25
February 2018, <https://www.ietf.org/archive/id/draft- February 2018,
ietf-trill-ecn-support-07.txt>. <https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-trill-ecn-support/>.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K. D., Briscoe, B., and G. White, "DualQ Coupled Schepper, K. D., Briscoe, B., and G. White, "DualQ Coupled
AQMs for Low Latency, Low Loss and Scalable Throughput AQMs for Low Latency, Low Loss and Scalable Throughput
(L4S)", Work in Progress, Internet-Draft, draft-ietf- (L4S)", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-aqm-dualq-coupled-24, July 2022, tsvwg-aqm-dualq-coupled-24, 7 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm- <https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-
dualq-coupled-24.txt>. dualq-coupled-24.txt>.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP", Congestion Notification to Protocols that Encapsulate IP",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn- Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-
encap-guidelines-17, 11 July 2022, encap-guidelines-17, 11 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecn- <https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecn-
encap-guidelines-17.txt>. encap-guidelines-17.txt>.
skipping to change at page 39, line 23 skipping to change at page 39, line 39
[I-D.ietf-tsvwg-l4sops] [I-D.ietf-tsvwg-l4sops]
White, G., "Operational Guidance for Deployment of L4S in White, G., "Operational Guidance for Deployment of L4S in
the Internet", Work in Progress, Internet-Draft, draft- the Internet", Work in Progress, Internet-Draft, draft-
ietf-tsvwg-l4sops-03, 28 April 2022, ietf-tsvwg-l4sops-03, 28 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4sops- <https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4sops-
03.txt>. 03.txt>.
[I-D.ietf-tsvwg-nqb] [I-D.ietf-tsvwg-nqb]
White, G. and T. Fossati, "A Non-Queue-Building Per-Hop White, G. and T. Fossati, "A Non-Queue-Building Per-Hop
Behavior (NQB PHB) for Differentiated Services", Work in Behavior (NQB PHB) for Differentiated Services", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-nqb-10, March Progress, Internet-Draft, draft-ietf-tsvwg-nqb-10, 4 March
2022, <https://www.ietf.org/archive/id/draft-ietf-tsvwg- 2022, <https://www.ietf.org/archive/id/draft-ietf-tsvwg-
nqb-10.txt>. nqb-10.txt>.
[I-D.ietf-tsvwg-rfc6040update-shim] [I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", Work in Across IP Tunnel Headers Separated by a Shim", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update- Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update-
shim-15, 11 July 2022, <https://www.ietf.org/archive/id/ shim-15, 11 July 2022, <https://www.ietf.org/archive/id/
draft-ietf-tsvwg-rfc6040update-shim-15.txt>. draft-ietf-tsvwg-rfc6040update-shim-15.txt>.
 End of changes. 26 change blocks. 
39 lines changed or deleted 52 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/