< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/