< draft-ietf-tsvwg-ecn-experimentation-04.txt		draft-ietf-tsvwg-ecn-experimentation-05.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 August 4, 2017		Updates: 3168, 4341, 4342, 5622, 6679 August 30, 2017
	(if approved)		(if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 5, 2018		Expires: March 3, 2018
	Explicit Congestion Notification (ECN) Experimentation		Explicit Congestion Notification (ECN) Experimentation
	draft-ietf-tsvwg-ecn-experimentation-04		draft-ietf-tsvwg-ecn-experimentation-05
	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 February 5, 2018.		This Internet-Draft will expire on March 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(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 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	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.ietf-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 very shallow
	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.
	TCP Control Packets and Retransmissions: RFC 3168 limits the use of		TCP Control Packets and Retransmissions: RFC 3168 limits the use of
	ECN with TCP to data packets, excluding retransmissions. With the		ECN with TCP to data packets, excluding retransmissions. With the
	successful deployment of ECN in large portions of the Internet,		successful deployment of ECN in large portions of the Internet,
	there is interest in extending the benefits of ECN to TCP control		there is interest in extending the benefits of ECN to TCP control
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT)		As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT)
	codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1),		codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1),
	with the second codepoint used to support ECN nonce functionality to		with the second codepoint used to support ECN nonce functionality to
	discourage receivers from exploiting ECN to improve their throughput		discourage receivers from exploiting ECN to improve their throughput
	at the expense of other network users, as specified in experimental		at the expense of other network users, as specified in experimental
	RFC 3540 [RFC3540]. This section explains why RFC 3540 is being		RFC 3540 [RFC3540]. This section explains why RFC 3540 is being
	reclassified as Historic and makes associated updates to RFC 3168.		reclassified as Historic and makes associated updates to RFC 3168.
	While the ECN Nonce works as specified, and has been deployed in		While the ECN Nonce works as specified, and has been deployed in
	limited environments, widespread usage in the Internet has not		limited environments, widespread usage in the Internet has not
	materialized. A study of the ECN behaviour of the Alexa top 1M web		materialized. A study of the ECN behaviour of the top one million
	servers using 2014 data [Trammell15] found that after ECN was		web servers using 2014 data [Trammell15] found that after ECN was
	negotiated, none of the 581,711 IPv4 servers tested were using both		negotiated, none of the 581,711 IPv4 servers tested were using both
	ECT codepoints, which would have been a possible sign of ECN Nonce		ECT codepoints, which would have been a possible sign of ECN Nonce
	usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and		usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and
	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.
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	documented in an Experimental RFC. The specific change to RFC 3168		documented in an Experimental RFC. The specific change to RFC 3168
	is to insert the words "Unless otherwise specified by an Experimental		is to insert the words "Unless otherwise specified by an Experimental
	RFC" at the beginning of the second sentence quoted above.		RFC" at the beginning of the second sentence quoted above.
	4.2. Congestion Marking Differences		4.2. Congestion Marking Differences
	Taken to its limit, an AQM algorithm that uses ECN congestion		Taken to its limit, an AQM algorithm that uses ECN congestion
	indications can be configured to maintain very shallow queues,		indications can be configured to maintain very shallow queues,
	thereby reducing network latency by comparison to maintaining a		thereby reducing network latency by comparison to maintaining a
	larger queue. Significantly more aggressive sender responses to ECN		larger queue. Significantly more aggressive sender responses to ECN
	are required to make effective use of such shallow queues; Datacenter		are needed to make effective use of such very shallow queues;
	TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In this case,		Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. In
	separate network node treatments are essential, both to prevent the		this case, separate network node treatments are essential, both to
	aggressive low latency traffic starving conventional traffic (if		prevent the aggressive low latency traffic starving conventional
	present) and to prevent any conventional traffic disruption to any		traffic (if present) and to prevent any conventional traffic
	lower latency service that uses the shallow queues. Use of different		disruption to any lower latency service that uses the very shallow
	ECN codepoints is a promising means of identifying these two classes		queues. Use of different ECN codepoints is a promising means of
	of traffic to network nodes, and hence this area of experimentation		identifying these two classes of traffic to network nodes, and hence
	is based on the use of the ECT(1) codepoint to request ECN congestion		this area of experimentation is based on the use of the ECT(1)
	marking behavior in the network that differs from ECT(0)		codepoint to request ECN congestion marking behavior in the network
	counterbalanced by use of a different IETF-approved congestion		that differs from ECT(0) counterbalanced by use of a different IETF-
	response to CE marks at the sender, e.g., as proposed in		approved congestion response to CE marks at the sender, e.g., as
	[I-D.ietf-tsvwg-ecn-l4s-id].		proposed in [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.
	When an AQM is configured to use ECN congestion indications to		When an AQM is configured to use ECN congestion indications to
	maintain a nearly empty queue, congestion indications are marked on		maintain a very shallow queue, congestion indications are marked on
	packets that would not have been dropped if ECN was not in use.		packets that would not have been dropped if ECN was not in use.
	Section 5 of RFC 3168 specifies that:		Section 5 of RFC 3168 specifies that:
	For a router, the CE codepoint of an ECN-Capable packet SHOULD		For a router, the CE codepoint of an ECN-Capable packet SHOULD
	only be set if the router would otherwise have dropped the packet		only be set if the router would otherwise have dropped the packet
	as an indication of congestion to the end nodes. When the		as an indication of congestion to the end nodes. When the
	router's buffer is not yet full and the router is prepared to drop		router's buffer is not yet full and the router is prepared to drop
	a packet to inform end nodes of incipient congestion, the router		a packet to inform end nodes of incipient congestion, the router
	should first check to see if the ECT codepoint is set in that		should first check to see if the ECT codepoint is set in that
	packet's IP header. If so, then instead of dropping the packet,		packet's IP header. If so, then instead of dropping the packet,
	the router MAY instead set the CE codepoint in the IP header.		the router MAY instead set the CE codepoint in the IP header.
	This memo updates RFC 3168 to allow congestion indications that are		This memo updates RFC 3168 to allow congestion indications that are
	not equivalent to drops, provided that the changes from RFC 3168 are		not equivalent to drops, provided that the changes from RFC 3168 are
	documented in an Experimental RFC. The specific change is to change		documented in an Experimental RFC. The specific change is to change
	"For a router," to "Unless otherwise specified by an Experimental		"For a router," to "Unless otherwise specified by an Experimental
	RFC" at the beginning of the first sentence of the above paragraph.		RFC" at the beginning of the first sentence of the above paragraph.
	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		very shallow 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.ietf-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
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	To reflect the reclassification of RFC 3540 as Historic, IANA is		To reflect the reclassification of RFC 3540 as Historic, IANA is
	requested to update the Transmission Control Protocol (TCP) Header		requested to update the Transmission Control Protocol (TCP) Header
	Flags registry (https://www.iana.org/assignments/tcp-header-flags/		Flags registry (https://www.iana.org/assignments/tcp-header-flags/
	tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration		tcp-header-flags.xhtml#tcp-header-flags-1) to remove the registration
	of bit 7 as the NS (Nonce Sum) bit and add an annotation to the		of bit 7 as the NS (Nonce Sum) bit and add an annotation to the
	registry to state that bit 7 was used by Historic RFC 3540 as the NS		registry to state that bit 7 was used by Historic RFC 3540 as the NS
	(Nonce Sum) bit.		(Nonce Sum) bit.
	9. Security Considerations		9. Security Considerations
	As a process memo that makes no changes to existing protocols, there		As a process memo that only removes limitations on proposed
	are no protocol security considerations.		experiments, there are no protocol security considerations. Security
			considerations for the proposed experiments are discussed in the
			Internet-Drafts that propose them.
	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
	the Internet-Drafts that propose them.
	See Appendix B.1 of [I-D.ietf-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, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, DOI 10.17487/RFC2914, September 2000,		RFC 2914, DOI 10.17487/RFC2914, September 2000,
	<http://www.rfc-editor.org/info/rfc2914>.		<https://www.rfc-editor.org/info/rfc2914>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<http://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Notification (ECN) Signaling with Nonces",
	RFC 3540, DOI 10.17487/RFC3540, June 2003,		RFC 3540, DOI 10.17487/RFC3540, June 2003,
	<http://www.rfc-editor.org/info/rfc3540>.		<https://www.rfc-editor.org/info/rfc3540>.
	[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion		[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
	Control Protocol (DCCP) Congestion Control ID 2: TCP-like		Control Protocol (DCCP) Congestion Control ID 2: TCP-like
	Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March		Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March
	2006, <http://www.rfc-editor.org/info/rfc4341>.		2006, <https://www.rfc-editor.org/info/rfc4341>.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram Congestion Control Protocol (DCCP) Congestion
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
	DOI 10.17487/RFC4342, March 2006,		DOI 10.17487/RFC4342, March 2006, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc4342>.		editor.org/info/rfc4342>.
	[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion		[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
	Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate		Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate
	Control for Small Packets (TFRC-SP)", RFC 5622,		Control for Small Packets (TFRC-SP)", RFC 5622,
	DOI 10.17487/RFC5622, August 2009,		DOI 10.17487/RFC5622, August 2009, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5622>.		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, <https://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, "ECN++: Adding Explicit		Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
	Congestion Notification (ECN) to TCP Control Packets",		Congestion Notification (ECN) to TCP Control Packets",
	draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),		draft-bagnulo-tcpm-generalized-ecn-04 (work in progress),
	May 2017.		May 2017.
	[I-D.ietf-tcpm-alternativebackoff-ecn]		[I-D.ietf-tcpm-alternativebackoff-ecn]
	Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,		Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
	"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-		"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
	alternativebackoff-ecn-01 (work in progress), May 2017.		alternativebackoff-ecn-01 (work in progress), May 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-09 (work		Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
	in progress), July 2017.		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.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,
	RFC 4774, DOI 10.17487/RFC4774, November 2006,		RFC 4774, DOI 10.17487/RFC4774, November 2006,
	<http://www.rfc-editor.org/info/rfc4774>.		<https://www.rfc-editor.org/info/rfc4774>.
	[Trammell15]		[Trammell15]
	Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,		Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I.,
	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
	skipping to change at page 17, line 22 ¶		skipping to change at page 17, line 22 ¶
	o Other minor edits.		o Other minor edits.
	Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04:		Changes from draft-ietf-tsvwg-ecn-experimentation-03 to -04:
	o Change name of "Generalized ECN" experimentation area to "TCP		o Change name of "Generalized ECN" experimentation area to "TCP
	Control Packets and Retransmissions."		Control Packets and Retransmissions."
	o Add IANA Considerations text to request removal of the		o Add IANA Considerations text to request removal of the
	registration of the NS bit in the TCP header.		registration of the NS bit in the TCP header.
			Changes from draft-ietf-tsvwg-ecn-experimentation-04 to -05:
			o Minor editorial changes from Area Director review
	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. 22 change blocks.
	41 lines changed or deleted		44 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/