< draft-moncaster-conex-concepts-uses-01.txt		draft-moncaster-conex-concepts-uses-02.txt >
	CONEX B. Briscoe		CONEX B. Briscoe
	Internet-Draft BT		Internet-Draft BT
	Intended status: Informational R. Woundy		Intended status: Informational R. Woundy
	Expires: January 13, 2011 Comcast		Expires: April 28, 2011 Comcast
	T. Moncaster, Ed.		T. Moncaster, Ed.
	Moncaster.com		Moncaster.com
	J. Leslie, Ed.		J. Leslie, Ed.
	JLC.net		JLC.net
	July 12, 2010		October 25, 2010
	ConEx Concepts and Use Cases		ConEx Concepts and Use Cases
	draft-moncaster-conex-concepts-uses-01		draft-moncaster-conex-concepts-uses-02
	Abstract		Abstract
	Internet Service Providers (ISPs) are facing problems where localized		Internet Service Providers (operators) are facing problems where
	congestion prevents full utilization of the path between sender and		localized congestion prevents full utilization of the path between
	receiver at today's "broadband" speeds. ISPs desire to control this		sender and receiver at today's "broadband" speeds. Operators desire
	congestion, which often appears to be caused by a small number of		to control this congestion, which often appears to be caused by a
	users consuming a large amount of bandwidth. Building out more		small number of users consuming a large amount of bandwidth.
	capacity along all of the path to handle this congestion can be		Building out more capacity along all of the path to handle this
	expensive and may not result in improvements for all users so network		congestion can be expensive and may not result in improvements for
	operators have sought other ways to manage congestion. The current		all users so network operators have sought other ways to manage
	mechanisms all suffer from difficulty measuring the congestion (as		congestion. The current mechanisms all suffer from difficulty
	distinguished from the total traffic).		measuring the congestion (as distinguished from the total traffic).
	The ConEx Working Group is designing a mechanism to make congestion		The ConEx Working Group is designing a mechanism to make congestion
	along any path visible at the Internet Layer. This document		along any path visible at the Internet Layer. This document
	describes example cases where this mechanism would be useful.		describes example cases where this mechanism would be useful.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at 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 January 13, 2011.		This Internet-Draft will expire on April 28, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Existing Approaches to Congestion Management . . . . . . . . . 7		3. Congestion Management . . . . . . . . . . . . . . . . . . . . 6
			3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 7
	4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8		4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8
	4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9		4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9
	5. Requirements for ConEx . . . . . . . . . . . . . . . . . . . . 10		5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. ConEx Issues . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. ConEx as a basis for traffic management . . . . . . . . . 10
	6. A Possible Congestion Exposure Mechanism . . . . . . . . . . . 11		5.2. ConEx to incentivise scavenger transports . . . . . . . . 10
	7. ConEx Architectural Elements . . . . . . . . . . . . . . . . . 12		5.3. ConEx to mitigate DDoS . . . . . . . . . . . . . . . . . . 11
	7.1. ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 13		5.4. Accounting for Congestion Volume . . . . . . . . . . . . . 11
	7.1.1. Edge Monitoring . . . . . . . . . . . . . . . . . . . 13		5.5. ConEx as a form of differential QoS . . . . . . . . . . . 12
	7.1.2. Border Monitoring . . . . . . . . . . . . . . . . . . 15		5.6. Partial vs. Full Deployment . . . . . . . . . . . . . . . 12
	7.2. ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 15		6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2.1. Egress Policing . . . . . . . . . . . . . . . . . . . 16		6.1. Congestion as a Commercial Secret . . . . . . . . . . . . 13
	7.2.2. Ingress Policing . . . . . . . . . . . . . . . . . . . 17		6.2. Information Security . . . . . . . . . . . . . . . . . . . 14
	7.2.3. Border Policing . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8.1. ConEx as a basis for traffic management . . . . . . . . . 19		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. ConEx to incentivise scavenger transports . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.3. ConEx to mitigate DDoS . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	8.4. Accounting for Congestion Volume . . . . . . . . . . . . . 20		10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	8.5. ConEx as a form of differential QoS . . . . . . . . . . . 21		Appendix A. ConEx Architectural Elements . . . . . . . . . . . . 20
	8.6. Partial vs. Full Deployment . . . . . . . . . . . . . . . 22		A.1. ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 20
	9. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 23		A.1.1. Edge Monitoring . . . . . . . . . . . . . . . . . . . 21
	9.1. Congestion as a Commercial Secret . . . . . . . . . . . . 23		A.1.2. Border Monitoring . . . . . . . . . . . . . . . . . . 22
	9.2. Information Security . . . . . . . . . . . . . . . . . . . 24		A.2. ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 22
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 24		A.2.1. Egress Policing . . . . . . . . . . . . . . . . . . . 23
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		A.2.2. Ingress Policing . . . . . . . . . . . . . . . . . . . 24
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		A.2.3. Border Policing . . . . . . . . . . . . . . . . . . . 25
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	13.2. Informative References . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	The growth of "always on" broadband connections, coupled with the		The growth of "always on" broadband connections, coupled with the
	steady increase in access speeds [OfCom], have caused unforeseen		steady increase in access speeds [OfCom], have caused unforeseen
	problems for network operators and users alike. Users are		problems for network operators and users alike. Users are
	increasingly seeing congestion at peak times and changes in usage		increasingly seeing congestion at peak times and changes in usage
	patterns (with the growth of real-time streaming) simply serve to		patterns (with the growth of real-time streaming) simply serve to
	exacerbate this. Operators want all their users to see a good		exacerbate this. Operators want all their users to see a good
	service but are unable to see where congestion problems originate.		service but are unable to see where congestion problems originate.
	But congestion results from sharing network capacity with others, not		But congestion results from sharing network capacity with others, not
	merely from using it. In general, today's "DSL" and cable-internet		merely from using it. In general, today's "DSL" and cable-internet
	users cannot "cause" congestion in the absence of competing traffic.		users cannot "cause" congestion in the absence of competing traffic.
	(Wireless ISPs and cellular internet have different tradeoffs which		(Wireless operators and cellular internet have different tradeoffs
	we will not discuss here.)		which we will not discuss here.)
	Congestion generally results from the interaction of traffic from an		Congestion generally results from the interaction of traffic from one
	ISPs own subscribers with traffic from other users. The tools		network operator's users with traffic from other users. The tools
	currently available don't allow an operator to identify which traffic		currently available don't allow an operator to identify which traffic
	contributes most to the congestion and so they are powerless to		contributes most to the congestion and so they are powerless to
	properly control it.		properly control it.
	While building out more capacity to handle increased traffic is		While building out more capacity to handle increased traffic is
	always good, the expense and lead-time can be prohibitive, especially		always good, the expense and lead-time can be prohibitive, especially
	for network operators that charge flat-rate feeds to subscribers and		for network operators that charge flat-rate feeds to subscribers and
	are thus unable to charge heavier users more for causing more		are thus unable to charge heavier users more for causing more
	congestion [BB-incentive]. For an operator facing congestion caused		congestion [BB-incentive]. For an operator facing congestion caused
	by other operators' networks, building out its own capacity is		by other operators' networks, building out its own capacity is
	unlikely to solve the congestion problem. Operators are thus facing		unlikely to solve the congestion problem. Operators are thus facing
	increased pressure to find effective solutions to dealing with the		increased pressure to find effective solutions to dealing with the
	increasing bandwidth demands of all users.		increasing bandwidth demands of all users.
	The growth of "scavenger" behaviour (e.g. [LEDBAT]) helps to reduce		The growth of "scavenger" behaviour (e.g. [LEDBAT]) helps to reduce
	congestion, but can actually make the ISPs problem less tractable.		congestion, but can actually make the problem less tractable. These
	These users are trying to make good use of the capacity of the path		users are trying to make good use of the capacity of the path while
	while minimising their own costs. Thus, users of such services may		minimising their own costs. Thus, users of such services may show
	show very heavy total traffic up until the moment congestion is		very heavy total traffic up until the moment congestion is detected
	detected (at the Transport Layer), but then will immediately back		(at the Transport Layer), but then will immediately back off.
	off. ISP monitoring (at the Internet Layer) cannot detect this		Monitoring (at the Internet Layer) cannot detect this congestion
	congestion avoidance if the congestion in question is in a different		avoidance if the congestion in question is in a different domain
	domain further along the path; and must treat such users as		further along the path; and must treat such users as congestion-
	congestion-causing users.		causing users.
	The ConEx working group proposes that Internet Protocol (IP) packets		The ConEx working group proposes that Internet Protocol (IP) packets
	have two "congestion" fields. The exact protocol details of these		will carry additional ConEx information. The exact protocol details
	fields are for another document, but we expect them to provide		are not described in this document, but the ConEx information will be
	measures of "congestion so far" and "congestion still expected".		sufficient to allow any node in the network to see how much
			congestion is attributable to a given traffic flow. See
			[ConEx-Abstract-Mech] for further details.
	Changes from previous drafts (to be removed by the RFC Editor):		Changes from previous drafts (to be removed by the RFC Editor):
			From -01 to -02:
			Updated document to take account of the new Abstract Mechanism
			draft [ConEx-Abstract-Mech]. PLEASE NOTE: As that draft develops,
			it is envisaged that more material will be able to be removed from
			this document, leaving this document free to concentrate on actual
			use cases for ConEx.
			Updated the definitions section.
			Removed sections on Requirements and Mechanism.
			Moved section on ConEx Architectural Elements to appendix.
			Minor changes throughout.
	From -00 to -01:		From -00 to -01:
	Changed end of Abstract to better reflect new title		Changed end of Abstract to better reflect new title
	Created new section describing the architectural elements of ConEx		Created new section describing the architectural elements of ConEx
	Section 7. Added Edge Monitors and Border Monitors (other		Appendix A. Added Edge Monitors and Border Monitors (other
	elements are Ingress, Egress and Border Policers).		elements are Ingress, Egress and Border Policers).
	Extensive re-write of Section 8 partly in response to suggestions		Extensive re-write of Section 5 partly in response to suggestions
	from Dirk Kutscher		from Dirk Kutscher
	Improved layout of Section 2 and added definitions of Whole Path		Improved layout of Section 2 and added definitions of Whole Path
	Congestion, ConEx-Enabled and ECN-Enabled. Re-wrote definition of		Congestion, ConEx-Enabled and ECN-Enabled. Re-wrote definition of
	Congestion Volume. Renamed Ingress and Egress Router to Ingress		Congestion Volume. Renamed Ingress and Egress Router to Ingress
	and Egress Node as these nodes may not actually be routers.		and Egress Node as these nodes may not actually be routers.
	Improved document structure. Merged sections on Exposing		Improved document structure. Merged sections on Exposing
	Congestion and ECN.		Congestion and ECN.
	Added new section on ConEx requirements Section 5 with a ConEx		Added new section on ConEx requirements with a ConEx Issues
	Issues subsection Section 5.1. Text for these came from the start		subsection. Text for these came from the start of the old ConEx
	of the old ConEx Use Cases section		Use Cases section
	Added a sub-section on Partial vs Full Deployment Section 8.6		Added a sub-section on Partial vs Full Deployment Section 5.6
	Added a discussion on ConEx as a Business Secret Section 9.1		Added a discussion on ConEx as a Business Secret Section 6.1
	From draft-conex-mechanism-00 to		From draft-conex-mechanism-00 to
	draft-moncaster-conex-concepts-uses-00:		draft-moncaster-conex-concepts-uses-00:
	Changed filename to draft-moncaster-conex-concepts-uses.		Changed filename to draft-moncaster-conex-concepts-uses.
	Changed title to ConEx Concepts and Use Cases.		Changed title to ConEx Concepts and Use Cases.
	Chose uniform capitalisation of ConEx.		Chose uniform capitalisation of ConEx.
	Moved definition of Congestion Volume to list of definitions.		Moved definition of Congestion Volume to list of definitions.
	Clarified Section 6. Changed section title.		Clarified mechanism section. Changed section title.
	Modified text relating to conex-aware policing and policers (which		Modified text relating to conex-aware policing and policers (which
	are NOT defined terms).		are NOT defined terms).
	Re-worded bullet on distinguishing ConEx and non-ConEx traffic in		Re-worded bullet on distinguishing ConEx and non-ConEx traffic in
	Section 8.		Section 5.
	2. Definitions		2. Definitions
	ConEx expects to build on Explicit Congestion Notification (ECN)		In this section we define a number of terms that are used throughout
	[RFC3168] where it is available. Hence we use the term "congestion"		the document. The key definition is that of congestion, which has a
	in a manner consistent with ECN, namely that congestion occurs before		number of meanings depending on context. The definition we use in
	any packet is dropped. In this section we define a number of terms		this document is based on the definition in [Padhye] where congestion
	that are used throughout the document.		is viewed as a probability that a packet will be dropped. This list
			of definitions is supplementary to that in [ConEx-Abstract-Mech].
	Congestion: Congestion is a measure of the probability that a given		Congestion: Congestion is a measure of the probability that a packet
	packet will be ECN-marked or dropped as it traverses the network.		will be marked or dropped as it traverses a queue.
	At any given router it is a function of the queue state at that
	router. Congestion is added in a combinatorial manner, that is,
	routers ignore the congestion a packet has already seen when they
	decide whether to mark it or not.
	Congestion Volume: Congestion volume is defined as the congestion a		flow: a series of packets from a single sender to a single receiver
	packet experiences, multiplied by the size of that packet. It can		that are treated by that sender as belonging to a single stream
	be expressed as the volume of bytes that have been ECN-marked or		for the purposes of congestion control. NB in general this is not
	dropped. By extension, the Congestion Rate would be the		the same as the aggregate of all traffic between the sender and
	transmission rate multiplied by the congestion level.		receiver.
	Upstream Congestion: The congestion that has already been		Congestion-rate: For any granularity of traffic (packet, flow,
	experienced by a packet as it travels along its path. In other		aggregate, etc.), the instantaneous rate of traffic discarded or
	words at any point on the path, it is the congestion between the		marked due to congestion. Conceptually, the instantaneous bit-
	source of the packet and that point.		rate of the traffic multiplied by the instantaneous congestion it
			is experiencing.
	Downstream Congestion: The congestion that a packet still has to		Congestion-volume: For any granularity of traffic (packet, flow,
	experience on the remainder of its path. In other words at any		aggregate, etc.), the volume of bytes dropped or marked in a given
	point it is the congestion still to be experienced as the packet		period of time. Conceptually, congestion-rate multipled by time.
	travels between that point and its destination.
	Whole Path Congestion: The total congestion that a packet		Upstream Congestion: the accumulated level of congestion experienced
	experiences between the ingress to the network and the egress.		by a traffic flow thus far along its path. In other words, at any
			point the Upstream Congestion is the accmulated level of
			congestion the traffic flow has experienced as it travels from the
			sender to that point. At the receiver this is equivalent to the
			end-to-end congestion level that (usually) is reported back to the
			sender.
	Network Ingress: The Network Ingress is the first node a packet		Downstream Congestion: the level of congestion a flow of traffic is
	traverses that is outside the source's own network. In a domestic		expected to experience on the remainder of its path. In other
	network that will be the first node downstream from the home		words, at any point the Downstream Congestion is the level of
	access equipment. In a business network it may be the first		congestion the traffic flow is yet to experience as it travels
	router downstream of the firewall.		from that point to the receiver.
	Network Egress: The Network Egress is the last node a packet		Ingress: the first node a packet traverses that is outside the
	traverses before it enters the destination network.		source's own network. In a domestic network that will be the
			first node downstream from the home access equipment. In an
			enterprise network this is the provider edge router.
	ConEx-Enabled: Any piece of equipment (end-system, router, tunnel		Egress: the last node a packet traverses before reaching the
	end-point, firewall, policer, etc) that fully implements the ConEx		receiver's network.
	protocol.
	ECN-enabled: Any router that fully enables Explicit Congestion		ConEx-enabled: Any piece of equipment (end-system, router, tunnel
	Notification (ECN) as defined in [RFC3168] and any relevant		end-point, firewall, policer, etc) that complies with the core
	updates to that standard.		ConEx protocol, which is to be defined by the ConEx working group.
			By extension a ConEx-enabled network is a network whose edge nodes
			are all ConEx-enabled.
	3. Existing Approaches to Congestion Management		3. Congestion Management
	A number of ISPs already use some form of traffic management.		Since 1988 the Internet architecture has made congestion management
	Generally this is an attempt to control the peak-time congestion		the responsibility of the end-systems. The network signals
	within their network and to better apportion shared network resources		congestion to the receiver, the receiver feeds this back to the
	between customers. Even ISPs that don't impose such traffic		sender and the sender is expected to try and reduce the traffic it
	management (such as those in Germany) may have caps on the capacity		sends.
	they allow for Best Effort traffic in their backhaul.
	These attempts to control congestion have usually focused on the peak		Any network that is persistently highly congested is inefficient.
	hours and aim to rate limit heavy users during that time. For		However the total absence of congestion is equally bad as it means
	example, users who have consumed a certain amount of bandwidth during		there is spare capacity in the network that hasn't been used. The
	the last 24 hours may be elected to have their traffic shaped once		long-standing aim of congestion control has been to find the point
	the total traffic reaches a given level in certain nodes within the		where these two things are in balance.
	operator's network.
			Over recent years, some network operators have come to the view that
			end-system congestion management is insufficient. Because of the
			heuristics used by TCP, a relatively small number of end-machines can
			get a disproportionately high share of network resources. They have
			sought to "correct" this perceived problem by using middleboxes that
			try and reduce traffic that is causing congestion or by artificially
			starving some traffic classes to create stronger congestion signals.
			3.1. Existing Approaches
	The authors have chosen not to exhaustively list current approaches		The authors have chosen not to exhaustively list current approaches
	to congestion management. Broadly these approaches can be divided		to congestion management. Broadly these approaches can be divided
	into those that happen at Layer 3 of the OSI model and those that use		into those that happen at Layer 3 of the OSI model and those that use
	information gathered from higher layers. In general these approaches		information gathered from higher layers. In general these approaches
	attempt to find a "proxy" measure for congestion. Layer 3 approaches		attempt to find a "proxy" measure for congestion. Layer 3 approaches
	include:		include:
	o Volume accounting -- the overall volume of traffic a given user or		o Volume accounting -- the overall volume of traffic a given user or
	network sends is measured. Users may be subject to an absolute		network sends is measured. Users may be subject to an absolute
	skipping to change at page 8, line 7		skipping to change at page 7, line 33
	for inter-network billing.		for inter-network billing.
	Higher layer approaches include:		Higher layer approaches include:
	o Bottleneck rate policing -- bottleneck flow rate policers aim to		o Bottleneck rate policing -- bottleneck flow rate policers aim to
	share the available capacity at a given bottleneck between all		share the available capacity at a given bottleneck between all
	concurrent users.		concurrent users.
	o DPI and application rate policing -- deep packet inspection and		o DPI and application rate policing -- deep packet inspection and
	other techniques can be used to determine what application a given		other techniques can be used to determine what application a given
	traffic flow is associated with. ISPs may then use this		traffic flow is associated with. Operators may then use this
	information to rate-limit or otherwise sanction certain		information to rate-limit or otherwise sanction certain
	applications at peak hours.		applications at peak hours.
	All of these current approaches suffer from some general limitations.		All of these current approaches suffer from some general limitations.
	First, they introduce performance uncertainty. Flat-rate pricing		First, they introduce performance uncertainty. Flat-rate pricing
	plans are popular because users appreciate the certainty of having		plans are popular because users appreciate the certainty of having
	their monthly bill amount remain the same for each billing period,		their monthly bill amount remain the same for each billing period,
	allowing them to plan their costs accordingly. But while flat-rate		allowing them to plan their costs accordingly. But while flat-rate
	pricing avoids billing uncertainty, it creates performance		pricing avoids billing uncertainty, it creates performance
	uncertainty: users cannot know whether the performance of their		uncertainty: users cannot know whether the performance of their
	skipping to change at page 9, line 5		skipping to change at page 8, line 32
	and conversely that their traffic impacts you. So if there is no		and conversely that their traffic impacts you. So if there is no
	congestion there need not be any restriction on the amount a user can		congestion there need not be any restriction on the amount a user can
	send; restrictions only need to apply when others are sending traffic		send; restrictions only need to apply when others are sending traffic
	such that there is congestion.		such that there is congestion.
	For example, an application intending to transfer large amounts of		For example, an application intending to transfer large amounts of
	data could use a congestion control mechanism like [LEDBAT] to reduce		data could use a congestion control mechanism like [LEDBAT] to reduce
	its transmission rate before any competing TCP flows do, by detecting		its transmission rate before any competing TCP flows do, by detecting
	an increase in end-to-end delay (as a measure of impending		an increase in end-to-end delay (as a measure of impending
	congestion). However such techniques rely on voluntary, altruistic		congestion). However such techniques rely on voluntary, altruistic
	action by end users and their application providers. ISPs can		action by end users and their application providers. Operators can
	neither enforce their use nor avoid penalizing them for congestion		neither enforce their use nor avoid penalizing them for congestion
	they avoid.		they avoid.
	The Internet was designed so that end-hosts detect and control		The Internet was designed so that end-hosts detect and control
	congestion. We argue that congestion needs to be visible to network		congestion. We argue that congestion needs to be visible to network
	nodes as well, not just to the end hosts. More specifically, a		nodes as well, not just to the end hosts. More specifically, a
	network needs to be able to measure how much congestion any		network needs to be able to measure how much congestion any
	particular traffic expects to cause between the monitoring point in		particular traffic expects to cause between the monitoring point in
	the network and the destination ("rest-of-path congestion"). This		the network and the destination ("rest-of-path congestion"). This
	would be a new capability. Today a network can use Explicit		would be a new capability. Today a network can use Explicit
	skipping to change at page 9, line 31		skipping to change at page 9, line 10
	uses of traditional TCP and UDP applications.		uses of traditional TCP and UDP applications.
	So we propose a new approach which we call Congestion Exposure. We		So we propose a new approach which we call Congestion Exposure. We
	propose that congestion information should be made visible at the IP		propose that congestion information should be made visible at the IP
	layer, so that any network node can measure the contribution to		layer, so that any network node can measure the contribution to
	congestion of an aggregate of traffic as easily as straight volume		congestion of an aggregate of traffic as easily as straight volume
	can be measured today. Once the information is exposed in this way,		can be measured today. Once the information is exposed in this way,
	it is then possible to use it to measure the true impact of any		it is then possible to use it to measure the true impact of any
	traffic on the network.		traffic on the network.
	In general, congestion exposure gives ISPs a principled way to hold		In general, congestion exposure gives operators a principled way to
	their customers accountable for the impact on others of their network		hold their customers accountable for the impact on others of their
	usage and reward them for choosing congestion-sensitive applications.		network usage and reward them for choosing congestion-sensitive
			applications.
	4.1. ECN - a Step in the Right Direction		4.1. ECN - a Step in the Right Direction
	Explicit Congestion Notification [RFC3168] allows routers to		Explicit Congestion Notification [RFC3168] allows routers to
	explicitly tell end-hosts that they are approaching the point of		explicitly tell end-hosts that they are approaching the point of
	congestion. ECN builds on Active Queue Mechanisms such as random		congestion. ECN builds on Active Queue Mechanisms such as random
	early discard (RED) [RFC2309] by allowing the router to mark a packet		early discard (RED) [RFC2309] by allowing the router to mark a packet
	with a Congestion Experienced (CE) codepoint, rather than dropping		with a Congestion Experienced (CE) codepoint, rather than dropping
	it. The probability of a packet being marked increases with the		it. The probability of a packet being marked increases with the
	length of the queue and thus the rate of CE marks is a guide to the		length of the queue and thus the rate of CE marks is a guide to the
	skipping to change at page 10, line 16		skipping to change at page 9, line 44
	receiver can only indirectly influence incoming congestion, by		receiver can only indirectly influence incoming congestion, by
	politely asking the sender to control it. A receiver cannot make a		politely asking the sender to control it. A receiver cannot make a
	sender install an adaptive codec, or install LEDBAT instead of TCP		sender install an adaptive codec, or install LEDBAT instead of TCP
	congestion-control. And a receiver cannot cause an attacker to stop		congestion-control. And a receiver cannot cause an attacker to stop
	flooding it with traffic.		flooding it with traffic.
	What is needed is knowledge of the downstream congestion level, for		What is needed is knowledge of the downstream congestion level, for
	which you need additional information that is still concealed from		which you need additional information that is still concealed from
	the network.		the network.
	5. Requirements for ConEx		5. ConEx Use Cases
	This document is intended to highlight some of the possible uses for
	a congestion exposure mechanism such as the one being proposed by the
	ConEx working group. The actual ConEx mechanism will be defined in
	another document.
	In this section we set out some basic requirements for any ConEx
	mechanism. We are not saying this is an exhaustive list of those
	requirements. This list is simply to allow readers to make a
	realistic assessment of the feasibility and utility of the use cases
	set out in Section 8.
	The three key requirements are
	1. Timeliness of information. The limitations of current network
	design gives a minimum delay of 1 round trip time (RTT) for
	congestion information to circulate the network. It is important
	that the conex mechanism operates on similar timescales to ensure
	the congestion information it exposes is as up to date as
	possible. Stale congestion information is useless since
	congestion levels can fluctuate widely over relatively short
	timescales.
	2. Accuracy of information. In order to be useful, congestion
	information has to be sufficiently accurate for the purposes for
	which it is to be used. In general the main purposes are
	monitoring congestion and controlling congestion. As a minimum,
	conex should equal the accuracy required for current TCP
	implementations. A unary signal such as that provided by ECN is
	sufficient though a more precise signal may be desirable.
	3. Visibility of information. In order to be useful conex
	information should be visible at every point in the network. In
	today's networks that means it must be visible at the IP layer.
	5.1. ConEx Issues
	If ConEx information is to be useful, it has to be accurate (within
	the limitations of the available feedback). This raises three issues
	that need to be addressed:
	Distinguishing ConEx traffic from non-ConEx traffic: An ISP may
	reasonably choose to do nothing different with ConEx traffic.
	Alternatively they might want to incentivise it in order to give
	it marginally better service.
	Over-declaring congestion: ConEx relies on the sender accurately
	declaring the congestion they expect to see. During TCP slow-
	start a sender is unable to predict the level of congestion they
	will experience and it is advisable to declare that expect to see
	some congestion on the first packet. However it is important to
	be cautious when over-declaring congestion lest you erode trust in
	the system. We do not initially propose any mechanism to deal
	with this issue.
	Under-declaring congestion: ConEx requires the sender to set the
	downstream congestion field in each packet to their best estimate
	of what they expect the whole path congestion to be. If this
	expected congestion level is to be used for traffic management
	(see use cases) then it benefits the user to under-declare.
	Mechanisms are needed to prevent this happening.
	There are three approaches that may work (individually or in
	combination):
	* An ingress router can monitor a user's feedback to see what
	their reported congestion level actually is.
	* If the congestion field carries the actual congestion value
	then a ConEx-Enabled Policer could potentially drop any packet
	with a downstream-congestion value of zero or less.
	* An egress router can actively monitor some or all flows to
	check that they are complying with the requirement that the
	downstream congestion value should be zero or (slightly
	positive) when it reaches the egress.
	6. A Possible Congestion Exposure Mechanism
	One possible protocol is based on a concept known as re-feedback
	[Re-Feedback], and builds on existing active queue management
	techniques like RED [RFC2309] and ECN [RFC3168] that network elements
	can already use to measure and expose congestion. The protocol is
	described in more detail in [Fairer-faster], but we summarise it
	below.
	In this protocol packets have two Congestion fields in their IP
	header:
	o An Upstream Congestion field to record the congestion already
	experienced along the path. Routers indicate their current
	congestion level by updating this field in every packet. As the
	packet traverses the network it builds up a record of the overall
	congestion along its path in this field. This data is sent back
	to the sender who uses it to determine its transmission rate.
	This can be achieved by using the existing ECN field [RFC3168].
	o A whole-path congestion field that uses re-feedback to record the
	total congestion expected along the path. The sender does this by
	re-inserting the current Congestion level for the path into this
	field for every packet it transmits.
	Thus at any node downstream of the sender you can see the Upstream
	Congestion for the packet and the whole path congestion (with a time
	lag of one round-trip-time (RTT)) and can calculate the Downstream
	Congestion by subtracting the Upstream from the Whole Path
	Congestion.
	So congestion exposure can be achieved by coupling congestion
	notification from routers with the re-insertion of this information
	by the sender. This establishes information symmetry between users
	and network providers.
	7. ConEx Architectural Elements
	ConEx is a simple concept that has revolutionary implications. It is
	that rare thing -- a truly disruptive technology, and as such it is
	hard to imagine the variety of uses it may be put to. Before even
	thinking what it might be used for we need to address the issue of
	how it can be used. This section describes four architectural
	elements that can be placed in the network and which utilise ConEx
	information to monitor or control traffic flows.
	In the following we are assuming the most abstract version of the
	ConEx mechanism, namely that every packet carries two congestion
	fields, one for upstream congestion and one for downstream.
	Section 6 outlines one possible approach for this.
	7.1. ConEx Monitoring
	One of the most useful things ConEx provides is the ability to
	monitor (and control) the amount of congestion entering or leaving a
	network. With ConEx, each packet carries sufficient information to
	work out the Upstream, Downstream and Total Congestion Volume that
	packet is responsible for. This allows the overall Congestion Volume
	to be calculated at any point in the network. In effect this gives a
	measure of how much excess traffic has been sent that was above the
	instantaneous transmission capacity of the network. A 1 Gbps router
	that is 0.1% congested implies that there is 1 Mbps of excess traffic
	at that point in time.
	The figure below shows 2 conceptual pieces of network equipment that
	utilise ConEx information in order to monitor the flow of congestion
	through the network. The Border Monitor sits at the border between
	two networks, while the Edge Monitor sits at the ingress or egress to
	the Internetwork.
	,---. ,---.
	,-----. / \ ,------. / \ ,------. ,-----.
	| Src |--( Net A )-| B.M. |-( Net B )--| E.M. |--| Dst |
	'-----` \ / '------` \ / '------` '-----`
	'---` ^ '---` ^
	Border Monitor Edge Monitor
	NB, the Edge Monitor could also be at the Src end of the network
	Figure 1: Ingress, egress and border monitors
	Note: In the tables below ECN-enabled and ConEx-Enabled are as
	defined in Section 2.
	7.1.1. Edge Monitoring
	+------------+----------------+----------------+--------------------+
	| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
	| Element | | | |
	+------------+----------------+----------------+--------------------+
	| Sender | Yes, if ECN is | Yes, must be | Must be receiving |
	| | used as basis | sending ConEx | congestion |
	| | for congestion | information | feedback |
	| | signal | | |
	| Sender's | ECN would be | Should | NB, it doesn't |
	| Network | beneficial | understand | have to be fully |
	| | | ConEx markings | ConEx-Enabled |
	| Core | ECN would be | Needn't | ConEx markings |
	| Network | beneficial | understand | must get through |
	| | | ConEx | the network |
	| Receiver's | ECN would be | Should | Deosn't have to be |
	| Network | beneficial | understand | fully |
	| | | ConEx markings | ConEx-Enabled |
	| Receiver | Only needed if | Should | Has to feedback |
	| | network is | understand | the congestion it |
	| | ECN-Enabled | ConEx | sees (either ECN |
	| | | | or drop) |
	+------------+----------------+----------------+--------------------+
	Table 1: Requirements for Edge Monitoring
	Edge Monitors are ideally positioned to verify the accuracy of ConEx
	markings. If there is an imbalance between the expected congestion
	and the actual congestion then this will show up at the egress. Edge
	Monitors can also be used by an operator to measure the service a
	given customer is receiving by monitoring how much congestion their
	traffic is causing. This may allow them to take pre-emptive action
	if they detect any anomalies.
	7.1.2. Border Monitoring
	+------------+-----------------+-----------------+------------------+
	| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
	| Element | | | |
	+------------+-----------------+-----------------+------------------+
	| Sender | Must be | Yes, must be | Must receive |
	| | ECN-enabled if | sending ConEx | accurate |
	| | any of the | information | congestion |
	| | network is | | feedback |
	| Sender's | ECN should be | Should | Ideally would be |
	| Network | enabled | understand | ConEx-Enabled |
	| | | ConEx markings | |
	| Core | ECN should be | Should | Ideally would be |
	| Network | enabled | understand | ConEx-Enabled |
	| | | ConEx markings | |
	| Receiver's | ECN should be | Should | Ideally would be |
	| Network | enabled | understand | ConEx-Enabled |
	| | | ConEx markings | |
	| Receiver | Must be | Must be ConEx | Receiver has to |
	| | ECN-enabled if | enabled | feedback the |
	| | any of the | | congestion it |
	| | network is | | sees |
	+------------+-----------------+-----------------+------------------+
	Table 2: Requirements for Border Monitoring
	At any border between 2 networks, the operator can see the total
	Congestion Volume that is being forwarded into its network by the
	neighbouring network. A Border Monitor is able to measure the bulk
	congestion markings and establish the flow of Congestion Volume each
	way across the border. This could be used as the basis for inter-
	network settlements. It also provides information to target upgrades
	to where they are actually needed and might help to identify network
	problems. Border Monitoring really needs the majority of the network
	to be ECN-Enabled in order to provide the necessary Upstream
	Congestion signal. Clearly the greatest benefit comes when there is
	also ConEx deployment in the nnetwork. However, as long as the
	sender is sending accurate ConEx information and the majority of the
	network is ECN-enabled, border monitoring will work.
	7.2. ConEx Policing
	As shown above, ConEx gives an easy method of measuring Congestion
	Volume. This information can be used as a control metric for making
	traffic management decisions (such as deciding which traffic to
	prioritise) or to identify and block sources of persistent and
	damaging congestion. Simple policer mechanisms, such as those
	described in [Policing-freedom] and [re-ecn-motive], can control the
	overall congestion volume traversing a network. Ingress Policing
	typically happens at the Ingress Node, Egress Policing typically
	happens at the Egress Node and Border Policing can happen at any
	border between two networks. The current charter concentrates on use
	cases employing Egress Policers.
	,---. ,---.
	+-----+ +------+ / \ +------+ / \ +------+ +-----+
	| Src |--| I.P. |--( Net A )-| B.P. |-( Net B )--| E.P. |--| Dst |
	+-----+ +------+ \ / +------+ \ / +------+ +-----+
	^ '---` ^ '---` ^
	Ingress Policer Border Policer Egress Policer
	Figure 2: Ingress, egress and border policers
	7.2.1. Egress Policing
	+------------+--------------+----------------+----------------------+
	| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
	| Element | | | |
	+------------+--------------+----------------+----------------------+
	| Sender | The sender | Must be | Must be receiving |
	| | should be | ConEx-Enabled | congestion feedback |
	| | ECN-enabled | | |
	| | if any of | | |
	| | the network | | |
	| | is | | |
	| Sender's | ECN is | ConEx is | ConEx would enable |
	| Network | optional but | optional | them to do Ingress |
	| | beneficial | | Policing (see later) |
	| Core | ECN is | Not needed | ConEx marks must |
	| Network | optional but | | survive crossing the |
	| | beneficial | | network |
	| Receiver's | ECN is | Must fully | Each receiver needs |
	| Network | optional but | understand | an Egress Policer |
	| | beneficial | ConEx | |
	| Receiver | Should be | Should | Must feedback the |
	| | ECN-enabled | understand | congestion it sees. |
	| | if any of | ConEx | ConEx may have a |
	| | the network | | compatibility mode |
	| | is | | if the receiver is |
	| | | | not ConEx-Enabled |
	+------------+--------------+----------------+----------------------+
	Table 3: Egress Policer Requirements
	An Egress Policer allows an ISP to monitor the Congestion Volume a
	user's traffic has caused throughout the network, and then use this
	to prioritise the traffic accordingly. By itself, such a policer
	cannot tell how much of this congestion was caused in the ISP's own
	network, but it will identify which users are the "heaviest" in terms
	of the congestion they have caused. Assuming the ConEx information
	is accurate then the Egress Policer will be able to see how much
	congestion exists between it and the final destination (what you
	might call "last-mile" congestion). There are a number of strategies
	that could be used to determine how traffic is treated by an Egress
	Policer. Obviously traffic that is not ConEx enabled needs to
	receive some form of "default" treatment. Traffic that is ConEx
	enabled may have under-declared congestion in which case it would be
	reasonable to give it a low scheduling priority. Traffic that
	appears to be over-declaring congestion may be simply a result of
	especially high "last-mile" congestion, in which case the ISP may
	want to upgrade the access capacity, or may want to try and reduce
	the volume of traffic. Where the ISP knows what the "last-mile"
	congestion is (for instance if it is able to measure several users
	sharing that same capacity) then any remaining over-declared
	congestion might be seen as a signal that the sender wishes to
	prioritise this traffic.
	7.2.2. Ingress Policing
	+------------+--------------+----------------+----------------------+
	| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
	| Element | | | |
	+------------+--------------+----------------+----------------------+
	| Sender | Should be | Must be | Must be receiving |
	| | ECN-enabled | ConEx-enabled | congestion feedback |
	| Sender's | ECN is | Must | |
	| Network | optional but | understand | |
	| | beneficial | ConEx | |
	| Core | ECN is | Needn't | ConEx markings must |
	| Network | optional but | understand | survive crossing the |
	| | beneficial | ConEx | network |
	| Receiver's | ECN is | Needn't | ConEx markings must |
	| Network | optional but | understand | survive crossing the |
	| | beneficial | ConEx | network |
	| Receiver | Should be | Should be | Must feedback the |
	| | ECN-enabled | ConEx-Enabled | congestion it sees. |
	| | if any of | | ConEx may have a |
	| | the network | | compatibility mode |
	| | is | | if the receiver is |
	| | | | not ConEx-Enabled |
	+------------+--------------+----------------+----------------------+
	Table 4: Ingress Policer Requirements
	At the Network Ingress, an ISP can police the amount of congestion a
	user is causing by limiting the congestion volume they send into the
	network. One system that achieves this is described in
	[Policing-freedom]. This uses a modified token bucket to limit the
	congestion rate being sent rather than the overall rate. Such
	ingress policing is relatively simple as it requires no flow state.
	Furthermore, unlike many mechanisms, it treats all a user's packets
	equally.
	7.2.3. Border Policing
	+------------+--------------+----------------+----------------------+
	| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
	| Element | | | |
	+------------+--------------+----------------+----------------------+
	| Sender | ECN should | Must be | Must receive |
	| | be enabled | ConEx-enabled | accurate congestion |
	| | | | feedback |
	| Sender's | ECN is | Must be | |
	| Network | optional but | ConEx-enabled | |
	| | beneficial | | |
	| Core | ECN is | Should be | Must be |
	| Network | optional but | ConEx-Enabled | ConEx-Enabled if it |
	| | beneficial | | is doing the |
	| | | | policing. At a |
	| | | | minimum must pass |
	| | | | ConEx markings |
	| | | | unaltered |
	| Receiver's | ECN is | Should be | At a minimum must |
	| Network | optional but | ConEx-Enabled | pass ConEx markings |
	| | beneficial | | unaltered |
	| Receiver | Should be | Should be | Must feedback the |
	| | ECN-Enabled | ConEx-Enabled | congestion it sees. |
	| | if any of | | ConEx may have a |
	| | the network | | compatibility mode |
	| | is | | if the receiver is |
	| | | | not ConEx-Enabled |
	+------------+--------------+----------------+----------------------+
	Table 5: Border Policer Requirements
	A Border Policer will allow an operator to directly control the
	congestion that it allows into its network. Normally we would expect
	the controls to be related to some form of contractual obligation
	between the two parties. However, such Policing could also be used
	to mitigate some effects of Distributed Denial of Service (see
	Section 8.3). In effect a Border Policer encourages the network
	upstream to take responsibility for congestion it will cause
	downstream and could be seen as an incentive for that network to
	participate in ConEx (e.g. install Ingress Policers)
	8. ConEx Use Cases
	This section sets out some of the use cases for ConEx. These use		This section sets out some of the use cases for ConEx. These use
	cases rely on some of the conceptual network elements (policers and		cases rely on some of the conceptual elements described in
	monitors) described in Section 7 above. The authors don't claim this		[ConEx-Abstract-Mech] and Appendix A. The authors don't claim this
	is an exhaustive list of use cases, nor that these have equal merit.		is an exhaustive list of use cases, nor that these have equal merit.
	In most cases ConEx is not the only solution to achieve these. But		In most cases ConEx is not the only solution to achieve these. But
	these use cases represent a consensus among people that have been		these use cases represent a consensus among people that have been
	working on this approach for some years.		working on this approach for some years.
	8.1. ConEx as a basis for traffic management		5.1. ConEx as a basis for traffic management
	Currently many ISPs impose some form of traffic management at peak		Currently many operators impose some form of traffic management at
	hours. This is a simple economic necessity -- the only reason the		peak hours. This is a simple economic necessity -- the only reason
	Internet works as a commercial concern is that ISPs are able to rely		the Internet works as a commercial concern is that operators are able
	on statistical multiplexing to share their expensive core network		to rely on statistical multiplexing to share their expensive core
	between large numbers of customers. In order to ensure all customers		network between large numbers of customers. In order to ensure all
	get some chance to access the network, the "heaviest" customers will		customers get some chance to access the network, the "heaviest"
	be subjected to some form of traffic management at peak times		customers will be subjected to some form of traffic management at
	(typically a rate cap for certain types of traffic) [Fair-use].		peak times (typically a rate cap for certain types of traffic)
	Often this traffic management is done with expensive flow aware		[Fair-use]. Often this traffic management is done with expensive
	devices such as DPI boxes or flow-aware routers.		flow aware devices such as DPI boxes or flow-aware routers.
	ConEx offers a better approach that will actually target the users		ConEx offers a better approach that will actually target the users
	that are causing the congestion. By using Ingress or Egress		that are causing the congestion. By using Ingress or Egress
	Policers, an ISP can identify which users are causing the greatest		Policers, an ISP can identify which users are causing the greatest
	Congestion Volume throughout the network. This can then be used as		Congestion Volume throughout the network. This can then be used as
	the basis for traffic management decisions. The Ingress Policer		the basis for traffic management decisions. The Ingress Policer
	described in [Policing-freedom] is one interesting approach that		described in [Policing-freedom] is one interesting approach that
	gives the user a congestion volume limit. So long as they stay		gives the user a congestion volume limit. So long as they stay
	within their limit then their traffic is unaffected. Once they		within their limit then their traffic is unaffected. Once they
	exceed that limit then their traffic will be blocked temporarily.		exceed that limit then their traffic will be blocked temporarily.
	8.2. ConEx to incentivise scavenger transports		5.2. ConEx to incentivise scavenger transports
	Recent work proposes a new approach for QoS where traffic is provided		Recent work proposes a new approach for QoS where traffic is provided
	with a less than best effort or "scavenger" quality of service. The		with a less than best effort or "scavenger" quality of service. The
	idea is that low priority but high volume traffic such as OS updates,		idea is that low priority but high volume traffic such as OS updates,
	P2P file transfers and view-later TV programs should be allowed to		P2P file transfers and view-later TV programs should be allowed to
	use any spare network capacity, but should rapidly get out of the way		use any spare network capacity, but should rapidly get out of the way
	if a higher priority or interactive application starts up. One		if a higher priority or interactive application starts up. One
	solution being actively explored is LEDBAT which proposes a new		solution being actively explored is LEDBAT which proposes a new
	congestion control algorithm that is less aggressive in seeking out		congestion control algorithm that is less aggressive in seeking out
	bandwidth than TCP.		bandwidth than TCP.
	At present most ISPs assume a strong correlation between the volume		At present most operators assume a strong correlation between the
	of a flow and the impact that flow causes in the network. This		volume of a flow and the impact that flow causes in the network.
	assumption has been eroded by the growth of interactive streaming		This assumption has been eroded by the growth of interactive
	which behaves in an inelastic manner and hence can cause high		streaming which behaves in an inelastic manner and hence can cause
	congestion at relatively low data volumes. Currently LEDBAT-like		high congestion at relatively low data volumes. Currently LEDBAT-
	transports get no incentive from the ISP since they still transfer		like transports get no incentive from the ISP since they still
	large volumes of data and may reach high transfer speeds if the		transfer large volumes of data and may reach high transfer speeds if
	network is uncongested. Consequently the only current incentive for		the network is uncongested. Consequently the only current incentive
	LEDBAT is that it can reduce self-congestion effects.		for LEDBAT is that it can reduce self-congestion effects.
	If the ISP has deployed a ConEx-aware ingress policer then they are		If the ISP has deployed a ConEx-aware Ingress Policer then they are
	able to incentivise the use of LEDBAT because a user will be policed		able to incentivise the use of LEDBAT because a user will be policed
	according to the overall congestion volume their traffic generates,		according to the overall congestion volume their traffic generates,
	not the rate or data volume. If all background file transfers are		not the rate or data volume. If all background file transfers are
	only generating a low level of congestion, then the sender has more		only generating a low level of congestion, then the sender has more
	"congestion budget" to "spend" on their interactive applications. It		"congestion budget" to "spend" on their interactive applications. It
	can be shown [Kelly] that this approach improves social welfare -- in		can be shown [Kelly] that this approach improves social welfare -- in
	other words if you limit the congestion that all users can generate		other words if you limit the congestion that all users can generate
	then everyone benefits from a better service.		then everyone benefits from a better service.
	8.3. ConEx to mitigate DDoS		5.3. ConEx to mitigate DDoS
	DDoS relies on subverting innocent end users and getting them to send		DDoS relies on subverting innocent end users and getting them to send
	flood traffic to a given destination. This is intended to cause a		flood traffic to a given destination. This is intended to cause a
	rapid increase in congestion in the immediate vicinity of that		rapid increase in congestion in the immediate vicinity of that
	destination. If it fails to do this then it can't be called Denial		destination. If it fails to do this then it can't be called Denial
	of Service. If the ingress ISP has deployed Ingress Policers, that		of Service. If the ingress ISP has deployed Ingress Policers, that
	ISP will effectively limit how much DDoS traffic enters the 'net. If		ISP will effectively limit how much DDoS traffic enters the 'net. If
	any ISP along the path has deployed Border Monitors then they will be		any ISP along the path has deployed Border Monitors then they will be
	able to detect a sharp rise in Congestion Volume and if they have		able to detect a sharp rise in Congestion Volume and if they have
	Border Policers they will be able to "turn off" this traffic. If the		Border Policers they will be able to "turn off" this traffic. If the
	skipping to change at page 20, line 47		skipping to change at page 11, line 35
	will be able to detect which traffic is causing problems. If the		will be able to detect which traffic is causing problems. If the
	compromised user tries to use the 'net during the DDoS attack, they		compromised user tries to use the 'net during the DDoS attack, they
	will quickly become aware that something is wrong, and their ISP can		will quickly become aware that something is wrong, and their ISP can
	show the evidence that their computer has become zombified.		show the evidence that their computer has become zombified.
	DDoS is a genuine problem and so far there is no perfect solution.		DDoS is a genuine problem and so far there is no perfect solution.
	ConEx does serve to raise the bar somewhat and can avoid the need for		ConEx does serve to raise the bar somewhat and can avoid the need for
	some of the more draconian measures that are currently used to		some of the more draconian measures that are currently used to
	control DDoS. More details of this can be found in [Malice].		control DDoS. More details of this can be found in [Malice].
	8.4. Accounting for Congestion Volume		5.4. Accounting for Congestion Volume
	Accountability was one of the original design goals for the Internet		Accountability was one of the original design goals for the Internet
	[Design-Philosophy]. At the time it was ranked low because the		[Design-Philosophy]. At the time it was ranked low because the
	network was non-commercial and it was assumed users had the best		network was non-commercial and it was assumed users had the best
	interests of the network at heart. Nowadays users generally treat		interests of the network at heart. Nowadays users generally treat
	the network as a commodity and the Internet has become highly		the network as a commodity and the Internet has become highly
	commercialised. This causes problems for ISPs and others which they		commercialised. This causes problems for operators and others which
	have tried to solve and often leads to a tragedy of the commons where		they have tried to solve and often leads to a tragedy of the commons
	users end up fighting each other for scarce peak capacity.		where users end up fighting each other for scarce peak capacity.
	The most elegant solution would be to introduce an Internet-wide		The most elegant solution would be to introduce an Internet-wide
	system of accountability where every actor in the network is held to		system of accountability where every actor in the network is held to
	account for the impact they have on others. If Policers are placed		account for the impact they have on others. If Policers are placed
	at every Network Ingress or Egress and Border Monitors at every		at every Network Ingress or Egress and Border Monitors at every
	border, then you have the basis for a system of congestion		border, then you have the basis for a system of congestion
	accounting. Simply by controlling the overall Congestion Volume each		accounting. Simply by controlling the overall Congestion Volume each
	end-system or stub-network can send you ensure everyone gets a better		end-system or stub-network can send you ensure everyone gets a better
	service.		service.
	8.5. ConEx as a form of differential QoS		5.5. ConEx as a form of differential QoS
	Most QoS approaches require the active participation of routers to		Most QoS approaches require the active participation of routers to
	control the delay and loss characteristics for the traffic. For		control the delay and loss characteristics for the traffic. For
	real-time interactive traffic it is clear that low delay (and		real-time interactive traffic it is clear that low delay (and
	predictable jitter) are critical, and thus these probably always need		predictable jitter) are critical, and thus these probably always need
	different treatment at a router. However if low loss is the issue		different treatment at a router. However if low loss is the issue
	then ConEx offers an alternative approach.		then ConEx offers an alternative approach.
	Assuming the ingress ISP has deployed a ConEx Ingress Policer, then		Assuming the ingress ISP has deployed a ConEx Ingress Policer, then
	the only control on a user's traffic is dependent on the congestion		the only control on a user's traffic is dependent on the congestion
	skipping to change at page 22, line 5		skipping to change at page 12, line 39
	there are strong economic pressures to maintain a high enough data		there are strong economic pressures to maintain a high enough data
	rate (as that will directly influence the Quality of Experience the		rate (as that will directly influence the Quality of Experience the
	end-user receives. This approach removes the need for bandwidth		end-user receives. This approach removes the need for bandwidth
	brokers to establish QoS sessions, by removing the need to coordinate		brokers to establish QoS sessions, by removing the need to coordinate
	requests from multiple sources to pre-allocate bandwidth, as well as		requests from multiple sources to pre-allocate bandwidth, as well as
	to coordinate which allocations to revoke when bandwidth predictions		to coordinate which allocations to revoke when bandwidth predictions
	turn out to be wrong. There is also no need to "rate-police" at the		turn out to be wrong. There is also no need to "rate-police" at the
	boundaries on a per-flow basis, removing the need to keep per-flow		boundaries on a per-flow basis, removing the need to keep per-flow
	state (which in turn makes this approach more scalable).		state (which in turn makes this approach more scalable).
	8.6. Partial vs. Full Deployment		5.6. Partial vs. Full Deployment
	In a fully-deployed ConEx-enabled internet, [QoS-Models] shows that		In a fully-deployed ConEx-enabled internet, [QoS-Models] shows that
	ISP settlements based on congestion volume can allocate money to		ISP settlements based on congestion volume can allocate money to
	where upgrades are needed. Fully-deployed implies that ConEx-marked		where upgrades are needed. Fully-deployed implies that ConEx-marked
	packets which have not exhausted their expected congestion would go		packets which have not exhausted their expected congestion would go
	through a congested path in preference to non-ConEx packets, with		through a congested path in preference to non-ConEx packets, with
	money changing hands to justify that priority.		money changing hands to justify that priority.
	In a partial deployment, routers that ignore ConEx markings and let		In a partial deployment, routers that ignore ConEx markings and let
	them pass unaltered are no problem unless they become congested and		them pass unaltered are no problem unless they become congested and
	skipping to change at page 23, line 9		skipping to change at page 13, line 45
	aggressively than TCP for any elastic traffic. Indeed they will		aggressively than TCP for any elastic traffic. Indeed they will
	actually have an incentive to use fully weighted congestion controls		actually have an incentive to use fully weighted congestion controls
	that allow traffic to cause congestion in proportion to its priority.		that allow traffic to cause congestion in proportion to its priority.
	Traffic which backs off more aggressively than TCP will see		Traffic which backs off more aggressively than TCP will see
	congestion charges remain the same (or even drop) as congestion		congestion charges remain the same (or even drop) as congestion
	increases; traffic which backs off less aggressively will see charges		increases; traffic which backs off less aggressively will see charges
	rise, but the user may be prepared to accept this if it is high-		rise, but the user may be prepared to accept this if it is high-
	priority traffic; traffic which backs off not at all will see charges		priority traffic; traffic which backs off not at all will see charges
	rise dramatically.		rise dramatically.
	9. Other issues		6. Other issues
	9.1. Congestion as a Commercial Secret		6.1. Congestion as a Commercial Secret
	Network operators have long viewed the congestion levels in their		Network operators have long viewed the congestion levels in their
	network as a business secret. In some ways this harks back to the		network as a business secret. In some ways this harks back to the
	days of fixed-line telecommunications where congestion manifested as		days of fixed-line telecommunications where congestion manifested as
	failed connections or dropped calls. But even in modern data-centric		failed connections or dropped calls. But even in modern data-centric
	packet networks congestion is viewed as a secret not to be shared		packet networks congestion is viewed as a secret not to be shared
	with competitors. It can be debated whether this view is sensible,		with competitors. It can be debated whether this view is sensible,
	but it may make operators uneasy about deploying ConEx. The		but it may make operators uneasy about deploying ConEx. The
	following two examples highlight some of the arguments used:		following two examples highlight some of the arguments used:
	o An ISP buys backhaul capacity from an operator. Most ISPs want		o An ISP buys backhaul capacity from an operator. Most operators
	their customers to get a decent service and so they want the		want their customers to get a decent service and so they want the
	backhaul to be relatively uncongested. If there is competition,		backhaul to be relatively uncongested. If there is competition,
	operators will seek to reassure their customers (the ISPs) that		operators will seek to reassure their customers (the operators)
	their network is not congested in order to attract their custom.		that their network is not congested in order to attract their
	Some operators may see ConEx as a threat since it will enable		custom. Some operators may see ConEx as a threat since it will
	those ISPs to see the actual congestion in their network. On the		enable those operators to see the actual congestion in their
	other hand, operators with low congestion could use ConEx to show		network. On the other hand, operators with low congestion could
	how well their network performs, and so might have an incentive to		use ConEx to show how well their network performs, and so might
	enable it.		have an incentive to enable it.
	o ISPs would like to be part of the lucrative content provision		o Operators would like to be part of the lucrative content provision
	market. Currently the ISP can gain a competitive edge as it can		market. Currently the ISP can gain a competitive edge as it can
	put its own content in a higher QoS class, whereas traffic from		put its own content in a higher QoS class, whereas traffic from
	content providers has to use the Best Effort class. The ISP may		content providers has to use the Best Effort class. The ISP may
	take the view that if they can conceal the congestion level in		take the view that if they can conceal the congestion level in
	their Best Effort class this will make it harder for the content		their Best Effort class this will make it harder for the content
	provider to maintain a good level of QoS. But in reality the		provider to maintain a good level of QoS. But in reality the
	Content Provider will just use the feedback mechanisms in		Content Provider will just use the feedback mechanisms in
	streaming protocols such as Adobe Flash to monitor the congestion.		streaming protocols such as Adobe Flash to monitor the congestion.
	Of course some might say that the idea of keeping congestion secret		Of course some might say that the idea of keeping congestion secret
	is silly. After all, end-hosts already have knowledge of the		is silly. After all, end-hosts already have knowledge of the
	congestion throughout the network, albeit only along specific paths,		congestion throughout the network, albeit only along specific paths,
	and ISPs can work out that there is persistent congestion as their		and operators can work out that there is persistent congestion as
	customers will be suffering degraded network performance.		their customers will be suffering degraded network performance.
	9.2. Information Security		6.2. Information Security
	make a source believe it has seen more congestion than it has		make a source believe it has seen more congestion than it has
	hijack a user's identity and make it appear they are dishonest at an		hijack a user's identity and make it appear they are dishonest at an
	egress policer		egress policer
	clear or otherwise tamper with the ConEx markings		clear or otherwise tamper with the ConEx markings
	...		...
	{ToDo} Write these up properly...		{ToDo} Write these up properly...
	10. Security Considerations		7. Security Considerations
	This document proposes a mechanism tagging onto Explicit Congestion		This document proposes a mechanism tagging onto Explicit Congestion
	Notification [RFC3168], and inherits the security issues listed		Notification [RFC3168], and inherits the security issues listed
	therein. The additional issues from ConEx markings relate to the		therein. The additional issues from ConEx markings relate to the
	degree of trust each forwarding point places in the ConEx markings it		degree of trust each forwarding point places in the ConEx markings it
	receives, which is a business decision mostly orthogonal to the		receives, which is a business decision mostly orthogonal to the
	markings themselves.		markings themselves.
	One expected use of exposed congestion information is to hold the		One expected use of exposed congestion information is to hold the
	end-to-end transport and the network accountable to each other. The		end-to-end transport and the network accountable to each other. The
	skipping to change at page 25, line 30		skipping to change at page 16, line 15
	congestion. This will be a particular problem with sources of		congestion. This will be a particular problem with sources of
	flooding attacks. "Policing" mechanisms have been proposed to		flooding attacks. "Policing" mechanisms have been proposed to
	deal with this.		deal with this.
	In addition there are potential problems from source spoofing. A		In addition there are potential problems from source spoofing. A
	malicious sender can pretend to be another user by spoofing the		malicious sender can pretend to be another user by spoofing the
	source address. Congestion Exposure allows for "Policers" and		source address. Congestion Exposure allows for "Policers" and
	"Traffic Shapers" so as to be robust against injection of false		"Traffic Shapers" so as to be robust against injection of false
	congestion information into the forward path.		congestion information into the forward path.
	11. IANA Considerations		8. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	12. Acknowledgments		9. Acknowledgments
	Bob Briscoe is partly funded by Trilogy, a research project (ICT-		Bob Briscoe is 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 Contributing Authors Bernard Aboba,		The authors would like to thank Contributing Authors Bernard Aboba,
	Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley,		Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley,
	Michael Menth, and Hannes Tschofenig for their inputs to this		Michael Menth, and Hannes Tschofenig for their inputs to this
	document. Useful feedback was also provided by Dirk Kutscher.		document. Useful feedback was also provided by Dirk Kutscher.
	13. References		10. References
	13.1. Normative References		10.1. Normative References
	[RFC3168] Ramakrishnan, K., Floyd,		[RFC3168] Ramakrishnan, K., Floyd,
	S., and D. Black, "The		S., and D. Black, "The
	Addition of Explicit		Addition of Explicit
	Congestion Notification		Congestion Notification
	(ECN) to IP", RFC 3168,		(ECN) to IP", RFC 3168,
	September 2001.		September 2001.
	13.2. Informative References		10.2. Informative References
	[BB-incentive] MIT Communications Futures		[BB-incentive] MIT Communications Futures
	Program (CFP) and		Program (CFP) and
	Cambridge University		Cambridge University
	Communications Research		Communications Research
	Network, "The Broadband		Network, "The Broadband
	Incentive Problem",		Incentive Problem",
	September 2005.		September 2005.
			[ConEx-Abstract-Mech] Briscoe, B., "Congestion
			Exposure (ConEx) Concepts
			and Abstract Mechanism", d
			raft-mathis-conex-
			abstract-mech-00 (work in
			progress), October 2010.
	[Design-Philosophy] Clarke, D., "The Design		[Design-Philosophy] Clarke, D., "The Design
	Philosophy of the DARPA		Philosophy of the DARPA
	Internet Protocols", 1988.		Internet Protocols", 1988.
	[Fair-use] Broadband Choices, "Truth		[Fair-use] Broadband Choices, "Truth
	about 'fair usage'		about 'fair usage'
	broadband", 2009.		broadband", 2009.
	[Fairer-faster] Briscoe, B., "A Fairer		[Fairer-faster] Briscoe, B., "A Fairer
	Faster Internet Protocol",		Faster Internet Protocol",
	skipping to change at page 27, line 36		skipping to change at page 18, line 30
	<http://		<http://
	wesii.econinfosec.org/		wesii.econinfosec.org/
	draft.php?paper_id=19>.		draft.php?paper_id=19>.
	[OfCom] Ofcom: Office of		[OfCom] Ofcom: Office of
	Communications, "UK		Communications, "UK
	Broadband Speeds 2008:		Broadband Speeds 2008:
	Research report",		Research report",
	January 2009.		January 2009.
			[Padhye] Padhye, J., Firoiu, V.,
			Towsley, D., and J.
			Kurose, "Modeling TCP
			Throughput: A Simple Model
			and its Empirical
			Validation", ACM SIGCOMM
			Computer Communications
			Review Vol 28(4), pages
			303-314, May 1998.
	[Policing-freedom] Briscoe, B., Jacquet, A.,		[Policing-freedom] Briscoe, B., Jacquet, A.,
	and T. Moncaster,		and T. Moncaster,
	"Policing Freedom to Use		"Policing Freedom to Use
	the Internet Resource		the Internet Resource
	Pool", RE-Arch 2008 hosted		Pool", RE-Arch 2008 hosted
	at the 2008 CoNEXT		at the 2008 CoNEXT
	conference ,		conference ,
	December 2008.		December 2008.
	[QoS-Models] Briscoe, B. and S. Rudkin,		[QoS-Models] Briscoe, B. and S. Rudkin,
	skipping to change at page 29, line 5		skipping to change at page 20, line 6
	[re-ecn-motive] Briscoe, B., Jacquet, A.,		[re-ecn-motive] Briscoe, B., Jacquet, A.,
	Moncaster, T., and A.		Moncaster, T., and A.
	Smith, "Re-ECN: A		Smith, "Re-ECN: A
	Framework for adding		Framework for adding
	Congestion Accountability		Congestion Accountability
	to TCP/IP", draft-briscoe-		to TCP/IP", draft-briscoe-
	tsvwg-re-ecn-tcp-		tsvwg-re-ecn-tcp-
	motivation-01 (work in		motivation-01 (work in
	progress), September 2009.		progress), September 2009.
			Appendix A. ConEx Architectural Elements
			ConEx is a simple concept that has revolutionary implications. It is
			that rare thing -- a truly disruptive technology, and as such it is
			hard to imagine the variety of uses it may be put to. Before even
			thinking what it might be used for we need to address the issue of
			how it can be used. This section describes four architectural
			elements that can be placed in the network and which utilise ConEx
			information to monitor or control traffic flows.
			In the following we are assuming the most abstract version of the
			ConEx mechanism, namely that every packet carries two congestion
			fields, one for upstream congestion and one for downstream.
			[ConEx-Abstract-Mech] outlines one possible approach for this.
			A.1. ConEx Monitoring
			One of the most useful things ConEx provides is the ability to
			monitor (and control) the amount of congestion entering or leaving a
			network. With ConEx, each packet carries sufficient information to
			work out the Upstream, Downstream and Total Congestion Volume that
			packet is responsible for. This allows the overall Congestion Volume
			to be calculated at any point in the network. In effect this gives a
			measure of how much excess traffic has been sent that was above the
			instantaneous transmission capacity of the network. A 1 Gbps router
			that is 0.1% congested implies that there is 1 Mbps of excess traffic
			at that point in time.
			The figure below shows 2 conceptual pieces of network equipment that
			utilise ConEx information in order to monitor the flow of congestion
			through the network. The Border Monitor sits at the border between
			two networks, while the Edge Monitor sits at the Ingress or Egress to
			the Internetwork.
			,---. ,---.
			,-----. / \ ,------. / \ ,------. ,-----.
			| Src |--( Net A )-| B.M. |-( Net B )--| E.M. |--| Dst |
			'-----` \ / '------` \ / '------` '-----`
			'---` ^ '---` ^
			Border Monitor Edge Monitor
			NB, the Edge Monitor could also be at the Src end of the network
			Figure 1: Ingress, egress and border monitors
			Note: In the tables below, ConEx-Enabled is as defined in Section 2
			and ECN-enabled means any router that fully enables Explicit
			Congestion Notification (ECN) as defined in [RFC3168] and any
			relevant updates to that standard.
			A.1.1. Edge Monitoring
			+------------+----------------+----------------+--------------------+
			| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
			| Element | | | |
			+------------+----------------+----------------+--------------------+
			| Sender | Yes, if ECN is | Yes, must be | Must be receiving |
			| | used as basis | sending ConEx | congestion |
			| | for congestion | information | feedback |
			| | signal | | |
			| Sender's | ECN would be | Should | NB, it doesn't |
			| Network | beneficial | understand | have to be fully |
			| | | ConEx markings | ConEx-Enabled |
			| Core | ECN would be | Needn't | ConEx markings |
			| Network | beneficial | understand | must get through |
			| | | ConEx | the network |
			| Receiver's | ECN would be | Should | Deosn't have to be |
			| Network | beneficial | understand | fully |
			| | | ConEx markings | ConEx-Enabled |
			| Receiver | Only needed if | Should | Has to feedback |
			| | network is | understand | the congestion it |
			| | ECN-Enabled | ConEx | sees (either ECN |
			| | | | or drop) |
			+------------+----------------+----------------+--------------------+
			Table 1: Requirements for Edge Monitoring
			Edge Monitors are ideally positioned to verify the accuracy of ConEx
			markings. If there is an imbalance between the expected congestion
			and the actual congestion then this will show up at the egress. Edge
			Monitors can also be used by an operator to measure the service a
			given customer is receiving by monitoring how much congestion their
			traffic is causing. This may allow them to take pre-emptive action
			if they detect any anomalies.
			A.1.2. Border Monitoring
			+------------+-----------------+-----------------+------------------+
			| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
			| Element | | | |
			+------------+-----------------+-----------------+------------------+
			| Sender | Must be | Yes, must be | Must receive |
			| | ECN-enabled if | sending ConEx | accurate |
			| | any of the | information | congestion |
			| | network is | | feedback |
			| Sender's | ECN should be | Should | Ideally would be |
			| Network | enabled | understand | ConEx-Enabled |
			| | | ConEx markings | |
			| Core | ECN should be | Should | Ideally would be |
			| Network | enabled | understand | ConEx-Enabled |
			| | | ConEx markings | |
			| Receiver's | ECN should be | Should | Ideally would be |
			| Network | enabled | understand | ConEx-Enabled |
			| | | ConEx markings | |
			| Receiver | Must be | Must be ConEx | Receiver has to |
			| | ECN-enabled if | enabled | feedback the |
			| | any of the | | congestion it |
			| | network is | | sees |
			+------------+-----------------+-----------------+------------------+
			Table 2: Requirements for Border Monitoring
			At any border between 2 networks, the operator can see the total
			Congestion Volume that is being forwarded into its network by the
			neighbouring network. A Border Monitor is able to measure the bulk
			congestion markings and establish the flow of Congestion Volume each
			way across the border. This could be used as the basis for inter-
			network settlements. It also provides information to target upgrades
			to where they are actually needed and might help to identify network
			problems. Border Monitoring really needs the majority of the network
			to be ECN-Enabled in order to provide the necessary Upstream
			Congestion signal. Clearly the greatest benefit comes when there is
			also ConEx deployment in the nnetwork. However, as long as the
			sender is sending accurate ConEx information and the majority of the
			network is ECN-enabled, border monitoring will work.
			A.2. ConEx Policing
			As shown above, ConEx gives an easy method of measuring Congestion
			Volume. This information can be used as a control metric for making
			traffic management decisions (such as deciding which traffic to
			prioritise) or to identify and block sources of persistent and
			damaging congestion. Simple policer mechanisms, such as those
			described in [Policing-freedom] and [re-ecn-motive], can control the
			overall congestion volume traversing a network. Ingress Policing
			typically happens at the Ingress Node, Egress Policing typically
			happens at the Egress Node and Border Policing can happen at any
			border between two networks. The current charter concentrates on use
			cases employing Egress Policers.
			,---. ,---.
			+-----+ +------+ / \ +------+ / \ +------+ +-----+
			| Src |--| I.P. |--( Net A )-| B.P. |-( Net B )--| E.P. |--| Dst |
			+-----+ +------+ \ / +------+ \ / +------+ +-----+
			^ '---` ^ '---` ^
			Ingress Policer Border Policer Egress Policer
			Figure 2: Ingress, egress and border policers
			A.2.1. Egress Policing
			+------------+--------------+----------------+----------------------+
			| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
			| Element | | | |
			+------------+--------------+----------------+----------------------+
			| Sender | The sender | Must be | Must be receiving |
			| | should be | ConEx-Enabled | congestion feedback |
			| | ECN-enabled | | |
			| | if any of | | |
			| | the network | | |
			| | is | | |
			| Sender's | ECN is | ConEx is | ConEx would enable |
			| Network | optional but | optional | them to do Ingress |
			| | beneficial | | Policing (see later) |
			| Core | ECN is | Not needed | ConEx marks must |
			| Network | optional but | | survive crossing the |
			| | beneficial | | network |
			| Receiver's | ECN is | Must fully | Each receiver needs |
			| Network | optional but | understand | an Egress Policer |
			| | beneficial | ConEx | |
			| Receiver | Should be | Should | Must feedback the |
			| | ECN-enabled | understand | congestion it sees. |
			| | if any of | ConEx | ConEx may have a |
			| | the network | | compatibility mode |
			| | is | | if the receiver is |
			| | | | not ConEx-Enabled |
			+------------+--------------+----------------+----------------------+
			Table 3: Egress Policer Requirements
			An Egress Policer allows an ISP to monitor the Congestion Volume a
			user's traffic has caused throughout the network, and then use this
			to prioritise the traffic accordingly. By itself, such a policer
			cannot tell how much of this congestion was caused in the ISP's own
			network, but it will identify which users are the "heaviest" in terms
			of the congestion they have caused. Assuming the ConEx information
			is accurate then the Egress Policer will be able to see how much
			congestion exists between it and the final destination (what you
			might call "last-mile" congestion). There are a number of strategies
			that could be used to determine how traffic is treated by an Egress
			Policer. Obviously traffic that is not ConEx enabled needs to
			receive some form of "default" treatment. Traffic that is ConEx
			enabled may have under-declared congestion in which case it would be
			reasonable to give it a low scheduling priority. Traffic that
			appears to be over-declaring congestion may be simply a result of
			especially high "last-mile" congestion, in which case the ISP may
			want to upgrade the access capacity, or may want to try and reduce
			the volume of traffic. Where the ISP knows what the "last-mile"
			congestion is (for instance if it is able to measure several users
			sharing that same capacity) then any remaining over-declared
			congestion might be seen as a signal that the sender wishes to
			prioritise this traffic.
			A.2.2. Ingress Policing
			+------------+--------------+----------------+----------------------+
			| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
			| Element | | | |
			+------------+--------------+----------------+----------------------+
			| Sender | Should be | Must be | Must be receiving |
			| | ECN-enabled | ConEx-enabled | congestion feedback |
			| Sender's | ECN is | Must | |
			| Network | optional but | understand | |
			| | beneficial | ConEx | |
			| Core | ECN is | Needn't | ConEx markings must |
			| Network | optional but | understand | survive crossing the |
			| | beneficial | ConEx | network |
			| Receiver's | ECN is | Needn't | ConEx markings must |
			| Network | optional but | understand | survive crossing the |
			| | beneficial | ConEx | network |
			| Receiver | Should be | Should be | Must feedback the |
			| | ECN-enabled | ConEx-Enabled | congestion it sees. |
			| | if any of | | ConEx may have a |
			| | the network | | compatibility mode |
			| | is | | if the receiver is |
			| | | | not ConEx-Enabled |
			+------------+--------------+----------------+----------------------+
			Table 4: Ingress Policer Requirements
			At the Network Ingress, an ISP can police the amount of congestion a
			user is causing by limiting the congestion volume they send into the
			network. One system that achieves this is described in
			[Policing-freedom]. This uses a modified token bucket to limit the
			congestion rate being sent rather than the overall rate. Such
			Ingress policing is relatively simple as it requires no flow state.
			Furthermore, unlike many mechanisms, it treats all a user's packets
			equally.
			A.2.3. Border Policing
			+------------+--------------+----------------+----------------------+
			| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
			| Element | | | |
			+------------+--------------+----------------+----------------------+
			| Sender | ECN should | Must be | Must receive |
			| | be enabled | ConEx-enabled | accurate congestion |
			| | | | feedback |
			| Sender's | ECN is | Must be | |
			| Network | optional but | ConEx-enabled | |
			| | beneficial | | |
			| Core | ECN is | Should be | Must be |
			| Network | optional but | ConEx-Enabled | ConEx-Enabled if it |
			| | beneficial | | is doing the |
			| | | | policing. At a |
			| | | | minimum must pass |
			| | | | ConEx markings |
			| | | | unaltered |
			| Receiver's | ECN is | Should be | At a minimum must |
			| Network | optional but | ConEx-Enabled | pass ConEx markings |
			| | beneficial | | unaltered |
			| Receiver | Should be | Should be | Must feedback the |
			| | ECN-Enabled | ConEx-Enabled | congestion it sees. |
			| | if any of | | ConEx may have a |
			| | the network | | compatibility mode |
			| | is | | if the receiver is |
			| | | | not ConEx-Enabled |
			+------------+--------------+----------------+----------------------+
			Table 5: Border Policer Requirements
			A Border Policer will allow an operator to directly control the
			congestion that it allows into its network. Normally we would expect
			the controls to be related to some form of contractual obligation
			between the two parties. However, such Policing could also be used
			to mitigate some effects of Distributed Denial of Service (see
			Section 5.3). In effect a Border Policer encourages the network
			upstream to take responsibility for congestion it will cause
			downstream and could be seen as an incentive for that network to
			participate in ConEx (e.g. install Ingress Policers)
	Authors' Addresses		Authors' Addresses
	Bob Briscoe		Bob Briscoe
	BT		BT
	B54/77, Adastral Park		B54/77, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 645196		Phone: +44 1473 645196
End of changes. 63 change blocks.
	570 lines changed or deleted		506 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/