draft-ietf-tcpm-generalized-ecn-01.txt   draft-ietf-tcpm-generalized-ecn-02.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Obsoletes: 5562 (if approved) B. Briscoe Obsoletes: 5562 (if approved) B. Briscoe
Intended status: Experimental CableLabs Intended status: Experimental CableLabs
Expires: April 1, 2018 September 28, 2017 Expires: May 3, 2018 October 30, 2017
ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control
Packets Packets
draft-ietf-tcpm-generalized-ecn-01 draft-ietf-tcpm-generalized-ecn-02
Abstract Abstract
This document describes an experimental modification to ECN when used This document describes an experimental modification to ECN when used
with TCP. It allows the use of ECN on the following TCP packets: with TCP. It allows the use of ECN on the following TCP packets:
SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 1, 2018. 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
(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 49 skipping to change at page 2, line 49
4.7. RSTs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.7. RSTs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8. Retransmitted Packets. . . . . . . . . . . . . . . . . . 29 4.8. Retransmitted Packets. . . . . . . . . . . . . . . . . . 29
4.9. General Fall-back for any Control Packet . . . . . . . . 30 4.9. General Fall-back for any Control Packet . . . . . . . . 30
5. Interaction with popular variants or derivatives of TCP . . . 31 5. Interaction with popular variants or derivatives of TCP . . . 31
5.1. IW10 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1. IW10 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2. TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. TCP Derivatives . . . . . . . . . . . . . . . . . . . . . 33 5.3. TCP Derivatives . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
RFC 3168 [RFC3168] specifies support of Explicit Congestion RFC 3168 [RFC3168] specifies support of Explicit Congestion
Notification (ECN) in IP (v4 and v6). By using the ECN capability, Notification (ECN) in IP (v4 and v6). By using the ECN capability,
network elements (e.g. routers, switches) performing Active Queue network elements (e.g. routers, switches) performing Active Queue
Management (AQM) can use ECN marks instead of packet drops to signal Management (AQM) can use ECN marks instead of packet drops to signal
skipping to change at page 4, line 8 skipping to change at page 4, line 8
bottleneck. For instance, with a drop probability of 1%, 1% of bottleneck. For instance, with a drop probability of 1%, 1% of
connection attempts suffer a timeout of about 1 second before the SYN connection attempts suffer a timeout of about 1 second before the SYN
is retransmitted, which is highly detrimental to the performance of is retransmitted, which is highly detrimental to the performance of
short flows. TCP control packets, particularly TCP SYNs and SYN- short flows. TCP control packets, particularly TCP SYNs and SYN-
ACKs, are important for performance, so dropping them is best ACKs, are important for performance, so dropping them is best
avoided. avoided.
Non-ECN control packets particularly harm performance in environments Non-ECN control packets particularly harm performance in environments
where the ECN marking level is high. For example, [judd-nsdi] shows where the ECN marking level is high. For example, [judd-nsdi] shows
that in a controlled private data centre (DC) environment where ECN that in a controlled private data centre (DC) environment where ECN
is used (in conjunction with DCTCP [I-D.ietf-tcpm-dctcp]), the is used (in conjunction with DCTCP [RFC8257]), the probability of
probability of being able to establish a new connection using a non- being able to establish a new connection using a non-ECN SYN packet
ECN SYN packet drops to close to zero even when there are only 16 drops to close to zero even when there are only 16 ongoing TCP flows
ongoing TCP flows transmitting at full speed. The issue is that transmitting at full speed. The issue is that DCTCP exhibits a much
DCTCP exhibits a much more aggressive response to packet marking more aggressive response to packet marking (which is why it is only
(which is why it is only applicable in controlled environments). applicable in controlled environments). This leads to a high marking
This leads to a high marking probability for ECN-capable packets, and probability for ECN-capable packets, and in turn a high drop
in turn a high drop probability for non-ECN packets. Therefore non- probability for non-ECN packets. Therefore non-ECN SYNs are dropped
ECN SYNs are dropped aggressively, rendering it nearly impossible to aggressively, rendering it nearly impossible to establish a new
establish a new connection in the presence of even mild traffic load. connection in the presence of even mild traffic load.
Finally, there are ongoing experimental efforts to promote the Finally, there are ongoing experimental efforts to promote the
adoption of a slightly modified variant of DCTCP (and similar adoption of a slightly modified variant of DCTCP (and similar
congestion controls) over the Internet to achieve low latency, low congestion controls) over the Internet to achieve low latency, low
loss and scalable throughput (L4S) for all communications loss and scalable throughput (L4S) for all communications
[I-D.ietf-tsvwg-l4s-arch]. In such an approach, L4S packets identify [I-D.ietf-tsvwg-l4s-arch]. In such an approach, L4S packets identify
themselves using an ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id]. With themselves using an ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id]. With
L4S and potentially other similar cases, preventing TCP control L4S and potentially other similar cases, preventing TCP control
packets from obtaining the benefits of ECN would not only expose them packets from obtaining the benefits of ECN would not only expose them
to the prevailing level of congestion loss, but it would also to the prevailing level of congestion loss, but it would also
skipping to change at page 10, line 45 skipping to change at page 10, line 45
is not even required when a SYN is lost [RFC5681]. is not even required when a SYN is lost [RFC5681].
If an initial window of 10 (IW10 [RFC6928]) is implemented, Section 5 If an initial window of 10 (IW10 [RFC6928]) is implemented, Section 5
gives additional recommendations. gives additional recommendations.
3.2.1.4. Fall-Back Following No Response to an ECT SYN 3.2.1.4. Fall-Back Following No Response to an ECT SYN
An ECT SYN might be lost due to an over-zealous path element (or An ECT SYN might be lost due to an over-zealous path element (or
server) blocking ECT packets that do not conform to RFC 3168. Some server) blocking ECT packets that do not conform to RFC 3168. Some
evidence of this was found in a 2014 study [ecn-pam], but in a more evidence of this was found in a 2014 study [ecn-pam], but in a more
recent 2017 study {ToDo: Add reference (under submission)} extensive recent study using 2017 data [Mandalari18] extensive measurements
measurements found no case where ECT on TCP control packets was found no case where ECT on TCP control packets was treated any
treated any differently from ECT on TCP data packets. Loss is differently from ECT on TCP data packets. Loss is commonplace for
commonplace for numerous other reasons, e.g. congestion loss at a numerous other reasons, e.g. congestion loss at a non-ECN queue on
non-ECN queue on the forward or reverse path, transmission errors, the forward or reverse path, transmission errors, etc.
etc. Alternatively, the cause of the loss might be the attempt to Alternatively, the cause of the loss might be the attempt to
negotiate AccECN, or possibly other unrelated options on the SYN. negotiate AccECN, or possibly other unrelated options on the SYN.
Therefore, if the timer expires after the TCP initiator has sent the Therefore, if the timer expires after the TCP initiator has sent the
first ECT SYN, it SHOULD make one more attempt to retransmit the SYN first ECT SYN, it SHOULD make one more attempt to retransmit the SYN
with ECT set (backing off the timer as usual). If the retransmission with ECT set (backing off the timer as usual). If the retransmission
timer expires again, it SHOULD retransmit the SYN with the not-ECT timer expires again, it SHOULD retransmit the SYN with the not-ECT
codepoint in the IP header, to expedite connection set-up. If other codepoint in the IP header, to expedite connection set-up. If other
experimental fields or options were on the SYN, it will also be experimental fields or options were on the SYN, it will also be
necessary to follow their specifications for fall-back too. It would necessary to follow their specifications for fall-back too. It would
make sense to coordinate all the strategies for fall-back in order to make sense to coordinate all the strategies for fall-back in order to
skipping to change at page 13, line 19 skipping to change at page 13, line 19
the problem has been resolved. the problem has been resolved.
3.2.3. Pure ACK 3.2.3. Pure ACK
For the experiments proposed here, the TCP implementation will set For the experiments proposed here, the TCP implementation will set
ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of
RFC 3168 to set not-ECT on a pure ACK. RFC 3168 to set not-ECT on a pure ACK.
A host that sets ECT on pure ACKs MUST reduce its congestion window A host that sets ECT on pure ACKs MUST reduce its congestion window
in response to any congestion feedback, in order to regulate any data in response to any congestion feedback, in order to regulate any data
segments it might be sending amongst the pure ACKs. {ToDo: Reconsider segments it might be sending amongst the pure ACKs. {ToDo: Write-up
this requirement in the light of WG comments.} It MAY also implement reconsideration of this requirement in the light of WG comments.} It
AckCC [RFC5690] to regulate the pure ACK rate, but this is not MAY also implement AckCC [RFC5690] to regulate the pure ACK rate, but
required. Note that, in comparison, TCP Congestion Control [RFC5681] this is not required. Note that, in comparison, TCP Congestion
does not require a TCP to detect or respond to loss of pure ACKs at Control [RFC5681] does not require a TCP to detect or respond to loss
all; it requires no reduction in congestion window or ACK rate. of pure ACKs at all; it requires no reduction in congestion window or
ACK rate.
The question of whether the receiver of pure ACKs is required to feed The question of whether the receiver of pure ACKs is required to feed
back any CE marks on them is a matter for the relevant feedback back any CE marks on them is a matter for the relevant feedback
specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is
outside the scope of the present specification. Currently AccECN outside the scope of the present specification. Currently AccECN
feedback is required to count CE marking of any control packet feedback is required to count CE marking of any control packet
including pure ACKs. Whereas RFC 3168 is silent on this point, so including pure ACKs. Whereas RFC 3168 is silent on this point, so
feedback of CE-markings might be implementation specific (see feedback of CE-markings might be implementation specific (see
Section 4.4.1). Section 4.4.1).
skipping to change at page 16, line 7 skipping to change at page 16, line 7
CE-marked, it will react as it would to any feedback of CE-marking on CE-marked, it will react as it would to any feedback of CE-marking on
a data packet. a data packet.
MEASUREMENTS NEEDED: Measurements are needed to learn how the MEASUREMENTS NEEDED: Measurements are needed to learn how the
deployed base of network elements and servers react to deployed base of network elements and servers react to
retransmissions marked with the ECT(0)/ECT(1)/CE codepoints, i.e. retransmissions marked with the ECT(0)/ECT(1)/CE codepoints, i.e.
whether they are dropped, codepoint cleared or processed. whether they are dropped, codepoint cleared or processed.
3.2.8. General Fall-back for any Control Packet or Retransmission 3.2.8. General Fall-back for any Control Packet or Retransmission
Extensive measurements in fixed and mobile networks {ToDo: reference Extensive measurements in fixed and mobile networks [Mandalari18]
(under submission)} have found no evidence of blockages due to ECT have found no evidence of blockages due to ECT being set on any type
being set on any type of TCP control packet. of TCP control packet.
In case traversal problems arise in future, fall-back measures have In case traversal problems arise in future, fall-back measures have
been specified above, but only for the cases where ECT on the initial been specified above, but only for the cases where ECT on the initial
packet of a half-connection (SYN or SYN-ACK) is persistently failing packet of a half-connection (SYN or SYN-ACK) is persistently failing
to get through. to get through.
Fall-back measures for blockage of ECT on other TCP control packets Fall-back measures for blockage of ECT on other TCP control packets
MAY be implemented. However they are not specified here given the MAY be implemented. However they are not specified here given the
lack of any evidence they will be needed. Section 4.9 justifies this lack of any evidence they will be needed. Section 4.9 justifies this
advice in more detail. advice in more detail.
skipping to change at page 20, line 19 skipping to change at page 20, line 19
the IP header and the appropriate ECN flags in the TCP header. Of the IP header and the appropriate ECN flags in the TCP header. Of
these, about 41% failed to establish a connection due to the ECN these, about 41% failed to establish a connection due to the ECN
flags in the TCP header even with a Not-ECT ECN field in the IP flags in the TCP header even with a Not-ECT ECN field in the IP
header (i.e. despite full compliance with RFC 3168). Therefore header (i.e. despite full compliance with RFC 3168). Therefore
adding the ECN capability to SYNs was increasing connection adding the ECN capability to SYNs was increasing connection
establishment failures by about 0.4%. establishment failures by about 0.4%.
In a study using 2017 data from a wider range of fixed and mobile In a study using 2017 data from a wider range of fixed and mobile
vantage points to the top 500k Alexa servers, no case was found where vantage points to the top 500k Alexa servers, no case was found where
adding the ECN capability to a SYN increased the likelihood of adding the ECN capability to a SYN increased the likelihood of
connection establishment failure {ToDo: reference (under connection establishment failure [Mandalari18].
submission)}.
MEASUREMENTS NEEDED: More investigation is needed to understand MEASUREMENTS NEEDED: More investigation is needed to understand
the different outcomes of the 2014 and 2017 studies. the different outcomes of the 2014 and 2017 studies.
RFC 3168 says "a host MUST NOT set ECT on SYN [...] packets", but it RFC 3168 says "a host MUST NOT set ECT on SYN [...] packets", but it
does not say what the responder should do if an ECN-capable SYN does not say what the responder should do if an ECN-capable SYN
arrives. So, in the 2014 study, perhaps some responder arrives. So, in the 2014 study, perhaps some responder
implementations were checking that the SYN complied with RFC 3168, implementations were checking that the SYN complied with RFC 3168,
then silently ignoring non-compliant SYNs (or perhaps returning a then silently ignoring non-compliant SYNs (or perhaps returning a
RST). Also some middleboxes (e.g. firewalls) might have been RST). Also some middleboxes (e.g. firewalls) might have been
skipping to change at page 30, line 34 skipping to change at page 30, line 34
than once to congestion. However, we argue that it is legitimate to than once to congestion. However, we argue that it is legitimate to
respond again to congestion if it still persists in subsequent round respond again to congestion if it still persists in subsequent round
trip(s). trip(s).
Therefore, in all three cases, it is not incorrect to set ECT on Therefore, in all three cases, it is not incorrect to set ECT on
retransmissions. retransmissions.
4.9. General Fall-back for any Control Packet 4.9. General Fall-back for any Control Packet
Extensive experiments have found no evidence of any traversal Extensive experiments have found no evidence of any traversal
problems with ECT on any TCP control packet {ToDo: reference (under problems with ECT on any TCP control packet [Mandalari18].
submission)}. Nonetheless, Sections 3.2.1.4 and 3.2.2.3 specify fall- Nonetheless, Sections 3.2.1.4 and 3.2.2.3 specify fall-back measures
back measures if ECT on the first packet of each half-connection (SYN if ECT on the first packet of each half-connection (SYN or SYN-ACK)
or SYN-ACK) appears to be blocking progress. Here, the question of appears to be blocking progress. Here, the question of fall-back
fall-back measures for ECT on other control packets is explored. It measures for ECT on other control packets is explored. It supports
supports the advice given in Section 3.2.8; until there's evidence the advice given in Section 3.2.8; until there's evidence that
that something's broken, don't fix it. something's broken, don't fix it.
If an implementation has had to disable ECT to ensure the first If an implementation has had to disable ECT to ensure the first
packet of a flow (SYN or SYN-ACK) gets through, the question arises packet of a flow (SYN or SYN-ACK) gets through, the question arises
whether it ought to disable ECT on all subsequent control packets whether it ought to disable ECT on all subsequent control packets
within the same TCP connection. Without evidence of any such within the same TCP connection. Without evidence of any such
problems, this seems unnecessarily cautious. Particularly given it problems, this seems unnecessarily cautious. Particularly given it
would be hard to detect loss of most other types of TCP control would be hard to detect loss of most other types of TCP control
packets that are not ACK'd. And particularly given that packets that are not ACK'd. And particularly given that
unnecessarily removing ECT from other control packets could lead to unnecessarily removing ECT from other control packets could lead to
performance problems, e.g. by directing them into an inferior queue performance problems, e.g. by directing them into an inferior queue
skipping to change at page 33, line 48 skipping to change at page 33, line 48
8. Acknowledgments 8. Acknowledgments
Thanks to Mirja Kuehlewind, David Black, Padma Bhooma and Gorry Thanks to Mirja Kuehlewind, David Black, Padma Bhooma and Gorry
Fairhurst for their useful reviews. Fairhurst for their useful reviews.
The work of Marcelo Bagnulo has been performed in the framework of The work of Marcelo Bagnulo has been performed in the framework of
the H2020-ICT-2014-2 project 5G NORMA. His contribution reflects the the H2020-ICT-2014-2 project 5G NORMA. His contribution reflects the
consortium's view, but the consortium is not liable for any use that consortium's view, but the consortium is not liable for any use that
may be made of any of the information contained therein. may be made of any of the information contained therein.
Bob Briscoe's contribution was partly funded by the Research Council
of Norway through the TimeIn project. The views expressed here are
solely those of the authors.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-03 (work in progress), May 2017. ecn-03 (work in progress), May 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-06 Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
(work in progress), September 2017. experimentation-07 (work in progress), October 2017.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 34, line 45 skipping to change at page 34, line 48
Wide Deployment of Explicit Congestion Notification", Wide Deployment of Explicit Congestion Notification",
Int'l Conf. on Passive and Active Network Measurement Int'l Conf. on Passive and Active Network Measurement
(PAM'15) pp193-205, 2015. (PAM'15) pp193-205, 2015.
[ECN-PLUS] [ECN-PLUS]
Kuzmanovic, A., "The Power of Explicit Congestion Kuzmanovic, A., "The Power of Explicit Congestion
Notification", ACM SIGCOMM 35(4):61--72, 2005. Notification", ACM SIGCOMM 35(4):61--72, 2005.
[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-06 (work and Secure Transport", draft-ietf-quic-transport-07 (work
in progress), September 2017. in progress), October 2017.
[I-D.ietf-tcpm-dctcp]
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
in progress), August 2017.
[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", draft-ietf-tsvwg-ecn-l4s-id-00 Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00
(work in progress), May 2017. (work in progress), May 2017.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency,
Low Loss, Scalable Throughput (L4S) Internet Service: Low Loss, Scalable Throughput (L4S) Internet Service:
skipping to change at page 35, line 38 skipping to change at page 35, line 32
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.
[judd-nsdi] [judd-nsdi]
Judd, G., "Attaining the promise and avoiding the pitfalls Judd, G., "Attaining the promise and avoiding the pitfalls
of TCP in the Datacenter", USENIX Symposium on Networked of TCP in the Datacenter", USENIX Symposium on Networked
Systems Design and Implementation (NSDI'15) pp.145-157, Systems Design and Implementation (NSDI'15) pp.145-157,
May 2015. May 2015.
[Mandalari18]
Mandalari, A., Lutu, A., Briscoe, B., Bagnulo, M., and Oe.
Alay, "Measuring ECN++: Good News for ++, Bad News for ECN
over Mobile", IEEE Communications Magazine , March 2018.
(to appear)
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
skipping to change at page 37, line 5 skipping to change at page 37, line 5
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661, TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015, DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/info/rfc7661>. <https://www.rfc-editor.org/info/rfc7661>.
[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>.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
 End of changes. 16 change blocks. 
49 lines changed or deleted 60 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/