draft-ietf-tsvwg-l4s-arch-07.txt   draft-ietf-tsvwg-l4s-arch-08.txt 
Transport Area Working Group B. Briscoe, Ed. Transport Area Working Group B. Briscoe, Ed.
Internet-Draft Independent Internet-Draft Independent
Intended status: Informational K. De Schepper Intended status: Informational K. De Schepper
Expires: April 30, 2021 Nokia Bell Labs Expires: May 19, 2021 Nokia Bell Labs
M. Bagnulo Braun M. Bagnulo Braun
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
G. White G. White
CableLabs CableLabs
October 27, 2020 November 15, 2020
Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture Architecture
draft-ietf-tsvwg-l4s-arch-07 draft-ietf-tsvwg-l4s-arch-08
Abstract Abstract
This document describes the L4S architecture, which enables Internet This document describes the L4S architecture, which enables Internet
applications to achieve Low queuing Latency, Low Loss, and Scalable applications to achieve Low queuing Latency, Low Loss, and Scalable
throughput (L4S). The insight on which L4S is based is that the root throughput (L4S). The insight on which L4S is based is that the root
cause of queuing delay is in the congestion controllers of senders, cause of queuing delay is in the congestion controllers of senders,
not in the queue itself. The L4S architecture is intended to enable not in the queue itself. The L4S architecture is intended to enable
_all_ Internet applications to transition away from congestion _all_ Internet applications to transition away from congestion
control algorithms that cause queuing delay, to a new class of control algorithms that cause queuing delay, to a new class of
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 April 30, 2021. This Internet-Draft will expire on May 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5 2. L4S Architecture Overview . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L4S Architecture Components . . . . . . . . . . . . . . . . . 7 4. L4S Architecture Components . . . . . . . . . . . . . . . . . 7
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Why These Primary Components? . . . . . . . . . . . . . . 11 5.1. Why These Primary Components? . . . . . . . . . . . . . . 12
5.2. What L4S adds to Existing Approaches . . . . . . . . . . 14 5.2. What L4S adds to Existing Approaches . . . . . . . . . . 14
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Applications . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Applicability with Specific Link Technologies . . . . . . 19 6.3. Applicability with Specific Link Technologies . . . . . . 20
6.4. Deployment Considerations . . . . . . . . . . . . . . . . 20 6.4. Deployment Considerations . . . . . . . . . . . . . . . . 20
6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 20 6.4.1. Deployment Topology . . . . . . . . . . . . . . . . . 21
6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 22 6.4.2. Deployment Sequences . . . . . . . . . . . . . . . . 22
6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 24 6.4.3. L4S Flow but Non-ECN Bottleneck . . . . . . . . . . . 25
6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 25 6.4.4. L4S Flow but Classic ECN Bottleneck . . . . . . . . . 25
6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 25 6.4.5. L4S AQM Deployment within Tunnels . . . . . . . . . . 26
7. IANA Considerations (to be removed by RFC Editor) . . . . . . 25 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 25 8.1. Traffic Rate (Non-)Policing . . . . . . . . . . . . . . . 26
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 26 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 27
8.3. Interaction between Rate Policing and L4S . . . . . . . . 28 8.3. Interaction between Rate Policing and L4S . . . . . . . . 29
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 29 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 29
8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 29 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10. Informative References . . . . . . . . . . . . . . . . . . . 30 10. Informative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. Standardization items . . . . . . . . . . . . . . . 38 Appendix A. Standardization items . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
It is increasingly common for _all_ of a user's applications at any It is increasingly common for _all_ of a user's applications at any
one time to require low delay: interactive Web, Web services, voice, one time to require low delay: interactive Web, Web services, voice,
conversational video, interactive video, interactive remote presence, conversational video, interactive video, interactive remote presence,
instant messaging, online gaming, remote desktop, cloud-based instant messaging, online gaming, remote desktop, cloud-based
applications and video-assisted remote control of machinery and applications and video-assisted remote control of machinery and
skipping to change at page 6, line 37 skipping to change at page 6, line 37
its recovery time triples to over 340 round trips, or still more its recovery time triples to over 340 round trips, or still more
than 12 seconds (Reno would take 57 seconds). than 12 seconds (Reno would take 57 seconds).
Scalable Congestion Control: A congestion control where the average Scalable Congestion Control: A congestion control where the average
time from one congestion signal to the next (the recovery time) time from one congestion signal to the next (the recovery time)
remains invariant as the flow rate scales, all other factors being remains invariant as the flow rate scales, all other factors being
equal. This maintains the same degree of control over queueing equal. This maintains the same degree of control over queueing
and utilization whatever the flow rate, as well as ensuring that and utilization whatever the flow rate, as well as ensuring that
high throughput is more robust to disturbances (e.g. from new high throughput is more robust to disturbances (e.g. from new
flows starting). For instance, DCTCP averages 2 congestion flows starting). For instance, DCTCP averages 2 congestion
signals per round-trip whatever the flow rate. See Section 4.3 of signals per round-trip whatever the flow rate, as do other
recently developed scalable congestion controls, e.g. Relentless
TCP [Mathis09], TCP Prague [PragueLinux] and the L4S variant of
SCReAM for real-time media [RFC8298]).See Section 4.3 of
[I-D.ietf-tsvwg-ecn-l4s-id] for more explanation. [I-D.ietf-tsvwg-ecn-l4s-id] for more explanation.
Classic service: The Classic service is intended for all the Classic service: The Classic service is intended for all the
congestion control behaviours that co-exist with Reno [RFC5681] congestion control behaviours that co-exist with Reno [RFC5681]
(e.g. Reno itself, Cubic [RFC8312], (e.g. Reno itself, Cubic [RFC8312],
Compound [I-D.sridharan-tcpm-ctcp], TFRC [RFC5348]). The term Compound [I-D.sridharan-tcpm-ctcp], TFRC [RFC5348]). The term
'Classic queue' means a queue providing the Classic service. 'Classic queue' means a queue providing the Classic service.
Low-Latency, Low-Loss Scalable throughput (L4S) service: The 'L4S' Low-Latency, Low-Loss Scalable throughput (L4S) service: The 'L4S'
service is intended for traffic from scalable congestion control service is intended for traffic from scalable congestion control
algorithms, such as Data Center TCP [RFC8257]. The L4S service is algorithms, such as Data Center TCP [RFC8257]. The L4S service is
for more general traffic than just DCTCP--it allows the set of for more general traffic than just DCTCP--it allows the set of
congestion controls with similar scaling properties to DCTCP to congestion controls with similar scaling properties to DCTCP to
evolve (e.g. Relentless TCP [Mathis09], TCP Prague [PragueLinux] evolve, such as the examples listed above (Relentless, Prague,
and the L4S variant of SCREAM for real-time media [RFC8298]). The SCReAM). The term 'L4S queue' means a queue providing the L4S
term 'L4S queue' means a queue providing the L4S service. service.
The terms Classic or L4S can also qualify other nouns, such as The terms Classic or L4S can also qualify other nouns, such as
'queue', 'codepoint', 'identifier', 'classification', 'packet', 'queue', 'codepoint', 'identifier', 'classification', 'packet',
'flow'. For example: an L4S packet means a packet with an L4S 'flow'. For example: an L4S packet means a packet with an L4S
identifier sent from an L4S congestion control. identifier sent from an L4S congestion control.
Both Classic and L4S services can cope with a proportion of Both Classic and L4S services can cope with a proportion of
unresponsive or less-responsive traffic as well, as long as it unresponsive or less-responsive traffic as well, as long as it
does not build a queue (e.g. DNS, VoIP, game sync datagrams, etc). does not build a queue (e.g. DNS, VoIP, game sync datagrams, etc).
skipping to change at page 10, line 48 skipping to change at page 10, line 48
be to differentiate flow rates (e.g. [Nadas20], which requires be to differentiate flow rates (e.g. [Nadas20], which requires
additional signalling of a per-flow 'value'), or to equalize additional signalling of a per-flow 'value'), or to equalize
flow-rates (perhaps in a similar way to Approx Fair CoDel [AFCD], flow-rates (perhaps in a similar way to Approx Fair CoDel [AFCD],
[I-D.morton-tsvwg-codel-approx-fair], but with two queues not [I-D.morton-tsvwg-codel-approx-fair], but with two queues not
one). one).
Note that whenever the term 'DualQ' is used loosely without Note that whenever the term 'DualQ' is used loosely without
saying whether marking is per-queue or per-flow, it means a dual saying whether marking is per-queue or per-flow, it means a dual
queue AQM with per-queue marking. queue AQM with per-queue marking.
Host mechanisms: The L4S architecture includes a number of mechanisms Host mechanisms: The L4S architecture includes two main mechanisms in
in the end host that we enumerate next: the end host that we enumerate next:
a. Data Center TCP is the most widely used example of a scalable a. Scalable Congestion Control: Data Center TCP is the most widely
congestion control. It has been documented as an informational used example. It has been documented as an informational record
record of the protocol currently in use [RFC8257]. It has been of the protocol currently in use in controlled
necessary to define a number of safety features for a variant environments [RFC8257]. A draft list of safety and performance
usable on the public Internet. A draft list of these, known as improvements for a scalable congestion control to be usable on
the Prague L4S requirements, has been drawn up (see Appendix A of the public Internet has been drawn up (the so-called 'Prague L4S
[I-D.ietf-tsvwg-ecn-l4s-id]). The list also includes some requirements' in Appendix A of [I-D.ietf-tsvwg-ecn-l4s-id]). The
optional performance improvements. subset that involve risk of harm to others have been captured as
normative requirements in Section 4 of
[I-D.ietf-tsvwg-ecn-l4s-id]. TCP Prague has been implemented in
Linux as a reference implementation to address these requirements
[PragueLinux].
b. Transport protocols other than TCP use various congestion Transport protocols other than TCP use various congestion
controls designed to be friendly with Reno. Before they can use controls that are designed to be friendly with Reno. Before they
the L4S service, it will be necessary to implement scalable can use the L4S service, it will be necessary to implement
variants of each of these congestion control behaviours. The scalable variants of each of these congestion control behaviours.
following standards track RFCs currently define these protocols: They will eventually need to be updated to implement a scalable
ECN in TCP [RFC3168], in SCTP [RFC4960], in RTP [RFC6679], and in
DCCP [RFC4340]. Not all are in widespread use, but those that
are will eventually need to be updated to allow a different
congestion response, which they will have to indicate by using congestion response, which they will have to indicate by using
the ECT(1) codepoint. Scalable variants are under consideration the ECT(1) codepoint. Scalable variants are under consideration
for some new transport protocols that are themselves under for some new transport protocols that are themselves under
development, e.g. QUIC [I-D.ietf-quic-transport] and certain development, e.g. QUIC. Also the L4S ECN part of
real-time media congestion avoidance techniques (RMCAT) BBRv2 [I-D.cardwell-iccrg-bbr-congestion-control] is a scalable
protocols. congestion control intended for the TCP and QUIC transports,
amongst others. Also an L4S variant of the RMCAT SCReAM
controller [RFC8298] has been implemented for media transported
over RTP.
c. ECN feedback is sufficient for L4S in some transport protocols b. ECN feedback is sufficient for L4S in some transport protocols
(RTCP, DCCP) but not others: (specifically DCCP [RFC4340] and QUIC [I-D.ietf-quic-transport]).
But others either require update or are in the process of being
updated:
* For the case of TCP, the feedback protocol for ECN embeds the * For the case of TCP, the feedback protocol for ECN embeds the
assumption from Classic ECN [RFC3168] that an ECN mark is assumption from Classic ECN [RFC3168] that an ECN mark is
equivalent to a drop, making it unusable for a scalable TCP. equivalent to a drop, making it unusable for a scalable TCP.
Therefore, the implementation of TCP receivers will have to be Therefore, the implementation of TCP receivers will have to be
upgraded [RFC7560]. Work to standardize and implement more upgraded [RFC7560]. Work to standardize and implement more
accurate ECN feedback for TCP (AccECN) is in accurate ECN feedback for TCP (AccECN) is in
progress [I-D.ietf-tcpm-accurate-ecn], [PragueLinux]. progress [I-D.ietf-tcpm-accurate-ecn], [PragueLinux].
* ECN feedback is only roughly sketched in an appendix of the * ECN feedback is only roughly sketched in an appendix of the
SCTP specification. A fuller specification has been proposed SCTP specification [RFC4960]. A fuller specification has been
[I-D.stewart-tsvwg-sctpecn], which would need to be proposed in a long-expired draft [I-D.stewart-tsvwg-sctpecn],
implemented and deployed before SCTCP could support L4S. which would need to be implemented and deployed before SCTCP
could support L4S.
* For RTP, sufficient ECN feedback was defined in [RFC6679], but
[I-D.ietf-avtcore-cc-feedback-message] defines the latest
standards track improvements.
5. Rationale 5. Rationale
5.1. Why These Primary Components? 5.1. Why These Primary Components?
Explicit congestion signalling (protocol): Explicit congestion Explicit congestion signalling (protocol): Explicit congestion
signalling is a key part of the L4S approach. In contrast, use of signalling is a key part of the L4S approach. In contrast, use of
drop as a congestion signal creates a tension because drop is both drop as a congestion signal creates a tension because drop is both
an impairment (less would be better) and a useful signal (more an impairment (less would be better) and a useful signal (more
would be better): would be better):
skipping to change at page 19, line 21 skipping to change at page 19, line 37
o Different types of transport (or application) congestion control: o Different types of transport (or application) congestion control:
* elastic (TCP/SCTP); * elastic (TCP/SCTP);
* real-time (RTP, RMCAT); * real-time (RTP, RMCAT);
* query (DNS/LDAP). * query (DNS/LDAP).
o Where low delay quality of service is required, but without o Where low delay quality of service is required, but without
inspecting or intervening above the IP inspecting or intervening above the IP layer [RFC8404]:
layer [I-D.smith-encrypted-traffic-management]:
* mobile and other networks have tended to inspect higher layers * mobile and other networks have tended to inspect higher layers
in order to guess application QoS requirements. However, with in order to guess application QoS requirements. However, with
growing demand for support of privacy and encryption, L4S growing demand for support of privacy and encryption, L4S
offers an alternative. There is no need to select which offers an alternative. There is no need to select which
traffic to favour for queuing, when L4S gives favourable traffic to favour for queuing, when L4S gives favourable
queuing to all traffic. queuing to all traffic.
o If queuing delay is minimized, applications with a fixed delay o If queuing delay is minimized, applications with a fixed delay
budget can communicate over longer distances, or via a longer budget can communicate over longer distances, or via a longer
chain of service functions [RFC7665] or onion routers. chain of service functions [RFC7665] or onion routers.
o If delay jitter is minimized, it is possible to reduce the
dejitter buffers on the receive end of video streaming, which
should improve the interactive experience
6.3. Applicability with Specific Link Technologies 6.3. Applicability with Specific Link Technologies
Certain link technologies aggregate data from multiple packets into Certain link technologies aggregate data from multiple packets into
bursts, and buffer incoming packets while building each burst. WiFi, bursts, and buffer incoming packets while building each burst. WiFi,
PON and cable all involve such packet aggregation, whereas fixed PON and cable all involve such packet aggregation, whereas fixed
Ethernet and DSL do not. No sender, whether L4S or not, can do Ethernet and DSL do not. No sender, whether L4S or not, can do
anything to reduce the buffering needed for packet aggregation. So anything to reduce the buffering needed for packet aggregation. So
an AQM should not count this buffering as part of the queue that it an AQM should not count this buffering as part of the queue that it
controls, given no amount of congestion signals will reduce it. controls, given no amount of congestion signals will reduce it.
skipping to change at page 31, line 39 skipping to change at page 32, line 26
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",
draft-briscoe-tsvwg-l4s-diffserv-02 (work in progress), draft-briscoe-tsvwg-l4s-diffserv-02 (work in progress),
November 2018. November 2018.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
"BBR Congestion Control", draft-cardwell-iccrg-bbr- "BBR Congestion Control", draft-cardwell-iccrg-bbr-
congestion-control-00 (work in progress), July 2017. congestion-control-00 (work in progress), July 2017.
[I-D.ietf-avtcore-cc-feedback-message]
Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
draft-ietf-avtcore-cc-feedback-message-09 (work in
progress), November 2020.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-32 (work and Secure Transport", draft-ietf-quic-transport-32 (work
in progress), October 2020. in progress), October 2020.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-11 (work in progress), March 2020. ecn-13 (work in progress), November 2020.
[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",
draft-ietf-tcpm-generalized-ecn-05 (work in progress), draft-ietf-tcpm-generalized-ecn-06 (work in progress),
November 2019. October 2020.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., and G. White, "DualQ Coupled Schepper, K., 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)", draft-ietf-tsvwg-aqm-dualq-coupled-12 (work in (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-12 (work in
progress), July 2020. progress), July 2020.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-13 (work in progress), May 2019. encap-guidelines-13 (work in progress), May 2019.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-10 (work in progress), March 2020. id-11 (work in progress), November 2020.
[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", draft-ietf- Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-10 (work in progress), March tsvwg-rfc6040update-shim-10 (work in progress), March
2020. 2020.
[I-D.morton-tsvwg-codel-approx-fair] [I-D.morton-tsvwg-codel-approx-fair]
Morton, J. and P. Heist, "Controlled Delay Approximate Morton, J. and P. Heist, "Controlled Delay Approximate
Fairness AQM", draft-morton-tsvwg-codel-approx-fair-01 Fairness AQM", draft-morton-tsvwg-codel-approx-fair-01
(work in progress), March 2020. (work in progress), March 2020.
[I-D.smith-encrypted-traffic-management]
Smith, K., "Network management of encrypted traffic",
draft-smith-encrypted-traffic-management-05 (work in
progress), May 2016.
[I-D.sridharan-tcpm-ctcp] [I-D.sridharan-tcpm-ctcp]
Sridharan, M., Tan, K., Bansal, D., and D. Thaler, Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed "Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
(work in progress), November 2008. (work in progress), November 2008.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", draft-stewart- Control Transmission Protocol (SCTP)", draft-stewart-
tsvwg-sctpecn-05 (work in progress), January 2014. tsvwg-sctpecn-05 (work in progress), January 2014.
 End of changes. 25 change blocks. 
60 lines changed or deleted 78 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/