< draft-ietf-tsvwg-ecn-experimentation-02.txt		draft-ietf-tsvwg-ecn-experimentation-03.txt >
	Transport Area Working Group D. Black		Transport Area Working Group D. Black
	Internet-Draft Dell EMC		Internet-Draft Dell EMC
	Updates: 3168, 4341, 4342, 5622, 6679 April 28, 2017		Updates: 3168, 4341, 4342, 5622, 6679 June 21, 2017
	(if approved)		(if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: October 30, 2017		Expires: December 23, 2017
	Explicit Congestion Notification (ECN) Experimentation		Explicit Congestion Notification (ECN) Experimentation
	draft-ietf-tsvwg-ecn-experimentation-02		draft-ietf-tsvwg-ecn-experimentation-03
	Abstract		Abstract
	This memo updates RFC 3168, which specifies Explicit Congestion		This memo updates RFC 3168, which specifies Explicit Congestion
	Notification (ECN) as a replacement for packet drops as indicators of		Notification (ECN) as a replacement for packet drops as indicators of
	network congestion. It relaxes restrictions in RFC 3168 that would		network congestion. It relaxes restrictions in RFC 3168 that would
	otherwise hinder experimentation towards benefits beyond just removal		otherwise hinder experimentation towards benefits beyond just removal
	of loss. This memo summarizes the anticipated areas of		of loss. This memo summarizes the anticipated areas of
	experimentation and updates RFC 3168 to enable experimentation in		experimentation and updates RFC 3168 to enable experimentation in
	these areas. An Experimental RFC is required to take advantage of		these areas. An Experimental RFC is required to take advantage of
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 http://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 October 30, 2017.		This Internet-Draft will expire on December 23, 2017.
	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		(http://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 52 ¶		skipping to change at page 2, line 52 ¶
	4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 10		4.3. Generalized ECN . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Effective Congestion Control is Required . . . . . . . . 11		4.4. Effective Congestion Control is Required . . . . . . . . 11
	5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 11		5. ECN for RTP Updates to RFC 6679 . . . . . . . . . . . . . . . 11
	6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13		6. ECN for DCCP Updates to RFCs 4341, 4342 and 5622 . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This memo updates RFC 3168 [RFC3168] which specifies Explicit		This memo updates RFC 3168 [RFC3168] which specifies Explicit
	Congestion Notification (ECN) as a replacement for packet drops as		Congestion Notification (ECN) as a replacement for packet drops as
	indicators of network congestion. It relaxes restrictions in RFC		indicators of network congestion. It relaxes restrictions in RFC
	3168 that would otherwise hinder experimentation towards benefits		3168 that would otherwise hinder experimentation towards benefits
	beyond just removal of loss. This memo summarizes the proposed areas		beyond just removal of loss. This memo summarizes the proposed areas
	of experimentation and updates RFC 3168 to enable experimentation in		of experimentation and updates RFC 3168 to enable experimentation in
	these areas. An Experimental RFC MUST be published for any protocol		these areas. An Experimental RFC MUST be published for any protocol
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	Congestion Response Differences: As discussed further in		Congestion Response Differences: As discussed further in
	Section 4.1, an ECN congestion indication communicates a higher		Section 4.1, an ECN congestion indication communicates a higher
	likelihood that a shorter queue exists at the network bottleneck		likelihood that a shorter queue exists at the network bottleneck
	node by comparison to a packet drop that indicates congestion		node by comparison to a packet drop that indicates congestion
	[I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests		[I-D.ietf-tcpm-alternativebackoff-ecn]. This difference suggests
	that for congestion indicated by ECN, a different sender		that for congestion indicated by ECN, a different sender
	congestion response (e.g., reduce the response so that the sender		congestion response (e.g., reduce the response so that the sender
	backs off by a smaller amount) may be appropriate by comparison to		backs off by a smaller amount) may be appropriate by comparison to
	the sender response to congestion indicated by loss, e.g., as		the sender response to congestion indicated by loss, e.g., as
	proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and		proposed in [I-D.ietf-tcpm-alternativebackoff-ecn] and
	[I-D.briscoe-tsvwg-ecn-l4s-id] - the experiment in the latter		[I-D.ietf-tsvwg-ecn-l4s-id] - the experiment in the latter draft
	draft couples the backoff change to Congestion Marking Differences		couples the backoff change to Congestion Marking Differences
	changes (next bullet). This is at variance with RFC 3168's		changes (next bullet). This is at variance with RFC 3168's
	requirement that a sender's congestion control response to ECN		requirement that a sender's congestion control response to ECN
	congestion indications be the same as to drops. IETF approval,		congestion indications be the same as to drops. IETF approval,
	e.g., via an Experimental RFC, is required for any sender		e.g., via an Experimental RFC, is required for any sender
	congestion response used in this area of experimentation.		congestion response used in this area of experimentation.
	Congestion Marking Differences: As discussed further in Section 4.2,		Congestion Marking Differences: As discussed further in Section 4.2,
	when taken to its limit, congestion marking at network nodes can		when taken to its limit, congestion marking at network nodes can
	be configured to maintain very shallow queues in conjunction with		be configured to maintain very shallow queues in conjunction with
	a different IETF-approved congestion response to congestion		a different IETF-approved congestion response to congestion
	indications (CE marks) at the sender, e.g., as proposed in		indications (CE marks) at the sender, e.g., as proposed in
	[I-D.briscoe-tsvwg-ecn-l4s-id]. The traffic involved needs to be		[I-D.ietf-tsvwg-ecn-l4s-id]. The traffic involved needs to be
	identified by the senders to the network nodes in order to avoid		identified by the senders to the network nodes in order to avoid
	damage to other network traffic whose senders do not expect the		damage to other network traffic whose senders do not expect the
	more frequent congestion marking used to maintain nearly empty		more frequent congestion marking used to maintain nearly empty
	queues. Use of different ECN codepoints, specifically ECT(0) and		queues. Use of different ECN codepoints, specifically ECT(0) and
	ECT(1), is a promising means of traffic identification for this		ECT(1), is a promising means of traffic identification for this
	purpose, but that technique is at variance with RFC 3168's		purpose, but that technique is at variance with RFC 3168's
	requirement that ECT(0)-marked traffic and ECT(1)-marked traffic		requirement that ECT(0)-marked traffic and ECT(1)-marked traffic
	not receive different treatment in the network.		not receive different treatment in the network.
	Generalized ECN: RFC 3168 limits the use of ECN with TCP to data		Generalized ECN: RFC 3168 limits the use of ECN with TCP to data
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	ECT(1) on data packets. This might have been evidence of use of the		ECT(1) on data packets. This might have been evidence of use of the
	ECN Nonce by these 4 servers, but might equally have been due to re-		ECN Nonce by these 4 servers, but might equally have been due to re-
	marking of the ECN field by an erroneous middlebox or router.		marking of the ECN field by an erroneous middlebox or router.
	With the emergence of new experimental functionality that depends on		With the emergence of new experimental functionality that depends on
	use of the ECT(1) codepoint for other purposes, continuing to reserve		use of the ECT(1) codepoint for other purposes, continuing to reserve
	that codepoint for the ECN Nonce experiment is no longer justified.		that codepoint for the ECN Nonce experiment is no longer justified.
	In addition, other approaches to discouraging receivers from		In addition, other approaches to discouraging receivers from
	exploiting ECN have emerged, see Appendix B.1 of		exploiting ECN have emerged, see Appendix B.1 of
	[I-D.briscoe-tsvwg-ecn-l4s-id]. Therefore, in support of ECN		[I-D.ietf-tsvwg-ecn-l4s-id]. Therefore, in support of ECN
	experimentation with the ECT(1) codepoint, this memo:		experimentation with the ECT(1) codepoint, this memo:
	o Declares that the ECN Nonce experiment [RFC3540] has concluded,		o Declares that the ECN Nonce experiment [RFC3540] has concluded,
	and notes the absence of widespread deployment.		and notes the absence of widespread deployment.
	o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce		o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce
	and use of ECT(1) for that Nonce. The specific text updates are		and use of ECT(1) for that Nonce. The specific text updates are
	omitted for brevity.		omitted for brevity.
	4. Updates to RFC 3168		4. Updates to RFC 3168
	skipping to change at page 7, line 48 ¶		skipping to change at page 7, line 48 ¶
	separate network node treatments are essential, both to prevent the		separate network node treatments are essential, both to prevent the
	aggressive low latency traffic starving conventional traffic (if		aggressive low latency traffic starving conventional traffic (if
	present) and to prevent any conventional traffic disruption to any		present) and to prevent any conventional traffic disruption to any
	lower latency service that uses the shallow queues. Use of different		lower latency service that uses the shallow queues. Use of different
	ECN codepoints is a promising means of identifying these two classes		ECN codepoints is a promising means of identifying these two classes
	of traffic to network nodes, and hence this area of experimentation		of traffic to network nodes, and hence this area of experimentation
	is based on the use of the ECT(1) codepoint to request ECN congestion		is based on the use of the ECT(1) codepoint to request ECN congestion
	marking behavior in the network that differs from ECT(0)		marking behavior in the network that differs from ECT(0)
	counterbalanced by use of a different IETF-approved congestion		counterbalanced by use of a different IETF-approved congestion
	response to CE marks at the sender, e.g., as proposed in		response to CE marks at the sender, e.g., as proposed in
	[I-D.briscoe-tsvwg-ecn-l4s-id].		[I-D.ietf-tsvwg-ecn-l4s-id].
	Section 5 of RFC 3168 specifies that:		Section 5 of RFC 3168 specifies that:
	Routers treat the ECT(0) and ECT(1) codepoints as equivalent.		Routers treat the ECT(0) and ECT(1) codepoints as equivalent.
	This memo updates RFC 3168 to allow routers to treat the ECT(0) and		This memo updates RFC 3168 to allow routers to treat the ECT(0) and
	ECT(1) codepoints differently, provided that the changes from RFC		ECT(1) codepoints differently, provided that the changes from RFC
	3168 are documented in an Experimental RFC. The specific change to		3168 are documented in an Experimental RFC. The specific change to
	RFC 3168 is to insert the words "unless otherwise specified by an		RFC 3168 is to insert the words "unless otherwise specified by an
	Experimental RFC" at the end of the above sentence.		Experimental RFC" at the end of the above sentence.
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	A larger update to RFC 3168 is necessary to enable sender usage of		A larger update to RFC 3168 is necessary to enable sender usage of
	ECT(1) to request network congestion marking behavior that maintains		ECT(1) to request network congestion marking behavior that maintains
	nearly empty queues at network nodes. When using loss as a		nearly empty queues at network nodes. When using loss as a
	congestion signal, the number of signals provided should be reduced		congestion signal, the number of signals provided should be reduced
	to a minimum and hence only presence or absence of congestion is		to a minimum and hence only presence or absence of congestion is
	communicated. In contrast, ECN can provide a richer signal, e.g., to		communicated. In contrast, ECN can provide a richer signal, e.g., to
	indicate the current level of congestion, without the disadvantage of		indicate the current level of congestion, without the disadvantage of
	a larger number of packet losses. A proposed experiment in this		a larger number of packet losses. A proposed experiment in this
	area, Low Latency Low Loss Scalable throughput (L4S)		area, Low Latency Low Loss Scalable throughput (L4S)
	[I-D.briscoe-tsvwg-ecn-l4s-id] significantly increases the CE marking		[I-D.ietf-tsvwg-ecn-l4s-id] significantly increases the CE marking
	probability for ECT(1)-marked traffic in a fashion that would		probability for ECT(1)-marked traffic in a fashion that would
	interact badly with existing sender congestion response functionality		interact badly with existing sender congestion response functionality
	because that functionality assumes that the network marks ECT packets		because that functionality assumes that the network marks ECT packets
	as frequently as it would drop Not-ECT packets . If network traffic		as frequently as it would drop Not-ECT packets. If network traffic
	that uses such a conventional sender congestion response were to		that uses such a conventional sender congestion response were to
	encounter L4S's increased marking probability (and hence rate) at a		encounter L4S's increased marking probability (and hence rate) at a
	network bottleneck queue, the resulting traffic throughput is likely		network bottleneck queue, the resulting traffic throughput is likely
	to be much less than intended for the level of congestion at the		to be much less than intended for the level of congestion at the
	bottleneck queue.		bottleneck queue.
	To avoid that interaction, this memo reserves ECT(1) for		To avoid that interaction, this memo reserves ECT(1) for
	experimentation, initially for L4S. The specific update to Section 5		experimentation, initially for L4S. The specific update to Section 5
	of RFC 3168 is to remove the following text:		of RFC 3168 is to remove the following two paragraphs:
	Senders are free to use either the ECT(0) or the ECT(1) codepoint		Senders are free to use either the ECT(0) or the ECT(1) codepoint
	to indicate ECT, on a packet-by-packet basis.		to indicate ECT, on a packet-by-packet basis.
	The use of both the two codepoints for ECT, ECT(0) and ECT(1), is		The use of both the two codepoints for ECT, ECT(0) and ECT(1), is
	motivated primarily by the desire to allow mechanisms for the data		motivated primarily by the desire to allow mechanisms for the data
	sender to verify that network elements are not erasing the CE		sender to verify that network elements are not erasing the CE
	codepoint, and that data receivers are properly reporting to the		codepoint, and that data receivers are properly reporting to the
	sender the receipt of packets with the CE codepoint set, as		sender the receipt of packets with the CE codepoint set, as
	required by the transport protocol. Guidelines for the senders		required by the transport protocol. Guidelines for the senders
	and receivers to differentiate between the ECT(0) and ECT(1)		and receivers to differentiate between the ECT(0) and ECT(1)
	codepoints will be addressed in separate documents, for each		codepoints will be addressed in separate documents, for each
	transport protocol. In particular, this document does not address		transport protocol. In particular, this document does not address
	mechanisms for TCP end-nodes to differentiate between the ECT(0)		mechanisms for TCP end-nodes to differentiate between the ECT(0)
	and ECT(1) codepoints. Protocols and senders that only require a		and ECT(1) codepoints. Protocols and senders that only require a
	single ECT codepoint SHOULD use ECT(0).		single ECT codepoint SHOULD use ECT(0).
	and replace it with:		and replace it with this paragraph:
	Protocols and senders MUST use the ECT(0) codepoint to indicate		Protocols and senders MUST use the ECT(0) codepoint to indicate
	ECT unless otherwise specified by an Experimental RFC. Guidelines		ECT unless otherwise specified by an Experimental RFC. Guidelines
	for senders and receivers to differentiate between the ECT(0) and		for senders and receivers to differentiate between the ECT(0) and
	ECT(1) codepoints will be addressed in separate documents, for		ECT(1) codepoints will be addressed in separate documents, for
	each transport protocol. In particular, this document does not		each transport protocol. In particular, this document does not
	address mechanisms for TCP end-nodes to differentiate between the		address mechanisms for TCP end-nodes to differentiate between the
	ECT(0) and ECT(1) codepoints.		ECT(0) and ECT(1) codepoints.
	Congestion Marking Differences experiments SHOULD modify the network		Congestion Marking Differences experiments SHOULD modify the network
	skipping to change at page 11, line 52 ¶		skipping to change at page 11, line 52 ¶
	the "ect" parameter in the "a=ecn-capable-rtp:" attribute.		the "ect" parameter in the "a=ecn-capable-rtp:" attribute.
	The Congestion Marking Differences area of experimentation increases		The Congestion Marking Differences area of experimentation increases
	the potential consequences of using ECT(1) instead of ECT(0), and		the potential consequences of using ECT(1) instead of ECT(0), and
	hence the above guidance is updated by adding the following two		hence the above guidance is updated by adding the following two
	sentences:		sentences:
	Random ECT values MUST NOT be used, as that may expose RTP to		Random ECT values MUST NOT be used, as that may expose RTP to
	differences in network treatment of traffic marked with ECT(1) and		differences in network treatment of traffic marked with ECT(1) and
	ECT(0) and differences in associated endpoint congestion		ECT(0) and differences in associated endpoint congestion
	responses, e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id].		responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]. In
			addition, ECT(0) MUST be used unless otherwise specified in an
	In addition, ECT(0) MUST be used unless otherwise specified in an
	Experimental RFC.		Experimental RFC.
	Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE		Section 7.3.3 of RFC 6679 specifies RTP's response to receipt of CE
	marked packets as being identical to the response to dropped packets:		marked packets as being identical to the response to dropped packets:
	The reception of RTP packets with ECN-CE marks in the IP header is		The reception of RTP packets with ECN-CE marks in the IP header is
	a notification that congestion is being experienced. The default		a notification that congestion is being experienced. The default
	reaction on the reception of these ECN-CE-marked packets MUST be		reaction on the reception of these ECN-CE-marked packets MUST be
	to provide the congestion control algorithm with a congestion		to provide the congestion control algorithm with a congestion
	notification that triggers the algorithm to react as if packet		notification that triggers the algorithm to react as if packet
	skipping to change at page 13, line 19 ¶		skipping to change at page 13, line 19 ¶
	wording as follows:		wording as follows:
	each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with		each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable with
	either the ECT(0) or the ECT(1) codepoint set.		either the ECT(0) or the ECT(1) codepoint set.
	This memo updates these sentences in each of the three RFCs as		This memo updates these sentences in each of the three RFCs as
	follows:		follows:
	each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable.		each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable.
	Unless otherwise specified by an Experimental RFC, such DCCP		Unless otherwise specified by an Experimental RFC, such DCCP
	senders SHOULD set the ECT(0) codepoint.		senders MUST set the ECT(0) codepoint.
	In support of Congestion Marking Differences experimentation (as		In support of Congestion Marking Differences experimentation (as
	noted in Section 3), this memo also updates all three of these RFCs		noted in Section 3), this memo also updates all three of these RFCs
	to remove discussion of the ECN Nonce. The specific text updates are		to remove discussion of the ECN Nonce. The specific text updates are
	omitted for brevity.		omitted for brevity.
	7. Acknowledgements		7. Acknowledgements
	The content of this draft, including the specific portions of RFC		The content of this draft, including the specific portions of RFC
	3168 that are updated draws heavily from		3168 that are updated draws heavily from
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	However, effective congestion control is crucial to the continued		However, effective congestion control is crucial to the continued
	operation of the Internet, and hence this memo places the		operation of the Internet, and hence this memo places the
	responsibility for not breaking Internet congestion control on the		responsibility for not breaking Internet congestion control on the
	experiments and the experimenters who propose them, as specified in		experiments and the experimenters who propose them, as specified in
	Section 4.4.		Section 4.4.
	Security considerations for the proposed experiments are discussed in		Security considerations for the proposed experiments are discussed in
	the Internet-Drafts that propose them.		the Internet-Drafts that propose them.
	See Appendix B.1 of [I-D.briscoe-tsvwg-ecn-l4s-id] for discussion of		See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of
	alternatives to the ECN Nonce.		alternatives to the ECN Nonce.
	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>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 15, line 19 ¶		skipping to change at page 15, line 19 ¶
	<http://www.rfc-editor.org/info/rfc5622>.		<http://www.rfc-editor.org/info/rfc5622>.
	[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, <http://www.rfc-editor.org/info/rfc6679>.
	10.2. Informative References		10.2. Informative References
	[I-D.bagnulo-tcpm-generalized-ecn]		[I-D.bagnulo-tcpm-generalized-ecn]
	Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion		Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
	Notification (ECN) to TCP control packets and TCP		Congestion Notification (ECN) to TCP Control Packets",
	retransmissions", draft-bagnulo-tcpm-generalized-ecn-03		draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),
	(work in progress), April 2017.		May 2017.
	[I-D.briscoe-tsvwg-ecn-l4s-id]
	Schepper, K., Briscoe, B., and I. Tsang, "Identifying
	Modified Explicit Congestion Notification (ECN) Semantics
	for Ultra-Low Queuing Delay", draft-briscoe-tsvwg-ecn-l4s-
	id-02 (work in progress), October 2016.
	[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-00 (work in progress), February		alternativebackoff-ecn-01 (work in progress), May 2017.
	2017.
	[I-D.ietf-tcpm-dctcp]		[I-D.ietf-tcpm-dctcp]
	Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,		Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
	and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion		and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
	Control for Datacenters", draft-ietf-tcpm-dctcp-05 (work		Control for Datacenters", draft-ietf-tcpm-dctcp-07 (work
	in progress), March 2017.		in progress), June 2017.
			[I-D.ietf-tsvwg-ecn-l4s-id]
			Schepper, K. and B. Briscoe, "Identifying Modified
			Explicit Congestion Notification (ECN) Semantics for
			Ultra-Low Queuing Delay", draft-ietf-tsvwg-ecn-l4s-id-00
			(work in progress), May 2017.
	[I-D.khademi-tsvwg-ecn-response]		[I-D.khademi-tsvwg-ecn-response]
	Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,		Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
	"Updating the Explicit Congestion Notification (ECN)		"Updating the Explicit Congestion Notification (ECN)
	Specification to Allow IETF Experimentation", draft-		Specification to Allow IETF Experimentation", draft-
	khademi-tsvwg-ecn-response-01 (work in progress), July		khademi-tsvwg-ecn-response-01 (work in progress), July
	2016.		2016.
	[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,
	skipping to change at page 16, line 17 ¶		skipping to change at page 16, line 17 ¶
	Fairhurst, G., and R. Scheffenegger, "Enabling Internet-		Fairhurst, G., and R. Scheffenegger, "Enabling Internet-
	Wide Deployment of Explicit Congestion Notification".		Wide Deployment of Explicit Congestion Notification".
	In Proc Passive & Active Measurement (PAM'15) Conference		In Proc Passive & Active Measurement (PAM'15) Conference
	(2015)		(2015)
	Appendix A. Change History		Appendix A. Change History
	[To be removed before RFC publication.]		[To be removed before RFC publication.]
	Changes from draft-black-tsvwg-ecn-experimentation-00 to -01:
	o Section 4.2 - also update RFC 3168 to remove sentence indicating
	that senders are free to use both ECT codepoints. Add a SHOULD
	for ECT Differences experiments to use ECT(1).
	o Section 5 - only discourage use of random ECT values, but use NOT
	RECOMMENDED to do so. Consistent use of ECT(1) without using
	ECT(0) is ok. Mention possible changes in endpoint response.
	o Add more Acknowledgements and Change History
	o Additional editorial changes.
	Changes from draft-black-tsvwg-ecn-experimentation-01 to -02:
	o Add DCCP RFC updates and one missing RFC 3168 update (probe
	packets).
	o Discourage RTP usage of ECT(1).
	o Strengthen text on lack of ECN Nonce deployment.
	o Cross-reference the L4S draft appendix that discusses ECN Nonce
	alternatives.
	o Additional editorial changes.
	Changes from draft-black-tsvwg-ecn-experimentation-02 to -03:
	o Clarify that "SHOULD use ECT(0)" guidance from RFC 3168 is about
	IP headers.
	o Add a "SHOULD NOT" requirement that middleboxes not discard TCP
	control packets, etc. solely because they use ECN.
	o Switch to pre-5378 boilerplate, due to vintage of RFCs being
	updated.
	o Additional editorial changes.
	Changes from draft-black-tsvwg-ecn-experimentation-03 to -04:
	o Use "Congestion Response Differences" as name of experimentation
	area instead of "Alternative Backoff" to avoid confusion with
	specific experiment.
	o Change ECT(1) requirement to "MUST NOT use unless otherwise
	specified by an Experimental RFC" This resulted in extensive
	changes to Section 4.2.
	o Clean up and tighten language requiring all congestion responses
	to be IETF-approved
	o Additional editorial changes.
	Initial WG draft, draft-ietf-tsvwg-ecn-experimentation-00, has the
	same contents as draft-black-tsvwg-ecn-experimentation-04.
	Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01:		Changes from draft-ietf-tsvwg-ecn-experimentation-00 to -01:
	o Add mention of DCTCP as another protocol that could benefit from		o Add mention of DCTCP as another protocol that could benefit from
	ECN experimentation (near end of Section 2).		ECN experimentation (near end of Section 2).
	Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02:		Changes from draft-ietf-tsvwg-ecn-experimentation-01 to -02:
	o Generalize to describe rationale for areas of experimentation,		o Generalize to describe rationale for areas of experimentation,
	with less focus on individual experiments		with less focus on individual experiments
	skipping to change at page 18, line 12 ¶		skipping to change at page 16, line 47 ¶
	o Add explanation of exception to "SHOULD NOT drop" requirement in		o Add explanation of exception to "SHOULD NOT drop" requirement in
	4.3		4.3
	o Rework RFC 3540 status change text to provide rationale for a		o Rework RFC 3540 status change text to provide rationale for a
	separate status change document that makes RFC 3540 Historic.		separate status change document that makes RFC 3540 Historic.
	Don't obsolete RFC 3540.		Don't obsolete RFC 3540.
	o Significant editorial changes based on reviews by Mirja		o Significant editorial changes based on reviews by Mirja
	Kuehlewind, Michael Welzl and Bob Briscoe.		Kuehlewind, Michael Welzl and Bob Briscoe.
			Changes from draft-ietf-tsvwg-ecn-experimentation-02 to -03:
			o Remove change history prior to WG adoption.
			o Update L4S draft reference to reflect TSVWG adoption of draft.
			o Change the "SHOULD" for DCCP sender use of ECT(0) to a "MUST"
			(overlooked in earlier editing).
			o Other minor edits.
	Author's Address		Author's Address
	David Black		David Black
	Dell EMC		Dell EMC
	176 South Street		176 South Street
	Hopkinton, MA 01748		Hopkinton, MA 01748
	USA		USA
	Email: david.black@dell.com		Email: david.black@dell.com
End of changes. 21 change blocks.
	92 lines changed or deleted		42 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/