< draft-ietf-conex-abstract-mech-04bis.txt		draft-ietf-conex-abstract-mech-04bis-BB-editorial.txt >
	Congestion Exposure (ConEx) Working M. Mathis		Congestion Exposure (ConEx) M. Mathis
	Group Google, Inc		Working Group Google, Inc
	Internet-Draft B. Briscoe		Internet-Draft B. Briscoe
	Intended status: Informational BT		Intended status: Informational BT
	Expires: September 13, 2012 March 12, 2012		Expires: January 16, 2013 July 15, 2012
	Congestion Exposure (ConEx) Concepts and Abstract Mechanism		Congestion Exposure (ConEx) Concepts and Abstract Mechanism
	draft-ietf-conex-abstract-mech-04bis		draft-ietf-conex-abstract-mech-04bis
	Abstract		Abstract
	This document describes an abstract mechanism by which senders inform		This document describes an abstract mechanism by which senders inform
	the network about the congestion encountered by packets earlier in		the network about the congestion encountered by packets earlier in
	the same flow. Today, network elements at any layer may signal		the same flow. Today, network elements at any layer may signal
	congestion to the receiver by dropping packets or by ECN markings,		congestion to the receiver by dropping packets or by ECN markings,
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 September 13, 2012.		This Internet-Draft will expire on January 16, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 9		skipping to change at page 4, line 9
	In both cases the congestion signals follow the route indicated in		In both cases the congestion signals follow the route indicated in
	Figure 1. A congested network device sends a signal in the data		Figure 1. A congested network device sends a signal in the data
	stream on the forward path to the transport receiver, the receiver		stream on the forward path to the transport receiver, the receiver
	passes it back to the sender through transport level feedback, and		passes it back to the sender through transport level feedback, and
	the sender makes some congestion control adjustment.		the sender makes some congestion control adjustment.
	This document extends the capabilities of the Internet protocol suite		This document extends the capabilities of the Internet protocol suite
	with the addition of a new Congestion Exposure signal. To a first		with the addition of a new Congestion Exposure signal. To a first
	approximation this signal, also shown in Figure 1, relays the		approximation this signal, also shown in Figure 1, relays the
	congestion information from the transport sender back through the		congestion information from the transport sender back through the
	internetwork layer where it is visible to all internetwork layer		internetwork layer where it is visible to any interested internetwork
	devices along the forward path. This document frames the engineering		layer devices along the forward path. This document frames the
	problem of designing the ConEx signal. The requirements are		engineering problem of designing the ConEx signal. The requirements
	described in Section 3 and some example encoding are presented in		are described in Section 3 and some example encoding are presented in
	Section 4. Section 5 describes all of the protocol components.		Section 4. Section 5 describes all of the protocol components.
	This new signal is expressly designed to support a variety of new		This new signal is expressly designed to support a variety of new
	policy mechanisms that might be used to instrument, monitor or manage		policy mechanisms that might be used to instrument, monitor or manage
	traffic. The policy devices are not shown in Figure 1 but might be		traffic. The policy devices are not shown in Figure 1 but might be
	placed anywhere along the forward data path. They are described in		placed anywhere along the forward data path. They are described in
	Section 5.4		Section 5.4
	,---------. ,---------.		,---------. ,---------.
	|Transport| |Transport|		|Transport| |Transport|
	skipping to change at page 5, line 8		skipping to change at page 5, line 8
	respectively.		respectively.
	Figure 1		Figure 1
	Since the policy devices can affect how traffic is treated it is		Since the policy devices can affect how traffic is treated it is
	assumed that there is an intrinsic motivation for users, applications		assumed that there is an intrinsic motivation for users, applications
	or operating systems to understate the congestion that they are		or operating systems to understate the congestion that they are
	causing. It is important to be able to audit ConEx signals, and to		causing. It is important to be able to audit ConEx signals, and to
	be able apply sufficient sanction to discourage cheating of		be able apply sufficient sanction to discourage cheating of
	congestion policies. The general approach to auditing is to count		congestion policies. The general approach to auditing is to count
	and compare congestion signals and ConEx signals on the forward path.		signals on the forward path to check that there are never less ConEx
	Many ConEx design constraints come from the need to assure that the		signals than actual congestion signals. Many ConEx design
	audit function is sufficiently robust. The audit function is		constraints come from the need to assure that the audit function is
	described in Section 5.5, however significant portions of this		sufficiently robust. The audit function is described in Section 5.5,
	document (and prior research[Refb-dis]) is motivated by issues		however significant portions of this document (and prior
	relating to the audit function and making it robust.		research[Refb-dis]) is motivated by issues relating to the audit
			function and making it robust.
	The congestion and ConEx signals shown in Figure 1 represent a series		The congestion and ConEx signals shown in Figure 1 represent a series
	of discrete events: ECN marks or lost packets, carried by the forward		of discrete events: ECN marks or lost packets, carried by the forward
	data stream and fed back into the Internetwork layer. The policy and		data stream and fed back into the Internetwork layer. The policy and
	audit functions are most likely to act on the accumulated values of		audit functions are most likely to act on the accumulated values of
	these signals, for which we use the term "volume". For example		these signals, for which we use the term "volume". For example
	traffic volume is the total number of bytes delivered, optionally		traffic volume is the total number of bytes delivered, optionally
	over a specified time interval and over some aggregate of traffic		over a specified time interval and over some aggregate of traffic
	(e.g. all traffic from a site). While loss-volume is the total		(e.g. all traffic from a site). While loss-volume is the total
	amount of bytes discarded from some aggregate over an interval. The		amount of bytes discarded from some aggregate over an interval. The
	term congestion-volume is defined precisely in		term congestion-volume is defined precisely in
	[I-D.ietf-conex-concepts-uses]. Note that volume per unit time is a		[I-D.ietf-conex-concepts-uses]. Note that volume per unit time is
	rate.		(average) rate.
	One of the design goals of the ConEx protocol is that none of the		One of the design goals of the ConEx protocol is that none of the
	important policy mechanisms requires per flow state, and that policy		important policy mechanisms requires per flow state, and that policy
	mechanisms can be implemented for heavily aggregated traffic in the		mechanisms can be implemented for heavily aggregated traffic in the
	core of the Internet with complexity akin to accumulating marking		core of the Internet with complexity akin to accumulating marking
	volumes per logical link. Ideally it would also be possible to audit		volumes per logical link. Ideally it would also be possible to audit
	ConEx signals without per flow state, however this is not always		ConEx signals without per flow state, however this is not always
	possible. Since auditing can be done near the edges of the network		possible. Since auditing can be done near the edges of the network
	where traffic is less aggregated, per flow state is more easily		where traffic is less aggregated, per flow state is more easily
	tolerated. Also, the flow-state required for audit creates itself as		tolerated. Also, the flow-state required for audit creates itself as
	skipping to change at page 6, line 23		skipping to change at page 6, line 24
	To be successful the ConEx protocol must have the property that the		To be successful the ConEx protocol must have the property that the
	relevant stakeholders each have the incentive to unilaterally start		relevant stakeholders each have the incentive to unilaterally start
	on each stage of partial deployment, which in turn creates incentives		on each stage of partial deployment, which in turn creates incentives
	for further deployment. Furthermore, legacy systems that will never		for further deployment. Furthermore, legacy systems that will never
	be upgraded do not become a barrier to deploying ConEx. Issues		be upgraded do not become a barrier to deploying ConEx. Issues
	relating to partial deployment are described in Section 6.		relating to partial deployment are described in Section 6.
	Note that ConEx signals are not intended to be used for fine-grained		Note that ConEx signals are not intended to be used for fine-grained
	congestion control. They are anticipated to be most useful at longer		congestion control. They are anticipated to be most useful at longer
	time scales, for example the total congestion caused by a user might		time scales, for example the total congestion caused by a user might
	be serve as an input to higher level policy or accountability		serve as an input to higher level policy or accountability functions,
	functions, designed to create incentives for improving user behavior,		designed to create incentives for improving user behavior, such as
	such as choosing to send large quantities of data at off peak times,		choosing to send large quantities of data at off-peak times, at lower
	at lower data rates or with less aggressive protocols such as		data rates or with less aggressive protocols such as LEDBAT
	LEDBAT[I-D.ietf-ledbat-congestion] (see		[I-D.ietf-ledbat-congestion] (see [I-D.ietf-conex-concepts-uses]).
	[I-D.ietf-conex-concepts-uses]).
	Ultimately ConEx signals have the potential to provide a mechanism to		Ultimately ConEx signals have the potential to provide a mechanism to
	regulate global Internet congestion. From the earliest days of		regulate global Internet congestion. From the earliest days of
	congestion control research there has been a concern that there is no		congestion control research there has been a concern that there is no
	mechanism to prevent transport designers from incrementally making		mechanism to prevent transport designers from incrementally making
	protocols more aggressive without bound and spiraling to a "tragedy		protocols more aggressive without bound and spiraling to a "tragedy
	of the commons" Internet congestion collapse. The "TCP friendly"		of the commons" Internet congestion collapse. The "TCP friendly"
	paradigm was created in part to forestall this failure. However, it		paradigm was created in part to forestall this failure. However, it
	no longer commands any authority because it has little to say about		no longer commands any authority because it has little to say about
	the Internet of today, which has moved beyond the scaling range of		the Internet of today, which has moved beyond the scaling range of
	standard TCP. As a consequence, many transports and applications are		standard TCP [RFC5681]. As a consequence, many transports and
	opening arbitrarily large numbers of connections or using arbitrary		applications are opening arbitrarily large numbers of connections or
	levels of aggressiveness. ConEx represents a recognition that the		using arbitrary levels of aggressiveness. ConEx represents a
	IETF cannot regulate this space directly because it concerns the		recognition that the IETF cannot regulate this space directly because
	behaviour of users and applications, not individual transport		it concerns the behaviour of users and applications, not individual
	protocols. Instead the IETF can give network operators the protocol		transport protocols. Instead the IETF can give network operators the
	tools to arbitrate the space themselves, with better bulk traffic		protocol tools to arbitrate the space themselves, with better bulk
	management. This in turn should create incentives for users, and		traffic management. This in turn should create incentives for users,
	designers of application and of transport protocols to be more		and designers of application and of transport protocols to be more
	mindful about contributing to congesting.		mindful about contributing to congesting.
	2.1. Terminology		2.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	ConEx signals in IP packet headers from the sender to the network:		ConEx signals in IP packet headers from the sender to the network:
	Not-ConEx: The transport is not ConEx-capable.		Not-ConEx: The transport (or at least this packet) is not ConEx-
			capable.
	ConEx-Capable: The transport is ConEx-Capable. This is the opposite		ConEx-Capable: The transport is ConEx-Capable. This is the opposite
	of Not-ConEx.		of Not-ConEx.
	ConEx Signal: A packet sent by a ConEx Capable transport. It		ConEx Signal: A packet sent by a ConEx Capable transport. It
	carries at least one of the following signals:		carries at least one of the following signals:
	Re-Echo-Loss: The transport has experienced a loss.		Re-Echo-Loss: The transport has experienced a loss.
	Re-Echo-ECN: The transport has experienced an ECN mark.		Re-Echo-ECN: The transport has experienced an ECN mark.
	Credit: The transport is building up credit to allow for any		Credit: The transport is building up credit to allow for any
	future delay in expected ConEx signals (see Section 5.5.1)		future delay in expected ConEx signals (see Section 5.5.1)
	ConEx-Not-Marked: The transport is ConEx-capable but is signaling		ConEx-Not-Marked: The transport is ConEx-capable but is signaling
	none of Re-Echo-Loss, Re-Echo-ECN or Credit.		none of Re-Echo-Loss, Re-Echo-ECN or Credit.
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	c. The ConEx signal SHOULD be timely. There will be a minimum delay		c. The ConEx signal SHOULD be timely. There will be a minimum delay
	of one RTT, and often longer if the transport protocol sends		of one RTT, and often longer if the transport protocol sends
	infrequent feedback (consider RTCP [RFC3550] for example). This		infrequent feedback (consider RTCP [RFC3550] for example). This
	delay complicates auditing, and SHOULD be minimized.		delay complicates auditing, and SHOULD be minimized.
	d. The ConEx signal SHOULD be accurate and auditable. The general		d. The ConEx signal SHOULD be accurate and auditable. The general
	approach is to observe the volume of congestion signals and ConEx		approach is to observe the volume of congestion signals and ConEx
	signals on the forward data path and verify that the ConEx		signals on the forward data path and verify that the ConEx
	signals do not under-represent the congestion signals (see		signals do not under-represent the congestion signals (see
	Section 5.5). The simplest mechanism to compensate for the round		Section 5.5). The simplest mechanism to compensate for the round
	trip delay between the signals is to include a "credit" signal to		trip delay between the signals is for the sender to include a
	cover the yet to be observed congestion that might occur during		"credit" signal to cover the yet to be observed congestion that
	this delay. (see Section 5.5.1 for details). Furthermore, the		might occur during this delay. (see Section 5.5.1 for details).
	ConEx signals for packet loss and ECN marking SHOULD have		Furthermore, the ConEx signals for packet loss and ECN marking
	distinct encodings because they are likely to require different		SHOULD have distinct encodings because they are likely to require
	auditing techniques.		different auditing techniques.
	It is already known implementing ConEx signals is likely to entail		It is already known that implementing ConEx signals is likely to
	some compromises, and therefore all the requirements above are		entail some compromises, and therefore all the requirements above are
	expressed with the keyword 'SHOULD' rather than 'MUST'. The only		expressed with the keyword 'SHOULD' rather than 'MUST'. The only
	mandatory requirement is that a concrete protocol description MUST		mandatory requirement is that a concrete protocol description MUST
	give sound reasoning if it chooses not to meet some requirement.		give sound reasoning if it chooses not to meet some requirement.
	3.2. Requirements for the Audit Function		3.2. Requirements for the Audit Function
	The role and constraints on the audit function are described in		The role and constraints on the audit function are described in
	Section 5.5. There is no intention to standardise the audit		Section 5.5. There is no intention to standardise the audit
	function. However, it is necessary to lay down the following		function. However, it is necessary to lay down the following
	normative constraints on audit behaviour so that transport designers		normative constraints on audit behaviour so that transport designers
	skipping to change at page 9, line 43		skipping to change at page 9, line 43
	conversions or accounting;		conversions or accounting;
	D. If the units are bytes a definition of which headers are		D. If the units are bytes a definition of which headers are
	included in the size of the packet;		included in the size of the packet;
	E. How tunnels should propagate the ConEx encoding;		E. How tunnels should propagate the ConEx encoding;
	F. Whether the encoding fields are mutable or not, to ensure that		F. Whether the encoding fields are mutable or not, to ensure that
	header authentication, checksum calculation, etc. process them		header authentication, checksum calculation, etc. process them
	correctly.		correctly.
	G. Definition of any extensibility;		G. Definition of any extensibility;
	H. Backward and forward compatibility and potential migration		H. Backward and forward compatibility and potential migration
	strategies;		strategies;
	I. Any (hopefully optional) modification to data-plane forwarding		I. Any (optional) modification to data-plane forwarding dependent
	dependent on the encoding (e.g. preferential discard,		on the encoding (e.g. preferential discard, interaction with
	interaction with Diffserv, ECN etc.);		Diffserv, ECN etc.);
	J. Any warning or error messages relevant to the encoding.		J. Any warning or error messages relevant to the encoding.
	Transport Layer:		Transport Layer:
	A. A specification of any required changes to congestion feedback		A. A specification of any required changes to congestion feedback
	in particular transport protocols.		in particular transport protocols.
	B. A specification (or minimally a recommendation) for how a		B. A specification (or minimally a recommendation) for how a
	transport should estimate credits at the beginning of a new		transport should estimate credits at the beginning of a new
	connection.		connection.
	C. @@@More TBA, incl ops & management@@@		C. @@@More TBA, incl ops & management@@@
	Security:		Security:
	skipping to change at page 11, line 21		skipping to change at page 11, line 21
	disincentives for deployment.		disincentives for deployment.
	Nonetheless, this Naive encoding does present a clear mental model of		Nonetheless, this Naive encoding does present a clear mental model of
	how the ConEx protocol might function under various uses. It is		how the ConEx protocol might function under various uses. It is
	useful for thought experiments where it can be stipulated that all		useful for thought experiments where it can be stipulated that all
	participants are honest and it does illustrate some of the incentives		participants are honest and it does illustrate some of the incentives
	that might be introduced by ConEx.		that might be introduced by ConEx.
	4.2. Null Encoding		4.2. Null Encoding
	In limited contexts is possible to implement ConEx like functions		In limited contexts it is possible to implement ConEx-like functions
	without any signals at all by measuring rest-of-path congestion		without any signals at all by measuring rest-of-path congestion
	directly from TCP headers. The algorithm is to keep at least one RTT		directly from TCP headers. The algorithm is to keep at least one RTT
	of past TCP headers and matching each new header against the history		of past TCP headers and matching each new header against the history
	to count duplicate data.		to count duplicate data.
	This could implement many ConEx policies, without any explicit		This could implement many ConEx policies, without any explicit
	protocol. It is fairly easy to implement, at least at low rate (e.g.		protocol. It is fairly easy to implement, at least at low rate (e.g.
	in a software based edge router). However, it would only be useful		in a software based edge router). However, it would only be useful
	in cases where the network operator can see the TCP headers. This is		in cases where the network operator can see the TCP headers. This is
	currently (2012) the vast majority of traffic because UDP, IPSEC and		currently (2012) the vast majority of traffic because UDP, IPSEC and
	VPN tunnels are used far less than SSL or TLS over TCP/IP, which do		VPN tunnels are used far less than SSL or TLS over TCP/IP, which do
	not hide TCP sequence numbers from network devices. However, anyone		not hide TCP sequence numbers from network devices. However, anyone
	specifically intending to avoid the attention of a congestion policy		specifically intending to avoid the attention of a congestion policy
	device would only have to hide their TCP headers from the network		device would only have to hide their TCP headers from the network
	operator (e.g. by using a VPN tunnel).		operator (e.g. by using a VPN tunnel).
	4.3. ECN Based Encoding		4.3. ECN Based Encoding
	The re-ECN specification [I-D.briscoe-tsvwg-re-ecn-tcp] presents an		The re-ECN specification [I-D.briscoe-conex-re-ecn-tcp] presents an
	IPv4 implementation of ConEx that was tightly integrated with ECN		encoding of ConEx in IPv4 and IPv6 that was tightly integrated with
	encoding in order to fit into the IPv4 header. ConEx and ECN are		the ECN encoding in order to fit into the IPv4 header. ConEx and ECN
	orthogonal signals in the sense that any individual packet may need		are orthogonal signals in the sense that any individual packet may
	to represent any one of the 4 possible combinations of signal values.		need to represent any one of the 4 possible combinations of signal
	Ideally their encoding should be entirely independent. However,		values. Ideally their encoding should be entirely independent.
	given the limited number of header bit and/or code points, these		However, given the limited number of header bits and/or code points,
	signals had to partially share code points.		re-ECN chooses to partially share code points between ConEx and ECN
			and to re-echo both loss and ECN with just one codepoint.
	The central theme of the re-ECN work was an audit mechanism that		The central theme of the re-ECN work is an audit mechanism that
	provides sufficient disincentives against misrepresenting congestion		provides sufficient disincentives against misrepresenting congestion
	[I-D.briscoe-tsvwg-re-ecn-motiv]. It is analyzed extensively in
			[I-D.briscoe-conex-re-ecn-motiv]. It is analyzed extensively in
	Briscoe's PhD dissertation [Refb-dis]. For a tutorial background on		Briscoe's PhD dissertation [Refb-dis]. For a tutorial background on
	re-ECN motivation and techniques, see [Re-fb, FairerFaster].		re-ECN motivation and techniques, see [Re-fb, FairerFaster].
	Re-ECN is an example of one chosen set of compromises attempting to		Re-ECN is an example of one chosen set of compromises attempting to
	meet the requirements of Section 3. The present document takes a		meet the requirements of Section 3. The present document takes a
	step back, aiming to state the ideal requirements in order to allow		step back, aiming to state the ideal requirements in order to allow
	the Internet community to assess whether different compromises might		the Internet community to assess whether different compromises might
	be better.		be better.
	The problem with Re-ECN is that it requires that receivers be ECN		The problem with Re-ECN is that it requires that receivers be ECN
	enabled in addition to sender changes. Newer encodings overcome this		enabled in addition to sender changes. Newer encodings
	problem by being able to represent both loss and ECN based		[I-D.ietf-conex-destopt] overcome this problem by being able to
	congestion, and assuming that both signals must be supported		represent loss and ECN based congestion separately.
	indefinitely.
	4.4. Independent Bits		4.4. Independent Bits
	This encoding involves flag bits, each of which the sender can set		This encoding involves flag bits, each of which the sender can set
	independently to indicate to the network one of the following four		independently to indicate to the network one of the following four
	signals:		signals:
	ConEx (Not-ConEx) The transport is (or is not) using ConEx with this		ConEx (Not-ConEx) The transport is (or is not) using ConEx with this
	packet (the protocol MUST be arranged so that legacy transport		packet (the protocol MUST be arranged so that legacy transport
	senders implicitly send Not-ConEx)		senders implicitly send Not-ConEx)
	Re-Echo-Loss (Not-Re-Echo-Loss) The transport has (or has not)		Re-Echo-Loss (Not-Re-Echo-Loss) The transport has (or has not)
	skipping to change at page 13, line 51		skipping to change at page 13, line 51
	[I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications		[I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications
	SHOULD be interpreted in units of bytes when responding to		SHOULD be interpreted in units of bytes when responding to
	congestion, at least on today's Internet. In any TCP implementation		congestion, at least on today's Internet. In any TCP implementation
	this is simple to achieve for varying size packets, given TCP SACK		this is simple to achieve for varying size packets, given TCP SACK
	tracks losses in bytes. If an encoding is specified in units of		tracks losses in bytes. If an encoding is specified in units of
	bytes, the encoding SHOULD also specify which headers to include in		bytes, the encoding SHOULD also specify which headers to include in
	the size of a packet.		the size of a packet.
	5. Congestion Exposure Components		5. Congestion Exposure Components
	The components shown in Figure 1 are described in more detail.		The components shown in Figure 1 as well as policy and audit are
			described in more detail.
	5.1. Network Devices (Not modified)		5.1. Network Devices (Not modified)
	Congestion signals originate from network devices as they do today.		Congestion signals originate from network devices as they do today.
	A congested router, switch or other network device can discard or ECN		A congested router, switch or other network device can discard or ECN
	mark packets when it is congested.		mark packets when it is congested.
	5.2. Modified Senders		5.2. Modified Senders
	The sending transport needs to be modified to send Congestion		The sending transport needs to be modified to send Congestion
	Exposure Signals in response to congestion feedback signals (For		Exposure Signals in response to congestion feedback signals (e.g. for
	example see [I-D.ietf-conex-tcp-modifications]). We want to permit		the case of a TCP transport see [I-D.ietf-conex-tcp-modifications]).
	ConEx without ECN (e.g. if the receiver does not support ECN).		We want to permit ConEx without ECN (e.g. if the receiver does not
	However, we want to encourage a ConEx sender to at least attempt to		support ECN). However, we want to encourage a ConEx sender to at
	negotiate ECN, because it is believed that ConEx without ECN is		least attempt to negotiate ECN, because it is believed that ConEx
	harder to audit, and thus potentially exposed to fraud. Since honest		without ECN is harder to audit, and thus potentially exposed to
	users have the potential to benefit from stronger mechanisms to		cheating. Since honest users have the potential to benefit from
	manage traffic they have an incentive to deploy ConEx and ECN		stronger mechanisms to manage traffic they have an incentive to
	together. This incentive is not sufficient to prevent a dishonest		deploy ConEx and ECN together. This incentive is not sufficient to
	user from constructing (or configuring) a sender that enables ConEx		prevent a dishonest user from constructing (or configuring) a sender
	after choosing not to negotiate ECN, but is should be sufficient to		that enables ConEx after choosing not to negotiate ECN, but is should
	prevent this from being the sustained default case for any		be sufficient to prevent this from being the sustained default case
	significant pool of users.		for any significant pool of users.
	Permitting ConEx without ECN is necessary to facilitate bootstrapping		Permitting ConEx without ECN is necessary to facilitate bootstrapping
	other parts of ConEx deployment.		other parts of ConEx deployment.
	5.3. Receivers (Optionally Modified)		5.3. Receivers (Optionally Modified)
	Any receiving transport may already feedback sufficiently useful		Any receiving transport may already feedback sufficiently useful
	signals to the sender so that it does not need to be altered.		signals to the sender so that it does not need to be altered.
	If the transport receiver does not support ECN, then it's native loss		If the transport receiver does not support ECN, then it's native loss
	skipping to change at page 14, line 50		skipping to change at page 14, line 50
	A traditional ECN implementation (RFC 3168 for TCP) signals		A traditional ECN implementation (RFC 3168 for TCP) signals
	congestion no more than once per round trip. The sender may require		congestion no more than once per round trip. The sender may require
	more precise feedback from the receiver otherwise it is at risk of		more precise feedback from the receiver otherwise it is at risk of
	appearing to be understating its ConEx Signals.		appearing to be understating its ConEx Signals.
	Ideally, ConEx should be added to a transport like TCP without		Ideally, ConEx should be added to a transport like TCP without
	mandatory modifications to the receiver. But an optional		mandatory modifications to the receiver. But an optional
	modification to the receiver could be recommended for precision (see		modification to the receiver could be recommended for precision (see
	[I-D.kuehlewind-tcpm-accurate-ecn]). This was the approach taken		[I-D.kuehlewind-tcpm-accurate-ecn]). This was the approach taken
	when adding re-ECN to TCP [I-D.briscoe-tsvwg-re-ecn-tcp].		when adding re-ECN to TCP [I-D.briscoe-conex-re-ecn-tcp].
	5.4. Policy Devices		5.4. Policy Devices
	Policy devices are characterised by a need to be configured with a		Policy devices are characterised by a need to be configured with a
	policy related to the users or neighboring networks being served. In		policy related to the users or neighboring networks being served. In
	contrast, the auditing devices referred to in the previous section		contrast, auditing devices solely enforce compliance with the ConEx
	primarily enforce compliance with the ConEx protocol and do not need		protocol and do not need to be configured with any client-specific
	to be configured with any client-specific policy.		policy.
	5.4.1. Congestion Monitoring Devices		5.4.1. Congestion Monitoring Devices
	Policy devices can typically be decomposed into two functions i)		Policy devices can typically be decomposed into two functions i)
	monitoring the ConEx signal to compare it with a policy then ii)		monitoring the ConEx signal to compare it with a policy then ii)
	acting in some way on the result. Various actions might be invoked		acting in some way on the result. Various actions might be invoked
	against 'out of contract' traffic, such as policing (see		against 'out of contract' traffic, such as policing (see
	Section 5.4.3), re-routing, or downgrading the class of service.		Section 5.4.3), re-routing, or downgrading the class of service.
	Alternatively a policy device might not act directly on the traffic,		Alternatively a policy device might not act directly on the traffic,
	skipping to change at page 15, line 34		skipping to change at page 15, line 34
	capacity upgrades, penalty clauses in contracts, levy charges based		capacity upgrades, penalty clauses in contracts, levy charges based
	on congestion, or merely send warnings to clients who are causing		on congestion, or merely send warnings to clients who are causing
	excessive congestion.		excessive congestion.
	Nonetheless, whatever action is invoked, the congestion monitoring		Nonetheless, whatever action is invoked, the congestion monitoring
	function will always be a necessary part of any policy device.		function will always be a necessary part of any policy device.
	5.4.2. Rest-of-Path Congestion Monitoring		5.4.2. Rest-of-Path Congestion Monitoring
	ConEx signals indicate the level of congestion along a whole path		ConEx signals indicate the level of congestion along a whole path
	from source to destination. In contrast when ECN signals are		from source to destination. In contrast, ECN signals monitored in
	monitored in the middle of a network, they indicate the level of		the middle of a network indicate the level of congestion experienced
	congestion experienced so far on the path.		so far on the path (of course, only in ECN-capable traffic).
	If a monitor in the middle of a network (e.g. at a network border)		If a monitor in the middle of a network (e.g. at a network border)
	measures both of these signals, it can subtract the level of ECN		measures both of these signals, it can subtract the level of ECN
	(path so far) from the level of ConEx (whole path) to derive a		(path so far) from the level of ConEx (whole path) to derive a
	measure of the congestion that packets are likely to experience		measure of the congestion that packets are likely to experience
	between the monitoring point and their destination (rest-of-path		between the monitoring point and their destination (rest-of-path
	congestion).		congestion).
	It will often be preferable for policy devices to monitor rest-of-		It will often be preferable for policy devices to monitor rest-of-
	path congestion if they can, because it is a measure of the		path congestion if they can, because it is a measure of the
	downstream congestion that the policy device can directly influence		downstream congestion that the policy device can directly influence
	by controlling the traffic passing through it.		by controlling the traffic passing through it.
	5.4.3. Congestion Policers		5.4.3. Congestion Policers
	A congestion policer can be implemented in a very similar way to a		A congestion policer can be implemented in a very similar way to a
	bit-rate policer, but its effect can be focused solely on traffic		bit-rate policer, but its effect can be focused solely on traffic of
	causing congestion downstream, which ConEx signals make visible.		users causing congestion downstream, which ConEx signals make
	Without ConEx signals, the only way to mitigate congestion is to		visible. Without ConEx signals, the only way to mitigate congestion
	blindly limit traffic bit-rate, on the assumption that high bit-rate		is to blindly limit traffic bit-rate, on the assumption that high
	is more likely to cause congestion.		bit-rate is more likely to cause congestion.
	A congestion policer monitors all ConEx traffic entering a network,		A congestion policer monitors all ConEx traffic entering a network,
	or some identifiable subset. Using ConEx signals (and preferably		or some identifiable subset. Using ConEx signals (and preferably
	subtracting ECN signals to yield rest-of-path congestion), it		subtracting ECN signals to yield rest-of-path congestion), it
	measures the amount of congestion that this traffic is contributing		measures the amount of congestion that this traffic is contributing
	somewhere downstream. If this exceeds a policy-configured		somewhere downstream. If this persistently exceeds a policy-
	'congestion-bit-rate' the congestion policer can limit all the		configured 'congestion-bit-rate' the congestion policer can limit all
	monitored ConEx traffic.		the monitored ConEx traffic.
	A congestion policer can be implemented by a simple token bucket.		A congestion policer can be implemented by a simple token bucket
	But unlike a bit-rate policer, it removes a token only when it		applied to an aggregate. But unlike a bit-rate policer, it removes
	forwards a packet that is ConEx-Marked, effectively treating Not-		tokens only when it forwards packets that are ConEx-Marked,
	ConEx-Marked packets as invisible. Consequently, because tokens give		effectively treating Not-ConEx-Marked packets as invisible.
	the right to send congested bits, the fill-rate of the token bucket		Consequently, because tokens give the right to send congested bits,
	will represent the allowed congestion-bit-rate. This should provide		the fill-rate of the token bucket will represent the allowed
	sufficient traffic management without having to additionally		congestion-bit-rate. This should provide sufficient traffic
	constrain the straight bit-rate at all. See [CongPol] for details.		management without having to additionally constrain the straight bit-
			rate at all. See [CongPol] for details.
	Note that the policing action is to introduce a throttle (delay		Note that the policing action is to introduce a throttle (delay
	through traffic) immediately upstream of the congestion policer.		through traffic) immediately upstream of the congestion policer.
	This throttle is likely to include a queue with its own AQM, which		This throttle could include a queue with its own AQM, which
	potentially increases the whole path congestion. In effect the		potentially increases the whole path congestion. In effect the
	congestion policer has moved the congestion earlier in the path, to		congestion policer has moved the congestion earlier in the path, and
	protect downstream resources by reducing the congestion in the rest		focused it on one user to protect downstream resources by reducing
	of the path.		the congestion in the rest of the path.
	5.5. Audit		5.5. Audit
	The most critical aspect of ConEx is the capability to support robust		The most critical aspect of ConEx is the capability to support robust
	auditing. It can be assumed that there will be an intrinsic		auditing. It can be assumed that there will be an intrinsic
	motivation for users to understate the congestion that they are		motivation for users to understate the congestion that they are
	causing. Without strong audit functions the ConEx signal is likely		causing. Without strong audit functions the ConEx signal is likely
	to become inaccurate to the point being useless. The most important		to become inaccurate to the point of being useless. The most
	feature of an encoding design is likely to be the robustness of the		important feature of an encoding design is likely to be the
	auditing it supports.		robustness of the auditing it supports.
	The general approach is to compare the volume of ConEx signals to		The general approach is to compare the volume of ConEx signals to
	direct measures of actual congestion volume. The technique described		direct measures of actual congestion volume. The credit approach
	in Section 5.5.1 can be used to guarantee that this is a strict		described in Section 5.5.1 can be used to guarantee that this is a
	bound: if the actual congestion exceeds the ConEx signal, then some		strict bound: if the actual congestion exceeds the ConEx signal, then
	congestion was understated and some sanction should be applied to the		some congestion was understated and some sanction should be applied
	traffic. Although sanctions are beyond the scope of this document,		to the traffic. Although sanctions are beyond the scope of this
	an example sanction might be to throttle the traffic immediately		document, an example sanction might be to throttle the traffic
	upstream of the auditor to prevent the user from getting any		immediately upstream of the auditor to prevent the user from getting
	advantage by understating congestion. Such a throttle would likely		any advantage by understating congestion. Such a throttle would
	include some combination of delaying, ECN marking or dropping		likely include some combination of delaying or dropping traffic.
	traffic.
	This document does not preclude "statistical auditing", where the		This document does not preclude "statistical auditing", where the
	audit function indicates some sort of probability that a particular		audit function indicates some sort of probability that a particular
	flow is under reporting congestion, however this design choice		flow is under-reporting congestion, however this design choice
	greatly complicates designing an appropriate sanction, due to the		greatly complicates designing an appropriate sanction, due to the
	possibility of a false hit.		possibility of a false hit.
	To facilitate ConEx deployment, not-ConEx traffic might be treated as		To facilitate ConEx deployment, not-ConEx traffic might be treated as
	a special case of understating congestion, but with a different		a special case of understating congestion, but with a different
	sanction. For example an ISP might apply a data rate cap to not-		sanction. For example an ISP might apply a data rate cap to not-
	ConEx traffic, while applying a congestion volume cap to ConEx marked		ConEx traffic, while applying a congestion volume cap to ConEx marked
	traffic. With suitable parameters this is likely to give ConEx		traffic. With suitable parameters this is likely to give ConEx
	marked traffic a much larger share of the network during off peak		marked traffic a much larger share of the network during off peak
	hours. (Note that in this example the ConEx auditor is also acting		hours. (Note that in this example the ConEx auditor is also acting
	as a ConEx policy device.) Another option to facilitate deployment		as a ConEx policy device.) Another option to facilitate deployment
	is for the auditor to act as a ConEx proxy, and insert ConEx signals		is for the auditor to act as a ConEx proxy, and insert ConEx signals
	in packets in behalf of the sender. Such a device is outside of the		in packets on behalf of the sender. Such a device is outside of the
	scope of this document, but nonetheless potentially useful for		scope of this document, but nonetheless potentially useful for
	supporting ConEx for legacy systems.		supporting ConEx for legacy systems.
	Auditing can be distributed and redundant. One flow may be audited		Auditing can be distributed and redundant. One flow may be audited
	in multiple places, using multiple techniques. Some audit techniques		in multiple places, using multiple techniques. Some audit techniques
	do not require any per flow state and can be applied to aggregate		do not require any per flow state and can be applied to aggregate
	traffic. These might be able to detect the presence of understated		traffic. These might be able to detect the presence of understated
	congestion at large scale and support recursively hunting for		congestion at large scale and support recursively hunting for
	individual flows that are understating their congestion. Even at		individual flows that are understating their congestion. Even at
	large scales, flows can be randomly selected for individual auditing.		large scales, flows can be randomly selected for individual auditing.
	The auditing function should be able to trigger sufficient sanction		The auditing function should be able to trigger sufficient sanction
	to discourage understating congestion[Salvatori05]. This potentially		to discourage understating congestion [Salvatori05]. This
	requires designing the sanction in consort with the policy functions,		potentially requires designing the sanction in concert with the
	even though they might be implemented in different parts of the		policy functions, even though they might be implemented in different
	network. Note that in the future it might prove to be desirable to		parts of the network. Note that in the future it might prove to be
	provide advise on uniformly implementing sanctions, because		desirable to provide advice on uniformly implementing sanctions,
	insufficient sanctions impairs the ability to implement policy		because insufficient sanctions impairs the ability to implement
	elsewhere in the network.		policy elsewhere in the network.
	Some of the audit algorithms require per flow state. This cost is		Some of the audit algorithms require per flow state. This cost is
	expected to be tolerable, because these techniques are most apropos		expected to be tolerable, because these techniques are most apropos
	near the edges of the network, where traffic is generally much less		near the edges of the network, where traffic is generally much less
	aggregated, so the state need not overwhelm any one device. Sampling		aggregated, so the state need not overwhelm any one device. Sampling
	techniques can also be used to bound the total auditing memory		techniques can also be used to bound the total auditing memory
	footprint, although the implementer must be wary of "identifier white		footprint, although the implementer must be wary of "identifier white
	washing" attacks to hide cheating connection among chaff.		washing when caught" tactics where a source cheats until caught by
			sampling, then simply discards that flow ID and starts cheating with
			a new one.
	At some point in the future, when ConEx is built into all transport		At some point in the future, when ConEx is built into all transport
	protocol implementations, it may not be necessary to audit all		protocol implementations, it may not be necessary to audit all
	traffic all the time. Auditing might be needed only to identify		traffic all the time. Auditing might be needed only to identify
	rogue actors and prevent them from gaining any long term advantage by		rogue actors and prevent them from gaining any long term advantage by
	cheating.		cheating.
	A ConEx auditor might use one of the following techniques:		A ConEx auditor might use one of the following techniques:
	ECN Auditing: Directly observe and compare the volume of ECN and		ECN Auditing: Directly observe and compare the volume of ECN and
	ConEx marks. Since the volume of ECN marks rises monotonically		ConEx marks. Since the volume of ECN marks rises monotonically
	skipping to change at page 18, line 32		skipping to change at page 18, line 34
	TCP-specific loss auditing: For non-encrypted standard TCP traffic		TCP-specific loss auditing: For non-encrypted standard TCP traffic
	on a single path, an auditor could measure losses by detecting		on a single path, an auditor could measure losses by detecting
	retransmissions, which appear as duplicate sequence numbers		retransmissions, which appear as duplicate sequence numbers
	upstream of the loss and out of order data downstream of the loss.		upstream of the loss and out of order data downstream of the loss.
	Since some reordering is present in the Internet, such a loss		Since some reordering is present in the Internet, such a loss
	estimator would be most accurate near the sender.		estimator would be most accurate near the sender.
	Predominant bottleneck loss auditing: For networks designed so that		Predominant bottleneck loss auditing: For networks designed so that
	losses predominantly occur due to Active Queue Management under		losses predominantly occur due to Active Queue Management under
	the control of one IP-aware node on the path, the auditor could be		the control of one IP-aware node on the path, the auditor could be
	located at this bottleneck. It could simply compare ConEx Signals		located at this bottleneck. It could simply compare ConEx Signals
	with actual local packet discards (or ECN marks). This is a good		with actual local packet discards (and ECN marks). This is a good
	model for most consumer access networks where audit accuracy could		model for most consumer access networks where audit accuracy could
	well be sufficient even if losses occasionally occur elsewhere in		well be sufficient even if losses occasionally occur elsewhere in
	the network.		the network.
	Although the auditor at the predominant bottleneck would not be		Although the auditor at the predominant bottleneck would not be
	able to count losses at other nodes, transports would not know		able to count losses at other nodes, transports would not know
	where losses were occurring either. Therefore a transport would		where losses were occurring either. Therefore a transport would
	not know which losses it could cheat and which ones it couldn't		not know which losses it could cheat and which ones it couldn't
	without getting caught.		without getting caught.
	skipping to change at page 19, line 15		skipping to change at page 19, line 17
	ConEx.		ConEx.
	In addition, other audit techniques may be identified in the future.		In addition, other audit techniques may be identified in the future.
	5.5.1. Using Credit to Simplify Audit		5.5.1. Using Credit to Simplify Audit
	At the audit function, there will be an inherent delay of at least		At the audit function, there will be an inherent delay of at least
	one round trip between a congestion signal and the subsequent ConEx		one round trip between a congestion signal and the subsequent ConEx
	signal it triggers, as shown in Figure 1. However, the audit		signal it triggers, as shown in Figure 1. However, the audit
	function cannot be expected to wait for a round trip to check that		function cannot be expected to wait for a round trip to check that
	one signal balances the other, because that requires excessive state		one signal balances the other, because that requires excessive state
	and the auditor can't easily determine the RTT of each transport.		and the auditor can't easily determine the RTT of each flow.
	The simplest mechanism to compensate for the round trip delay between		The simplest mechanism to compensate for the round trip delay between
	the signals is to have the sender include a "credit" signal to cover		the signals is to have the sender include a "credit" signal to cover
	the yet to be observed congestion that might occur during this delay.		the yet to be observed congestion that might occur during this delay.
	The transport signals sufficient credit in advance to cover		The transport signals sufficient credit in advance to cover
	congestion expected during its feedback delay. Then, the audit		congestion expected during its feedback delay. Then, the audit
	function does not need to make allowance for round trip delays that		function does not need to make allowance for round trip delays that
	it cannot quantify. This design choice correctly makes the transport		it cannot quantify. This design choice correctly makes the transport
	responsible for both minimizing feedback delay and for the risk that		responsible for both minimizing feedback delay and for the risk that
	packets in flight will cause congestion to others before the source		packets in flight will cause congestion to others before the source
	skipping to change at page 20, line 46		skipping to change at page 20, line 46
	This greater freedom acts as an inducement for the source to		This greater freedom acts as an inducement for the source to
	volunteer ConEx information.		volunteer ConEx information.
	Receivers: A ConEx source should be able to work without a modified		Receivers: A ConEx source should be able to work without a modified
	receiver. However, without sufficiently precise congestion		receiver. However, without sufficiently precise congestion
	feedback from the receiver, the source may have to conservatively		feedback from the receiver, the source may have to conservatively
	send extra ConEx markings in order to avoid understating		send extra ConEx markings in order to avoid understating
	congestion. The need for more precise receiver feedback is not		congestion. The need for more precise receiver feedback is not
	exclusive to ConEx, for instance Data Centre TCP (DCTCP [DCTCP])		exclusive to ConEx, for instance Data Centre TCP (DCTCP [DCTCP])
	uses precise feedback to good effect. Nonetheless, if a receiver		uses precise feedback to good effect. Nonetheless, if a receiver
	offers precise feedback, it will be best if ConEx uses it (see		offers precise feedback, it will be best if ConEx uses it (see
	Section 5.3).		Section 5.3) and [I-D.kuehlewind-tcpm-accurate-ecn].
	Proxies: Although it was stated above that ConEx requires a		Proxies: Although it was stated above that ConEx requires a
	modification to the source, ConEx signals could theoretically be		modification to the source, ConEx signals could theoretically be
	introduced by a proxy for the source, as long as it can intercept		introduced by a proxy for the source, as long as it can intercept
	feedback from the receiver. Similarly, more precise feedback		feedback from the receiver. Similarly, more precise feedback
	could thoretically be provided by a proxy for the receiver rather		could thoretically be provided by a proxy for the receiver rather
	than modifying the receiver itself.		than modifying the receiver itself.
	Queues: No modification to queues is needed for ConEx.		Forwarding: No modification to forwarding or queuing is needed for
			ConEx.
	However, once ConEx is deployed, it is possible that a queue		However, once ConEx is deployed, it is possible that a queue
	implementation could take advantage of the ConEx information in		implementation could optionally take advantage of the ConEx
	packets. For instance, it has been suggested		information in packets. For instance, it has been suggested
	[I-D.briscoe-tsvwg-re-ecn-tcp] that a queue would be more robust		[I-D.briscoe-conex-re-ecn-tcp] that a queue would be more robust
	against flooding if it preferentially discarded Not-ConEx packets		against flooding if it preferentially discarded Not-ConEx packets
	then Not-Marked ConEx packets.		then Not-Marked ConEx packets.
	A ConEx sender re-echoes congestion whether the queues signaling		A ConEx sender re-echoes congestion whether the queues signaling
	congestion are ECN-enabled or not. Nonetheless, auditing works		congestion are ECN-enabled or not. Nonetheless, auditing works
	best if most congestion is indicated by ECN rather than loss (see		best if most congestion is indicated by ECN rather than loss (see
	Section 3). Also, monitoring rest-of-path congestion is not		Section 3). Also, monitoring rest-of-path congestion is not
	accurate if there are congested non-ECN queues upstream of the		accurate if there are congested non-ECN queues upstream of the
	monitoring point (Section 5.4.2).		monitoring point (Section 5.4.2).
	Networks: If a subset of traffic sources (or proxies) use ConEx		Networks: If a subset of traffic sources (or proxies) use ConEx
	skipping to change at page 21, line 37		skipping to change at page 21, line 38
	ConEx marked packets may safely traverse a network that ignores		ConEx marked packets may safely traverse a network that ignores
	them. Networks MUST NOT change ConEx marked packets to Not-ConEx.		them. Networks MUST NOT change ConEx marked packets to Not-ConEx.
	If necessary, endpoints SHOULD be able to detect if a network is		If necessary, endpoints SHOULD be able to detect if a network is
	removing ConEx signals.		removing ConEx signals.
	An operator can deploy policy devices (Section 5.4) wherever		An operator can deploy policy devices (Section 5.4) wherever
	traffic enters its network, in order to monitor the downstream		traffic enters its network, in order to monitor the downstream
	congestion that incoming traffic contributes to, and control it if		congestion that incoming traffic contributes to, and control it if
	necessary. See [I-D.ietf-conex-concepts-uses] for further		necessary. See [I-D.ietf-conex-concepts-uses] for further
	discussion of deployment incentives for networks and scenarios		discussion of deployment incentives for networks and scenarios
	where some networks use ConEx-based policy devices and other		where some networks use ConEx-based policy devices and others
	don't.		don't.
	An operator can deploy audit devices Section 5.5 unilaterally		An operator can deploy audit devices (Section 5.5) unilaterally
	within its own network to verify that traffic sources are not		within its own network to verify that traffic sources are not
	understating ConEx information. From the viewpoint of one network		understating ConEx information. From the viewpoint of one network
	operator (say N_a), it only cares that the level of ConEx		operator (say N_a), it only cares that the level of ConEx
	signaling is sufficient to cover congestion in its own network.		signaling is sufficient to cover congestion in its own network.
	If traffic continues into a congested downstream network (say		If traffic continues into a congested downstream network (say
	N_b), it is of no concern to the first network (N_a) if the end-		N_b), it is of no concern to the first network (N_a) if the end-
	to-end ConEx signaling is insufficient to cover the congestion in		to-end ConEx signaling is insufficient to cover the congestion in
	N_b as well. This is N-b's concern, and N_b can both detect such		N_b as well. This is N_b's concern, and N_b can both detect such
	anomalous traffic and deal with it using ConEx-based policy		anomalous traffic and deal with it using ConEx-based policy
	devices (Section 5.4).		devices (Section 5.4).
	7. IANA Considerations		7. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	skipping to change at page 23, line 33		skipping to change at page 23, line 33
	www.statslab.cam.ac.uk/~frank/		www.statslab.cam.ac.uk/~frank/
	evol.html>.		evol.html>.
	[FairerFaster] Briscoe, B., "A Fairer, Faster		[FairerFaster] Briscoe, B., "A Fairer, Faster
	Internet Protocol", IEEE		Internet Protocol", IEEE
	Spectrum Dec 2008:38--43,		Spectrum Dec 2008:38--43,
	December 2008, <http://		December 2008, <http://
	bobbriscoe.net/projects/		bobbriscoe.net/projects/
	refb/#fairfastip>.		refb/#fairfastip>.
	[I-D.briscoe-tsvwg-re-ecn-motiv] Briscoe, B., Jacquet, A.,		[I-D.briscoe-conex-re-ecn-motiv] Briscoe, B., Jacquet, A.,
	Moncaster, T., and A. Smith, "Re-		Moncaster, T., and A. Smith, "Re-
	ECN: A Framework for adding		ECN: A Framework for adding
	Congestion Accountability to		Congestion Accountability to
	TCP/IP", draft-briscoe-tsvwg-re-		TCP/IP", draft-briscoe-conex-re-
	ecn-tcp-motivation-02 (work in		ecn-motiv-00 (work in progress),
	progress), October 2010.		April 2012.
	[I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., Jacquet, A.,		[I-D.briscoe-conex-re-ecn-tcp] Briscoe, B., Jacquet, A.,
	Moncaster, T., and A. Smith, "Re-		Moncaster, T., and A. Smith, "Re-
	ECN: Adding Accountability for		ECN: Adding Accountability for
	Causing Congestion to TCP/IP",		Causing Congestion to TCP/IP",
	draft-briscoe-tsvwg-re-ecn-tcp-09		draft-briscoe-conex-re-ecn-tcp-00
	(work in progress), October 2010.		(work in progress), April 2012.
	[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.		[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.
	Cooper, "ConEx Concepts and Use		Cooper, "ConEx Concepts and Use
	Cases",		Cases",
	draft-ietf-conex-concepts-uses-04		draft-ietf-conex-concepts-uses-03
	(work in progress), March 2012.		(work in progress), October 2011.
	[I-D.ietf-conex-destopt] Krishnan, S., Kuehlewind, M., and		[I-D.ietf-conex-destopt] Krishnan, S., Kuehlewind, M., and
	C. Ucendo, "IPv6 Destination		C. Ucendo, "IPv6 Destination
	Option for Conex",		Option for Conex",
	draft-ietf-conex-destopt-02 (work		draft-ietf-conex-destopt-01 (work
	in progress), March 2012.		in progress), October 2011.
	[I-D.ietf-conex-tcp-modifications] Kuehlewind, M. and R.		[I-D.ietf-conex-tcp-modifications] Kuehlewind, M. and R.
	Scheffenegger, "TCP modifications		Scheffenegger, "TCP modifications
	for Congestion Exposure", draft-		for Congestion Exposure", draft-
	ietf-conex-tcp-modifications-00		ietf-conex-tcp-modifications-02
	(work in progress),		(work in progress), May 2012.
	December 2011.
	[I-D.ietf-ledbat-congestion] Shalunov, S., Hazel, G., Iyengar,		[I-D.ietf-ledbat-congestion] Shalunov, S., Hazel, G., Iyengar,
	J., and M. Kuehlewind, "Low Extra		J., and M. Kuehlewind, "Low Extra
	Delay Background Transport		Delay Background Transport
	(LEDBAT)",		(LEDBAT)",
	draft-ietf-ledbat-congestion-09		draft-ietf-ledbat-congestion-06
	(work in progress), October 2011.		(work in progress), May 2011.
	[I-D.ietf-tsvwg-byte-pkt-congest] Briscoe, B. and J. Manner, "Byte		[I-D.ietf-tsvwg-byte-pkt-congest] Briscoe, B. and J. Manner, "Byte
	and Packet Congestion		and Packet Congestion
	Notification", draft-ietf-tsvwg-		Notification", draft-ietf-tsvwg-
	byte-pkt-congest-07 (work in		byte-pkt-congest-07 (work in
	progress), February 2012.		progress), February 2012.
	[I-D.kuehlewind-tcpm-accurate-ecn] Kuehlewind, M. and R.		[I-D.kuehlewind-tcpm-accurate-ecn] Kuehlewind, M. and R.
	Scheffenegger, "Accurate ECN		Scheffenegger, "Accurate ECN
	Feedback in TCP", draft-		Feedback Option in TCP", draft-
	kuehlewind-tcpm-accurate-ecn-00		kuehlewind-tcpm-accurate-ecn-
	(work in progress),		option-01 (work in progress),
	December 2011.		July 2012.
	[RFC3448] Handley, M., Floyd, S., Padhye,		[RFC3448] Handley, M., Floyd, S., Padhye,
	J., and J. Widmer, "TCP Friendly		J., and J. Widmer, "TCP Friendly
	Rate Control (TFRC): Protocol		Rate Control (TFRC): Protocol
	Specification", RFC 3448,		Specification", RFC 3448,
	January 2003.		January 2003.
	[RFC3514] Bellovin, S., "The Security Flag		[RFC3514] Bellovin, S., "The Security Flag
	in the IPv4 Header", RFC 3514,		in the IPv4 Header", RFC 3514,
	April 1 2003.		April 2003.
	[RFC3550] Schulzrinne, H., Casner, S.,		[RFC3550] Schulzrinne, H., Casner, S.,
	Frederick, R., and V. Jacobson,		Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for		"RTP: A Transport Protocol for
	Real-Time Applications", STD 64,		Real-Time Applications", STD 64,
	RFC 3550, July 2003.		RFC 3550, July 2003.
			[RFC5681] Allman, M., Paxson, V., and E.
			Blanton, "TCP Congestion
			Control", RFC 5681,
			September 2009.
	[Re-fb] Briscoe, B., Jacquet, A., Di		[Re-fb] Briscoe, B., Jacquet, A., Di
	Cairano-Gilfedder, C., Salvatori,		Cairano-Gilfedder, C., Salvatori,
	A., Soppera, A., and M. Koyabe,		A., Soppera, A., and M. Koyabe,
	"Policing Congestion Response in		"Policing Congestion Response in
	an Internetwork Using Re-		an Internetwork Using Re-
	Feedback", ACM SIGCOMM		Feedback", ACM SIGCOMM
	CCR 35(4)277--288, August 2005, <		CCR 35(4)277--288, August 2005, <
	http://www.acm.org/sigs/sigcomm/		http://www.acm.org/sigs/sigcomm/
	sigcomm2005/		sigcomm2005/
	techprog.html#session8>.		techprog.html#session8>.
End of changes. 52 change blocks.
	153 lines changed or deleted		163 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/