< draft-ietf-conex-concepts-uses-05a.txt		draft-ietf-conex-concepts-uses-05c.txt >
	ConEx B. Briscoe, Ed.		ConEx B. Briscoe, Ed.
	Internet-Draft BT		Internet-Draft BT
	Intended status: Informational R. Woundy, Ed.		Intended status: Informational R. Woundy, Ed.
	Expires: December 30, 2012 Comcast		Expires: January 17, 2013 Comcast
	A. Cooper, Ed.		A. Cooper, Ed.
	CDT		CDT
	June 28, 2012		July 16, 2012
	ConEx Concepts and Use Cases		ConEx Concepts and Use Cases
	draft-ietf-conex-concepts-uses-05		draft-ietf-conex-concepts-uses-05
	Abstract		Abstract
	This document provides the entry point to the set of documentation		This document provides the entry point to the set of documentation
	about the Congestion Exposure (ConEx) protocol. It explains the		about the Congestion Exposure (ConEx) protocol. It explains the
	motivation for including a ConEx marking at the IP layer: to expose		motivation for including a ConEx marking at the IP layer: to expose
	information about congestion to network nodes. Although such		information about congestion to network nodes. Although such
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 December 30, 2012.		This Internet-Draft will expire on January 17, 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 2, line 17		skipping to change at page 2, line 17
	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
	2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5		2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5
	2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 5		2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6
	2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Core Use Case: Informing Traffic Management . . . . . . . . . 7		3. Core Use Case: Informing Traffic Management . . . . . . . . . 8
	3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7		3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 8
	3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 8		3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9
	3.3. Comparison with Existing Approaches . . . . . . . . . . . 9		3.3. Comparison with Existing Approaches . . . . . . . . . . . 9
	4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11		4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 11		5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Experimental Considerations . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Informative References . . . . . . . . . . . . . . . . . . . . 13		9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 15
			10. Informative References . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The power of Internet technology comes from multiplexing shared		The power of Internet technology comes from multiplexing shared
	capacity with packets rather than circuits. Network operators aim to		capacity with packets rather than circuits. Network operators aim to
	provide sufficient shared capacity, but when too much packet load		provide sufficient shared capacity, but when too much packet load
	meets too little shared capacity, congestion results. Congestion		meets too little shared capacity, congestion results. Congestion
	appears as either increased delay, dropped packets or packets		appears as either increased delay, dropped packets or packets
	explicitly marked with Explicit Congestion Notification (ECN)		explicitly marked with Explicit Congestion Notification (ECN)
	markings [RFC3168]. As described in Figure 1, congestion control		markings [RFC3168]. As described in Figure 1, congestion control
	skipping to change at page 4, line 9		skipping to change at page 4, line 9
	| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |		| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
	| | | | / | |		| | | | / | |
	| |_____________| |_______________ / | |		| |_____________| |_______________ / | |
	| | | | |/ | |		| | | | |/ | |
	`---------' `-----------' ' `---------'		`---------' `-----------' ' `---------'
	Figure 1: The ConEx Protocol in the Internet Architecture		Figure 1: The ConEx Protocol in the Internet Architecture
	One of the key benefits of exposing this congestion information at		One of the key benefits of exposing this congestion information at
	the IP layer is that it makes the information available to network		the IP layer is that it makes the information available to network
	operators for use as input into their traffic management procedures.		operators for use as input into their traffic management procedures.
	As shown in Figure 1, a ConEx-enabled sender signals whole path		A ConEx-enabled sender signals expected whole path congestion, which
	congestion, which is (approximately) the congestion one round trip		is approximately the congestion at least a round trip time earlier as
	time earlier as reported by the receiver to the sender. The ConEx		reported by the receiver to the sender (Figure 1). The ConEx signal
	signal is a mark in the IP header that is easy for any IP device to		is a mark in the IP header that is easy for any IP device to read.
	read. Therefore a node performing traffic management can count		Therefore a node performing traffic management can count congestion
	congestion as easily as it might count data volume today by simply		as easily as it might count data volume today by simply counting the
	counting the volume of packets with ConEx markings.		volume of packets with ConEx markings.
	ConEx-based traffic management can make highly efficient use of		ConEx-based traffic management can make highly efficient use of
	capacity. In times of no congestion, all traffic management		capacity. In times of no congestion, all traffic management
	restraints can be removed, leaving the network's full capacity		restraints can be removed, leaving the network's full capacity
	available to all its users. If some users on the network cause		available to all its users. If some users on the network cause
	disproportionate congestion, the traffic management function can		disproportionate congestion, the traffic management function can
	learn about this and directly limit those users' traffic in order to		learn about this and directly limit those users' traffic in order to
	protect the service of other users sharing the same capacity. ConEx-		protect the service of other users sharing the same capacity. ConEx-
	based traffic management thus presents a step change in terms of the		based traffic management thus presents a step change in terms of the
	options available to network operators for managing traffic on their		options available to network operators for managing traffic on their
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	how exposing congestion can significantly improve Internet traffic		how exposing congestion can significantly improve Internet traffic
	management, among other benefits. Section 2 introduces a number of		management, among other benefits. Section 2 introduces a number of
	concepts that are fundamental to understanding how ConEx-based		concepts that are fundamental to understanding how ConEx-based
	traffic management works. Section 3 shows how ConEx can be used for		traffic management works. Section 3 shows how ConEx can be used for
	traffic management, discusses additional benefits from such usage,		traffic management, discusses additional benefits from such usage,
	and compares ConEx-based traffic management to existing traffic		and compares ConEx-based traffic management to existing traffic
	management approaches. Section 4 discusses other related use cases.		management approaches. Section 4 discusses other related use cases.
	Section 5 briefly discusses deployment arrangements. The final		Section 5 briefly discusses deployment arrangements. The final
	sections are standard RFC back matter.		sections are standard RFC back matter.
	The remainder of the core ConEx document suite is comprised of:		The remainder of the core ConEx document suite consists of:
	[I-D.ietf-conex-abstract-mech], which provides an abstract		[I-D.ietf-conex-abstract-mech], which provides an abstract
	encoding of ConEx signals, explains the ConEx audit and security		encoding of ConEx signals, explains the ConEx audit and security
	mechanisms, and describes incremental deployment features;		mechanisms, and describes incremental deployment features;
	[I-D.ietf-conex-destopt], which specifies the IPv6 destination		[I-D.ietf-conex-destopt], which specifies the IPv6 destination
	option encoding for ConEx;		option encoding for ConEx;
	[I-D.ietf-conex-tcp-modifications], which specifies TCP sender		[I-D.ietf-conex-tcp-modifications], which specifies TCP sender
	modifications for use of ConEx; and		modifications for use of ConEx;
			and the following documents, which describe some feasible
			scenarios for deploying ConEx:
	[I-D.briscoe-conex-initial-deploy], which gives concrete examples		[I-D.briscoe-conex-initial-deploy], which describes a scenario
	of feasible initial deployment scenarios.		around a fixed broadband access network;
			[I-D.ietf-conex-mobile], which describes a scenario around a
			mobile communications provider;
			[I-D.briscoe-conex-data-centre], which describes how ConEx
			could be used for performance isolation between tenants of a
			data centre.
	2. Concepts		2. Concepts
	ConEx relies on a precise definition of congestion and a number of		ConEx relies on a precise definition of congestion and a number of
	newer concepts that are introduced and defined in this section.		newer concepts that are introduced then formally defined in this
			section.
	2.1. Congestion		2.1. Congestion
	Despite its central role in network control and management,		Despite its central role in network control and management,
	congestion is a remarkably difficult concept to define. Experts in		congestion is a remarkably difficult concept to define. Experts in
	different disciplines and with different perspectives define		different disciplines and with different perspectives define
	congestion in a variety of ways [Bauer09].		congestion in a variety of ways [Bauer09].
	The definition used for the purposes of ConEx is expressed as the		The definition used for the purposes of ConEx is expressed as the
	probability of packet loss (or the probability of packet marking if		probability of packet loss (or the probability of packet marking if
	ECN is in use). This definition focuses on how congestion is		ECN is in use). This definition focuses on how congestion is
	measured, rather than describing congestion as a condition or state.		measured, rather than describing congestion as a condition or state.
	2.2. Congestion-Volume		2.2. Congestion-Volume
	The metric that ConEx exposes is congestion-volume: the volume of		The metric that ConEx exposes is congestion-volume: the volume of
	bytes dropped or ECN-marked in a given period of time. Counting		bytes dropped or ECN-marked in a given period of time. Counting
	congestion-volume allows each user to be held responsible for his or		congestion-volume allows each user to be held responsible for his or
	her contribution to causing congestion. Congestion-volume is a		her contribution to congestion. Congestion-volume can only be a
	property of traffic, whereas congestion is a property of a link or a		property of traffic, whereas congestion can be a property of traffic
	path.		or a property of a link or a path.
	To understand congestion-volume, consider a simple example. Imagine		To understand congestion-volume, consider a simple example. Imagine
	Alice sends 1GB while the loss-probability is a constant 0.2%. Her		Alice sends 1GB of a file while the loss-probability is a constant
	contribution to congestion -- her congestion-volume -- is 1GB x 0.2%		0.2%. Her contribution to congestion -- her congestion-volume -- is
	= 2MB. If she then sends 3GB while the loss-probability is 0.1%,		1GB x 0.2% = 2MB. If she then sends another 3GB of the file while
	this adds 3MB to her congestion-volume. Her total contribution to		the loss-probability is 0.1%, this adds 3MB to her congestion-volume.
	congestion is then 2MB+3MB = 5MB.		Her total contribution to congestion is then 2MB+3MB = 5MB.
	Fortunately, measuring Alice's congestion-volume on a real network		Fortunately, measuring Alice's congestion-volume on a real network
	does not require the kind of arithmetic shown above because		does not require the kind of arithmetic shown above because
	congestion-volume can be directly measured by counting the total		congestion-volume can be directly measured by counting the total
	volume of Alice's traffic that gets discarded or ECN-marked. (A		volume of Alice's traffic that gets discarded or ECN-marked. (A
	queue with a percentage loss involves multiplication inherently.)		queue with varying percentage loss does these multiplications and
	Network operators can count congestion-volume using techniques very		additions inherently.) With ConEx, network operators can count
	similar to those they use for counting volume.		congestion-volume using techniques very similar to those they use for
			counting volume.
	2.3. Rest-of-Path Congestion		2.3. Rest-of-Path Congestion
	At a particular measurement point within a network, "rest-of-path		At a particular measurement point within a network, "rest-of-path
	congestion" (also known as "downstream congestion") is the level of		congestion" (also known as "downstream congestion") is the level of
	congestion that a traffic flow is expected to experience between the		congestion that a traffic flow is expected to experience between the
	measurement point and its final destination. "Upstream congestion"		measurement point and its final destination. "Upstream congestion"
	is the congestion experienced up to the measurement point.		is the congestion experienced up to the measurement point.
	Measurement points that only observe ECN marks are capable of		If traffic is ECN-capable, ECN signals monitored in the middle of a
	measuring upstream congestion, whereas measurement points that		network will indicate the congestion experienced so far on the path
	observe ConEx marks in addition to ECN marks can use both kinds of		(upstream congestion). In contrast, the ConEx signals inserted into
	marks to calculate rest-of-path congestion. When ECN signals are		IP headers as shown in Figure 1 indicate the congestion along a whole
	monitored in the middle of a network, they indicate the congestion		path from transport source to transport destination. Therefore if a
	experienced so far on the path (upstream congestion). In contrast,		measurement point detects both of these signals, it can subtract the
	the ConEx signals inserted into IP headers as shown in Figure 1		level of ECN (upstream congestion) from the level of ConEx (whole
	indicate the congestion along a whole path from source to		path) to derive a measure of the congestion that packets are likely
	destination. Therefore if a measurement point detects both of these		to experience between the monitoring point and their destination
	signals, it can subtract the level of ECN (upstream congestion) from		(rest-of-path congestion).
	the level of ConEx (whole path) to derive a measure of the congestion
	that packets are likely to experience between the monitoring point
	and their destination (rest-of-path congestion).
	[I-D.ietf-conex-abstract-mech] has further discussion of the		A network monitor can count the volume of all passing ConEx marked
	constraints around the network's ability to measure rest-of-path		packets and subtract the volume of all ECN marked packets regardless
	congestion.		of the flows within the aggregate. The resulting measure of
			downstream congestion-volume reflects the total 'harm' the aggregate
			contributes to other traffic beyond that point, on its way to its
			various destinations.
			If traffic is not ECN-capable, upstream congestion is not always
			possible to measure. [I-D.ietf-conex-abstract-mech] has further
			discussion of the constraints around the network's ability to measure
			upstream and rest-of-path congestion in these circumstances. Given
			these constraints, there are still some significant intial deployment
			arrangements that need ConEx but work without ECN (see Section 5).
	2.4. Definitions		2.4. Definitions
	Congestion: In general, congestion occurs when any user's traffic		Congestion: In general, congestion occurs when any user's traffic
	suffers loss, ECN marking, or increased delay as a result of one		suffers loss, ECN marking, or increased delay as a result of one
	or more network resources becoming overloaded. For the purposes		or more network resources becoming overloaded. For the purposes
	of ConEx, congestion is measured using the concrete signals		of ConEx, congestion is measured using the concrete signals
	provided by loss and ECN markings (delay is not considered).		provided by loss and ECN markings (delay is not considered).
	Congestion is measured as the probability of loss or the		Congestion is measured as the probability of loss or the
	probability of ECN marking, usually expressed as a dimensionless		probability of ECN marking, usually expressed as a dimensionless
	percentage.		percentage.
	Congestion-volume: For any granularity of traffic (packet, flow,		Congestion-volume: For any granularity of traffic (packet, flow,
	aggregate, link, etc.), the volume of bytes dropped or ECN-marked		aggregate, link, etc.), the volume of bytes dropped or ECN-marked
	in a given period of time. Conceptually, data volume multiplied		in a given period of time. Conceptually, data volume multiplied
	by the congestion each packet of the volume experienced. Usually		by the congestion each packet of the volume experienced. Usually
	expressed in bytes (or MB or GB).		expressed in bytes (or MB or GB).
	skipping to change at page 6, line 49		skipping to change at page 7, line 21
	in a given period of time. Conceptually, data volume multiplied		in a given period of time. Conceptually, data volume multiplied
	by the congestion each packet of the volume experienced. Usually		by the congestion each packet of the volume experienced. Usually
	expressed in bytes (or MB or GB).		expressed in bytes (or MB or GB).
	Congestion policer: A logical entity that allows a network operator		Congestion policer: A logical entity that allows a network operator
	to monitor each user's congestion-volume and enforce congestion-		to monitor each user's congestion-volume and enforce congestion-
	volume limits (discussed in Section 3.1).		volume limits (discussed in Section 3.1).
	Rest-of-path congestion (or downstream congestion): The congestion a		Rest-of-path congestion (or downstream congestion): The congestion a
	flow of traffic is expected to experience on the remainder of its		flow of traffic is expected to experience on the remainder of its
	path. In other words, at a measurement point in the network the		path. In other words, at a measurement point in the network, the
	rest-of-path congestion is the congestion the traffic flow has yet		rest-of-path congestion is the congestion the traffic flow has yet
	to experience as it travels from that point to the receiver.		to experience as it travels from that point to the receiver.
			Expressed as a dimensionless percentage.
	Upstream congestion: The accumulated congestion experienced by a		Upstream congestion: The accumulated congestion experienced by a
	traffic flow thus far, relative to a point along its path. In		traffic flow thus far, relative to a point along its path. In
	other words, at a measurement point in the network the upstream		other words, at a measurement point in the network the upstream
	congestion is the accumulated congestion the traffic flow has		congestion is the accumulated congestion the traffic flow has
	experienced as it travels from the sender to that point. At the		experienced as it travels from the sender to that point. At the
	receiver this is equivalent to the end-to-end congestion level		receiver this is equivalent to the end-to-end congestion level
	that (usually) is reported back to the sender.		that (usually) is reported back to the sender. Expressed as a
			dimensionless percentage.
	Network operators (or providers): Operator of a residential,		Network operators (or providers): Operator of a residential,
	commercial, enterprise, campus or other network.		commercial, enterprise, campus or other network.
	User: The contractual entity that represents an individual,		User: The contractual entity that represents an individual,
	household, business, or institution that uses the service of a		household, business, or institution that uses the service of a
	network operator. There is no implication that the contract has		network operator. There is no implication that the contract has
	to be commercial; for instance, the users of a university or		to be commercial; for instance, the users of a university or
	enterprise network service could be students or employees who do		enterprise network service could be students or employees who do
	not pay for access but may be required to comply with some form of		not pay for access but may be required to comply with some form of
	skipping to change at page 8, line 37		skipping to change at page 9, line 12
	IP node, the Broadband Remote Access Server (BRAS). From the BRAS,		IP node, the Broadband Remote Access Server (BRAS). From the BRAS,
	traffic is delivered to access nodes. The BRAS carries enhanced		traffic is delivered to access nodes. The BRAS carries enhanced
	functionality including IP QoS and traffic management capabilities.		functionality including IP QoS and traffic management capabilities.
	By deploying a congestion policer at the BRAS location, the network		By deploying a congestion policer at the BRAS location, the network
	operator can measure the congestion-volume created by users within		operator can measure the congestion-volume created by users within
	the access nodes and police misbehaving users before their traffic		the access nodes and police misbehaving users before their traffic
	affects others on the access network. The policer would be		affects others on the access network. The policer would be
	provisioned with a traffic management policy, perhaps directing the		provisioned with a traffic management policy, perhaps directing the
	BRAS to drop packets from users that exceed their congestion-volume		BRAS to drop packets from users that exceed their congestion-volume
	quotas during times of congestion. Those users would be likely to		quotas during times of congestion. Those users' apps would be likely
	react in the typical way to drops, backing off (assuming use of		to react in the typical way to drops, backing off (assuming at least
	standard TCP), and thereby lowering their congestion-volumes back		some use TCP), and thereby lowering the users' congestion-volumes
	within the quota limits.		back within the quota limits. If none of a user's apps responded,
			the policer would continue to increase focused drops and effectively
			enforce its own congestion control.
	3.2. Additional Benefits		3.2. Additional Benefits
	The ConEx-based approach to traffic management has a number of		The ConEx-based approach to traffic management has a number of
	benefits in addition to efficient management of traffic. It provides		benefits in addition to efficient management of traffic. It provides
	incentives for users to make use of "scavenger" transport protocols,		incentives for users to make use of "scavenger" transport protocols,
	such as [I-D.ietf-ledbat-congestion], that provide ways for bulk-		such as [I-D.ietf-ledbat-congestion], that provide ways for bulk-
	transfer applications to rapidly yield when interactive applications		transfer applications to rapidly yield when interactive applications
	require capacity (thereby "scavenging" remaining bandwidth). With a		require capacity (thereby "scavenging" remaining bandwidth). With a
	congestion policer in place as described in Section 3.1, users of		congestion policer in place as described in Section 3.1, users of
	skipping to change at page 9, line 15		skipping to change at page 9, line 40
	applications generate the same volume of traffic without being		applications generate the same volume of traffic without being
	sensitive to congestion. In short, two users who produce similar		sensitive to congestion. In short, two users who produce similar
	traffic volumes over the same time interval may produce different		traffic volumes over the same time interval may produce different
	congestion-volumes if one of them is using a scavenger transport		congestion-volumes if one of them is using a scavenger transport
	protocol and the other is not; in that situation the scavenger user's		protocol and the other is not; in that situation the scavenger user's
	traffic is less likely to be managed by the network operator.		traffic is less likely to be managed by the network operator.
	ConEx-based traffic management also makes it possible for a user to		ConEx-based traffic management also makes it possible for a user to
	control the relative performance among its own traffic flows. If a		control the relative performance among its own traffic flows. If a
	user wants some flows to have more bandwidth than others, it can		user wants some flows to have more bandwidth than others, it can
	allow the higher bandwidth traffic to generate more congestion		reduce the rate of some traffic so that it consumes less congestion-
	signals, leaving less congestion "budget" for the user to "spend" on		volume "budget", leaving more congestion "budget" for the user to
	other traffic. This approach is most relevant if congestion is		"spend" on making other traffic go faster. This approach is most
	signalled by ECN, because no impairment due to loss is involved and		relevant if congestion is signalled by ECN, because no impairment due
	delay can remain low.		to loss is involved and delay can remain low.
	3.3. Comparison with Existing Approaches		3.3. Comparison with Existing Approaches
	A variety of approaches already exist for network operators to manage		A variety of approaches already exist for network operators to manage
	congestion, traffic, and the disproportionate usage of scarce		congestion, traffic, and the disproportionate usage of scarce
	capacity by a small number of users. Common approaches can be		capacity by a small number of users. Common approaches can be
	categorized as rate-based, volume-based, or application-based.		categorized as rate-based, volume-based, or application-based.
	Rate-based approaches constrain the traffic rate per user or per		Rate-based approaches constrain the traffic rate per user or per
	network. A user's peak and average (or "committed") rate may be		network. A user's peak and average (or "committed") rate may be
	skipping to change at page 11, line 12		skipping to change at page 11, line 32
	can be used to reduce the performance uncertainty that some users		can be used to reduce the performance uncertainty that some users
	currently experience.		currently experience.
	4. Other Use Cases		4. Other Use Cases
	ConEx information can be put to a number of uses other than informing		ConEx information can be put to a number of uses other than informing
	traffic management. These include:		traffic management. These include:
	Informing inter-operator contracts: ConEx information is made		Informing inter-operator contracts: ConEx information is made
	visible to every IP node, including border nodes between networks.		visible to every IP node, including border nodes between networks.
	Network operators can use this information to measure how much		Network operators can use ConEx combined with ECN markings to
	traffic from each network contributes to congestion in the other.		measure how much traffic from each network contributes to
	As such, congestion-volume could be included as a metric in inter-		congestion in the other. As such, congestion-volume could be
	operator contracts, just as volume or bit-rate are included today.		included as a metric in inter-operator contracts, just as volume
			or bit-rate are included today. This would not be an initial
			deployment scenario, unless ECN became widely deployed.
	Enabling more efficient capacity provisioning: Section 3.2 explained		Enabling more efficient capacity provisioning: Section 3.2 explained
	how operators can use ConEx-based traffic management to encourage		how operators can use ConEx-based traffic management to encourage
	use of scavenger transport protocols, which significantly improves		use of scavenger transport protocols, which significantly improves
	the performance of interactive applications while still allowing		the performance of interactive applications while still allowing
	heavy users to transfer high volumes. Here we explain how this		heavy users to transfer high volumes. Here we explain how this
	can also benefit network operators.		can also benefit network operators.
	Today, when loss, delay or averaged utilization exceeds a certain		Today, when loss, delay or averaged utilization exceeds a certain
	threshold, some operators just buy more capacity without		threshold, some operators just buy more capacity without
	skipping to change at page 12, line 14		skipping to change at page 12, line 38
	this case the developer makes the first move, expecting it will		this case the developer makes the first move, expecting it will
	prompt at least some networks to move in response, using the ConEx		prompt at least some networks to move in response, using the ConEx
	information to reward users of the scavenger transport protocol.		information to reward users of the scavenger transport protocol.
	On the host side, we have already shown (Figure 1) how the sender		On the host side, we have already shown (Figure 1) how the sender
	piggy-backs ConEx signals on normal data packets to re-insert		piggy-backs ConEx signals on normal data packets to re-insert
	feedback about packet drops (and/or ECN) back into the IP layer. In		feedback about packet drops (and/or ECN) back into the IP layer. In
	the case of TCP, [I-D.ietf-conex-tcp-modifications] proposes the		the case of TCP, [I-D.ietf-conex-tcp-modifications] proposes the
	required sender modifications. ConEx works with any TCP receiver as		required sender modifications. ConEx works with any TCP receiver as
	long as it uses SACK, which most do. There is a receiver		long as it uses SACK, which most do. There is a receiver
	optimisation [I-D.kuehlewind-conex-accurate-ecn] that improves ConEx		optimisation [I-D.tcpm-accurate-ecn] that improves ConEx precision
	precision when using ECN, but ConEx can still use ECN without it.		when using ECN, but ConEx can still use ECN without it.
	On the network side the provider solely needs to place ConEx		On the network side the provider solely needs to place ConEx
	congestion policers at each ingress to its network, in a similar		congestion policers at each ingress to its network, in a similar
	arrangement to the edge-policed architecture of Diffserv [RFC2475].		arrangement to the edge-policed architecture of Diffserv [RFC2475].
	A sender can choose whether to send ConEx or Not-ConEx packets.		A sender can choose whether to send packets that support ConEx or
	ConEx packets bring information to the policer about congestion		packets that don't. ConEx-enabled packets bring information to the
	expected on the rest of the path beyond the policer. Not-ConEx		policer about congestion expected on the rest of the path beyond the
	packets bring no such information. Therefore the network will tend		policer. Packets that do not support ConEx bring no such
	to rate-limit not-ConEx packets conservatively in order to manage the		information. Therefore the network will tend to conservatively rate-
	unknown risk of congestion. In contrast, a network doesn't normally		limit non-ConEx-enabled packets in order to manage the unknown risk
	need to rate-limit ConEx-enabled packets unless they reveal a		of congestion. In contrast, a network doesn't normally need to rate-
	persistently high contribution to congestion. This natural tendency		limit ConEx-enabled packets unless they reveal a persistently high
	for networks to favour senders that provide ConEx information		contribution to congestion.
	reinforces ConEx deployment.
			This natural tendency for networks to favour senders that provide
			ConEx information reinforces ConEx deployment. Deployment can start
			with one implementation of TCP and proceed to other TCP
			implementations and other transports (e.g. LEDBAT, or RTP over UDP)
			as the need arises.
			Three supporting documents give concrete examples of feasible initial
			deployment scenarios, respectively in a broadband access network
			scenario [I-D.briscoe-conex-initial-deploy], a mobile communications
			network scenario [I-D.ietf-conex-mobile], and a multi-tenant data
			centre scenario [I-D.briscoe-conex-data-centre]. The first two of
			these scenarios are believed to work well without ECN support, but
			others are more difficult without ECN. For instance, the data centre
			scenario works best with ECN, but this is reasonable given some data
			centres already enable ECN.
	The above gives only the most salient aspects of ConEx deployment.		The above gives only the most salient aspects of ConEx deployment.
	For further detail, [I-D.ietf-conex-abstract-mech] describes the		For further detail, [I-D.ietf-conex-abstract-mech] describes the
	incremental deployment features of the ConEx protocol and the		incremental deployment features of the ConEx protocol and the
	components that need to be deployed for ConEx to work. Then		components that need to be deployed for ConEx to work.
	[I-D.briscoe-conex-initial-deploy] gives concrete examples of
	feasible initial deployment scenarios.
	6. Security Considerations		6. Experimental Considerations
			ConEx is initially intended for the experimental track because it
			makes an ambitious change at the interoperability (IP) layer, so no
			amount of careful design can foresee all the potential feature
			interactions with other uses of IP. This section identifies a number
			of question that it would be useful to answer through well-designed
			experiments:
			o Are there any show-stoppers because of the compromises that were
			necessary to fit the ConEx encoding into IP (e.g. initially
			designed solely for IPv6 not IPv4, limited visibility when
			tunnelled [I-D.ietf-conex-destopt])? Would it be preferable to
			make different encoding compromises
			[I-D.ietf-conex-abstract-mech]?
			o Do techniques to distinguish self-congestion from shared
			congestion work [I-D.briscoe-conex-initial-deploy]? Are other
			techniques needed?
			o If ECN deployment remains patchy, are the proposed initial ConEx
			deployment scenarios (Section 5) still useful enough to kick-start
			deployment? (e.g. Is audit effective when based on loss at a
			primary bottleneck? Where rest-of-path congestion can be
			approximated without ECN certain cases, is it good enough?) Are
			there other useful deployment scenarios?
			o In practice, how does traffic management using ConEx compare with
			traditional techniques (Section 3.3)? Does it give the benefits
			claimed in Section 3.1 and Section 3.2?
			o Approaches are proposed for congestion policing of ConEx traffic
			alongside existing management of non-ConEx traffic
			[I-D.ietf-conex-abstract-mech]? Are they strategy-proof against
			users selectively using both? Are there better transition
			strategies?
			o Audit devices have been designed and implemented to assure ConEx
			signal integrity [I-D.ietf-conex-abstract-mech]. Do they achieve
			minimal false hits and false misses in a wide range of traffic
			scenarios? Are there new attacks? Are there better audit designs
			to defend against these?
			ConEx is intended to be a generative technology that might be used
			for unexpected purposes unforeseen by the designers. Therefore this
			list of potential experiments is not intended to be exhaustive.
			7. Security Considerations
	This document does not specify a mechanism, it merely motivates		This document does not specify a mechanism, it merely motivates
	congestion exposure at the IP layer. Therefore security		congestion exposure at the IP layer. Therefore security
	considerations are described in the companion document that gives an		considerations are described in the companion document that gives an
	abstract description of the ConEx protocol and the components that		abstract description of the ConEx protocol and the components that
	would use it [I-D.ietf-conex-abstract-mech].		would use it [I-D.ietf-conex-abstract-mech].
	7. IANA Considerations		8. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Acknowledgments		9. Acknowledgments
	Bob Briscoe was partly funded by Trilogy, a research project (ICT-		Bob Briscoe was partly funded by Trilogy, a research project (ICT-
	216372) supported by the European Community under its Seventh		216372) supported by the European Community under its Seventh
	Framework Programme. The views expressed here are those of the		Framework Programme. The views expressed here are those of the
	author only.		author only.
	The authors would like to thank the many people that have commented		The authors would like to thank the many people that have commented
	on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira		on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira
	Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven		Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven
	Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan,		Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan,
	Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis,		Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis,
	Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis,		Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis,
	Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and		Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and
	Stuart Venters. Please accept our apologies if your name has been		Stuart Venters. Please accept our apologies if your name has been
	missed off this list.		missed off this list.
	8.1. Contributors		9.1. Contributors
	Philip Eardley and Andrea Soppera made helpful text contributions to		Philip Eardley and Andrea Soppera made helpful text contributions to
	this document.		this document.
	The following co-edited this document through most of its life:		The following co-edited this document through most of its life:
	Toby Moncaster		Toby Moncaster
	Computer Laboratory		Computer Laboratory
	William Gates Building		William Gates Building
	JJ Thomson Avenue		JJ Thomson Avenue
	skipping to change at page 13, line 44		skipping to change at page 15, line 29
	UK		UK
	EMail: toby.moncaster@cl.cam.ac.uk		EMail: toby.moncaster@cl.cam.ac.uk
	John Leslie		John Leslie
	JLC.net		JLC.net
	10 Souhegan Street		10 Souhegan Street
	Milford, NH 03055		Milford, NH 03055
	US		US
	EMail: john@jlc.net		EMail: john@jlc.net
	9. Informative References		10. Informative References
	[Bauer09] Bauer, S., Clark, D., and W.		[Bauer09] Bauer, S., Clark, D., and W.
	Lehr, "The Evolution of Internet		Lehr, "The Evolution of Internet
	Congestion", 2009.		Congestion", 2009.
	[CongPol] Briscoe, B., Jacquet, A., and T.		[CongPol] Briscoe, B., Jacquet, A., and T.
	Moncaster, "Policing Freedom to		Moncaster, "Policing Freedom to
	Use the Internet Resource Pool",		Use the Internet Resource Pool",
	RE-Arch 2008 hosted at the 2008		RE-Arch 2008 hosted at the 2008
	CoNEXT conference ,		CoNEXT conference ,
	December 2008.		December 2008.
	[I-D.briscoe-conex-initial-deploy] Briscoe, B., "Initial Congestion		[I-D.briscoe-conex-data-centre] Briscoe, B. and M. Sridharan,
	Exposure (ConEx) Deployment		"Network Performance Isolation in
	Examples", draft-briscoe-conex-		Data Centres using Congestion
	initial-deploy-02 (work in		Exposure (ConEx)", draft-briscoe-
	progress), March 2012.		conex-data-centre-00 (work in
			progress), July 2012.
	[I-D.ietf-conex-abstract-mech] Mathis, M. and B. Briscoe,		[I-D.briscoe-conex-initial-deploy] Briscoe, B., "Initial Congestion
	"Congestion Exposure (ConEx)		Exposure (ConEx) Deployment
	Concepts and Abstract		Examples", draft-briscoe-conex-
	Mechanism", draft-ietf-conex-		initial-deploy-02 (work in
	abstract-mech-04 (work in		progress), March 2012.
	progress), March 2012.
	[I-D.ietf-conex-destopt] Krishnan, S., Kuehlewind, M.,		[I-D.ietf-conex-abstract-mech] Mathis, M. and B. Briscoe,
	and C. Ucendo, "IPv6 Destination		"Congestion Exposure (ConEx)
	Option for Conex",		Concepts and Abstract Mechanism",
	draft-ietf-conex-destopt-02		draft-ietf-conex-abstract-mech-04
	(work in progress), March 2012.		(work in progress), March 2012.
	[I-D.ietf-conex-tcp-modifications] Kuehlewind, M. and R.		[I-D.ietf-conex-destopt] Krishnan, S., Kuehlewind, M., and
	Scheffenegger, "TCP		C. Ucendo, "IPv6 Destination
	modifications for Congestion		Option for Conex",
	Exposure", draft-ietf-conex-tcp-		draft-ietf-conex-destopt-02 (work
	modifications-02 (work in		in progress), March 2012.
	progress), May 2012.
	[I-D.ietf-ledbat-congestion] Hazel, G., Iyengar, J.,		[I-D.ietf-conex-mobile] Kutscher, D., Mir, F., Winter,
	Kuehlewind, M., and S. Shalunov,		R., Krishnan, S., Zhang, Y., and
	"Low Extra Delay Background		C. Bernardos, "Mobile
	Transport (LEDBAT)",		Communication Congestion Exposure
	draft-ietf-ledbat-congestion-09		Scenario",
	(work in progress),		draft-ietf-conex-mobile-00 (work
	October 2011.		in progress), July 2012.
	[I-D.kuehlewind-conex-accurate-ecn] Kuehlewind, M. and R.		[I-D.ietf-conex-tcp-modifications] Kuehlewind, M. and R.
	Scheffenegger, "Accurate ECN		Scheffenegger, "TCP modifications
	Feedback in TCP", draft-		for Congestion Exposure", draft-
	kuehlewind-conex-accurate-ecn-01		ietf-conex-tcp-modifications-02
	(work in progress),		(work in progress), May 2012.
	October 2011.
	[RFC2475] Blake, S., Black, D., Carlson,		[I-D.ietf-ledbat-congestion] Hazel, G., Iyengar, J.,
	M., Davies, E., Wang, Z., and W.		Kuehlewind, M., and S. Shalunov,
	Weiss, "An Architecture for		"Low Extra Delay Background
	Differentiated Services",		Transport (LEDBAT)",
	RFC 2475, December 1998.		draft-ietf-ledbat-congestion-09
			(work in progress), October 2011.
	[RFC3168] Ramakrishnan, K., Floyd, S., and		[I-D.tcpm-accurate-ecn] Kuehlewind, M. and R.
	D. Black, "The Addition of		Scheffenegger, "Accurate ECN
	Explicit Congestion Notification		Feedback Option in TCP", draft-
	(ECN) to IP", RFC 3168,		kuehlewind-tcpm-accurate-ecn-
	September 2001.		option-01 (work in progress),
			July 2012.
	[RFC6057] Bastian, C., Klieber, T.,		[RFC2475] Blake, S., Black, D., Carlson,
	Livingood, J., Mills, J., and R.		M., Davies, E., Wang, Z., and W.
	Woundy, "Comcast's Protocol-		Weiss, "An Architecture for
	Agnostic Congestion Management		Differentiated Services",
	System", RFC 6057,		RFC 2475, December 1998.
	December 2010.
	[TR-059] Anschutz, T., Ed., "DSL Forum		[RFC3168] Ramakrishnan, K., Floyd, S., and
	Technical Report TR-059:		D. Black, "The Addition of
	Requirements for the Support of		Explicit Congestion Notification
	QoS-Enabled IP Services",		(ECN) to IP", RFC 3168,
	September 2003.		September 2001.
	[TR-101] Cohen, A., Ed. and E. Schrum,		[RFC6057] Bastian, C., Klieber, T.,
	Ed., "DSL Forum Technical Report		Livingood, J., Mills, J., and R.
	TR-101: Migration to Ethernet-		Woundy, "Comcast's Protocol-
	Based DSL Aggregation",		Agnostic Congestion Management
	April 2006.		System", RFC 6057, December 2010.
			[TR-059] Anschutz, T., Ed., "DSL Forum
			Technical Report TR-059:
			Requirements for the Support of
			QoS-Enabled IP Services",
			September 2003.
			[TR-101] Cohen, A., Ed. and E. Schrum,
			Ed., "DSL Forum Technical Report
			TR-101: Migration to Ethernet-
			Based DSL Aggregation",
			April 2006.
	Authors' Addresses		Authors' Addresses
	Bob Briscoe (editor)		Bob Briscoe (editor)
	BT		BT
	B54/77, Adastral Park		B54/77, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
End of changes. 44 change blocks.
	157 lines changed or deleted		254 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/