< draft-ietf-conex-concepts-uses-00.txt		draft-ietf-conex-concepts-uses-01.txt >
	CONEX B. Briscoe		CONEX T. Moncaster, Ed.
	Internet-Draft BT		Internet-Draft Moncaster Internet Consulting
	Intended status: Informational R. Woundy		Intended status: Informational J. Leslie, Ed.
	Expires: May 19, 2011 Comcast		Expires: October 16, 2011 JLC.net
	T. Moncaster, Ed.		B. Briscoe
	Moncaster.com		BT
	J. Leslie, Ed.		R. Woundy
	JLC.net		Comcast
	November 15, 2010		D. McDysan
			Verizon
			April 14, 2011
	ConEx Concepts and Use Cases		ConEx Concepts and Use Cases
	draft-ietf-conex-concepts-uses-00		draft-ietf-conex-concepts-uses-01
	Abstract		Abstract
	Internet Service Providers (operators) are facing problems where		Internet Service Providers (operators) are facing problems where
	localized congestion prevents full utilization of the path between		localized congestion prevents full utilization of the path between
	sender and receiver at today's "broadband" speeds. Operators desire		sender and receiver at today's "broadband" speeds. Operators desire
	to control this congestion, which often appears to be caused by a		to control this congestion, which often appears to be caused by a
	small number of users consuming a large amount of bandwidth.		small number of users consuming a large amount of bandwidth.
	Building out more capacity along all of the path to handle this		Building out more capacity along all of the path to handle this
	congestion can be expensive and may not result in improvements for		congestion can be expensive and may not result in improvements for
	skipping to change at page 1, line 47		skipping to change at page 2, line 4
	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 October 16, 2011.
	This Internet-Draft will expire on May 19, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Congestion Management . . . . . . . . . . . . . . . . . . . . 6		3. Congestion Management . . . . . . . . . . . . . . . . . . . . 7
	3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 7		3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 7
	4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8		4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 9
	4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9		4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 10
	5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10		5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. ConEx as a basis for traffic management . . . . . . . . . 10		5.1. ConEx as a basis for traffic management . . . . . . . . . 10
	5.2. ConEx to incentivise scavenger transports . . . . . . . . 10		5.2. ConEx to incentivise scavenger transports . . . . . . . . 11
	5.3. Accounting for Congestion Volume . . . . . . . . . . . . . 11		5.3. Accounting for Congestion Volume . . . . . . . . . . . . . 12
	5.4. ConEx as a form of differential QoS . . . . . . . . . . . 11		5.4. ConEx as a form of differential QoS . . . . . . . . . . . 12
	5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 12		5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 13
	6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Statistical Multiplexing over Differing Timescales . . . . . . 14
	6.1. Congestion as a Commercial Secret . . . . . . . . . . . . 13		6.1. ConEx Objectives for This Issue . . . . . . . . . . . . . 15
	6.2. Information Security . . . . . . . . . . . . . . . . . . . 14		6.2. ConEx as a Solution . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6.3. Additional Support Using other Measures and Mechanisms . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		7.1. Congestion as a Commercial Secret . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7.2. Information Security . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
			10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
			11. Informative References . . . . . . . . . . . . . . . . . . . . 20
	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, have caused unforeseen problems for
	problems for network operators and users alike. Users are		network operators and users alike. Users are increasingly seeing
	increasingly seeing congestion at peak times and changes in usage		congestion at peak times and changes in usage patterns (with the
	patterns (with the growth of real-time streaming) simply serve to		growth of real-time streaming) simply serve to exacerbate this.
	exacerbate this. Operators want all their users to see a good		Operators want all their users to see a good service but are unable
	service but are unable to see where congestion problems originate.		to see where congestion problems originate. But congestion results
	But congestion results from sharing network capacity with others, not		from sharing network capacity with others, not merely from using it.
	merely from using it. In general, today's "DSL" and cable-internet		In general, today's "DSL" and cable-internet users cannot "cause"
	users cannot "cause" congestion in the absence of competing traffic.		congestion in the absence of competing traffic. (Wireless operators
	(Wireless operators and cellular internet have different tradeoffs		and cellular internet have different tradeoffs which we will not
	which we will not discuss here.)		discuss here.)
	Congestion generally results from the interaction of traffic from one		Despite its central role in network control and management,
	network operator's users with traffic from other users. The tools		congestion is a remarkably hard conept to define. The discussions in
	currently available don't allow an operator to identify which traffic		[Bauer09] provide a good academic background. [RFC6077] defines it
	contributes most to the congestion and so they are powerless to		as "as a state or condition that occurs when network resources are
	properly control it.		overloaded, resulting in impairments for network users as objectively
			measured by the probability of loss and/or delay." An economist
			might define it as the condition where the utility of a given user
			decreases due to an increase in network load. Common to these
			definitions is the idea that an increase in load results in a
			reduction of service from the network.
			Congestion takes two distinct forms. The first results from the
			interaction of traffic from one set of users with traffic from other
			users, causing in a reduction in service (a cost) for all of them.
			the second, often referred to as "self-congestion", occurs when an
			increase in traffic from a single user causes that user to suffer a
			worse service (for instance because their traffic is being "shaped"
			by their ISP, or because they have an excessively large buffer in
			their home router). ConEx is principally interested in the first
			form of congestion since it involves informing those other users of
			the impact you expect to have on them.
	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]. The operators also face the challenge
			that network traffic grows according to Moore's Law -- increasing
			capacity may only be buying a few months grace before you are again
			facing increasing congestion, reducing utility and customers
			demanding a better service. 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 problem less tractable. These		congestion, but can actually make the problem less tractable. These
	users are trying to make good use of the capacity of the path while		users are trying to make good use of the capacity of the path while
	minimising their own costs. Thus, users of such services may show		minimising their own costs. Thus, users of such services may show
	very heavy total traffic up until the moment congestion is detected		very heavy total traffic up until the moment congestion is detected
	(at the Transport Layer), but then will immediately back off.		(at the Transport Layer), but then will immediately back off.
	Monitoring (at the Internet Layer) cannot detect this congestion		Monitoring (at the Internet Layer) cannot detect this congestion
	avoidance if the congestion in question is in a different domain		avoidance if the congestion in question is in a different domain
	further along the path; and must treat such users as congestion-		further along the path and hence such users may get tretated as
	causing users.		congestion-causing users.
	The ConEx working group proposes that Internet Protocol (IP) packets		The ConEx working group proposes that Internet Protocol (IP) packets
	will carry additional ConEx information. The exact protocol details		will carry additional ConEx information. The exact protocol details
	are not described in this document, but the ConEx information will be		are not described in this document, but the ConEx information will be
	sufficient to allow any node in the network to see how much		sufficient to allow any node in the network to see how much
	congestion is attributable to a given traffic flow. See		congestion is attributable to a given traffic flow. See
	[ConEx-Abstract-Mech] for further details.		[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 draft-ietf-conex-concepts-uses-00 to -01:
			Added section on timescales: Section 6
			Revised introduction to clarify congestion definitions
			Changed source for congestion definition in Section 2
			Other minor changes
	From draft-moncaster-conex-concepts-uses-02 to		From draft-moncaster-conex-concepts-uses-02 to
	draft-ietf-conex-concepts-uses-00 (per decisions of working group):		draft-ietf-conex-concepts-uses-00 (per decisions of working group):
	Removed section on DDoS mitigation use case.		Removed section on DDoS mitigation use case.
	Removed appendix on ConEx Architectural Elements. PLEASE NOTE:		Removed appendix on ConEx Architectural Elements. PLEASE NOTE:
	Alignment of terminology with the Abstract Mechanism draft has		Alignment of terminology with the Abstract Mechanism draft has
	been deferred to the next version.		been deferred to the next version.
	From draft-moncaster-conex-concepts-uses-01 to		From draft-moncaster-conex-concepts-uses-01 to
	skipping to change at page 5, line 11		skipping to change at page 5, line 42
	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 with a ConEx Issues		Added new section on ConEx requirements with a ConEx Issues
	subsection. Text for these came from the start of the old ConEx		subsection. Text for these came from the start of the old ConEx
	Use Cases section		Use Cases section
	Added a sub-section on Partial vs Full Deployment Section 5.5		Added a sub-section on Partial vs Full Deployment Section 5.5
	Added a discussion on ConEx as a Business Secret Section 6.1		Added a discussion on ConEx as a Business Secret Section 7.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.
	skipping to change at page 5, line 37		skipping to change at page 6, line 22
	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 5.		Section 5.
	2. Definitions		2. Definitions
	In this section we define a number of terms that are used throughout		In this section we define a number of terms that are used throughout
	the document. The key definition is that of congestion, which has a		the document. The key definition is that of congestion, which has a
	number of meanings depending on context. The definition we use in		number of meanings depending on context. The definition we use in
	this document is based on the definition in [Padhye] where congestion		this document is based on the definition in [RFC6077]. This list of
	is viewed as a probability that a packet will be dropped. This list		definitions is supplementary to that in [ConEx-Abstract-Mech].
	of definitions is supplementary to that in [ConEx-Abstract-Mech].
	Congestion: Congestion is a measure of the probability that a packet		Congestion: Congestion occurs when any user's traffic suffers
	will be marked or dropped as it traverses a queue.		increased delay, loss or ECN marking as a result of one or more
			network resources being overloaded.
	flow: a series of packets from a single sender to a single receiver		Flow: a series of packets from a single sender to a single receiver
	that are treated by that sender as belonging to a single stream		that are treated by that sender as belonging to a single stream
	for the purposes of congestion control. NB in general this is not		for the purposes of congestion control. NB in general this is not
	the same as the aggregate of all traffic between the sender and		the same as the aggregate of all traffic between the sender and
	receiver.		receiver.
	Congestion-rate: For any granularity of traffic (packet, flow,		Congestion-rate: For any granularity of traffic (packet, flow,
	aggregate, etc.), the instantaneous rate of traffic discarded or		aggregate, etc.), the instantaneous rate of traffic discarded or
	marked due to congestion. Conceptually, the instantaneous bit-		marked due to congestion. Conceptually, the instantaneous bit-
	rate of the traffic multiplied by the instantaneous congestion it		rate of the traffic multiplied by the instantaneous congestion it
	is experiencing.		is experiencing.
	skipping to change at page 13, line 32		skipping to change at page 14, line 13
	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.
	6. Other issues		6. Statistical Multiplexing over Differing Timescales
	6.1. Congestion as a Commercial Secret		Access networks are usually provisioned assuming statistical
			multiplexing, where end-users are presumed not all to use their
			maximum bandwidth simultaneously. Typically, an ISP might design
			access networks with shared resources (e.g., circuits, ports,
			schedulers) dimensioned in proportion to the sum of average usage by
			the customers involved. Generally, ISPs monitor actual usage
			averaged over some time period (typically stated in minutes) to plan
			when upgrades to shared resources will be needed.
			Almost always, they find that certain busy periods of the day have
			higher usage; and that actual contention for bandwidth at a shared
			resource (e.g., circuit, port, scheduler) is limited to those
			periods. This leads to "economic congestion" as defined in Section
			3.4 of [Bauer09], where traffic by one end-user imposes a "cost" of
			reduced utility on other users. Sometimes, there is an extended
			period between economic congestion being first observed and the
			completion of upgrades. In other cases, a trend of "economic
			congestion" is used by a service provider before congestion as
			defined in the abstract mechanism (loss or ECN marking) occurs.
			During busy periods, it has been observed that roughly 20% of the
			end-users are using 80% of the bandwidth [Varian]. We call this
			roughly-20% "heavy users", and the others "light users". Left to
			itself, this situation means that heavy users cause queues to fill at
			a rate much greater than light users do. (Note that this heavy/light
			categorization is for illustrative purposes since there is actually a
			continuum of "heaviness" across users.) When both heavy and light
			users pay the same flat rate, ISPs believe heavy users should bear
			more of the "cost" of reduced utility.
			When all users have unlimited access to a shared resource bottleneck,
			this problem is the most severe since maximum per user bandwidth is
			that of the shared resource. In order to provide more control over
			the maximum rate at which individual users may send, many ISPs have
			deployed "traffic shapers" to limit bandwidth available to an
			individual user during all time periods. Note that this limits the
			per user maximum bandwidth in the sub-second timeframe of the shaper
			queue. Currently, these "shapers" make no distinction between busy
			periods where shared resource congestion may occur and periods when
			no congestion occurs.
			During a period of higher usage, a shared resource becomes the
			bottleneck and causes filling of a shared queue or individual user
			shaper queues. However, heavy users create much more queuing and
			therefore potentially more congestion volume Section 2 as compared
			with lighter users. This means that during periods of higher usage,
			heavier and lighter users see comparable congestion (i.e., packet
			loss or ECN marking). Thus, the overall utility (i.e., probability
			of a packet not being lost or ECN marked) is reduced by the fewer
			heavier users at the expense of the many lighter users.
			During periods of lighter usage, heavier users will fill their
			individual shaper queues, potentially creating loss or ECN marking,
			such that TCP congestion-control does what the ISP desires and cuts
			back the sending rate giving the user the expected maximum bandwidth.
			6.1. ConEx Objectives for This Issue
			ConEx should provide better information for a provider to address the
			"economic congestion" problem. Specifically, ConEx should help to
			distinguish which users cause queue-filling over a time interval
			matching the economic congestion and statistical multiplexing
			algorithm time scales. This can range from seconds, to minutes, to
			hours. It is also desirable to distinguish "self-congestion" where
			there is no contention for a shared resource bandwidth (e.g.,
			circuit, port, scheduler), which is referred to as "inter-user
			congestion" in the following. If this is visible to end-users, they
			could use an out-of-band mechanism to "go faster" if only "self-
			congestion" is limiting their throughput.
			There are (at least) three approaches for addressing this issue.
			1. Treat "self-congestion" the same as "inter-user congestion" since
			they both create congestion as perceived by the flow user;
			2. Signal more information to the receiver about the cause of loss
			since the remedy may differ;
			3. Process (and generate) ConEx information at the same network
			element which implements the shaper, which has knowledge of the
			configured maximum bandwidth for the users as well as local
			shared resource congestion.
			For the most part, these don't require any changes to the abstract
			mechanism; but a subcase of 2), where the traffic-shaper might use
			ConEx to signal that the "congestion" is actually due to traffic-
			shaping, not shared resource contention, could require additional
			signaling to be defined in the ConEx protocol.
			Note that during busy periods "self congestion" might not be the
			limiting factor, but there will inevitably be less-busy periods where
			"self-congestion" will predominate.
			6.2. ConEx as a Solution
			Over a time period related to the statistical multiplexing or
			economic congestion interval (e.g., many seconds to minutes to hours)
			total up the number of bytes that have been congestion marked and the
			total number of bytes sent per end-user. Compute the ratio of
			congested bytes to total bytes. This measures the average rate per
			user.
			Quantizing users into classes using one threshold on total and and
			another threshold on ratio results in a grid that identifies four
			classes of user:
			+------------+-------------+-------------+
			| | Volume |
			| Ratio | Large | Small |
			+------------+-------------+-------------+
			| High | Heavy User | Bursty User |
			+------------+-------------+-------------+
			| Low | LEDBAT User | Light User |
			+------------+-------------+-------------+
			(Where "LEDBAT User" includes other Less-than-Best-Effort algorithms.)
			Figure 1: Four Classes of User
			Note that Bursty and Heavy Users contribute more to congestion
			marking, but a Bursty user contributes less overall congestion
			marking and may be creating shorter periods of queue filling as
			compared with heavy users. LEDBAT and light users create less to
			congestion marking, with LEDBAT users able to transfer more volume as
			compared with light users since LEDBAT users back off before
			congestion marking occurs. An operator might reasonably take this
			into account in their shaping algorithms.
			6.3. Additional Support Using other Measures and Mechanisms
			An additional congestion measure of burstiness (in addition to
			"congestion") would allow nodes upstream from the node implementing
			the shaper to implement traffic management. This measure could be
			derived from signals in the abstract mechanism but would require (a
			majority) of the heavier senders and receivers to implement conex and
			also would only work if loss or ECN marking occurs. Also, signaling
			a measure of the burstiness (or something related to it) would
			partially address the scenario where no loss or ECN marking occurs.
			As an alternative, a "light weight" TCP proxy might be implemented at
			the network element containing the shaper, and an upstream network
			element (e.g., an ingress router), could potentially create a ConEx
			control loop between these network elements to provide more optimal
			balance between heavier and lighter users during congested intervals.
			This would be a closed domain where the signals could be implicitly
			trusted. The burstiness measure could be communicated using TCP
			extensions between these proxies.
			There is also the aspect of "self congestion" where a traffic-shaper
			is at the access node. Using the current mechanisms, the receiver
			cannot tell the difference between "self-congestion" and "inter-user
			congestion." Adding a signal to the abstract mechanism could enable
			a receiver to inform the sender about the cause of congestion,
			enabling the sender to request that the traffic-shaper parameters
			change to enable the flow to "go faster".
			7. Other issues
			7.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:
	skipping to change at page 14, line 8		skipping to change at page 17, line 50
	want 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 operators)		operators will seek to reassure their customers (the operators)
	that their network is not congested in order to attract their		that their network is not congested in order to attract their
	custom. Some operators may see ConEx as a threat since it will		custom. Some operators may see ConEx as a threat since it will
	enable those operators to see the actual congestion in their		enable those operators to see the actual congestion in their
	network. On the other hand, operators with low congestion could		network. On the other hand, operators with low congestion could
	use ConEx to show how well their network performs, and so might		use ConEx to show how well their network performs, and so might
	have an incentive to enable it.		have an incentive to enable it.
	o Operators would like to be part of the lucrative content provision		o ISPs 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 operators can work out that there is persistent congestion as		and operators can work out that there is persistent congestion as
	their customers will be suffering degraded network performance.		their customers will be suffering degraded network performance.
	6.2. Information Security		7.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...
	7. Security Considerations		8. 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 15, line 48		skipping to change at page 19, line 42
	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.
	8. IANA Considerations		9. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	9. Acknowledgments		10. 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 the many people that have commented
	Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley,		on this document. Bernard Aboba, Mikael Abrahamsson, Joao Taveira
	Michael Menth, and Hannes Tschofenig for their inputs to this		Araujo, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness,
	document. Useful feedback was also provided by Dirk Kutscher.		Alissa Cooper, Philip Eardley, Matthew Ford, Ingemar Johansson, Mirja
			Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Michael Menth, Chris
	10. References		Morrow, Hannes Tschofenig and Stuart Venters. Please accept our
			apologies if your name has been missed off this list.
	10.1. Normative References
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black,
	"The Addition of Explicit Congestion
	Notification (ECN) to IP", RFC 3168,
	September 2001.
	10.2. Informative References		11. Informative References
	[BB-incentive] MIT Communications Futures Program (CFP) and		[BB-incentive] MIT Communications Futures Program (CFP) and
	Cambridge University Communications Research		Cambridge University Communications Research
	Network, "The Broadband Incentive Problem",		Network, "The Broadband Incentive Problem",
	September 2005.		September 2005.
			[Bauer09] Bauer, S., Clark, D., and W. Lehr, "The
			Evolution of Internet Congestion", 2009.
	[ConEx-Abstract-Mech] Briscoe, B., "Congestion Exposure (ConEx)		[ConEx-Abstract-Mech] Briscoe, B., "Congestion Exposure (ConEx)
	Concepts and Abstract Mechanism",		Concepts and Abstract Mechanism",
	draft-mathis-conex-abstract-mech-00 (work in		draft-ietf-conex-abstract-mech-00 (work in
	progress), October 2010.		progress), March 2011.
	[Design-Philosophy] Clarke, D., "The Design Philosophy of the		[Design-Philosophy] Clarke, D., "The Design Philosophy of the
	DARPA Internet Protocols", 1988.		DARPA Internet Protocols", 1988.
	[Fair-use] Broadband Choices, "Truth about 'fair usage'		[Fair-use] Broadband Choices, "Truth about 'fair usage'
	broadband", 2009.		broadband", 2009.
	[Fairer-faster] Briscoe, B., "A Fairer Faster Internet		[Fairer-faster] Briscoe, B., "A Fairer Faster Internet
	Protocol", IEEE Spectrum Dec 2008 pp38-43,		Protocol", IEEE Spectrum Dec 2008 pp38-43,
	December 2008.		December 2008.
	skipping to change at page 17, line 22		skipping to change at page 21, line 12
	draft-ietf-ledbat-congestion-01 (work in		draft-ietf-ledbat-congestion-01 (work in
	progress), March 2010.		progress), March 2010.
	[Malice] Briscoe, B., "Using Self Interest to Prevent		[Malice] Briscoe, B., "Using Self Interest to Prevent
	Malice; Fixing the Denial of Service Flaw of		Malice; Fixing the Denial of Service Flaw of
	the Internet", WESII - Workshop on the		the Internet", WESII - Workshop on the
	Economics of Securing the Information		Economics of Securing the Information
	Infrastructure 2006, 2006, <http://		Infrastructure 2006, 2006, <http://
	wesii.econinfosec.org/draft.php?paper_id=19>.		wesii.econinfosec.org/draft.php?paper_id=19>.
	[OfCom] Ofcom: Office of Communications, "UK Broadband
	Speeds 2008: Research report", January 2009.
	[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J.		[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J.
	Kurose, "Modeling TCP Throughput: A Simple		Kurose, "Modeling TCP Throughput: A Simple
	Model and its Empirical Validation", ACM		Model and its Empirical Validation", ACM
	SIGCOMM Computer Communications Review Vol		SIGCOMM Computer Communications Review Vol
	28(4), pages 303-314, May 1998.		28(4), pages 303-314, May 1998.
	[Policing-freedom] Briscoe, B., Jacquet, A., and T. Moncaster,		[Policing-freedom] Briscoe, B., Jacquet, A., and T. Moncaster,
	"Policing Freedom to Use the Internet Resource		"Policing Freedom to Use the Internet Resource
	Pool", RE-Arch 2008 hosted at the 2008 CoNEXT		Pool", RE-Arch 2008 hosted at the 2008 CoNEXT
	conference , December 2008.		conference , December 2008.
	skipping to change at page 17, line 49		skipping to change at page 21, line 36
	23 (2), April 2005.		23 (2), April 2005.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie,		[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie,
	B., Deering, S., Estrin, D., Floyd, S.,		B., Deering, S., Estrin, D., Floyd, S.,
	Jacobson, V., Minshall, G., Partridge, C.,		Jacobson, V., Minshall, G., Partridge, C.,
	Peterson, L., Ramakrishnan, K., Shenker, S.,		Peterson, L., Ramakrishnan, K., Shenker, S.,
	Wroclawski, J., and L. Zhang, "Recommendations		Wroclawski, J., and L. Zhang, "Recommendations
	on Queue Management and Congestion Avoidance		on Queue Management and Congestion Avoidance
	in the Internet", RFC 2309, April 1998.		in the Internet", RFC 2309, April 1998.
			[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black,
			"The Addition of Explicit Congestion
			Notification (ECN) to IP", RFC 3168,
			September 2001.
			[RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and
			B. Briscoe, "Open Research Issues in Internet
			Congestion Control", RFC 6077, February 2011.
	[Re-Feedback] Briscoe, B., Jacquet, A., Di Cairano-		[Re-Feedback] Briscoe, B., Jacquet, A., Di Cairano-
	Gilfedder, C., Salvatori, A., Soppera, A., and		Gilfedder, C., Salvatori, A., Soppera, A., and
	M. Koyabe, "Policing Congestion Response in an		M. Koyabe, "Policing Congestion Response in an
	Internetwork Using Re-Feedback", ACM SIGCOMM		Internetwork Using Re-Feedback", ACM SIGCOMM
	CCR 35(4)277--288, August 2005, <http://		CCR 35(4)277--288, August 2005, <http://
	www.acm.org/sigs/sigcomm/sigcomm2005/		www.acm.org/sigs/sigcomm/sigcomm2005/
	techprog.html#session8>.		techprog.html#session8>.
	[Savage] Savage, S., Wetherall, D., and T. Anderson,		[Savage] Savage, S., Wetherall, D., and T. Anderson,
	"TCP Congestion Control with a Misbehaving		"TCP Congestion Control with a Misbehaving
	Receiver", ACM SIGCOMM Computer Communication		Receiver", ACM SIGCOMM Computer Communication
	Review , 1999.		Review , 1999.
			[Varian] Varian, H., "Congestion pricing principles",
			Technical Plenary 78th IETF Meeting, July .
	[re-ecn-motive] Briscoe, B., Jacquet, A., Moncaster, T., and		[re-ecn-motive] Briscoe, B., Jacquet, A., Moncaster, T., and
	A. Smith, "Re-ECN: A Framework for adding		A. Smith, "Re-ECN: A Framework for adding
	Congestion Accountability to TCP/IP",		Congestion Accountability to TCP/IP",
	draft-briscoe-tsvwg-re-ecn-tcp-motivation-02		draft-briscoe-tsvwg-re-ecn-tcp-motivation-02
	(work in progress), October 2010.		(work in progress), October 2010.
	Authors' Addresses		Authors' Addresses
			Toby Moncaster (editor)
			Moncaster Internet Consulting
			Dukes
			Layer Marney
			Colchester CO5 9UZ
			UK
			EMail: toby@moncaster.com
			John Leslie (editor)
			JLC.net
			10 Souhegan Street
			Milford, NH 03055
			US
			EMail: john@jlc.net
	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
	EMail: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	skipping to change at page 18, line 32		skipping to change at page 23, line 4
	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
	EMail: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	Richard Woundy		Richard Woundy
	Comcast		Comcast
	Comcast Cable Communications		Comcast Cable Communications
	27 Industrial Avenue		27 Industrial Avenue
	Chelmsford, MA 01824		Chelmsford, MA 01824
	US		US
	EMail: richard_woundy@cable.comcast.com		EMail: richard_woundy@cable.comcast.com
	URI: http://www.comcast.com		URI: http://www.comcast.com
	Toby Moncaster (editor)
	Moncaster.com
	Dukes
	Layer Marney
	Colchester CO5 9UZ
	UK
	EMail: toby@moncaster.com		Dave McDysan
			Verizon
	John Leslie (editor)		22001 Loudon County Pkwy
	JLC.net		Ashburn, VA 20147
	10 Souhegan Street
	Milford, NH 03055
	US		US
	EMail: john@jlc.net		EMail: dave.mcdysan@verizon.com
End of changes. 35 change blocks.
	95 lines changed or deleted		299 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/