draft-ietf-tsvwg-l4s-arch-00.txt   draft-ietf-tsvwg-l4s-arch-01.txt 
Transport Area Working Group B. Briscoe, Ed. Transport Area Working Group B. Briscoe, Ed.
Internet-Draft Simula Research Lab Internet-Draft CableLabs
Intended status: Informational K. De Schepper Intended status: Informational K. De Schepper
Expires: November 6, 2017 Nokia Bell Labs Expires: May 3, 2018 Nokia Bell Labs
M. Bagnulo Braun M. Bagnulo Braun
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
May 5, 2017 October 30, 2017
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-00 draft-ietf-tsvwg-l4s-arch-01
Abstract Abstract
This document describes the L4S architecture for the provision of a This document describes the L4S architecture for the provision of a
new Internet service that could eventually replace best efforts for new Internet service that could eventually replace best efforts for
all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is
becoming common for _all_ (or most) applications being run by a user becoming common for _all_ (or most) applications being run by a user
at any one time to require low latency. However, the only solution at any one time to require low latency. However, the only solution
the IETF can offer for ultra-low queuing delay is Diffserv, which the IETF can offer for ultra-low queuing delay is Diffserv, which
only favours a minority of packets at the expense of others. In only favours a minority of packets at the expense of others. In
skipping to change at page 2, line 13 skipping to change at page 2, line 13
aforementioned enhanced Internet service. aforementioned enhanced Internet service.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 November 6, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
6.3.4. Other Potential Deployment Issues . . . . . . . . . . 20 6.3.4. Other Potential Deployment Issues . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 21 8.1. Traffic (Non-)Policing . . . . . . . . . . . . . . . . . 21
8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 22 8.2. 'Latency Friendliness' . . . . . . . . . . . . . . . . . 22
8.3. Policing Prioritized L4S Bandwidth . . . . . . . . . . . 22 8.3. Policing Prioritized L4S Bandwidth . . . . . . . . . . . 22
8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 23 8.4. ECN Integrity . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Standardization items . . . . . . . . . . . . . . . 28 Appendix A. Standardization items . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 5, line 26 skipping to change at page 5, line 26
2) Protocol: A host needs to distinguish L4S and Classic packets 2) Protocol: A host needs to distinguish L4S and Classic packets
with an identifier so that the network can classify them into with an identifier so that the network can classify them into
their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers their separate treatments. [I-D.ietf-tsvwg-ecn-l4s-id] considers
various alternative identifiers, and concludes that all various alternative identifiers, and concludes that all
alternatives involve compromises, but the ECT(1) codepoint of the alternatives involve compromises, but the ECT(1) codepoint of the
ECN field is a workable solution. ECN field is a workable solution.
3) Host: Scalable congestion controls already exist. They solve the 3) Host: Scalable congestion controls already exist. They solve the
scaling problem with TCP first pointed out in [RFC3649]. The one scaling problem with TCP first pointed out in [RFC3649]. The one
used most widely (in controlled environments) is Data Centre TCP used most widely (in controlled environments) is Data Centre TCP
(DCTCP [I-D.ietf-tcpm-dctcp]), which has been implemented and (DCTCP [RFC8257]), which has been implemented and deployed in
deployed in Windows Server Editions (since 2012), in Linux and in Windows Server Editions (since 2012), in Linux and in FreeBSD.
FreeBSD. Although DCTCP as-is 'works' well over the public Although DCTCP as-is 'works' well over the public Internet, most
Internet, most implementations lack certain safety features that implementations lack certain safety features that will be
will be necessary once it is used outside controlled environments necessary once it is used outside controlled environments like
like data centres (see later). A similar scalable congestion data centres (see later). A similar scalable congestion control
control will also need to be transplanted into protocols other will also need to be transplanted into protocols other than TCP
than TCP (SCTP, RTP/RTCP, RMCAT, etc.) (SCTP, RTP/RTCP, RMCAT, etc.)
(2) (1) (2) (1)
.-------^------. .--------------^-------------------. .-------^------. .--------------^-------------------.
,-(3)-----. ______ ,-(3)-----. ______
; ________ : L4S --------. | | ; ________ : L4S --------. | |
:|Scalable| : _\ ||___\_| mark | :|Scalable| : _\ ||___\_| mark |
:| sender | : __________ / / || / |______|\ _________ :| sender | : __________ / / || / |______|\ _________
:|________|\; | |/ --------' ^ \1| | :|________|\; | |/ --------' ^ \1| |
`---------'\_| IP-ECN | Coupling : \|priority |_\ `---------'\_| IP-ECN | Coupling : \|priority |_\
________ / |Classifier| : /|scheduler| / ________ / |Classifier| : /|scheduler| /
|Classic |/ |__________|\ --------. ___:__ / |_________| |Classic |/ |__________|\ --------. ___:__ / |_________|
skipping to change at page 8, line 41 skipping to change at page 8, line 41
comply with to ensure that the L4S and Classic services will coexist. comply with to ensure that the L4S and Classic services will coexist.
For instance, a variant of PIE called Dual PI Squared [PI2] has been For instance, a variant of PIE called Dual PI Squared [PI2] has been
implemented and found to perform better than Curvy RED over a wide implemented and found to perform better than Curvy RED over a wide
range of conditions, so it has been documented in a second appendix range of conditions, so it has been documented in a second appendix
of [I-D.ietf-tsvwg-aqm-dualq-coupled]. of [I-D.ietf-tsvwg-aqm-dualq-coupled].
Host mechanisms: The L4S architecture includes a number of mechanisms Host mechanisms: The L4S architecture includes a number of mechanisms
in the end host that we enumerate next: in the end host that we enumerate next:
a. Data Centre TCP is the most widely used example of a scalable a. Data Centre TCP is the most widely used example of a scalable
congestion control. It is being documented in the TCPM WG as an congestion control. It has been documented as an informational
informational record of the protocol currently in use record of the protocol currently in use [RFC8257]. It will be
[I-D.ietf-tcpm-dctcp]. It will be necessary to define a number necessary to define a number of safety features for a variant
of safety features for a variant usable on the public Internet. usable on the public Internet. A draft list of these, known as
A draft list of these, known as the TCP Prague requirements, has the TCP Prague requirements, has been drawn up (see Appendix A of
been drawn up (see Appendix A of [I-D.ietf-tsvwg-ecn-l4s-id]). [I-D.ietf-tsvwg-ecn-l4s-id]). The list also includes some
The list also includes some optional performance improvements. optional performance improvements.
b. Transport protocols other than TCP use various congestion b. Transport protocols other than TCP use various congestion
controls designed to be friendly with Classic TCP. Before they controls designed to be friendly with Classic TCP. Before they
can use the L4S service, it will be necessary to implement can use the L4S service, it will be necessary to implement
scalable variants of each of these congestion control behaviours. scalable variants of each of these congestion control behaviours.
The following standards track RFCs currently define these The following standards track RFCs currently define these
protocols: ECN in TCP [RFC3168], in SCTP [RFC4960], in RTP protocols: ECN in TCP [RFC3168], in SCTP [RFC4960], in RTP
[RFC6679], and in DCCP [RFC4340]. Not all are in widespread use, [RFC6679], and in DCCP [RFC4340]. Not all are in widespread use,
but those that are will eventually need to be updated to allow a but those that are will eventually need to be updated to allow a
different congestion response, which they will have to indicate different congestion response, which they will have to indicate
skipping to change at page 21, line 36 skipping to change at page 21, line 36
bottleneck, such networks will introduce some queuing and dropping. bottleneck, such networks will introduce some queuing and dropping.
When a scalable congestion control detects a drop it will have to When a scalable congestion control detects a drop it will have to
respond as if it is a Classic congestion control (as required in respond as if it is a Classic congestion control (as required in
Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]). This will ensure safe Section 2.3 of [I-D.ietf-tsvwg-ecn-l4s-id]). This will ensure safe
interworking with other traffic at the 'legacy' bottleneck, but it interworking with other traffic at the 'legacy' bottleneck, but it
will degrade the L4S service to no better (but never worse) than will degrade the L4S service to no better (but never worse) than
classic best efforts, whenever a legacy (non-L4S) bottleneck is classic best efforts, whenever a legacy (non-L4S) bottleneck is
encountered on a path. encountered on a path.
Certain network operators might choose to restrict access to the L4S Certain network operators might choose to restrict access to the L4S
class, perhaps only to customers who have paid a premium. Their class, perhaps only to selected premium customers as a value-added
packet classifier (item 2 in Figure 1) could identify such customers service. Their packet classifier (item 2 in Figure 1) could identify
against some other field (e.g. source address range) as well as ECN. such customers against some other field (e.g. source address range)
If only the ECN L4S identifier matched, but not the source address as well as ECN. If only the ECN L4S identifier matched, but not the
(say), the classifier could direct these packets (from non-paying source address (say), the classifier could direct these packets (from
customers) into the Classic queue. Allowing operators to use an non-premium customers) into the Classic queue. Allowing operators to
additional local classifier is intended to remove any incentive to use an additional local classifier is intended to remove any
bleach the L4S identifier. Then at least the L4S ECN identifier will incentive to bleach the L4S identifier. Then at least the L4S ECN
be more likely to survive end-to-end even though the service may not identifier will be more likely to survive end-to-end even though the
be supported at every hop. Such arrangements would only require service may not be supported at every hop. Such arrangements would
simple registered/not-registered packet classification, rather than only require simple registered/not-registered packet classification,
the managed application-specific traffic policing against customer- rather than the managed application-specific traffic policing against
specific traffic contracts that Diffserv requires. customer-specific traffic contracts that Diffserv requires.
8.2. 'Latency Friendliness' 8.2. 'Latency Friendliness'
The L4S service does rely on self-constraint - not in terms of The L4S service does rely on self-constraint - not in terms of
limiting capacity usage, but in terms of limiting burstiness. It is limiting rate, but in terms of limiting latency. It is hoped that
hoped that standardisation of dynamic behaviour (cf. TCP slow-start) standardisation of dynamic behaviour (cf. TCP slow-start) and self-
and self-interest will be sufficient to prevent transports from interest will be sufficient to prevent transports from sending
sending excessive bursts of L4S traffic, given the application's own excessive bursts of L4S traffic, given the application's own latency
latency will suffer most from such behaviour. will suffer most from such behaviour.
Whether burst policing becomes necessary remains to be seen. Without Whether burst policing becomes necessary remains to be seen. Without
it, there will be potential for attacks on the low latency of the L4S it, there will be potential for attacks on the low latency of the L4S
service. However it may only be necessary to apply such policing service. However it may only be necessary to apply such policing
reactively, e.g. punitively targeted at any deployments of new bursty reactively, e.g. punitively targeted at any deployments of new bursty
malware. malware.
8.3. Policing Prioritized L4S Bandwidth 8.3. Policing Prioritized L4S Bandwidth
As mentioned in Section 5.2, L4S should remove the need for low As mentioned in Section 5.2, L4S should remove the need for low
latency Diffserv classes. However, those Diffserv classes that give latency Diffserv classes. However, those Diffserv classes that give
certain applications or users priority over capacity, would still be certain applications or users priority over capacity, would still be
applicable. Then, within such Diffserv classes, L4S would often be applicable. Then, within such Diffserv classes, L4S would often be
applicable to give traffic low latency and low loss. WIthin such a applicable to give traffic low latency and low loss. Within such a
class, the bandwidth available to a user or application is often class, the bandwidth available to a user or application is often
limited by a rate policer. Similarly, in the default Diffserv class, limited by a rate policer. Similarly, in the default Diffserv class,
rate policers are used to partition shared capacity. rate policers are used to partition shared capacity.
A classic rate policer drops any packets exceeding a set rate, A classic rate policer drops any packets exceeding a set rate,
usually also giving a burst allowance (variants exist where the usually also giving a burst allowance (variants exist where the
policer re-marks non-compliant traffic to a discard-eligible Diffserv policer re-marks non-compliant traffic to a discard-eligible Diffserv
codepoint, so they may be dropped elsewhere during contention). In codepoint, so they may be dropped elsewhere during contention). In
networks that deploy L4S and use rate policers, it will be preferable networks that deploy L4S and use rate policers, it will be preferable
to deploy a policer designed to be more friendly to the L4S service, to deploy a policer designed to be more friendly to the L4S service,
skipping to change at page 23, line 37 skipping to change at page 23, line 37
congestion feedback, but it is being reclassified as historic. congestion feedback, but it is being reclassified as historic.
Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] gives more details of Appendix C.1 of [I-D.ietf-tsvwg-ecn-l4s-id] gives more details of
these techniques including their applicability and pros and cons. these techniques including their applicability and pros and cons.
9. Acknowledgements 9. Acknowledgements
Thanks to Wes Eddy, Karen Nielsen and David Black for their useful Thanks to Wes Eddy, Karen Nielsen and David Black for their useful
review comments. review comments.
Bob Briscoe and Koen De Schepper were part-funded by the European
Community under its Seventh Framework Programme through the Reducing
Internet Transport Latency (RITE) project (ICT-317700). Bob Briscoe
was also part-funded by the Research Council of Norway through the
TimeIn project. The views expressed here are solely those of the
authors.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 10.2. Informative References
[BBR] Cardwell, N., Cheng, Y., Gunn, C., Yeganeh, S., and V. [BBR] Cardwell, N., Cheng, Y., Gunn, C., Yeganeh, S., and V.
Jacobson, "BBR: Congestion-Based Congestion Control; Jacobson, "BBR: Congestion-Based Congestion Control;
Measuring bottleneck bandwidth and round-trip propagation Measuring bottleneck bandwidth and round-trip propagation
time", ACM Queue (14)5, December 2016. time", ACM Queue (14)5, December 2016.
[DCttH15] De Schepper, K., Bondarenko, O., Tsang, I., and B. [DCttH15] De Schepper, K., Bondarenko, O., Tsang, I., and B.
Briscoe, "'Data Centre to the Home': Ultra-Low Latency for Briscoe, "'Data Centre to the Home': Ultra-Low Latency for
skipping to change at page 24, line 18 skipping to change at page 24, line 25
dctth_preprint.pdf>. dctth_preprint.pdf>.
(Under submission) (Under submission)
[Hohlfeld14] [Hohlfeld14]
Hohlfeld , O., Pujol, E., Ciucu, F., Feldmann, A., and P. Hohlfeld , O., Pujol, E., Ciucu, F., Feldmann, A., and P.
Barford, "A QoE Perspective on Sizing Network Buffers", Barford, "A QoE Perspective on Sizing Network Buffers",
Proc. ACM Internet Measurement Conf (IMC'14) hmm, November Proc. ACM Internet Measurement Conf (IMC'14) hmm, November
2014. 2014.
[I-D.bagnulo-tcpm-generalized-ecn]
Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion
Notification (ECN) to TCP control packets and TCP
retransmissions", draft-bagnulo-tcpm-generalized-ecn-03
(work in progress), April 2017.
[I-D.briscoe-conex-policing] [I-D.briscoe-conex-policing]
Briscoe, B., "Network Performance Isolation using Briscoe, B., "Network Performance Isolation using
Congestion Policing", draft-briscoe-conex-policing-01 Congestion Policing", draft-briscoe-conex-policing-01
(work in progress), February 2014. (work in progress), February 2014.
[I-D.iab-protocol-transitions] [I-D.iab-protocol-transitions]
Thaler, D., "Planning for Protocol Adoption and Subsequent Thaler, D., "Planning for Protocol Adoption and Subsequent
Transitions", draft-iab-protocol-transitions-08 (work in Transitions", draft-iab-protocol-transitions-08 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-aqm-fq-codel] [I-D.ietf-aqm-fq-codel]
Hoeiland-Joergensen, T., McKenney, P., Hoeiland-Joergensen, T., McKenney, P.,
dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The
FlowQueue-CoDel Packet Scheduler and Active Queue FlowQueue-CoDel Packet Scheduler and Active Queue
Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in
progress), March 2016. progress), March 2016.
[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-02 (work in progress), October 2016. ecn-03 (work in progress), May 2017.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-01 (work in progress), May 2017. alternativebackoff-ecn-02 (work in progress), October
2017.
[I-D.ietf-tcpm-cubic] [I-D.ietf-tcpm-cubic]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
draft-ietf-tcpm-cubic-04 (work in progress), February draft-ietf-tcpm-cubic-06 (work in progress), September
2017. 2017.
[I-D.ietf-tcpm-dctcp] [I-D.ietf-tcpm-generalized-ecn]
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion Congestion Notification (ECN) to TCP Control Packets",
Control for Datacenters", draft-ietf-tcpm-dctcp-05 (work draft-ietf-tcpm-generalized-ecn-02 (work in progress),
in progress), March 2017. October 2017.
[I-D.ietf-tsvwg-aqm-dualq-coupled] [I-D.ietf-tsvwg-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang, Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,
"DualQ Coupled AQM for Low Latency, Low Loss and Scalable "DualQ Coupled AQM for Low Latency, Low Loss and Scalable
Throughput", draft-ietf-tsvwg-aqm-dualq-coupled-00 (work Throughput", draft-ietf-tsvwg-aqm-dualq-coupled-00 (work
in progress), April 2017. in progress), April 2017.
[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-08 (work in progress), March 2017. encap-guidelines-09 (work in progress), July 2017.
[I-D.ietf-tsvwg-ecn-experimentation] [I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Explicit Congestion Notification (ECN) Black, D., "Relaxing Restrictions on Explicit Congestion
Experimentation", draft-ietf-tsvwg-ecn-experimentation-02 Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
(work in progress), April 2017. experimentation-07 (work in progress), October 2017.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K., Briscoe, B., and I. Tsang, "Identifying Schepper, K., Briscoe, B., and I. Tsang, "Identifying
Modified Explicit Congestion Notification (ECN) Semantics Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s- for Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-
id-00 (work in progress), April 2017. id-00 (work in progress), April 2017.
[I-D.johansson-quic-ecn] [I-D.johansson-quic-ecn]
Johansson, I., "ECN support in QUIC", draft-johansson- Johansson, I., "ECN support in QUIC", draft-johansson-
quic-ecn-02 (work in progress), April 2017. quic-ecn-03 (work in progress), May 2017.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft- Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
[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.
skipping to change at page 26, line 37 skipping to change at page 26, line 37
July 2007. July 2007.
[PI2] De Schepper, K., Bondarenko, O., Tsang, I., and B. [PI2] De Schepper, K., Bondarenko, O., Tsang, I., and B.
Briscoe, "PI^2 : A Linearized AQM for both Classic and Briscoe, "PI^2 : A Linearized AQM for both Classic and
Scalable TCP", Proc. ACM CoNEXT 2016 pp.105-119, December Scalable TCP", Proc. ACM CoNEXT 2016 pp.105-119, December
2016, 2016,
<http://dl.acm.org/citation.cfm?doid=2999572.2999578>. <http://dl.acm.org/citation.cfm?doid=2999572.2999578>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<http://www.rfc-editor.org/info/rfc2697>. <https://www.rfc-editor.org/info/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<http://www.rfc-editor.org/info/rfc2698>. <https://www.rfc-editor.org/info/rfc2698>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>. <https://www.rfc-editor.org/info/rfc3246>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003, RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>. <https://www.rfc-editor.org/info/rfc3540>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003, RFC 3649, DOI 10.17487/RFC3649, December 2003,
<http://www.rfc-editor.org/info/rfc3649>. <https://www.rfc-editor.org/info/rfc3649>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<http://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, DOI 10.17487/RFC4774, November 2006, RFC 4774, DOI 10.17487/RFC4774, November 2006,
<http://www.rfc-editor.org/info/rfc4774>. <https://www.rfc-editor.org/info/rfc4774>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,
"Problem Statement and Requirements for Increased Accuracy "Problem Statement and Requirements for Increased Accuracy
in Explicit Congestion Notification (ECN) Feedback", in Explicit Congestion Notification (ECN) Feedback",
RFC 7560, DOI 10.17487/RFC7560, August 2015, RFC 7560, DOI 10.17487/RFC7560, August 2015,
<http://www.rfc-editor.org/info/rfc7560>. <https://www.rfc-editor.org/info/rfc7560>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>. <https://www.rfc-editor.org/info/rfc7713>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A "Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<http://www.rfc-editor.org/info/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[TCP-sub-mss-w] [TCP-sub-mss-w]
Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion
Window for Small Round Trip Times", BT Technical Report Window for Small Round Trip Times", BT Technical Report
TR-TUB8-2015-002, May 2015, TR-TUB8-2015-002, May 2015,
<http://www.bobbriscoe.net/projects/latency/ <http://www.bobbriscoe.net/projects/latency/
sub-mss-w.pdf>. sub-mss-w.pdf>.
Appendix A. Standardization items Appendix A. Standardization items
skipping to change at page 29, line 21 skipping to change at page 29, line 26
+-----+------------------------+------------------------------------+ +-----+------------------------+------------------------------------+
| 0 | ARCHITECTURE | | | 0 | ARCHITECTURE | |
| 1 | L4S IDENTIFIER | [I-D.ietf-tsvwg-ecn-l4s-id] | | 1 | L4S IDENTIFIER | [I-D.ietf-tsvwg-ecn-l4s-id] |
| 2 | DUAL QUEUE AQM | [I-D.ietf-tsvwg-aqm-dualq-coupled] | | 2 | DUAL QUEUE AQM | [I-D.ietf-tsvwg-aqm-dualq-coupled] |
| 3 | Suitable ECN Feedback | [I-D.ietf-tcpm-accurate-ecn], | | 3 | Suitable ECN Feedback | [I-D.ietf-tcpm-accurate-ecn], |
| | | [I-D.stewart-tsvwg-sctpecn]. | | | | [I-D.stewart-tsvwg-sctpecn]. |
| | | | | | | |
| | SCALABLE TRANSPORT - | | | | SCALABLE TRANSPORT - | |
| | SAFETY ADDITIONS | | | | SAFETY ADDITIONS | |
| 4-1 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, | | 4-1 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, |
| | Reno/Cubic on loss | [I-D.ietf-tcpm-dctcp] | | | Reno/Cubic on loss | [RFC8257] |
| 4-2 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 | | 4-2 | Fall back to | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 |
| | Reno/Cubic if classic | | | | Reno/Cubic if classic | |
| | ECN bottleneck | | | | ECN bottleneck | |
| | detected | | | | detected | |
| | | | | | | |
| 4-3 | Reduce RTT-dependence | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 | | 4-3 | Reduce RTT-dependence | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3 |
| | | | | | | |
| 4-4 | Scaling TCP's | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, | | 4-4 | Scaling TCP's | [I-D.ietf-tsvwg-ecn-l4s-id] S.2.3, |
| | Congestion Window for | [TCP-sub-mss-w] | | | Congestion Window for | [TCP-sub-mss-w] |
| | Small Round Trip Times | | | | Small Round Trip Times | |
| | SCALABLE TRANSPORT - | | | | SCALABLE TRANSPORT - | |
| | PERFORMANCE | | | | PERFORMANCE | |
| | ENHANCEMENTS | | | | ENHANCEMENTS | |
| 5-1 | Setting ECT in TCP | [I-D.bagnulo-tcpm-generalized-ecn] | | 5-1 | Setting ECT in TCP | [I-D.ietf-tcpm-generalized-ecn] |
| | Control Packets and | | | | Control Packets and | |
| | Retransmissions | | | | Retransmissions | |
| 5-2 | Faster-than-additive | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx | | 5-2 | Faster-than-additive | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx |
| | increase | A.2.2) | | | increase | A.2.2) |
| 5-3 | Faster Convergence at | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx | | 5-3 | Faster Convergence at | [I-D.ietf-tsvwg-ecn-l4s-id] (Appx |
| | Flow Start | A.2.2) | | | Flow Start | A.2.2) |
+-----+------------------------+------------------------------------+ +-----+------------------------+------------------------------------+
+-----+--------+-----+-------+-----------+--------+--------+--------+ +-----+--------+-----+-------+-----------+--------+--------+--------+
| # | WG | TCP | DCTCP | DCTCP-bis | TCP | SCTP | RMCAT | | # | WG | TCP | DCTCP | DCTCP-bis | TCP | SCTP | RMCAT |
| | | | | | Prague | Prague | Prague | | | | | | | Prague | Prague | Prague |
skipping to change at page 30, line 40 skipping to change at page 30, line 40
| | | | | | | | | | | | | | | | | |
| 5-2 | tcpm/ | | | Y | Y | Y | ? | | 5-2 | tcpm/ | | | Y | Y | Y | ? |
| | iccrg? | | | | | | | | | iccrg? | | | | | | |
| 5-3 | tcpm/ | | | Y | Y | Y | ? | | 5-3 | tcpm/ | | | Y | Y | Y | ? |
| | iccrg? | | | | | | | | | iccrg? | | | | | | |
+-----+--------+-----+-------+-----------+--------+--------+--------+ +-----+--------+-----+-------+-----------+--------+--------+--------+
Authors' Addresses Authors' Addresses
Bob Briscoe (editor) Bob Briscoe (editor)
Simula Research Lab CableLabs
UK
Email: ietf@bobbriscoe.net Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
Koen De Schepper Koen De Schepper
Nokia Bell Labs Nokia Bell Labs
Antwerp Antwerp
Belgium Belgium
Email: koen.de_schepper@nokia.com Email: koen.de_schepper@nokia.com
URI: https://www.bell-labs.com/usr/koen.de_schepper URI: https://www.bell-labs.com/usr/koen.de_schepper
 End of changes. 43 change blocks. 
82 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/