< draft-ietf-tsvwg-ecn-l4s-id-00.txt		draft-ietf-tsvwg-ecn-l4s-id-01.txt >
	Transport Services (tsv) K. De Schepper		Transport Services (tsv) K. De Schepper
	Internet-Draft Nokia Bell Labs		Internet-Draft Nokia Bell Labs
	Intended status: Experimental B. Briscoe, Ed.		Intended status: Experimental B. Briscoe, Ed.
	Expires: November 6, 2017 Simula Research Lab		Expires: May 3, 2018 CableLabs
	May 5, 2017		October 30, 2017
	Identifying Modified Explicit Congestion Notification (ECN) Semantics		Identifying Modified Explicit Congestion Notification (ECN) Semantics
	for Ultra-Low Queuing Delay		for Ultra-Low Queuing Delay
	draft-ietf-tsvwg-ecn-l4s-id-00		draft-ietf-tsvwg-ecn-l4s-id-01
	Abstract		Abstract
	This specification defines the identifier to be used on IP packets		This specification defines the identifier to be used on IP packets
	for a new network service called low latency, low loss and scalable		for a new network service called low latency, low loss and scalable
	throughput (L4S). It is similar to the original (or 'Classic')		throughput (L4S). It is similar to the original (or 'Classic')
	Explicit Congestion Notification (ECN). 'Classic' ECN marking was		Explicit Congestion Notification (ECN). 'Classic' ECN marking was
	required to be equivalent to a drop, both when applied in the network		required to be equivalent to a drop, both when applied in the network
	and when responded to by a transport. Unlike 'Classic' ECN marking,		and when responded to by a transport. Unlike 'Classic' ECN marking,
	for packets carrying the L4S identifier, the network applies marking		for packets carrying the L4S identifier, the network applies marking
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	scalable transports.		scalable transports.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 6, 2017.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . 12		6.1. Normative References . . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . 13		6.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. The 'TCP Prague Requirements' . . . . . . . . . . . 17		Appendix A. The 'TCP Prague Requirements' . . . . . . . . . . . 17
	A.1. Requirements for Scalable Transport Protocols . . . . . . 18		A.1. Requirements for Scalable Transport Protocols . . . . . . 18
	A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 18		A.1.1. Use of L4S Packet Identifier . . . . . . . . . . . . 18
	A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 18		A.1.2. Accurate ECN Feedback . . . . . . . . . . . . . . . . 18
	A.1.3. Fall back to Reno/Cubic congestion control on packet		A.1.3. Fall back to Reno/Cubic congestion control on packet
	loss . . . . . . . . . . . . . . . . . . . . . . . . 19		loss . . . . . . . . . . . . . . . . . . . . . . . . 18
	A.1.4. Fall back to Reno/Cubic congestion control on classic		A.1.4. Fall back to Reno/Cubic congestion control on classic
	ECN bottlenecks . . . . . . . . . . . . . . . . . . . 19		ECN bottlenecks . . . . . . . . . . . . . . . . . . . 19
	A.1.5. Reduce RTT dependence . . . . . . . . . . . . . . . . 20		A.1.5. Reduce RTT dependence . . . . . . . . . . . . . . . . 20
	A.1.6. Scaling down the congestion window . . . . . . . . . 20		A.1.6. Scaling down the congestion window . . . . . . . . . 20
	A.2. Scalable Transport Protocol Optimizations . . . . . . . . 21		A.2. Scalable Transport Protocol Optimizations . . . . . . . . 21
	A.2.1. Setting ECT in TCP Control Packets and		A.2.1. Setting ECT in TCP Control Packets and
	Retransmissions . . . . . . . . . . . . . . . . . . . 21		Retransmissions . . . . . . . . . . . . . . . . . . . 21
	A.2.2. Faster than Additive Increase . . . . . . . . . . . . 21		A.2.2. Faster than Additive Increase . . . . . . . . . . . . 21
	A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 22		A.2.3. Faster Convergence at Flow Start . . . . . . . . . . 22
	Appendix B. Alternative Identifiers . . . . . . . . . . . . . . 22		Appendix B. Alternative Identifiers . . . . . . . . . . . . . . 22
	B.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 22		B.1. ECT(1) and CE codepoints . . . . . . . . . . . . . . . . 22
	B.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 24		B.2. ECN Plus a Diffserv Codepoint (DSCP) . . . . . . . . . . 24
	B.3. ECN capability alone . . . . . . . . . . . . . . . . . . 27		B.3. ECN capability alone . . . . . . . . . . . . . . . . . . 26
	B.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 28		B.4. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 28
	B.5. Source or destination addressing . . . . . . . . . . . . 28		B.5. Source or destination addressing . . . . . . . . . . . . 28
	B.6. Summary: Merits of Alternative Identifiers . . . . . . . 29		B.6. Summary: Merits of Alternative Identifiers . . . . . . . 28
	Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 29		Appendix C. Potential Competing Uses for the ECT(1) Codepoint . 29
	C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 30		C.1. Integrity of Congestion Feedback . . . . . . . . . . . . 29
	C.2. Notification of Less Severe Congestion than CE . . . . . 31		C.2. Notification of Less Severe Congestion than CE . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This specification defines the identifier to be used on IP packets		This specification defines the identifier to be used on IP packets
	for a new network service called low latency, low loss and scalable		for a new network service called low latency, low loss and scalable
	throughput (L4S). It is similar to the original (or 'Classic')		throughput (L4S). It is similar to the original (or 'Classic')
	Explicit Congestion Notification (ECN). 'Classic' ECN marking was		Explicit Congestion Notification (ECN). 'Classic' ECN marking was
	required to be equivalent to a drop, both when applied in the network		required to be equivalent to a drop, both when applied in the network
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	roughly the same as a 'Classic' flow under the same conditions.		roughly the same as a 'Classic' flow under the same conditions.
	Nonetheless, the much more frequent control signals and the finer		Nonetheless, the much more frequent control signals and the finer
	responses to them result in ultra-low queuing delay without		responses to them result in ultra-low queuing delay without
	compromising link utilization, even during high load.		compromising link utilization, even during high load.
	An example of an active queue management (AQM) marking algorithm that		An example of an active queue management (AQM) marking algorithm that
	enables the L4S service is the DualQ Coupled AQM defined in a		enables the L4S service is the DualQ Coupled AQM defined in a
	complementary specification [I-D.ietf-tsvwg-aqm-dualq-coupled]. An		complementary specification [I-D.ietf-tsvwg-aqm-dualq-coupled]. An
	example of a scalable transport that would enable the L4S service is		example of a scalable transport that would enable the L4S service is
	Data Centre TCP (DCTCP), which until now has been applicable solely		Data Centre TCP (DCTCP), which until now has been applicable solely
	to controlled environments like data centres [I-D.ietf-tcpm-dctcp],		to controlled environments like data centres [RFC8257], because it is
	because it is too aggressive to co-exist with existing TCP. However,		too aggressive to co-exist with existing TCP. However, AQMs like
	AQMs like DualQ Coupled enable scalable transports like DCTCP to co-		DualQ Coupled enable scalable transports like DCTCP to co-exist with
	exist with existing traffic, each getting roughly the same flow rate		existing traffic, each getting roughly the same flow rate when they
	when they compete under similar conditions. Note that DCTCP will		compete under similar conditions. Note that DCTCP will still not be
	still not be safe to deploy on the Internet until it satisfies the		safe to deploy on the Internet until it satisfies the requirements
	requirements listed in Section 2.3.		listed in Section 2.3.
	The new L4S identifier is the key piece that enables these two parts		The new L4S identifier is the key piece that enables these two parts
	to interwork and distinguishes them from 'Classic' traffic. It gives		to interwork and distinguishes them from 'Classic' traffic. It gives
	an incremental migration path so that existing 'Classic' TCP traffic		an incremental migration path so that existing 'Classic' TCP traffic
	will be no worse off, but it can be prevented from degrading the		will be no worse off, but it can be prevented from degrading the
	ultra-low delay and loss of the new scalable transports. The		ultra-low delay and loss of the new scalable transports. The
	performance improvement is so great that it is hoped it will motivate		performance improvement is so great that it is hoped it will motivate
	initial deployment of the separate parts of this system.		initial deployment of the separate parts of this system.
	1.1. Problem		1.1. Problem
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	tunnels and it is relatively expensive to implement.		tunnels and it is relatively expensive to implement.
	Latency is not our only concern: It was known when TCP was first		Latency is not our only concern: It was known when TCP was first
	developed that it would not scale to high bandwidth-delay products.		developed that it would not scale to high bandwidth-delay products.
	Given regular broadband bit-rates over WAN distances are		Given regular broadband bit-rates over WAN distances are
	already [RFC3649] beyond the scaling range of 'Classic' TCP Reno,		already [RFC3649] beyond the scaling range of 'Classic' TCP Reno,
	'less unscalable' Cubic [I-D.ietf-tcpm-cubic] and		'less unscalable' Cubic [I-D.ietf-tcpm-cubic] and
	Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been		Compound [I-D.sridharan-tcpm-ctcp] variants of TCP have been
	successfully deployed. However, these are now approaching their		successfully deployed. However, these are now approaching their
	scaling limits. Unfortunately, fully scalable TCPs such as DCTCP		scaling limits. Unfortunately, fully scalable TCPs such as DCTCP
	[I-D.ietf-tcpm-dctcp] cause 'Classic' TCP to starve itself, which is		[RFC8257] cause 'Classic' TCP to starve itself, which is why they
	why they have been confined to private data centres or research		have been confined to private data centres or research testbeds
	testbeds (until now).		(until now).
	It turns out that a TCP algorithm like DCTCP that solves TCP's		It turns out that a TCP algorithm like DCTCP that solves TCP's
	scalability problem also solves the latency problem, because the		scalability problem also solves the latency problem, because the
	finer sawteeth cause very little queuing delay. A supporting paper		finer sawteeth cause very little queuing delay. A supporting paper
	[DCttH15] gives the full explanation of why the design solves both		[DCttH15] gives the full explanation of why the design solves both
	the latency and the scaling problems, both in plain English and in		the latency and the scaling problems, both in plain English and in
	more precise mathematical form. The explanation is summarised		more precise mathematical form. The explanation is summarised
	without the maths in the L4S architecture document		without the maths in the L4S architecture document
	[I-D.ietf-tsvwg-l4s-arch].		[I-D.ietf-tsvwg-l4s-arch].
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	marked with the CE codepoint. This is termed a scalable congestion		marked with the CE codepoint. This is termed a scalable congestion
	control, because the number of control signals (ECN marks) per round		control, because the number of control signals (ECN marks) per round
	trip remains roughly constant for any flow rate. As with all		trip remains roughly constant for any flow rate. As with all
	transport behaviours, a detailed specification will need to be		transport behaviours, a detailed specification will need to be
	defined for each type of transport or application, including the		defined for each type of transport or application, including the
	timescale over which the proportionality is averaged, and control of		timescale over which the proportionality is averaged, and control of
	burstiness. The inverse proportionality requirement above is worded		burstiness. The inverse proportionality requirement above is worded
	as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility		as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
	when defining these specifications.		when defining these specifications.
	Data Center TCP (DCTCP [I-D.ietf-tcpm-dctcp]) is an example of a		Data Center TCP (DCTCP [RFC8257]) is an example of a scalable
	scalable congestion control.		congestion control.
	Each sender in a session can use a scalable congestion control		Each sender in a session can use a scalable congestion control
	independently of the congestion control used by the receiver(s) when		independently of the congestion control used by the receiver(s) when
	they send data. Therefore there might be ECT(1) packets in one		they send data. Therefore there might be ECT(1) packets in one
	direction and ECT(0) in the other.		direction and ECT(0) in the other.
	In order to coexist safely with other Internet traffic, a scalable		In order to coexist safely with other Internet traffic, a scalable
	congestion control MUST NOT identify its packets with the ECT(1)		congestion control MUST NOT identify its packets with the ECT(1)
	codepoint unless it complies with the following bulleted		codepoint unless it complies with the following bulleted
	requirements. The specification of a particular scalable congestion		requirements. The specification of a particular scalable congestion
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 24 ¶
	McGregor for the discussions that led to this specification. Ing-jyh		McGregor for the discussions that led to this specification. Ing-jyh
	(Inton) Tsang was a contributor to the early drafts of this document.		(Inton) Tsang was a contributor to the early drafts of this document.
	inAppendix A listing the TCP Prague Requirements is based on text		inAppendix A listing the TCP Prague Requirements is based on text
	authored by Marcelo Bagnulo Braun that was originally an appendix to		authored by Marcelo Bagnulo Braun that was originally an appendix to
	[I-D.ietf-tsvwg-l4s-arch]. That text was in turn based on the		[I-D.ietf-tsvwg-l4s-arch]. That text was in turn based on the
	collective output of the attendees listed in the minutes of a 'bar		collective output of the attendees listed in the minutes of a 'bar
	BoF' on DCTCP Evolution during IETF-94 [TCPPrague].		BoF' on DCTCP Evolution during IETF-94 [TCPPrague].
	The authors' contributions were part-funded by the European Community		The authors' contributions were part-funded by the European Community
	under its Seventh Framework Programme through the Reducing Internet		under its Seventh Framework Programme through the Reducing Internet
	Transport Latency (RITE) project (ICT-317700). The views expressed		Transport Latency (RITE) project (ICT-317700). Bob Briscoe was also
	here are solely those of the authors.		part-funded by the Research Council of Norway through the TimeIn
			project. The views expressed here are solely those of the authors.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	[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>.
	[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>.
	6.2. Informative References		6.2. Informative References
	[Alizadeh-stability]		[Alizadeh-stability]
	Alizadeh, M., Javanmard, A., and B. Prabhakar, "Analysis		Alizadeh, M., Javanmard, A., and B. Prabhakar, "Analysis
	of DCTCP: Stability, Convergence, and Fairness", ACM		of DCTCP: Stability, Convergence, and Fairness", ACM
	SIGMETRICS 2011 , June 2011.		SIGMETRICS 2011 , June 2011.
	[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An		[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An
	Algorithm for Increasing the Robustness of RED's Active		Algorithm for Increasing the Robustness of RED's Active
	Queue Management", ACIRI Technical Report , August 2001,		Queue Management", ACIRI Technical Report , August 2001,
	<http://www.icir.org/floyd/red.html>.		<http://www.icir.org/floyd/red.html>.
	[DCttH15] De Schepper, K., Bondarenko, O., Briscoe, B., and I.		[DCttH15] De Schepper, K., Bondarenko, O., Briscoe, B., and I.
	Tsang, "'Data Centre to the Home': Ultra-Low Latency for		Tsang, "'Data Centre to the Home': Ultra-Low Latency for
	All", 2015, <http://www.bobbriscoe.net/projects/latency/		All", 2015, <http://www.bobbriscoe.net/projects/latency/
	dctth_preprint.pdf>.		dctth_preprint.pdf>.
	(Under submission)		(Under submission)
	[I-D.bagnulo-tcpm-generalized-ecn]
	Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion
	Notification (ECN) to TCP control packets and TCP
	retransmissions", draft-bagnulo-tcpm-generalized-ecn-03
	(work in progress), April 2017.
	[I-D.bagnulo-tswg-generalized-ecn]
	Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion
	Notification (ECN) to TCP control packets", draft-bagnulo-
	tswg-generalized-ecn-00 (work in progress), July 2016.
	[I-D.ietf-aqm-fq-codel]		[I-D.ietf-aqm-fq-codel]
	Hoeiland-Joergensen, T., McKenney, P.,		Hoeiland-Joergensen, T., McKenney, P.,
	dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The		dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The
	FlowQueue-CoDel Packet Scheduler and Active Queue		FlowQueue-CoDel Packet Scheduler and Active Queue
	Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in		Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in
	progress), March 2016.		progress), March 2016.
	[I-D.ietf-aqm-pie]		[I-D.ietf-aqm-pie]
	Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A		Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A
	Lightweight Control Scheme To Address the Bufferbloat		Lightweight Control Scheme To Address the Bufferbloat
	Problem", draft-ietf-aqm-pie-10 (work in progress),		Problem", draft-ietf-aqm-pie-10 (work in progress),
	September 2016.		September 2016.
	[I-D.ietf-tcpm-accurate-ecn]		[I-D.ietf-tcpm-accurate-ecn]
	Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More		Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
	Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-		Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
	ecn-02 (work in progress), October 2016.		ecn-03 (work in progress), May 2017.
	[I-D.ietf-tcpm-cubic]		[I-D.ietf-tcpm-cubic]
	Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and		Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
	R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",		R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
	draft-ietf-tcpm-cubic-04 (work in progress), February		draft-ietf-tcpm-cubic-06 (work in progress), September
	2017.		2017.
	[I-D.ietf-tcpm-dctcp]		[I-D.ietf-tcpm-generalized-ecn]
	Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,		Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
	and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion		Congestion Notification (ECN) to TCP Control Packets",
	Control for Datacenters", draft-ietf-tcpm-dctcp-05 (work		draft-ietf-tcpm-generalized-ecn-02 (work in progress),
	in progress), March 2017.		October 2017.
	[I-D.ietf-tsvwg-aqm-dualq-coupled]		[I-D.ietf-tsvwg-aqm-dualq-coupled]
	Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,		Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,
	"DualQ Coupled AQM for Low Latency, Low Loss and Scalable		"DualQ Coupled AQM for Low Latency, Low Loss and Scalable
	Throughput", draft-ietf-tsvwg-aqm-dualq-coupled-00 (work		Throughput", draft-ietf-tsvwg-aqm-dualq-coupled-01 (work
	in progress), November 2016.		in progress), July 2017.
	[I-D.ietf-tsvwg-ecn-encap-guidelines]		[I-D.ietf-tsvwg-ecn-encap-guidelines]
	Briscoe, B., Kaippallimalil, J., and P. Thaler,		Briscoe, B., Kaippallimalil, J., and P. Thaler,
	"Guidelines for Adding Congestion Notification to		"Guidelines for Adding Congestion Notification to
	Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-		Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
	encap-guidelines-08 (work in progress), March 2017.		encap-guidelines-09 (work in progress), July 2017.
	[I-D.ietf-tsvwg-ecn-experimentation]		[I-D.ietf-tsvwg-ecn-experimentation]
	Black, D., "Explicit Congestion Notification (ECN)		Black, D., "Relaxing Restrictions on Explicit Congestion
	Experimentation", draft-ietf-tsvwg-ecn-experimentation-00		Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
	(work in progress), November 2016.		experimentation-07 (work in progress), October 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:
	Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in		Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in
	progress), November 2016.		progress), May 2017.
	[I-D.moncaster-tcpm-rcv-cheat]		[I-D.moncaster-tcpm-rcv-cheat]
	Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to		Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
	Allow Senders to Identify Receiver Non-Compliance", draft-		Allow Senders to Identify Receiver Non-Compliance", draft-
	moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.		moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
	[I-D.sridharan-tcpm-ctcp]		[I-D.sridharan-tcpm-ctcp]
	Sridharan, M., Tan, K., Bansal, D., and D. Thaler,		Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
	"Compound TCP: A New TCP Congestion Control for High-Speed		"Compound TCP: A New TCP Congestion Control for High-Speed
	and Long Distance Networks", draft-sridharan-tcpm-ctcp-02		and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
	skipping to change at page 15, line 17 ¶		skipping to change at page 14, line 51 ¶
	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.
	[Mathis09]		[Mathis09]
	Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,		Mathis, M., "Relentless Congestion Control", PFLDNeT'09 ,
	May 2009, <http://www.hpcc.jp/pfldnet2009/		May 2009, <http://www.hpcc.jp/pfldnet2009/
	Program_files/1569198525.pdf>.		Program_files/1569198525.pdf>.
	[QV] Briscoe, B. and P. Hurtig, "Up to Speed with Queue View",		[QV] Briscoe, B. and P. Hurtig, "Up to Speed with Queue View",
	RITE Technical Report D2.3; Appendix C.2, August 2015,		RITE Technical Report D2.3; Appendix C.2, August 2015,
	<https://riteproject.files.wordpress.com/2015/12/rite-		<https://riteproject.files.wordpress.com/2015/12/
	deliverable-2-3.pdf>.		rite-deliverable-2-3.pdf>.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,		[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
	S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,		S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
	Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,		Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
	S., Wroclawski, J., and L. Zhang, "Recommendations on		S., Wroclawski, J., and L. Zhang, "Recommendations on
	Queue Management and Congestion Avoidance in the		Queue Management and Congestion Avoidance in the
	Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,		Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
	<http://www.rfc-editor.org/info/rfc2309>.		<https://www.rfc-editor.org/info/rfc2309>.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	DOI 10.17487/RFC2474, December 1998,		DOI 10.17487/RFC2474, December 1998,
	<http://www.rfc-editor.org/info/rfc2474>.		<https://www.rfc-editor.org/info/rfc2474>.
	[RFC2983] Black, D., "Differentiated Services and Tunnels",		[RFC2983] Black, D., "Differentiated Services and Tunnels",
	RFC 2983, DOI 10.17487/RFC2983, October 2000,		RFC 2983, DOI 10.17487/RFC2983, October 2000,
	<http://www.rfc-editor.org/info/rfc2983>.		<https://www.rfc-editor.org/info/rfc2983>.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,		Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
	<http://www.rfc-editor.org/info/rfc3246>.		<https://www.rfc-editor.org/info/rfc3246>.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Notification (ECN) Signaling with Nonces",
	RFC 3540, DOI 10.17487/RFC3540, June 2003,		RFC 3540, DOI 10.17487/RFC3540, June 2003,
	<http://www.rfc-editor.org/info/rfc3540>.		<https://www.rfc-editor.org/info/rfc3540>.
	[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",		[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
	RFC 3649, DOI 10.17487/RFC3649, December 2003,		RFC 3649, DOI 10.17487/RFC3649, December 2003,
	<http://www.rfc-editor.org/info/rfc3649>.		<https://www.rfc-editor.org/info/rfc3649>.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	Congestion Control Protocol (DCCP)", RFC 4340,		Congestion Control Protocol (DCCP)", RFC 4340,
	DOI 10.17487/RFC4340, March 2006,		DOI 10.17487/RFC4340, March 2006,
	<http://www.rfc-editor.org/info/rfc4340>.		<https://www.rfc-editor.org/info/rfc4340>.
	[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,
	<http://www.rfc-editor.org/info/rfc4342>.		<https://www.rfc-editor.org/info/rfc4342>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<http://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.		[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.
	Ramakrishnan, "Adding Explicit Congestion Notification		Ramakrishnan, "Adding Explicit Congestion Notification
	(ECN) Capability to TCP's SYN/ACK Packets", RFC 5562,		(ECN) Capability to TCP's SYN/ACK Packets", RFC 5562,
	DOI 10.17487/RFC5562, June 2009,		DOI 10.17487/RFC5562, June 2009,
	<http://www.rfc-editor.org/info/rfc5562>.		<https://www.rfc-editor.org/info/rfc5562>.
	[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,
	<http://www.rfc-editor.org/info/rfc5622>.		<https://www.rfc-editor.org/info/rfc5622>.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<http://www.rfc-editor.org/info/rfc5681>.		<https://www.rfc-editor.org/info/rfc5681>.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <http://www.rfc-editor.org/info/rfc5925>.		June 2010, <https://www.rfc-editor.org/info/rfc5925>.
	[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.		[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
	Briscoe, "Open Research Issues in Internet Congestion		Briscoe, "Open Research Issues in Internet Congestion
	Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,		Control", RFC 6077, DOI 10.17487/RFC6077, February 2011,
	<http://www.rfc-editor.org/info/rfc6077>.		<https://www.rfc-editor.org/info/rfc6077>.
	[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three		[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
	Pre-Congestion Notification (PCN) States in the IP Header		Pre-Congestion Notification (PCN) States in the IP Header
	Using a Single Diffserv Codepoint (DSCP)", RFC 6660,		Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
	DOI 10.17487/RFC6660, July 2012,		DOI 10.17487/RFC6660, July 2012,
	<http://www.rfc-editor.org/info/rfc6660>.		<https://www.rfc-editor.org/info/rfc6660>.
	[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,		[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe,
	"Problem Statement and Requirements for Increased Accuracy		"Problem Statement and Requirements for Increased Accuracy
	in Explicit Congestion Notification (ECN) Feedback",		in Explicit Congestion Notification (ECN) Feedback",
	RFC 7560, DOI 10.17487/RFC7560, August 2015,		RFC 7560, DOI 10.17487/RFC7560, August 2015,
	<http://www.rfc-editor.org/info/rfc7560>.		<https://www.rfc-editor.org/info/rfc7560>.
	[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,
	<http://www.rfc-editor.org/info/rfc7567>.		<https://www.rfc-editor.org/info/rfc7567>.
	[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)		[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
	Concepts, Abstract Mechanism, and Requirements", RFC 7713,		Concepts, Abstract Mechanism, and Requirements", RFC 7713,
	DOI 10.17487/RFC7713, December 2015,		DOI 10.17487/RFC7713, December 2015,
	<http://www.rfc-editor.org/info/rfc7713>.		<https://www.rfc-editor.org/info/rfc7713>.
			[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
			and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
			Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
			October 2017, <https://www.rfc-editor.org/info/rfc8257>.
	[TCP-sub-mss-w]		[TCP-sub-mss-w]
	Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion		Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion
	Window for Small Round Trip Times", BT Technical Report		Window for Small Round Trip Times", BT Technical Report
	TR-TUB8-2015-002, May 2015,		TR-TUB8-2015-002, May 2015,
	<http://www.bobbriscoe.net/projects/latency/		<http://www.bobbriscoe.net/projects/latency/
	sub-mss-w.pdf>.		sub-mss-w.pdf>.
	[TCPPrague]		[TCPPrague]
	Briscoe, B., "Notes: DCTCP evolution 'bar BoF': Tue 21 Jul		Briscoe, B., "Notes: DCTCP evolution 'bar BoF': Tue 21 Jul
	skipping to change at page 18, line 13 ¶		skipping to change at page 17, line 50 ¶
	L4S identifier in packets it sends into the Internet. As well as		L4S identifier in packets it sends into the Internet. As well as
	necessary safety improvements (requirements) this appendix also		necessary safety improvements (requirements) this appendix also
	includes preferable performance improvements (optimizations).		includes preferable performance improvements (optimizations).
	These recommendations have become know as the TCP Prague		These recommendations have become know as the TCP Prague
	Requirements, because they were originally identified at an ad hoc		Requirements, because they were originally identified at an ad hoc
	meeting during IETF-94 in Prague [TCPPrague]. The wording has been		meeting during IETF-94 in Prague [TCPPrague]. The wording has been
	generalized to apply to all scalable congestion controls, not just		generalized to apply to all scalable congestion controls, not just
	TCP congestion control specifically.		TCP congestion control specifically.
	DCTCP [I-D.ietf-tcpm-dctcp] is currently the most widely used		DCTCP [RFC8257] is currently the most widely used scalable transport
	scalable transport protocol. In its current form, DCTCP is specified		protocol. In its current form, DCTCP is specified to be deployable
	to be deployable only in controlled environments. Deploying it in		only in controlled environments. Deploying it in the public Internet
	the public Internet would lead to a number of issues, both from the		would lead to a number of issues, both from the safety and the
	safety and the performance perspective. The modifications and		performance perspective. The modifications and additional mechanisms
	additional mechanisms listed in this section will be necessary for		listed in this section will be necessary for its deployment over the
	its deployment over the global Internet. Where an example is needed,		global Internet. Where an example is needed, DCTCP is used as a
	DCTCP is used as a base, but it is likely that most of these		base, but it is likely that most of these requirements equally apply
	requirements equally apply to other scalable transport protocols.		to other scalable transport protocols.
	A.1. Requirements for Scalable Transport Protocols		A.1. Requirements for Scalable Transport Protocols
	A.1.1. Use of L4S Packet Identifier		A.1.1. Use of L4S Packet Identifier
	Description: A scalable congestion control needs to distinguish the		Description: A scalable congestion control needs to distinguish the
	packets it sends from those sent by classic congestion controls.		packets it sends from those sent by classic congestion controls.
	Motivation: It needs to be possible for a network node to classify		Motivation: It needs to be possible for a network node to classify
	L4S packets without flow state into a queue that applies an L4S ECN		L4S packets without flow state into a queue that applies an L4S ECN
	skipping to change at page 21, line 35 ¶		skipping to change at page 21, line 24 ¶
	Description: To improve performance, scalable transport protocols		Description: To improve performance, scalable transport protocols
	ought to enable ECN at the IP layer in TCP control packets (SYN, SYN-		ought to enable ECN at the IP layer in TCP control packets (SYN, SYN-
	ACK, pure ACKs, etc.) and in retransmitted packets. The same is true		ACK, pure ACKs, etc.) and in retransmitted packets. The same is true
	for derivatives of TCP, e.g. SCTP.		for derivatives of TCP, e.g. SCTP.
	Motivation: RFC 3168 prohibits the use of ECN on these types of TCP		Motivation: RFC 3168 prohibits the use of ECN on these types of TCP
	packet, based on a number of arguments. This means these packets are		packet, based on a number of arguments. This means these packets are
	not protected from congestion loss by ECN, which considerably harms		not protected from congestion loss by ECN, which considerably harms
	performance, particularly for short flows.		performance, particularly for short flows.
	[I-D.bagnulo-tcpm-generalized-ecn] counters each argument in RFC 3168		[I-D.ietf-tcpm-generalized-ecn] counters each argument in RFC 3168 in
	in turn, showing it was over-cautious. Instead it proposes		turn, showing it was over-cautious. Instead it proposes experimental
	experimental use of ECN on all types of TCP packet.		use of ECN on all types of TCP packet.
	A.2.2. Faster than Additive Increase		A.2.2. Faster than Additive Increase
	Description: It would improve performance if scalable congestion		Description: It would improve performance if scalable congestion
	controls did not limit their congestion window increase to the		controls did not limit their congestion window increase to the
	traditional additive increase of 1 MSS per round trip [RFC5681]		traditional additive increase of 1 MSS per round trip [RFC5681]
	during congestion avoidance. The same is true for derivatives of TCP		during congestion avoidance. The same is true for derivatives of TCP
	congestion control.		congestion control.
	Motivation: As currently defined, DCTCP uses the traditional TCP Reno		Motivation: As currently defined, DCTCP uses the traditional TCP Reno
	skipping to change at page 24, line 22 ¶		skipping to change at page 24, line 9 ¶
	Non-L4S service for control packets: The classic ECN RFCs [RFC3168]		Non-L4S service for control packets: The classic ECN RFCs [RFC3168]
	and [RFC5562] require a sender to clear the ECN field to Not-ECT		and [RFC5562] require a sender to clear the ECN field to Not-ECT
	for retransmissions and certain control packets specifically pure		for retransmissions and certain control packets specifically pure
	ACKs, window probes and SYNs. When L4S packets are classified by		ACKs, window probes and SYNs. When L4S packets are classified by
	the ECN field alone, these control packets would not be classified		the ECN field alone, these control packets would not be classified
	into an L4S queue, and could therefore be delayed relative to the		into an L4S queue, and could therefore be delayed relative to the
	other packets in the flow. This would not cause re-ordering		other packets in the flow. This would not cause re-ordering
	(because retransmissions are already out of order, and the control		(because retransmissions are already out of order, and the control
	packets carry no data). However, it would make critical control		packets carry no data). However, it would make critical control
	packets more vulnerable to loss and delay. To address this		packets more vulnerable to loss and delay. To address this
	problem, [I-D.bagnulo-tswg-generalized-ecn] proposes an experiment		problem, [I-D.ietf-tcpm-generalized-ecn] proposes an experiment in
	in which all TCP control packets and retransmissions are ECN-		which all TCP control packets and retransmissions are ECN-capable.
	capable.
	Pros:		Pros:
	Should work e2e: The ECN field generally works end-to-end across the		Should work e2e: The ECN field generally works end-to-end across the
	Internet. Unlike the DSCP, the setting of the ECN field is at		Internet. Unlike the DSCP, the setting of the ECN field is at
	least forwarded unchanged by networks that do not support ECN, and		least forwarded unchanged by networks that do not support ECN, and
	networks rarely clear it to zero;		networks rarely clear it to zero;
	Should work in tunnels: Unlike Diffserv, ECN is defined to always		Should work in tunnels: Unlike Diffserv, ECN is defined to always
	work across tunnels. However, tunnels do not always implement ECN		work across tunnels. However, tunnels do not always implement ECN
	skipping to change at page 32, line 4 ¶		skipping to change at page 31, line 39 ¶
	less severe level of pre-congestion notification than CE [RFC6660].		less severe level of pre-congestion notification than CE [RFC6660].
	However, the ECN field only takes on the PCN semantics if packets		However, the ECN field only takes on the PCN semantics if packets
	carry a Diffserv codepoint defined to indicate PCN marking within a		carry a Diffserv codepoint defined to indicate PCN marking within a
	controlled environment. PCN is required to be applied solely to the		controlled environment. PCN is required to be applied solely to the
	outer header of a tunnel across the controlled region in order not to		outer header of a tunnel across the controlled region in order not to
	interfere with any end-to-end use of the ECN field. Therefore a PCN		interfere with any end-to-end use of the ECN field. Therefore a PCN
	region on the path would not interfere with any of the L4S service		region on the path would not interfere with any of the L4S service
	identifiers proposed in Appendix B.		identifiers proposed in Appendix B.
	Authors' Addresses		Authors' Addresses
	Koen De Schepper		Koen De Schepper
	Nokia Bell Labs		Nokia Bell Labs
	Antwerp		Antwerp
	Belgium		Belgium
	Email: koen.de_schepper@nokia.com		Email: koen.de_schepper@nokia.com
	URI: https://www.bell-labs.com/usr/koen.de_schepper		URI: https://www.bell-labs.com/usr/koen.de_schepper
	Bob Briscoe (editor)		Bob Briscoe (editor)
	Simula Research Lab		CableLabs
			UK
	Email: ietf@bobbriscoe.net		Email: ietf@bobbriscoe.net
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
End of changes. 51 change blocks.
	91 lines changed or deleted		86 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/