draft-briscoe-tsvarea-fair-01.txt		draft-briscoe-tsvarea-fair-02.txt
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe
	Internet-Draft BT & UCL		Internet-Draft BT & UCL
	Intended status: Informational March 05, 2007		Intended status: Informational July 06, 2007
	Expires: September 6, 2007		Expires: January 7, 2008
	Flow Rate Fairness: Dismantling a Religion		Flow Rate Fairness: Dismantling a Religion
	draft-briscoe-tsvarea-fair-01.pdf		draft-briscoe-tsvarea-fair-02.pdf
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2007.		This Internet-Draft will expire on January 7, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Resource allocation and accountability have been major unresolved		Resource allocation and accountability have been major unresolved
	problems with the Internet ever since its inception. The reason we		problems with the Internet ever since its inception. The reason we
	never resolve these issues is a broken idea of what the problem is.		never resolve these issues is a broken idea of what the problem is.
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	Comparing flow rates should never again be used for claims of		Comparing flow rates should never again be used for claims of
	fairness in production networks. Instead, we should judge fairness		fairness in production networks. Instead, we should judge fairness
	mechanisms on how they share out the `cost' of each user's actions on		mechanisms on how they share out the `cost' of each user's actions on
	others.		others.
	Summary of Changes (to be removed by the RFC Editor on Publication)		Summary of Changes (to be removed by the RFC Editor on Publication)
	Full diffs created using the rfcdiff tool are available at		Full diffs created using the rfcdiff tool are available at
	<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>		<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>
			From -01 to -02 (the present version):
			Introduction: Added motivation for more optimal fairness so ISPs
			don't try to make allocations more optimal manually using DPI etc.
			Clarified minimal impact on 'legacy' protocols using flow rate
			fairness as a goal, even if it is no longer a goal for future
			protocols.
			Section 3.1: clarified that cost fairness and re-ECN are not
			equivalent in any sense.
			Considerably clarified Section 4 "Cost, not Benefit", explaining
			better why the product of congestion and rate represents the cost
			to other users and why being able to reduce prices towards cost is
			desirable for users. Emphasised that cost fairness does not
			require congestion pricing and we do not recommend it. Also
			emphasised that ISPs don't have to use the congestion metric to
			enforce cost fairness, even if it is available. Clarified that
			fairness is relevant within more Diffserv behaviour aggregates
			than just best effort. Clarified that congestion includes
			congestion of lower layer resources including radio resources etc.
			Recommended Siris's algorithm rather than MulTCP.
			Section 5.2 "Comparing Costs": expanded on the marginal cost
			example. Re-emphasised that putting a limit on congestion in a
			service level agreement is not congestion pricing.
			Section 7 "Seminal Literature": added Jain's index of fairness.
			Added reference to the new TFRC-SP RFC in Section 8.3 on TFRC and
			in Section 9 on "Implications for the RFC Series".
			Section 8.5 on "Packet Size and Fairness": Summarised advice in
			referenced I-D.
			Updated references and numerous other minor edits and
			clarifications.
	From -00 to -01:		From -00 to -01:
	Toned down the polemic.		Toned down the polemic.
	Added Section 8 "Critiques of Specific Schemes", adding		Added Section 8 "Critiques of Specific Schemes", adding
	subsections on TCP and WFQ to previously disparate material on		subsections on TCP and WFQ to previously disparate material on
	max-min fairness, TFRC & router-based fairness approaches like		max-min fairness, TFRC & router-based fairness approaches like
	XCP, which have been shortened and clarified. Also added		XCP, which have been shortened and clarified. Also added
	subsections on TCP-style fairness wrt RTT and packet size that has		subsections on TCP-style fairness wrt. RTT and packet size that
	been copied by other transports.		has been copied by other transports.
	Added substantial new Section 9 "Implications for the RFC Series".		Added substantial new Section 9 "Implications for the RFC Series".
	Added to the introduction the importance of the issue and the		Added to the introduction the importance of the issue and the
	general implications.		general implications.
	Created an expanded and clarified new subsection Section 5.2		Created an expanded and clarified new subsection Section 5.2
	"Comparing Costs" from text previously at the end of Section 5.1		"Comparing Costs" from text previously at the end of Section 5.1
	"Something to Integrate the Allocations"		"Something to Integrate the Allocations"
	Added quote on flow granularity from RFC2309 & RFC2914.		Added quote on flow granularity from RFC2309 & RFC2914.
	Clarified and expanded Section 5.3.2 "Enforcing Cost Fairness".		Clarified and expanded Section 5.3.2 "Enforcing Cost Fairness".
	Various clarifications throughout.		Various clarifications throughout.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
	3. Fair Allocation of What Among What? . . . . . . . . . . . . . 7		3. Fair Allocation of What Among What? . . . . . . . . . . . . . 8
	3.1. Structure of Document . . . . . . . . . . . . . . . . . . 7		3.1. Structure of Document . . . . . . . . . . . . . . . . . . 9
	4. Cost, not Benefit . . . . . . . . . . . . . . . . . . . . . . 8		4. Cost, not Benefit . . . . . . . . . . . . . . . . . . . . . . 9
	5. Economic Entities not Flows . . . . . . . . . . . . . . . . . 11		5. Economic Entities not Flows . . . . . . . . . . . . . . . . . 14
	5.1. Something to Integrate the Allocations . . . . . . . . . . 11		5.1. Something to Integrate the Allocations . . . . . . . . . . 14
	5.2. Comparing Costs . . . . . . . . . . . . . . . . . . . . . 13		5.2. Comparing Costs . . . . . . . . . . . . . . . . . . . . . 15
	5.3. Enforcement of Fairness . . . . . . . . . . . . . . . . . 15		5.3. Enforcement of Fairness . . . . . . . . . . . . . . . . . 18
	5.3.1. Cheating with Whitewashed or Split Flow Identities . . 15		5.3.1. Cheating with Whitewashed or Split Flow Identities . . 18
	5.3.2. Enforcing Cost Fairness . . . . . . . . . . . . . . . 17		5.3.2. Enforcing Cost Fairness . . . . . . . . . . . . . . . 20
	6. Fairness between Fairnesses . . . . . . . . . . . . . . . . . 19		6. Fairness between Fairnesses . . . . . . . . . . . . . . . . . 22
	7. The Seminal Literature . . . . . . . . . . . . . . . . . . . . 21		7. The Seminal Literature . . . . . . . . . . . . . . . . . . . . 24
	8. Critiques of Specific Schemes . . . . . . . . . . . . . . . . 24		8. Critiques of Specific Schemes . . . . . . . . . . . . . . . . 27
	8.1. Max-min flow rate fairness . . . . . . . . . . . . . . . . 24		8.1. Max-min flow rate fairness . . . . . . . . . . . . . . . . 27
	8.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.3. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.3. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.4. RTT and Fairness . . . . . . . . . . . . . . . . . . . . . 25		8.4. RTT and Fairness . . . . . . . . . . . . . . . . . . . . . 29
	8.5. Packet Size and Fairness . . . . . . . . . . . . . . . . . 26		8.5. Packet Size and Fairness . . . . . . . . . . . . . . . . . 29
	8.6. XCP and router-based fairness schemes . . . . . . . . . . 26		8.6. XCP and router-based fairness schemes . . . . . . . . . . 30
	8.7. WFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		8.7. WFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	9. Implications for the RFC Series . . . . . . . . . . . . . . . 27		9. Implications for the RFC Series . . . . . . . . . . . . . . . 31
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 30		11. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30		12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 34
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
	14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 32		14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 36
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 32		15.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	15.2. Informative References . . . . . . . . . . . . . . . . . . 33		15.2. Informative References . . . . . . . . . . . . . . . . . . 37
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 40		Intellectual Property and Copyright Statements . . . . . . . . . . 44
	1. Introduction		1. Introduction
	"But he has nothing on at all."		"But he has nothing on at all."
	_The Emperor's New Clothes, Hans Christian Andersen_		_The Emperor's New Clothes, Hans Christian Andersen_
	This document is deliberately destructive. It sets out to destroy an		This document is deliberately destructive. It sets out to destroy an
	ideology that is blocking progress---the idea that fairness between		ideology that is blocking progress--the idea that fairness between
	multiplexed packet traffic can be achieved by controlling relative		multiplexed packet traffic can be achieved by controlling relative
	flow rates alone. Flow rate fairness was the goal behind fair		flow rates alone. Flow rate fairness was the goal behind fair
	resource allocation in widely deployed protocols like weighted fair		resource allocation in widely deployed protocols like weighted fair
	queuing (WFQ), TCP congestion control and TCP-friendly rate		queuing [WFQ], TCP congestion control [RFC2581] and TCP-friendly
	control [WFQ][RFC2581][RFC3448]. But it is actually just		rate control [RFC3448]. But it is actually just unsubstantiated
	unsubstantiated dogma to say that equal flow rates are fair. This is		dogma to say that equal flow rates are fair. This is why resource
	why resource allocation and accountability keep reappearing on every		allocation and accountability keep reappearing on every list of
	list of requirements for the Internet architecture		requirements for the Internet architecture (e.g. [NewArchReq]), but
	(e.g. [NewArchReq]), but never get solved. Obscured by this broken		never get solved. Obscured by this broken idea, we wouldn't know a
	idea, we wouldn't know a good solution from a bad one.		good solution from a bad one.
	Controlling relative flow rates _alone_ is a completely impractical		Controlling relative flow rates _alone_ is a completely impractical
	way of going about the problem. To be realistic for large-scale		way of going about the problem. To be realistic for large-scale
	Internet deployment, relative flow rates should be the _outcome_ of		Internet deployment, relative flow rates should be the _outcome_ of
	another fairness mechanism, not the mechanism itself. That other		another fairness mechanism, not the mechanism itself. That other
	mechanism should share out the `cost' of one user's actions on		mechanism should share out the `cost' of one user's actions on
	others---how much each user's transfers restrict other transfers,		others--how much each user's transfers restrict other transfers,
	given capacity constraints. Then flow rates will depend on a deeper		given capacity constraints. Then flow rates will depend on a deeper
	level of fairness that has so far remained unnamed in the literature,		level of fairness that has so far remained unnamed in the literature,
	but is best termed `cost fairness'.		but is best termed `cost fairness'.
	It really is only the idea of flow rate fairness that needs		It really is only the idea of flow rate fairness that needs
	destroying---nearly everything we've engineered can remain. The		destroying--nearly everything we've engineered can remain. The
	Internet architecture needs some minor additions, but otherwise it is		Internet architecture needs some minor additions, but otherwise it is
	largely already suited to cost fairness.		largely already suited to cost fairness.
	The metric required to arbitrate cost fairness is simply volume of		The metric required to arbitrate cost fairness is simply volume of
	congestion, that is congestion times the bit rate of each user		congestion, that is congestion times the bit rate of each user
	causing it, taken over time. In engineering terms, for each user it		causing it, taken over time. In engineering terms, for each user it
	can be measured very easily as the amount of data the user sent that		can be measured very easily as the amount of data the user sent that
	was dropped. Or with explicit congestion notification		was dropped. Or with explicit congestion notification
	(ECN [RFC3168]) the amount of each user's data to have been		(ECN [RFC3168]) the amount of each user's data to have been
	congestion marked. Importantly, unlike flow rates, this metric		congestion marked. Importantly, unlike flow rates, this metric
	integrates easily and correctly across different flows on different		integrates easily and correctly across different flows on different
	paths and across time.		paths and across time, so it can be easily incorporated into future
			service level agreements of ISPs.
	What we call cost fairness has been in the literature for nearly a		What we call cost fairness has been in the literature for nearly a
	decade, but it hasn't been put so bluntly before. We were moved to		decade, but it hasn't been put so bluntly before. We were moved to
	spell it out unambiguously (and avoiding maths), because this isn't		spell it out unambiguously (and avoiding maths), because this isn't
	just some dry academic fairness debate that might change allocation		just some dry academic fairness debate that might change allocation
	percentages somewhere in the third decimal place. The outcomes due		percentages somewhere in the third decimal place. The outcomes due
	to flow rate fairness that we see on the Internet today are		to flow rate fairness that we see on the Internet today are
	hopelessly unlike the outcomes that would result from cost fairness.		hopelessly unlike the outcomes that would result from cost fairness.
	Not that the outcomes we see are the deliberate intent of flow rate		Not that the outcomes we see are the deliberate intent of flow rate
	skipping to change at page 5, line 20		skipping to change at page 6, line 23
	control, because flow rate fairness isn't even capable of reasoning		control, because flow rate fairness isn't even capable of reasoning
	about questions like, "How many flows is it fair to start between two		about questions like, "How many flows is it fair to start between two
	endpoints? or over different routes?" or, "What rate is fair for a		endpoints? or over different routes?" or, "What rate is fair for a
	flow that has been running longer than another?".		flow that has been running longer than another?".
	Resource allocation and accountability are two issues that reappear		Resource allocation and accountability are two issues that reappear
	on every list of requirements for a new Internet		on every list of requirements for a new Internet
	architecture [NewArchReq]. We could have started filling this		architecture [NewArchReq]. We could have started filling this
	architectural vacuum a decade ago, but architecture not only requires		architectural vacuum a decade ago, but architecture not only requires
	foundational ideas, it also requires consensus. In 1997, the basis		foundational ideas, it also requires consensus. In 1997, the basis
	of the dominant consensus was completely undermined, but it didn't		of the dominant consensus was completely undermined, but its
	even notice.		believers didn't even notice.
	While everyone prevaricates, novel p2p applications have started to		While everyone prevaricates, novel p2p applications have started to
	thoroughly exploit this architectural vacuum with no guilt or shame,		thoroughly exploit this architectural vacuum with no guilt or shame,
	by just running more flows for longer. Application developers		by just running more flows for longer. Application developers
	assume, and they have been led to assume, that fairness is dealt with		assume, and they have been led to assume, that fairness is dealt with
	by TCP at the transport layer. In response some ISPs are deploying		by TCP at the transport layer. In response some ISPs are deploying
	kludges like volume caps or throttling specific applications using		kludges like volume caps or throttling specific applications using
	deep packet inspection. Innocent experimental probing has turned		deep packet inspection. Innocent experimental probing has turned
	into an arms race. The p2p community's early concern for the good of		into an arms race. The p2p community's early concern for the good of
	the Internet is being set aside, aided and abetted by commercial		the Internet is being set aside, aided and abetted by commercial
	skipping to change at page 5, line 43		skipping to change at page 6, line 46
	are fighting back. Bystanders sharing the same capacity are		are fighting back. Bystanders sharing the same capacity are
	suffering heavy collateral damage.		suffering heavy collateral damage.
	This trend has spread beyond the p2p community. There is now no		This trend has spread beyond the p2p community. There is now no
	shame in opening multiple TCP connections, or offering VoIP or video		shame in opening multiple TCP connections, or offering VoIP or video
	streaming software without any congestion control.		streaming software without any congestion control.
	Whether the prevailing notion of flow rate fairness has been the root		Whether the prevailing notion of flow rate fairness has been the root
	cause or not, there will certainly be no solution until the		cause or not, there will certainly be no solution until the
	networking community gets its head out of the sand and understands		networking community gets its head out of the sand and understands
	how unrealistic its view is, and how important this issue is.		how unrealistic its view is; and how important this issue is--a
	Certainly fairness is not a question of technical function---any		conflict between the vested interests of real businesses and real
	allocation `works'. But getting it hopelessly wrong badly skews the		people.
	outcome of conflicts between the vested interests of real businesses
	and real people.		Certainly fairness is not a question of technical function--any
			allocation `works'. But allowing self-interest to go largely
			unchecked leads to an outcome hopelessly skewed away from one that
			would better satisfy more people more of the time. ISPs intuitively
			know that their capacity isn't being shared in the best interests of
			the majority of their customers. This is why technologies like deep
			packet inspection middleboxes have been developed--ISPs know that
			throttling certain applications puts them at a considerable
			competitive advantage over ISPs that don't. These middleboxes are
			blocking the potential of the Internet to evolve future applications,
			but instead of wringing our hands over this issue, we should provide
			a protocol architecture that does a much better job of automatically
			sharing out Internet capacity. Then ISPs won't need these kludges to
			protect the experience of their customers.
	But isn't it a basic article of faith that multiple views of fairness		But isn't it a basic article of faith that multiple views of fairness
	should be able to co-exist, the choice depending on policy?		should be able to co-exist, the choice depending on policy?
	Absolutely correct---and we shall return to how this can be done		Absolutely correct--and we shall return to how this can be done
	later. But that doesn't mean we have to give the time of day to any		later. But that doesn't mean we have to give the time of day to any
	random idea of fairness.		random idea of fairness.
	Fair allocation of rates between flows was used in good faith as a		Fair allocation of rates between flows was used in good faith as a
	guiding principle, but it isn't based on any respected definition of		guiding principle, but it isn't based on any respected definition of
	fairness from philosophy or the social sciences. It has just		fairness from philosophy or the social sciences. It has just
	gradually become the way things are done in networking. But it's		gradually become the way things are done in networking. But it's
	actually self-referential dogma. Or put more bluntly, bonkers.		actually self-referential dogma. Or put more bluntly, bonkers.
	We expect to be fair to people, groups of people, institutions,		We expect to be fair to people, groups of people, institutions,
	companies---things the security community would call `principals'.		companies--things the security community would call `principals'.
	But a flow is merely an information transfer between two		But a flow is merely an information transfer between two
	applications. Where does the argument come from that information		applications. Where does the argument come from that information
	transfers should have equal rights with each other? It's equivalent		transfers should have equal rights with each other? It's equivalent
	to claiming food rations are fair because the boxes are all the same		to claiming food rations are fair because the boxes are all the same
	size, irrespective of how many boxes each person gets or how often		size, irrespective of how many boxes each person gets or how often
	they get them.		they get them.
	Because flows don't deserve rights in real life, it is not surprising		Because flows don't deserve rights in real life, it is not surprising
	that two loopholes the size of barn doors appear when trying to		that two loopholes the size of barn doors appear when trying to
	allocate rate fairly to flows in a non-co-operative environment. If		allocate rate fairly to flows in a non-cooperative environment. If
	at every instant a resource is shared among the flows competing for a		at every instant a resource is shared among the flows competing for a
	share, any real-world entity can gain by i) creating more flows than		share, any real-world entity can gain by i) creating more flows than
	anyone else, and ii) keeping them going longer than anyone else.		anyone else, and ii) keeping them going longer than anyone else.
	We appeal to the networking community to quietly set aside rate		We appeal to the networking community to quietly set aside rate
	fairness between flows. It had its time, but now it has been shown		fairness between flows. It had its time, but now it has been shown
	to be unfounded, unrealistic and impractical. Papers and standards		to be unfounded, unrealistic and impractical. Future papers and
	proposals using it should be rejected. No-one should ever have to		standards proposals claiming fairness on the basis of flow rates
	cater for it in future Internet protocols---it places arbitrary		should be rejected. This does not mean we need to phase out 'legacy'
	requirements on the system that can't be met and wouldn't achieve any		protocols that aimed for flow rate fairness--they will continue to
	meaningful sort of fairness even if they could be met.		function adequately (Section 9); they simply might not make best use
			of future service level agreements offered by ISPs. But no-one
			should ever set flow rate fairness as a goal in future Internet
			protocols--it places arbitrary requirements on the system that can't
			be met and wouldn't achieve any meaningful sort of fairness even if
			they could be met.
	Alternatively, someone should write a defence of flow rate fairness.		Alternatively, someone should write a defence of flow rate fairness.
	Continuing to use flow rate fairness as the dominant ideology,		Continuing to use flow rate fairness as the dominant ideology,
	without rebutting Kelly's seminal 1997 paper that undermined it, just		without rebutting Kelly's seminal 1997 paper that undermined it, just
	leaves the Internet community divided into religious sects, making a		leaves the Internet community divided into religious sects, making a
	mockery of the scientific process towards consensus.		mockery of the scientific process towards consensus.
	2. Requirements notation		2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 7, line 19		skipping to change at page 8, line 36
	fairness doesn't even allocate the correct thing. And it doesn't		fairness doesn't even allocate the correct thing. And it doesn't
	allocate it among the correct entities either. At this most basic		allocate it among the correct entities either. At this most basic
	level we will contrast the two main contending views:		level we will contrast the two main contending views:
	o Allocate rate among flows (flow rate fairness)		o Allocate rate among flows (flow rate fairness)
	o Allocate congestion cost among the bits sent by economic entities		o Allocate congestion cost among the bits sent by economic entities
	(cost fairness)		(cost fairness)
	When cost fairness was proposed, it stated its case in terms of the		When cost fairness was proposed, it stated its case in terms of the
	dominant belief system---flow rate fairness. Unfortunately, this		dominant belief system--flow rate fairness. Unfortunately, this
	meant that the dominant belief system didn't notice it had been		meant that the dominant belief system didn't notice it had been
	struck an intellectual death blow. Its believers carried on		struck an intellectual death blow. Its believers carried on
	regardless and it remains dominant today.		regardless and it remains dominant today.
	As a result, one sees talk of weighted proportional fairness in the		As a result, one sees talk of weighted proportional fairness in the
	same context as proportional, max-min or min-max fairness as if they		same context as proportional, max-min or min-max fairness as if they
	are all members of the same set. They are not. Weighted		are all members of the same set. They are not. Weighted
	proportional fairness has an extra weight parameter w that all the		proportional fairness has an extra weight parameter w that all the
	others lack. With weighted proportional fairness, the interesting		others lack. With weighted proportional fairness, the interesting
	bit is what regulates users in their choice of w. Otherwise, it		bit is what regulates users in their choice of w. Otherwise, it
	skipping to change at page 7, line 47		skipping to change at page 9, line 18
	bits sent by economic entities, regardless of which flows the bits		bits sent by economic entities, regardless of which flows the bits
	are in. A user's choice of w then depends on that.		are in. A user's choice of w then depends on that.
	3.1. Structure of Document		3.1. Structure of Document
	The body of this document is structured around our question, "Fair		The body of this document is structured around our question, "Fair
	allocation of what among what?":		allocation of what among what?":
	o Section 4 answers the "...of what...?" question, explaining why		o Section 4 answers the "...of what...?" question, explaining why
	fair allocation of costs is a sufficient and realistic form of		fair allocation of costs is a sufficient and realistic form of
	fairness, and allocation of rate is not. A sub-section also		fairness, and allocation of rate is not.
	explains why TCP fair rate control (TFRC) causes greater
	congestion costs than TCP, because it wrongly tries to achieve
	equality of flow rate.
	o Section 5 answers the "...among what?" question, explaining why		o Section 5 answers the "...among what?" question, explaining why
	fairness among flows can only be myopic whereas fairness among		fairness among economic entities naturally spans all flows from
	economic entities naturally spans all flows and spans time. Also		that entity across the Internet (space) and across time, whereas
	we show fairness among flows is hard, if not impossible, to		fairness among flows can only be myopic; in one location and at
	enforce while enforcing fairness among economic entities seems		one instant. Also, to demonstrate that it would be practical to
	practical.		enforce cost fairness, we briefly outline a protocol proposal
			called re-ECN. Note that cost fairness and re-ECN are in no sense
			equivalent; re-ECN is just one possible way in which cost fairness
			might be enforced and anyway re-ECN was actually designed to
			enforce both cost fairness and flow rate fairness.
	Having debunked the dominant ideology of flow rate fairness, and		Having debunked the dominant ideology of flow rate fairness, and
	replaced it with cost fairness, in Section 6 we discuss how other		replaced it with cost fairness, in Section 6 we discuss how other
	forms of fairness can be asserted locally. Then, before we draw		forms of fairness can be asserted locally. Then, before we draw
	conclusions, Section 7 maps the progression of seminal ideas in the		conclusions, Section 7 maps the progression of seminal ideas in the
	literature on which this memo is based and Section 8 outlines		literature on which this memo is based and Section 8 outlines
	concrete criticisms of specific fairness schemes: max-min flow rate		concrete criticisms of specific fairness schemes: max-min flow rate
	fairness, TCP, TFRC, WFQ and XCP as well as discussions of dependence		fairness, TCP, TFRC, WFQ and XCP as well as discussions of dependence
	on RTT and packet size. Finally, Section 9 surveys the implications		on RTT and packet size. Finally, Section 9 surveys which RFCs will
	on the RFC series if we are to dismantle all traces of flow rate		have to be updated if we are to stop using flow rate fairness as a
	fairness. A FAQ Web page [FairFAQ] is planned to answer some		goal for future IETF protocols. A FAQ Web page [FairFAQ] is also
	frequently asked questions that didn't fit easily into the main flow		planned to answer some frequently asked questions that didn't fit
	of this document.		easily into the main flow of this document.
	4. Cost, not Benefit		4. Cost, not Benefit
	The issues of fair allocation of resources comes under the domain of		The issues of fair allocation of resources comes under the domain of
	political economy, with philosophy reasoning about our judgements.		political economy, with philosophy reasoning about our judgements.
	In Section 6 we will discuss how different fairness policies can co-		In Section 6 we will discuss how different fairness policies can co-
	exist. But to answer our question, "Fair allocation of what?" we		exist. But to answer our question, "Fair allocation of what?" we
	start from the premise used in economics (and life) that fairness		start from the premise used in microeconomics (and life) that
	concerns comparing benefits, costs or both.		fairness concerns comparing benefits, costs or both.
	The benefit of a data transfer can be assumed to increase with flow		The benefit of a data transfer can be assumed to increase with flow
	rate, but the shape and size of the function relating the two (the		rate, but the shape and size of the function relating the two (the
	utility function) is unknown, subjective and private to each user.		utility function) is unknown, subjective and private to each user.
	Flow rate itself is an extremely inadequate measure for comparing		Flow rate itself is an extremely inadequate measure for comparing
	benefits: user benefit per bit rate might be ten orders of magnitude		benefits: user benefit per bit rate might be ten orders of magnitude
	different for different types of flow (e.g. SMS and video). So		different for different types of flow (e.g. SMS and video). So
	different applications might derive completely different benefits		different applications might derive completely different benefits
	from equal flow rates and equal benefits might be derived from very		from equal flow rates and equal benefits might be derived from very
	different flow rates.		different flow rates.
	Turning to the cost of a data transfer across a network, flow rate		Turning to the cost of a data transfer across a network, flow rate
	alone is not the measure of that either. Cost is also dependent on		alone is not the measure of that either. Cost is also dependent on
	the level of congestion on the path. This is counter-intuitive for		the level of congestion on the path. This is counter-intuitive for
	some people so we shall explain a little further. Once a network has		some people so we shall explain a little further. Once a network has
	been provisioned at a certain size, it doesn't cost a network		been provisioned at a certain size, it doesn't cost a network
	operator any more whether a user sends more data or not. But if the		operator any more whether a user sends more data or not. But if the
	network becomes congested, each user restricts every other user,		network becomes congested, each user restricts every other user,
	which can be interpreted as a cost _to all_---an externality in		which can be interpreted as a cost _to all_--an externality in
	economic terms. For any level of congestion, Kelly		economic terms. When there is no congestion, more usage costs
	showed [wPropFair] that the system is optimal if the blame for		nothing. But at each instant that congestion exists, continued usage
	congestion is attributed among all the users causing it, in		of the congested resource leads to a cost to all those trying to use
			it. This cost is proportional to the risk of data not being
			forwarded--the loss rate. Each user causes the cost to everyone else
			as well as to themselves.
			Kelly showed [wPropFair] that the system becomes optimal if the blame
			for congestion is attributed among all the users causing it, in
	proportion to their bit rates. That's exactly what routers are		proportion to their bit rates. That's exactly what routers are
	designed to do anyway. During congestion, a queue randomly		designed to do anyway. During congestion, a queue randomly
	distributes the losses so all flows see about the same loss rate (or		distributes the losses so all flows see about the same loss rate (or
	ECN marking rate); if a flow has twice the bit rate of another it		ECN marking rate); if a flow has twice the bit rate of another it
	should see twice the losses. In this respect random early detection		should see twice the losses. In this respect random early detection
	(RED [RFC2309]) is slightly fairer than drop tail, but to a first		(RED [RFC2309]) is slightly fairer than drop tail, but to a first
	order approximation they both meet this criterion.		order approximation they both meet this criterion.
	So in networking, the cost of one flow's behaviour depends on the		So in networking, the usage cost of one flow's behaviour depends on
	congestion volume it causes which is the product of its instantaneous		the congestion volume it causes, which is the product of its
	flow rate and congestion on its path, integrated over time. For		instantaneous flow rate and congestion on its path, integrated over
	instance, if two users are sending at 200kbps and 300kbps into a		time. For instance, if two users are sending at 200kbps and 300kbps
	450kbps line for 0.5s, congestion is (200+300-450)/(200+300) = 10% so		into a 450kbps line for 0.5s, congestion is (200+300-450)/(200+300) =
	the congestion volume each causes is 200kx 10%x 0.5 = 10kb and 15kb		10% so the congestion volume each causes is 200kx 10%x 0.5 = 10kb and
	respectively.		15kb respectively.
	So cost depends not only on flow rate, but on congestion as well.		So cost depends not only on flow rate, but on congestion as well.
	Typically congestion might be in the fractions of a percent but it		Typically congestion might be in the fractions of a percent but it
	varies from zero to tens of percent. So, flow rate can never alone		varies from zero to tens of percent. So, flow rate can never alone
	serve as a measure of cost.		serve as a measure of cost.
	To summarise so far, flow rate is a hopelessly incorrect proxy both		To summarise so far, flow rate is a hopelessly incorrect proxy both
	for benefit and for cost. Even if the intent was to equalise		for benefit and for cost. Even if the intent was to equalise
	benefits, equalising flow-rates wouldn't achieve it. Even if the		benefits, equalising flow-rates wouldn't achieve it. Even if the
	intent was to equalise costs, equalising flow-rates wouldn't achieve		intent was to equalise costs, equalising flow-rates wouldn't achieve
	it.		it.
	But actually a realistic resource allocation mechanism only needs to		But actually a realistic resource allocation mechanism only needs to
	concern itself with costs. If we set aside political economy for a		concern itself with costs, then benefits will look after themselves.
	moment and use pure microeconomics, we can use a competitive market
	to arbitrate fairness, which handles the benefits side, as we shall
	now explain. Then once we have a feasible, scalable system that at
	least implements one defined form of fairness, we will show how to
	build other forms of fairness within that.
	In life, as long as people cover the cost of their actions, it is		In life, as long as people cover the cost of their actions, it is
	generally considered fair enough. If one person enjoys a hot shower		generally considered fair enough. If one person enjoys a hot shower
	more than their neighbour enjoys the toast they made with equal units		more than their neighbour enjoys the toast they made with equal units
	of electricity, no-one expects the one who enjoyed the shower to have		of electricity, no-one expects the one who enjoyed the shower to have
	to pay more. If someone makes more of their lot in life than		to pay more. If someone makes more of their lot in life than
	another, some complain it's not fair, but most call this envy, not		another, some complain it's not fair, but most call this envy, not
	unfairness.		unfairness. Market economics works on the same premise
			(unsurprisingly given life and market economics are closely related).
	Market economics works on the same premise (unsurprisingly given life		The ideal of pure microeconomics is to ensure that everyone pays as
	and market economics are closely related). In fact, a market adjusts		little as possible (the cost) for the things they value. The reason
	supply to meet demand so that benefits are as fairly distributed as		we try to ensure markets are competitive is that any provider who
	is consistent with the pre-existing inequalities in life. But this		tries to sell above cost price will be undercut by a competitor. And
	fairness between benefits is an _outcome_ and it is only met as long		once things are sold at cost, the idea is that people will choose not
	as a market mechanism makes people accountable for the costs of their		to have an item if they will get less benefit from it than it costs.
	actions (and various market failures are avoided).		Being prevented from having something if you aren't prepared to cover
			the cost is a basic level of fairness that is particularly important
			when the cost is suffered by others around you.
			The problem with the current Internet architecture is that the cost
			of usage (congestion volume) is hidden from network providers.
			Everyone would like prices to drop towards cost, but even if Internet
			provision gets more competitive, there is no mechanism to reveal what
			the costs are. So no-one can stop certain users causing more costs
			to others than they have paid for (except by using the damaging
			kludges mentioned early).
			So far, we have only used the pure microeconomics of a market. But
			this only ensures benefits are as fairly distributed as is consistent
			with the pre-existing inequalities in life, setting aside other forms
			of fairness that might be required (the concern of political
			economy). But once we have a feasible, scalable system that
			counterbalances basic self-interest and at least implements one
			defined form of fairness, we will show (in Section 6) how to build
			other forms of fairness within that.
			To further summarise so far, making people accountable for the cost
			of their actions is a basic form of fairness, and we can only achieve
			various more sophisticated forms of fairness if a basic market
			mechanism can make people accountable for the costs of their actions
			(and various market failures are avoided).
	We deliberately say `make people accountable' to avoid the phrase		We deliberately say `make people accountable' to avoid the phrase
	`make people pay', because users tend to prefer flat rate		`make people pay', because users tend to prefer flat rate
	subscription for Internet access. So, ISPs want to be able to limit		subscription for Internet access not unpredictable congestion
	the congestion costs they are able to cause (Section 5.3.2), not just		charges. So, ISPs will want to be able to limit the congestion costs
	charge them for whatever unlimited costs they cause.		their users are able to cause (Section 5.3.2), rather than charge
			them for whatever unlimited costs they cause. We are certainly not
			advocating congestion pricing for retail users. No matter how many
			times we say this, people still wrongly jump to this conclusion. So
			note well again: we neither require nor recommend that retail users
			pay congestion prices to be able to achieve cost fairness.
			Indeed, all we are saying is that a congestion metric should be
			visible to those ISPs who want to include it in their service level
			agreements. We are _not_ saying ISPs _should_ do this, just that it
			is in everyone's interests that the costs people cause can be limited
			to what they have paid. So the Internet architecture should be
			_able_ to reveal a cost metric.
	If we do make users truly accountable for the cost of the congestion		If we do make users truly accountable for the cost of the congestion
	they cause, a form of fairness between flow rates emerges		they cause, a form of fairness between flow rates emerges
	automatically. As everyone increases the rate of each of their		automatically. As everyone increases the rate of each of their
	flows, congestion rises. As congestion rises, everyone pays due		flows, congestion rises. As congestion rises, everyone pays due
	regard to the share of the cost attributed to them. So, each		regard to the share of the cost attributed to them. So, each
	individual will want their congestion control algorithm to		individual will want their congestion control algorithm to
	continuously adjust its rate to maximise their net utility---benefit		continuously adjust its rate to maximise their net utility--benefit
	minus cost. Kelly [wPropFair] shows that even if each user keeps		minus cost. Kelly [wPropFair] shows that even if each user keeps
	their utility function private but we _model_ all the different users		their utility function private but we _model_ all the different users
	by an arbitrary weight that scales their utility function relative to		by an arbitrary weight that scales their utility function relative to
	others, users will allocate themselves flow rates so that the cost		others, users will allocate themselves flow rates so that the cost
	they cause will equal the weight they choose---weighted proportional		they cause will equal the weight they choose--weighted proportional
	fairness.		fairness.
	But such a flow rate allocation is not the measure of fairness, it is		But such a flow rate allocation is not the measure of fairness, it is
	merely a possible _outcome_ caused by cost fairness, given some		merely a possible _outcome_ caused by cost fairness, given some
	assumptions about how to model the shape of users' private utility		assumptions about how to model the shape of users' private utility
	functions. Enforcing underlying cost fairness is in itself a		functions. Enforcing underlying cost fairness is in itself a
	sufficient form of fairness. We repeat: _the resulting relative flow		sufficient form of fairness. We repeat: _the resulting relative flow
	rates are not the measure of fairness_.		rates are not the measure of fairness_.
	Most importantly, Kelly proved cost fairness would lead everyone to		Most importantly, Kelly proved cost fairness would lead everyone to
	maximise their combined aggregate utility across the whole Internet.		maximise their combined aggregate utility across the whole Internet.
	In other words, if anyone was allocated more and someone else less,		In other words, if anyone was allocated more and someone else less,
	the outcome would be worse as a whole. This is why cost fairness is		the outcome would be less aggregate utility as a whole. This is why
	so important, as other forms of fairness cannot be better, unless		cost fairness is so important, as other forms of fairness cannot be
	some major flaw is found in Kelly's assumptions. Kelly _et al_ also		better, unless some major flaw is found in Kelly's assumptions.
	proved that, even though relative flow rates would likely be very		Kelly _et al_ also proved that, even though relative flow rates would
	different from those seen today, the Internet would remain stable		likely be very different from those seen today, the Internet would
	given reasonable constraints and assumptions [wPropStab].		remain stable given reasonable constraints and
			assumptions [wPropStab].
	While on the subject of assumptions, we should add that the benefit		While on the subject of assumptions, we should add that the benefit
	of a real-time application depends on jitter, not just transfer rate.		of a real-time application depends on jitter, not just transfer rate.
	But simple scaling arguments show that it will be possible for		But simple scaling arguments show that it will be possible for
	network operators to minimise congestion delay as networks increase		network operators to minimise congestion delay as networks increase
	in capacity ([SelfMan] S.2), an argument supported by recent research		in capacity ([SelfMan] S.2), an argument supported by recent research
	showing that router buffers are often significantly		showing that router buffers are often significantly
	oversized [BufSizUp].		oversized [BufSizUp].
	On the other hand, no-one has even tried to claim that flow rate		We should also point out that fairness can be relevant within any
	equality achieves any fairness objective. It has just been asserted		Diffserv behaviour aggregate [RFC2475], not just best effort, and
	as an arbitrary engineer's dogma. This is why flow rate fairness is		that congestion is not solely a property of network layer buffers.
	so open to criticism as unrealistic---having no basis in any		Path congestion can consist of contributions from near-exhaustion of
	recognised form of fairness in real life, science or philosophy.		all sorts of physical resources at all layers: e.g. radio transmitter
			power, spectrum interference and battery power. Siris
			[ECNFixedWireless] explains how all these can and should be collected
			together along a path into ECN markings at the network layer to be
			fed back to the source transport.
			These are what we mean by reasonable assumptions around Kelly's
			fairness definition. On the other hand, no-one has even tried to
			claim that flow rate equality achieves any fairness objective. It
			has just been asserted as an arbitrary engineer's dogma. This is why
			flow rate fairness is so open to criticism as unrealistic--having no
			basis in any recognised form of fairness in real life, science or
			philosophy.
	Proponents of flow-rate fairness might be forgiven for aiming for an		Proponents of flow-rate fairness might be forgiven for aiming for an
	`unrealistic' form of fairness if a `realistic' form was difficult to		`unrealistic' form of fairness if a `realistic' form was difficult to
	implement in practice. In fact, it is flow rate fairness that is		implement in practice. In fact, it is flow rate fairness that is
	completely impractical to enforce (Section 5.3.1). The reason we are		completely impractical to enforce (Section 5.3.1). The reason we are
	resurrecting cost fairness is that we believe there are now much more		resurrecting cost fairness is that we believe there are now much more
	practical ways to enforce it---ways that are built around existing		practical ways to enforce it--ways that are built around existing
	Internet congestion control but, unlike Kelly's, they don't require		Internet congestion control but, unlike Kelly's, they don't require
	all ISPs to change their retail model to congestion charging		all ISPs to change their retail model to congestion charging
	(Section 5.3.2).		(Section 5.3.2).
	But how would users "allocate themselves flow rates in proportion to		But how would users "allocate themselves flow rates in proportion to
	the share of the cost that they cause"? If they were made		the share of the cost that they cause"? If they were made
	accountable for congestion, they would install a version of TCP with		accountable for congestion, they would install a version of TCP with
	a weight parameter (for example MulTCP [MulTCP]), at least for TCP-		a weight parameter, at least for TCP-based applications.
	based applications. Of course, most users wouldn't want the fuss of		MulTCP [MulTCP] is a simple example of such a TCP. An application
	weighting each individual flow. But if they chose to set policies on		can give it a parameter w to emulate the congestion behaviour of w
	average for large classes of flows (or to accept the defaults set by		TCP flows. MulTCP is conceptually useful for those familiar with
	application developers), the resulting suboptimal outcome for		TCP, but it has various failings (e.g. w<1 became increasingly
	themselves would be their own private choice to trade optimality		problematic). Instead we would recommend an algorithm such as
	against hassle. The underlying fairness criterion would still be		Siris's weighted window-based control [WindowPropFair].
	met: that people should be accountable for the costs they cause to
	others.		Of course, most users wouldn't want the fuss of weighting each
			individual flow. But if they chose to set policies on average for
			large classes of flows (or to accept the defaults set by application
			developers), the resulting suboptimal outcome for themselves would be
			their own private choice to trade optimality against hassle. The
			underlying fairness criterion would still be met: that people should
			be accountable for the costs they cause to others.
	In contrast, with flow-rate fairness, two flows may cause orders of		In contrast, with flow-rate fairness, two flows may cause orders of
	magnitude different costs to others (for instance if one has been		magnitude different costs to others (for instance if one has been
	running orders of magnitude longer) by running at equal rates.		running orders of magnitude longer) by running at equal rates.
	Nowhere do we find any justification for the dogma that flow rates		Nowhere do we find any justification for the dogma that flow rates
	must be equal to be fair. Nowhere do we find any rebuttal of Kelly's		must be equal to be fair. Nowhere do we find any rebuttal of Kelly's
	destruction of flow rate fairness, even after nine years.		destruction of flow rate fairness, even after ten years.
	5. Economic Entities not Flows		5. Economic Entities not Flows
	5.1. Something to Integrate the Allocations		5.1. Something to Integrate the Allocations
	Imagine loaves of bread are regularly delivered to a famine-struck		Imagine loaves of bread are regularly delivered to a famine-struck
	refugee camp. Each time a loaf is brought out, a queue forms and the		refugee camp. Each time a loaf is brought out, a queue forms and the
	loaf is divided equally among those in the queue. If the individuals		loaf is divided equally among those in the queue. If the individuals
	who appear in each queue are always different, except for one who		who appear in each queue are always different, except for one who
	always appears in every queue, would it still be fair to share each		always appears in every queue, would it still be fair to share each
	skipping to change at page 12, line 21		skipping to change at page 14, line 47
	So a fairness mechanism that claims to support commercially realistic		So a fairness mechanism that claims to support commercially realistic
	fairness policies must be structured to hold individual history		fairness policies must be structured to hold individual history
	without destroying scalability. And here, `individual' means some		without destroying scalability. And here, `individual' means some
	real-world entity with an economic existence, not a flow.		real-world entity with an economic existence, not a flow.
	Router-based flow rate fairness mechanisms tend to have to be myopic.		Router-based flow rate fairness mechanisms tend to have to be myopic.
	To be otherwise would seem to require holding the history of most		To be otherwise would seem to require holding the history of most
	Internet connected individuals on most routers, because a flow from		Internet connected individuals on most routers, because a flow from
	nearly any individual in the world might appear at nearly any router.		nearly any individual in the world might appear at nearly any router.
	So instead, router-based schemes tend to share out flow rate at each		So instead, router-based schemes tend to share out flow rate at each
	instant without regard to individual history---and unfortunately		instant without regard to individual history--and unfortunately
	without regard to commercial reality.		without regard to commercial reality.
	Instead of arbitrating fairness on routers, fairness can be and		Instead of arbitrating fairness on routers, fairness can be and
	already is arbitrated where state can be held scalably---at the		already is arbitrated where state can be held scalably--at the
	endpoints where the congestion costs of each individual are already		endpoints where the congestion costs of each individual are already
	collected together. One reason for our frustration with the		collected together. One reason for our frustration with the
	networking community's focus on flow rate fairness is that the TCP/		networking community's focus on flow rate fairness is that the TCP/
	IP-based architecture of the Internet already has a structure very		IP-based architecture of the Internet already has a structure very
	close to that required to arbitrate fairness based on the costs that		close to that required to arbitrate fairness based on the costs that
	individuals cause, rather than on flow rates.		individuals cause, rather than on flow rates.
	Congested routers generate cost signals (losses or ECN marks) that		Congested routers generate cost signals (losses or ECN marks) that
	are carried to the transport causing the congestion, piggy-backed in		are carried to the transport causing the congestion, piggy-backed in
	the packet stream either as gaps in the transport stream or as ECN		the packet stream either as gaps in the transport stream or as ECN
	marks. These congestion signals are already fed back to the sending		marks. These congestion signals are already fed back to the sending
	transport by nearly all transport protocols. And congestion control		transport by nearly all transport protocols. And congestion control
	algorithms like TCP already adapt their flow rates in response to		algorithms like TCP already adapt their flow rates in response to
	congestion. So all we would need to change would be to use a		congestion. So all we would need to change would be to use a
	weighted TCP algorithm [MulTCP] (or equivalent for inelastic		weighted TCP algorithm [WindowPropFair] (or equivalent for inelastic
	applications) that could weight itself under the control of a process		applications) that could weight itself under the control of a process
	overarching all the flows of one user, which would take into account		overarching all the flows of one user, which would take into account
	the user's cost history across all flows.		the user's cost history across all flows.
	Of course, there is no incentive for anyone to voluntarily subject		Of course, there is no incentive for anyone to voluntarily subject
	themselves to such fairness (nonetheless, they already subject		themselves to such fairness (nonetheless, they already subject
	themselves to TCP which voluntarily halves its rate whenever it		themselves to TCP which voluntarily halves its rate whenever it
	senses congestion). But as we shall see in Section 5.3.1, policing		senses congestion). But as we shall see in Section 5.3.1, policing
	fairness between individuals (and between networks) at their point of		fairness between individuals (and between networks) at their point of
	attachment to the Internet has already been solved, whereas getting		attachment to the Internet has already been solved, whereas getting
	skipping to change at page 13, line 28		skipping to change at page 16, line 7
	connection with the global economy.		connection with the global economy.
	Different types of users (heavy users, light users, servers, server		Different types of users (heavy users, light users, servers, server
	farms, companies) will want to be able to cause different volumes of		farms, companies) will want to be able to cause different volumes of
	congestion. As long as congestion can be equated to cost, it can be		congestion. As long as congestion can be equated to cost, it can be
	related to the amount each user has paid for their attachment to the		related to the amount each user has paid for their attachment to the
	Internet. Even if some localised authority asserts a non-economic		Internet. Even if some localised authority asserts a non-economic
	variant of fairness between some sub-set of users (e.g. in a		variant of fairness between some sub-set of users (e.g. in a
	university or corporation), the authority as a whole will still align		university or corporation), the authority as a whole will still align
	its understanding of cost with that of the global economy (see		its understanding of cost with that of the global economy (see
	Section 6).		Section 6) on Fairness between Fairnesses.
	To be able to compare costs globally, we cannot merely talk of volume		To be able to compare costs globally, we cannot merely talk of volume
	of congestion as a cost to other users without calibrating it---		of congestion as a cost to other users without calibrating it--
	without specifying how it relates to monetary cost. In a competitive		without specifying how it relates to monetary cost. In a competitive
	market, the monetary cost that should be assigned to congestion		market, the monetary cost that should be assigned to congestion
	volume turns out to be the marginal cost of the capacity needed to		volume turns out to be the marginal cost of the capacity needed to
	alleviate the congestion [PrCong] (see FAQ [FairFAQ] for details)		alleviate the congestion [PrCong] (see FAQ [FairFAQ] for details).
	The term `marginal' cost is used in economics for the slope of the		The term `marginal' cost is used in economics for the slope of the
	curve of cost against capacity. To take a toy example, imagine a		curve of cost against capacity. To take a toy example, imagine a
	10Gbps interface card costs $1,000 and the cost follows a rough		10Gbps interface card costs $1,000 and the cost follows a rough
	square root law so that a 20Gbps interface card will cost about		square root law so that a 20Gbps interface card will cost about
	$1,400 (sqrt(2)x the cost for 2x the capacity). Even though the		$1,400 (2 times the capacity costs sqrt(2) times as much). Even
	average cost of the 10Gbps card is $100 per Gbps, the marginal cost		though the average cost of the 10Gbps card is $100 per Gbps, the
	is only $50 per Gbps, implying an 11Gbps card (if cards could be		marginal cost is only $50 per Gbps. (Because: If X is capacity, C is
	upgraded with such fine granularity) would cost about $1,050.		cost and k is a constant, we have assumed C = k sqrt(X), so marginal
			cost = dC/dX = k/2sqrt(X) = C/2X, which is half of the average cost =
			C/X). This implies an 11Gbps card (if cards could be upgraded with
			such fine granularity) would cost about $1,050.
	Note that when we say that the cost of congestion equates to the		Note that when we say that the cost of congestion equates to the
	marginal cost of capacity, we are not introducing any additional		marginal cost of capacity, we are not introducing any additional
	cost; we are merely categorising cost into sub-divisions. So, an		cost; we are merely categorising cost into sub-divisions. So, an
	existing flat fee Internet charge should be considered to consist of		existing flat fee Internet charge should be considered to consist of
	parts to cover:		parts to cover:
	o operational (non-capacity) costs;		o operational (non-capacity) costs;
	o capacity upgrade costs to alleviate congestion (the $50/Gbps);		o capacity upgrade costs to alleviate congestion (the $50/Gbps
			marginal cost);
	o the balance of the cost of capacity ($100-$50=$50/Gbps).		o the balance of the average cost of capacity ($100-$50=$50/Gbps).
	The distinction between the last two is important, because the cost		The distinction between the last two is important, because the cost
	of capacity is traditionally shared out in proportion to access link		of capacity is traditionally shared out in proportion to access link
	capacity. But different users with the same access link capacity can		capacity. But different users with the same access link capacity can
	cause _hugely_ different volumes of congestion across time and across		cause _hugely_ different volumes of congestion across time and across
	all the Internet links they regularly use, so it is fair to share out		all the Internet links they regularly use, so it is fair to share out
	the upgrade cost part in proportion to congestion caused, not access		the upgrade cost part in proportion to congestion caused, not access
	link capacity.		link capacity.
	Once a cost is assigned to congestion that equates to the cost of		Once a cost is assigned to congestion that equates to the cost of
	alleviating it, users will only cause congestion if they want extra		alleviating it, users will only cause congestion if they want extra
	capacity enough to be willing to pay its cost. Of course, there will		capacity enough to be willing to pay its cost (e.g. using up
	be no need to be too precise about that rule. Perhaps some people		congestion quota they have paid for). Of course, there will be no
	might be allowed to get more than they pay for and others less.		need to be too precise about that rule. Perhaps some people might be
	Perhaps some people will be prepared to pay for what others get, and		allowed to get more than they pay for and others less. Perhaps some
	so on.		people will be prepared to pay for what others get, and so on.
	But, in a system the size of the Internet, there has to be be some		But, in a system the size of the Internet, there has to be some
	handle to arbitrate how much cost some users cause to others. Flow		handle to arbitrate how much cost some users cause to others. Flow
	rate fairness comes nowhere near being up to the job. It just isn't		rate fairness comes nowhere near being up to the job. It just isn't
	realistic to create a system the size of the Internet and define		realistic to create a system the size of the Internet and define
	fairness within the system without reference to fairness outside the		fairness within the system without reference to fairness outside the
	system---in the real world where everyone grudgingly accepts that		system--in the real world where everyone grudgingly accepts that
	fairness usually means "you get what you pay for".		fairness usually means "you get what you pay for".
	Note that we use the phrase "you get what you pay for" not just "you		Note that we use the phrase "you get what you pay for" not just "you
	pay for what you get". In Kelly's original formulation, users had to		pay for what you get". In Kelly's original formulation, users had to
	pay for the congestion they caused, which was unlikely to be taken up		pay for the congestion they caused, which was unlikely to be taken up
	commercially. But the reason we are revitalising Kelly's work is		commercially. But the reason we are revitalising Kelly's work is
	that recent advances (Section 5.3.2) should allow ISPs to keep their		that recent advances (Section 5.3.2) should allow ISPs to keep their
	popular flat fee pricing packages by aiming to ensure that users		popular flat fee pricing packages along with a service level
	cannot cause more congestion costs than their flat fee pays for.		agreement that ensures users cannot cause excessive congestion (e.g.
			not more congestion cost than their flat fee pays for). Note that
			limiting congestion is _not_ congestion pricing, just as a volume cap
			is not volume charging.
	The engineering details of all these commercially realistic systems		The engineering details of all these commercially realistic
	don't have to concern the research or standards communities in		accountability systems don't have to concern the research or
	networking. It is sufficient to design protocols so that congestion		standards communities in networking. It is sufficient to design
	costs _can_ be integrated into one simple counter across different		protocols so that congestion costs _can_ be integrated into one
	flows and across time for some higher layer to use, so that senders		simple counter across different flows and across time for some higher
	_can_ be made accountable for the congestion they cause. Systems and		layer to use, so that senders _can_ be made accountable for the
	protocols intended for Internet deployment do not have to _always_		congestion they cause. Systems and protocols intended for Internet
	realise the sort of fairness over time that we find around us in the		deployment do not have to _always_ realise the sort of fairness over
	real world, but they must _be able_ to.		time that we find around us in the real world, but they must _be
			able_ to.
	This subtle connection with the global economy at every Internet		This subtle connection with the global economy at every Internet
	attachment point ensures that there is no need for some system to		attachment point ensures that there is no need for some system to
	decide how far back the history of each individual's costs should		decide how far back the history of each individual's costs should
	still be taken into account. Once the cost that one entity causes to		still be taken into account. Once the cost that one entity causes to
	others (integrated over time and over all its flows) has been		others (integrated over time and over all its flows) has been
	suffered by that entity itself, it can be forgotten. Just like the		suffered by that entity itself (e.g. by subtracting from a quota), it
	costs for all the other benefits everyone assimilates in their daily		can be forgotten. Just like the costs for all the other benefits
	lives. And the concept of a customer account also naturally ensures		everyone assimilates in their daily lives. And the concept of a
	that a user cannot escape accountability merely by roaming or		customer account also naturally ensures that a user cannot escape
	mobility.		accountability merely by roaming or mobility.
	Finally, note well that this `ISP' and `customer' terminology doesn't		Finally, note well that this `ISP' and `customer' terminology doesn't
	preclude peer-to-peer creations that arbitrate fair use of the		preclude peer-to-peer creations that arbitrate fair use of the
	resources of a self-provided community network [ArchP2pEcon].		resources of a self-provided community network [ArchP2pEcon].
	5.3. Enforcement of Fairness		5.3. Enforcement of Fairness
	5.3.1. Cheating with Whitewashed or Split Flow Identities		5.3.1. Cheating with Whitewashed or Split Flow Identities
	In the real world of deployed networks, if it is easy to cheat the		In the real world of deployed networks, if it is easy to cheat the
	skipping to change at page 16, line 5		skipping to change at page 18, line 40
	whitewashed reputation for its traffic.		whitewashed reputation for its traffic.
	And it's no good imagining that a router will be able to tell which		And it's no good imagining that a router will be able to tell which
	flow IDs are actually all from the same entity (either in the		flow IDs are actually all from the same entity (either in the
	security sense or the economic sense), because routers have to		security sense or the economic sense), because routers have to
	arbitrate between flows emanating from networks many domains away.		arbitrate between flows emanating from networks many domains away.
	They cannot be expected to know which sets of flow identifiers should		They cannot be expected to know which sets of flow identifiers should
	be treated as a single entity. Flows between a pair of IP addresses		be treated as a single entity. Flows between a pair of IP addresses
	may even be attributable to more than one entity, for instance, an IP		may even be attributable to more than one entity, for instance, an IP
	address may be shared by many hundreds of accounts on a Web or e-mail		address may be shared by many hundreds of accounts on a Web or e-mail
	hosting site or behind a NAT.		hosting site or behind a NAT. And anyway, even if entities could be
			identified separately, not all entities are equal, for instance
			compare your granny's PC with a large server.
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|See draft-briscoe-tsvarea-fair-01.pdf version for figure here		|See draft-briscoe-tsvarea-fair-02.pdf version for figure here
	|		|
	|		|
	|		|
	Figure 1: Splitting flow identifiers to cheat against flow rate		Figure 1: Splitting flow identifiers to cheat against flow rate
	fairness.		fairness.
	Bottleneck policers [pBox],[XCHOKe],[AFD], suffer from the same		Bottleneck policers [pBox],[XCHOKe],[AFD], suffer from the same
	inherent problem. They look for a flow ID at a bottleneck that is		inherent problem. They look for a flow ID at a bottleneck that is
	consuming much more bit rate than other flows in order to police use		consuming much more bit rate than other flows in order to police use
	skipping to change at page 17, line 19		skipping to change at page 20, line 16
	"We would guess that the source/destination host pair gives the most		"We would guess that the source/destination host pair gives the most
	appropriate granularity in many circumstances. The granularity of		appropriate granularity in many circumstances. The granularity of
	flows for congestion management is, at least in part, a policy		flows for congestion management is, at least in part, a policy
	question that needs to be addressed in the wider IETF community.".		question that needs to be addressed in the wider IETF community.".
	Given identifiers can generally be freely created in cyberspace, it		Given identifiers can generally be freely created in cyberspace, it
	is well-known that they shouldn't be relied on for resource		is well-known that they shouldn't be relied on for resource
	allocation (or more generally for negative		allocation (or more generally for negative
	reputation) [FrRideP2p],[CheapPseud]. Kelly [wPropFair] chose cost-		reputation) [FrRideP2p],[CheapPseud]. Kelly [wPropFair] chose cost-
	based fairness (his term was `pricing per unit share') because it was		based fairness (his term was `pricing per unit share') because it was
	immune to this problem---it allocates cost to bits not to flows and		immune to this problem--it allocates cost to bits not to flows and
	hence doesn't rely on any cyber-identifiers.		hence doesn't rely on any cyber-identifiers.
	In summary, once one accepts that fairness should be based on		In summary, once one accepts that fairness should be based on
	concepts from social science, fairness can only be meaningful between		concepts from social science, fairness can only be meaningful between
	entities with real-world identities---humans, organisations,		entities with real-world identities--humans, organisations,
	institutions, businesses. Otherwise two entities can claim to have		institutions, businesses. Otherwise two entities can claim to have
	arbitrarily many flows between them, making fairness between flows		arbitrarily many flows between them, making fairness between flows
	completely meaningless.		completely meaningless.
	5.3.2. Enforcing Cost Fairness		5.3.2. Enforcing Cost Fairness
	If enforcing flow rate fairness is impractical, is enforcing cost		If enforcing flow rate fairness is impractical, is enforcing cost
	fairness any more achievable? Happily, the Internet's architecture		fairness any more achievable? Happily, the Internet's architecture
	is already suited to carrying the right cost information for cost		is already suited to carrying the right cost information for cost
	fairness mechanisms to be enforced in a non-co-operative environment.		fairness mechanisms to be enforced in a non-cooperative environment.
	Kelly's stated motivation for his focus on pricing was so that the		Kelly's stated motivation for his focus on pricing was so that the
	system would be applicable to a non-co-operative environment. In		system would be applicable to a non-cooperative environment. In
	1999, Gibbens and Kelly went further, pointing out [Evol_cc] that		1999, Gibbens and Kelly went further, pointing out [Evol_cc] that
	ECN [RFC3168] provided an ideal basis on which to base cost fairness.		ECN [RFC3168] provided an ideal basis on which to base cost fairness.
	The idea was simply for network operators to ECN mark traffic at		The idea was simply for network operators to ECN mark traffic at
	congested routers without regard to flows, then to apply a price to		congested routers without regard to flows, then to apply a price to
	the volume of traffic carrying ECN marks, which would make the		the volume of traffic carrying ECN marks, which would make the
	transport endpoints accountable for the congestion they caused.		transport endpoints accountable for the congestion they caused.
	However, understandably, the idea of Internet retailers charging		However, understandably, the idea of Internet retailers charging
	their end-customers directly for congestion met strong resistance.		their end-customers directly for congestion met strong resistance.
	Customers are known to be highly averse to unpredictable charges for		Customers are known to be highly averse to unpredictable charges for
	services ([PMP] S.5) so duration charging for each Internet flow was		services ([PMP] S.5) so Kelly's duration charging for each Internet
	unlikely to replace flat monthly charging.		flow was unlikely to replace flat monthly charging.
	Many threw out the baby with the bath water, associating Kelly's		Many threw out the baby with the bath water, associating Kelly's
	theoretical work solely with its suggested pricing model. But over		theoretical work solely with its suggested pricing model. But over
	the ensuing years, an active research community has sought to keep		the ensuing years, an active research community has sought to keep
	the underlying theory but wrapped around with a more realistic		the underlying theory but wrapped around with more realistic and
	incarnation.		flexible pricing and service possibilities.
	Indeed the recent proposal called re-ECN [Re-TCP] claims to do just		Indeed the recent proposal called re-ECN [Re-TCP] claims to do just
	that. Here the discussion is confined to whether the economic		that. We will give an overview or re-ECN below, but first we must
	structure and functional effect on the network service that re-ECN		make it absolutely clear that re-ECN shouldn't be equated with cost
	aspires to is valid. If it is, the research agenda should be focused		fairness. Re-ECN could provide one way to achieve cost fairness but
	on producing that outcome, even if re-ECN itself isn't the answer.		other mechanisms might also be feasible. Also re-ECN was designed to
			be able to enforce flow rate fairness as well as cost fairness.
			So here the discussion is confined to whether the economic structure
			and functional effect on the network service that re-ECN aspires to
			is valid. If it is, the research agenda should be focused on
			producing that outcome, even if re-ECN itself isn't the answer.
	(Readers tempted to game re-ECN shouldn't rely on the brief		(Readers tempted to game re-ECN shouldn't rely on the brief
	description here; rather they should use the full spec above, which,		description here; rather they should use the full spec above, which,
	as of early 2007, documents one outstanding vulnerability and		as of mid-2007, documents one outstanding vulnerability and defences
	defences against other known attacks.)		against other known attacks.)
	Re-ECN aims not to constrain retail pricing, requiring no change to		Re-ECN aims not to constrain retail pricing, requiring no change to
	typical flat rate Internet contracts. But it enables addition of a		typical flat rate Internet contracts. But it enables addition of a
	policer that can limit the volume of congestion a customer's sent		policer that can limit the volume of congestion a customer's sent
	traffic causes over, say, a moving month. Thus, if endpoint		traffic causes over, say, a moving month. Thus, if endpoint
	congestion control (e.g. MulTCP [MulTCP]) doesn't voluntarily act		congestion control doesn't voluntarily act fairly the network ingress
	fairly the network ingress can force it to. It is expected that		can force it to. It is expected that various styles of policing
	various styles of policing (including none) will evolve through		(including none) will evolve through market selection. Policing can
	market selection.		be per-user or per flow, but bulk per-user policing is sufficient for
			cost fairness.
	Although Gibbens & Kelly rightly identified that standard ECN reveals		Although Gibbens & Kelly rightly identified that standard ECN reveals
	the necessary information for cost-based fairness, it doesn't reveal		the necessary information for cost-based fairness, it doesn't reveal
	it in the right place for network layer policing---at the _sender's_		it in the right place for network layer policing--at the _sender's_
	network attachment. In the current TCP/IP architecture, congestion		network attachment. In the current TCP/IP architecture, congestion
	information emerges from the end of a forward data path, which is the		information emerges from the end of a forward data path, which is the
	last point in the feedback loop that any network operator can		last point in the feedback loop that any network operator can
	reliably intercept it---the wrong end for policing the sender.		reliably intercept it--the wrong end for policing the sender.
	Re-ECN preserves IP's datagram model, but makes delivery conditional		Re-ECN reveals congestion at the start of a data path while managing
	on the sender `pre-loading' packet streams with enough `credit' to		to preserve IP's connectionless datagram model. It makes delivery
	remain non-negative despite being decremented by congestion		conditional on the sender `pre-loading' packet streams with enough
	experienced along the path. It should then be in _both_ the		`credit' to remain non-negative despite being decremented by
	endpoints' interests for the sender to use a pattern of feedback		congestion experienced along the path. It should then be in _both_
			the endpoints' interests for the sender to use a pattern of feedback
	where the sender re-inserts the feedback from each congestion event		where the sender re-inserts the feedback from each congestion event
	into the next sent packet as a `credit' (re-feedback [Re-fb]). It		into the next sent packet as a `credit' (re-feedback [Re-fb]). It
	should also be in the sender's interest to start every flow slowly		should also be in the sender's interest to start every flow slowly
	and with some initial `credit' while it establishes the path's		and with some initial `credit' while it establishes the path's
	congestion level.		congestion level.
	Like Kelly's original proposal, re-ECN uses ECN routers (and		Like Kelly's original proposal, re-ECN uses ECN routers (and
	receivers) unchanged to ensure the cost of congestion is communicated		receivers) unchanged to ensure the cost of congestion is communicated
	to each transport causing it, precisely in proportion to their bit		to each transport causing it, precisely in proportion to their bit
	rates, without any per-flow processing in the network. But, unlike		rates, without any per-flow processing in the network. But, unlike
	Kelly, sources not receivers are held responsible and the network		Kelly, sources not receivers are held responsible and the network
	cannot raise unsolicited charges without the sender deliberately		cannot raise unsolicited charges without the sender deliberately
	marking packets itself.		marking packets itself.
	Re-ECN also aims to ensure cost-fairness between whole networks.		Re-ECN also aims to ensure cost-fairness between whole networks.
	Because the congestion level in every stream of packets decrements		Because the congestion level in every stream of packets decrements
	towards zero, at an inter-domain border both neighbouring networks		towards zero, at an inter-domain border both neighbouring networks
	can count the bulk volume of congestion that the passing packets are		can count the bulk volume of congestion that the passing packets are
	causing downstream of the border. If the downstream neighbour		causing downstream of the border. If the downstream neighbour
	charges the upstream neighbour this cost (complementing fixed		penalises the upstream neighbour proportionate to this volume of
	capacity charges), the upstream network should in turn want to ensure		congestion (complementing fixed capacity charges), the upstream
	its upstream users (or networks) are accountable for their share of		network should in turn want to ensure its upstream users (or
	these costs arriving from their borders.		networks) are accountable for their share of these costs arriving
			from their borders.
	Each network could choose to share out its downstream costs between		Each network could choose to share out its downstream costs between
	its upstream customers by some other fairness policy than cost		its upstream customers by some other fairness policy than cost
	(including absence of policy, which ensures incremental deployment).		(including absence of policy, which ensures incremental deployment).
	So, on the grander scale, re-ECN aims to ensure that networks have to		So, on the grander scale, re-ECN aims to ensure that networks have to
	be fair to each other, and that different fairness policies can co-		be fair to each other, and that different fairness policies can co-
	exist, which is the subject of the next section.		exist, which is the subject of the next section.
	6. Fairness between Fairnesses		6. Fairness between Fairnesses
	skipping to change at page 19, line 47		skipping to change at page 23, line 6
	`realistic' form of fairness; a form of fairness that people		`realistic' form of fairness; a form of fairness that people
	grudgingly accept they have to live with, where the buyer gets no		grudgingly accept they have to live with, where the buyer gets no
	more than she pays for, at a competitive price that reflects the		more than she pays for, at a competitive price that reflects the
	effort expended by the seller.		effort expended by the seller.
	However, monarchs, governments, charities and so on have also been		However, monarchs, governments, charities and so on have also been
	stamping their own view of fairness on this backdrop, sometimes less		stamping their own view of fairness on this backdrop, sometimes less
	equal sometimes more. But even if different allocation schemes are		equal sometimes more. But even if different allocation schemes are
	chosen locally, perhaps taking account of social inequality, on a		chosen locally, perhaps taking account of social inequality, on a
	global scale arbitration between local views on fairness has largely		global scale arbitration between local views on fairness has largely
	been through market economics---we are not asking anyone to judge		been through market economics--we are not asking anyone to judge
	whether this is good or bad, it just is. The Internet should at		whether this is good or bad, it just is. The Internet should at
	least be able to cope with the world as it is (as well as how it		least be able to cope with the world as it is (as well as how it
	might be). This doesn't imply we believe that economic forces are		might be). This doesn't imply we believe that economic forces are
	somehow above policy control. Rather, we observe that market forces		somehow above policy control. Rather, we observe that market forces
	(aside from wars) have been the default _global_ resource allocation		(aside from wars) have been the default _global_ resource allocation
	mechanism over many centuries. In the Greco-Roman civilisations, in		mechanism over many centuries. In the Greco-Roman civilisations, in
	the Buddhist, Confucian and later in the Islamic world, trade was a		the Buddhist, Confucian and later in the Islamic world, trade was a
	necessary but not central aspect of life. And over the last two		necessary but not central aspect of life. And over the last two
	decades, Western civilisations have been going through a phase of		decades, Western civilisations have been going through a phase of
	`economics imperialism', where attempting to exert policy control		`economics imperialism', where attempting to exert policy control
	over economics is even viewed as counter-productive.		over economics is even viewed as counter-productive.
	However, we must not assume the current globalisation trend [Saul05]		However, we must not assume the current globalisation trend [Saul05]
	heralds the end of history. The Internet should be able to reflect		heralds the end of history. The Internet should be able to reflect
	the shifting of societal forces as different local fairness regimes		the shifting of societal forces as different local fairness regimes
	come and go---`design for tussle' [Tussle]. On the whole,		come and go--`design for tussle' [Tussle]. On the whole,
	interworking of resource allocation between most parts of the		interworking of resource allocation between most parts of the
	Internet must _be able_ to be based on market economics, but it		Internet must _be able_ to be based on market economics, but it
	should be possible to apply other fairness criteria locally. For		should be possible to apply other fairness criteria locally. For
	instance, a University might choose to allocate network resources to		instance, a University might choose to allocate network resources to
	each student equally rather than by how much their parents can		each student equally rather than by how much their parents can
	afford. But the network resources one whole University gets relative		afford. But the network resources one whole University gets relative
	to another institution depend on how much each pays their service		to another institution depend on how much each pays their service
	provider.		provider.
	With arbitration of fairness at the network edge, these enclaves		With arbitration of fairness at the network edge, these enclaves
	where local fairness prevails can be virtual overlays; they need not		where local fairness prevails can be virtual networks of disparate
	align with physical network boundaries. A distance-learning		users; they need not align with physical network boundaries and users
	University or company with a mobile sales-force could buy quotas from		could roam too, with their service level agreement following them. A
	different networks and redistribute the aggregate among its members		distance-learning University or company with a mobile sales-force
	using its own view of fairness. Or whole countries might arrange to		could buy quotas from different networks and redistribute the
	subsidise a minimum universal service obligation for Internet		aggregate among its members using its own view of fairness. Or whole
	_usage_, but still, the country as a whole would be expected to pay		countries might arrange to subsidise a minimum universal service
	its way in the world.		obligation for Internet _usage_, but still, the country as a whole
			would be expected to pay its way in the world.
	On the other hand, in market-led countries, commercial ISPs might		On the other hand, in market-led countries, commercial ISPs might
	solely allocate resources proportionate to customer subscriptions.		solely allocate resources proportionate to customer subscriptions.
	Local pockets of heterogeneity will exist, from computer clubs to		Local pockets of heterogeneity will exist, from computer clubs to
	NATO, but the overall fabric of resource allocation gluing all these		NATO, but the overall fabric of resource allocation gluing all these
	pockets together at the (inter)network layer is likely to be market-		pockets together at the (inter)network layer is likely to be market-
	based.		based.
	This is what we mean by `realistic'---fitting the commercial reality		This is what we mean by `realistic'--fitting the commercial reality
	of a global market economy. We are fully aware that the power of		of a global market economy. We are fully aware that the power of
	market economics can be stretched too far; controlling aspects of		market economics can be stretched too far; controlling aspects of
	society where economic assumptions break down (prompting Samuelson to		society where economic assumptions break down (prompting Samuelson to
	describe Friedman as "...somebody who had learned how to spell banana		describe Friedman as "...somebody who had learned how to spell banana
	but didn't know where to stop" [Swed90]). But we are not advocating		but didn't know where to stop" [Swed90]). But we are not advocating
	that one religion should replace another---market economics replacing		that one religion should replace another--market economics replacing
	flow rate fairness. However, in the case of Internet resource		flow rate fairness. However, in the case of Internet resource
	allocation, it must at least _be possible_ to use market economics,		allocation, it must at least _be possible_ to use market economics,
	despite its known failings, given it is currently the most		despite its known failings, given it is currently the most
	appropriate tool for managing conflicting demands on resources from		appropriate tool for managing conflicting demands on resources from
	any part of the globe.		any part of the globe.
	A market is meant to optimise allocations in the face of conflicts of		A market is meant to optimise allocations in the face of conflicts of
	self-interest. If we want to assert other fairness regimes, we must		self-interest. If we want to assert other fairness regimes, we must
	recognise this acts against self-interest. If we don't understand		recognise this acts against self-interest. If we don't understand
	how to overcome self-interest, its invisible hand will force its will		how to overcome self-interest, its invisible hand will force its will
	skipping to change at page 21, line 40		skipping to change at page 24, line 47
	ways.		ways.
	7. The Seminal Literature		7. The Seminal Literature
	For a rigorous tutorial on the various form of fairness, the reader		For a rigorous tutorial on the various form of fairness, the reader
	is referred to Le Boudec [ccFairTut].		is referred to Le Boudec [ccFairTut].
	Max-min flow rate fairness has a long history in networking, with		Max-min flow rate fairness has a long history in networking, with
	research to find distributed (router-based) max-min algorithms		research to find distributed (router-based) max-min algorithms
	starting in 1980 [DeMaxMin] and Nagle proposing a novel approach in		starting in 1980 [DeMaxMin] and Nagle proposing a novel approach in
	1985 [RFC0970]. All these early `fair queuing' algorithms gave equal		1985 [RFC0970]. All these early `fair queuing' algorithms considered
	rights to each source. In 1989, to solve the problem of some sources		fairness should be considered among sources and that equality implied
	deserving more rate than others, the authors of `weighted fair		fairness. Indeed, in 1984, Jain et al proposed an index of fairness
	queuing' (WFQ) proposed that per-source destination pair would be a		[FairIdx] that quantified how far a set of shares were from equality.
	better model of the size of different sources. It was admitted that
	a source could deny service to other sources by faking transfers with		In 1989, to solve the problem of some sources deserving more rate
	numerous destinations, but a reasonable trade-off between efficiency		than others, the authors of `weighted fair queuing' (WFQ) proposed
	and security was required [WFQ]. Recently, an approach called		that per-source destination pair would be a better model of the size
			of different sources. It was admitted that a source could deny
			service to other sources by faking transfers with numerous
			destinations, but a reasonable trade-off between efficiency and
			security was required [WFQ]. Recently, an approach called
	Justice [Jstce] has proposed a return to (weighted) per source fair		Justice [Jstce] has proposed a return to (weighted) per source fair
	queuing, but with configurable link weights throughout the network.		queuing, but with configurable link weights throughout the network.
	However, all these `fair queuing' approaches allocate bit rate as		However, all these `fair queuing' approaches allocate bit rate as
	their measure of fairness.		their measure of fairness.
	TCP congestion control was also introduced in the late 1980s [TCPcc],		TCP congestion control was also introduced in the late 1980s [TCPcc],
	based on the assumption that it would be fair if flow rates through a		based on the assumption that it would be fair if flow rates through a
	single bottleneck converged on equality.		single bottleneck converged on equality.
	In 1991, Mazumdar _et al_ [UtilFair] pointed out that there was		In 1991, Mazumdar _et al_ [UtilFair] pointed out that there was
	skipping to change at page 23, line 25		skipping to change at page 26, line 35
	traffic: elastic and inelastic, distinguished respectively by their		traffic: elastic and inelastic, distinguished respectively by their
	concave and sigmoid utility functions [FundUtil]. Whatever the		concave and sigmoid utility functions [FundUtil]. Whatever the
	utility function, Kelly teaches us that covering congestion costs is		utility function, Kelly teaches us that covering congestion costs is
	sufficient to achieve fairness. But then the outcome (in terms of		sufficient to achieve fairness. But then the outcome (in terms of
	flow rates) depends on the type of utility function:		flow rates) depends on the type of utility function:
	o Weighted proportionally fair flow rates will be the outcome for		o Weighted proportionally fair flow rates will be the outcome for
	elastic traffic streaming;		elastic traffic streaming;
	o Inelastic traffic flows hit a discontinuity once congestion rises		o Inelastic traffic flows hit a discontinuity once congestion rises
	beyond a certain level, at which point each is better off with		beyond a certain level, at which point no-one derives any useful
	zero rate, leading to a need for some form of admission control,		value unless some are given zero rate, leading to a need for some
	whether self-admission control or arbitrated by the		form of admission control, whether self-admission control or
	network [DCAC]. This was the theoretical backing to the IETF		arbitrated by the network [DCAC]. This was the theoretical
	working group on doing admission control using pre-congestion		backing to the IETF working group recently chartered to
	notification (PCN), which is in the process of being chartered		standardise admission control using pre-congestion notification
	[PCNcharter].		(PCN) [PCNcharter].
	o Key & Massoulie identified a third major class of network traffic		o Key & Massoulie identified a third major class of network traffic
	where utility is derived solely from the duration required to		where utility is derived solely from the duration required to
	complete transfer of a fixed volume of data [UtilFile]. They		complete transfer of a fixed volume of data [UtilFile]. They
	proposed that, if cost fairness applied, self-interested		proposed that, if cost fairness applied, self-interested
	congestion control would toggle between full line rate and zero		congestion control would toggle between full line rate and zero
	(with occasional probes). Such behaviour alone can destabilise		(with occasional probes). Such behaviour alone can destabilise
	the network, but it can be stabilised by mixing with streaming		the network, but it can be stabilised by mixing with streaming
	traffic [FairIntgr]. Research on the second order incentives		traffic [FairIntgr]. Research on the second order incentives
	necessary to encourage stability continues. Policing rather than		necessary to encourage stability continues. Policing rather than
	skipping to change at page 24, line 11		skipping to change at page 27, line 18
	has continued, but the main thrust of research has been to find more		has continued, but the main thrust of research has been to find more
	realistic and practical ways of applying the insights, a process		realistic and practical ways of applying the insights, a process
	which is now bearing fruit (see Section 5.3.2).		which is now bearing fruit (see Section 5.3.2).
	8. Critiques of Specific Schemes		8. Critiques of Specific Schemes
	8.1. Max-min flow rate fairness		8.1. Max-min flow rate fairness
	In 1997, Kelly demonstrated [wPropFair] that realistic users would		In 1997, Kelly demonstrated [wPropFair] that realistic users would
	not choose max-min flow rate fairness if they were accountable for		not choose max-min flow rate fairness if they were accountable for
	the congestion they caused to others. Users would only have chosen		the congestion they caused to others. Users would only choose max-
	max-min if they valued bit rate with an unrealistically extreme set		min if they valued bit rate with an unrealistically extreme set of
	of utility functions that were all identical and that all valued low		utility functions that were all identical and that all valued low bit
	bit rate infinitesimally less than high bit rate. To spell Kelly's		rate infinitesimally less than high bit rate. To spell Kelly's
	result out even more bluntly, max-min fair rate allocation would only		result out even more bluntly, max-min fair rate allocation would only
	be considered fair if _everyone_ valued bit rate in a really weird		be considered fair if _everyone_ valued bit rate in a really weird
	way: that is, they all valued very low bit rate hardly any less than		way: that is, they all valued very low bit rate hardly any less than
	very high bit rate and they all valued bit rate exactly the same as		very high bit rate and they all valued bit rate exactly the same as
	each other. (Note that max-min could be meaningful if allocating		each other. (Note that max-min could be meaningful if allocating
	something like utility among users, but not rate among flows.)		something like utility among users, but not rate among flows.)
	8.2. TCP		8.2. TCP
	TCP's congestion avoidance [RFC2581] leads to a form of fairness		TCP's congestion avoidance [RFC2581] leads to a form of fairness
	similar to cost fairness, except it is myopic, only being concerned		similar to cost fairness, except it is myopic, only being concerned
	with each instant in time and with each flow, as explained in		with each instant in time and with each flow, as explained in
	Section 5. To be cost fair each user would have to take account of		Section 5. To be cost fair each user would have to take account of
	costs across time and across flows, and weight each class of TCP flow		costs across time and across flows, and weight each TCP flow
	according to its importance to them, as can be done with		according to its importance to them, as can be done with
	MulTCP [MulTCP].		MulTCP [MulTCP].
	8.3. TFRC		8.3. TFRC
	An algorithm that converges on the same flow rate as TCP at		An algorithm that converges on the same flow rate as TCP at
	equilibrium is called TCP-friendly. It can only claim to be TCP-		equilibrium is called TCP-friendly. It can only claim to be TCP-
	compatible if it also exhibits the same dynamics as the TCP		compatible if it also exhibits the same dynamics as the TCP
	specification [RFC2581]. Certain streaming applications won't work		specification [RFC2581]. Certain streaming applications won't work
	unless they are allowed a more sluggish response to congestion than		unless they are allowed a more sluggish response to congestion than
	TCP's, so researchers invented TCP-friendly rate control		TCP's, so researchers invented TCP-friendly rate control
	(TFRC [RFC3448]) to define fair use of the network in competition		(TFRC [RFC3448]) to define fair use of the network in competition
	with TCP-compatible flows.		with TCP-compatible flows.
	`TCP-friendly' congestion control currently has proposed standard		`TCP-friendly' congestion control currently has proposed standard
	status in the IETF [RFC3448], and it is incorporated into one of the		status in the IETF [RFC3448], and it is incorporated into one of the
	congestion control profiles of the new datagram congestion control		congestion control profiles of the new datagram congestion control
	protocol (DCCP [RFC4342]) that is also a proposed standard.		protocol (DCCP [RFC4342]) that is also a proposed standard. An
			experimental small packet variant has also been proposed [RFC4828].
	Given TFRC aims to emulate TCP, by far its most significant fairness		Given TFRC aims to emulate TCP, by far its most significant fairness
	problems are those it shares with TCP as just mentioned. However,		problems are those it shares with TCP as just mentioned. However,
	even if we set aside this myopia in time and within flows, TFRC		even if we set aside this myopia in time and within flows, TFRC
	exhibits an extra fairness problem because its design was based		exhibits an extra fairness problem because its design was based
	wholly on the broken idea that it is fair for a TCP-friendly flow to		wholly on the broken idea that it is fair for a TCP-friendly flow to
	get the same rate as a TCP-compatible flow.		get the same rate as a TCP-compatible flow.
	|		|
	|		|
	skipping to change at page 25, line 21		skipping to change at page 28, line 31
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|		|
	|See draft-briscoe-tsvarea-fair-01.pdf version for figure here		|See draft-briscoe-tsvarea-fair-02.pdf version for figure here
	|		|
	|		|
	|		|
	Figure 2: Schematic showing `TCP-friendly' flows cause more		Figure 2: Schematic showing `TCP-friendly' flows cause more
	congestion than TCP. A TCP-friendly flow is smoother than a TCP-		congestion than TCP. A TCP-friendly flow is smoother than a TCP-
	compatible one but with the same mean rate if measured over long		compatible one but with the same mean rate if measured over long
	enough time. Therefore at times of high congestion (t_2) it uses more		enough time. Therefore at times of high congestion (t_2) it uses more
	bandwidth than TCP while at times of low congestion (t_1) it uses		bandwidth than TCP while at times of low congestion (t_1) it uses
	less.		less.
	skipping to change at page 25, line 48		skipping to change at page 29, line 10
	schematic plots of congestion and flow rate are shown as mirror		schematic plots of congestion and flow rate are shown as mirror
	images of each other. A more sluggish rate response is not as good		images of each other. A more sluggish rate response is not as good
	at tracking the fast-changing congestion process. So the sluggish		at tracking the fast-changing congestion process. So the sluggish
	flow more often uses higher bandwidth when congestion is high, and		flow more often uses higher bandwidth when congestion is high, and
	more often uses lower bandwidth when congestion is low, causing more		more often uses lower bandwidth when congestion is low, causing more
	volume of congestion on average. Giving more during times of plenty		volume of congestion on average. Giving more during times of plenty
	doesn't compensate for taking it back during times of scarcity.		doesn't compensate for taking it back during times of scarcity.
	8.4. RTT and Fairness		8.4. RTT and Fairness
	TCP, and congestion controls such as SCTP that inherit from it,		TCP, and congestion controls such as SCTP [RFC2960] that inherit from
	converge on a rate that is inversely proportional to round trip time		it, converge on a rate that is inversely proportional to round trip
	(RTT). This is due to TCP's original design goal of avoiding adding		time (RTT). This is due to TCP's original design goal of avoiding
	more than one segment to the data in flight each RTT.		adding more than one segment to the data in flight each RTT.
	Congestion controls certainly have to take RTT delay in the feedback		Congestion controls certainly have to take RTT delay in the feedback
	loop into account to ensure stability, but RTT is not in itself a		loop into account to ensure stability. Nonetheless, It is perfectly
	factor that affects fairness. In fact, once a sender is accountable		possible to design a robust congestion control that responds more
	for the congestion it causes, it will be in its own interests to be		slowly to changes on longer paths, but still converges to the same
	more cautious on longer RTT paths, as it has proportionately more		rate as it would with a shorter RTT. FAST TCP [FAST] is an example
	data in flight so it risks causing more congestion before it can		of such a congestion control. Siris's weighted window-based
	react.		congestion controller [WindowPropFair] also has dynamics that are
			sensitive to RTT, while converging on a bit-rate that is independent
			of RTT.
	It is perfectly possible to design a robust congestion control that		RTT is not in itself a factor that affects fairness. In fact, once a
	responds more slowly to changes on longer paths, but still converges		sender is accountable for the congestion it causes, it will be in its
	to the same rate as it would with a shorter RTT. FAST TCP [FAST] is		own interests to be more cautious on longer RTT paths, as it has
	an example of such a congestion control. Siris's weighted window-		proportionately more data in flight so it risks causing more
	based congestion controller [WindowPropFair] also has dynamics that		congestion before it can react.
	are sensitive to RTT, while converging on a bit-rate that is
	independent of RTT.
	Broadly the extra risk of causing congestion with larger RTTs is		Broadly the extra risk of causing congestion with larger RTTs is
	usually sufficient to encourage behaviour that leads to stability.		usually sufficient to encourage behaviour that leads to stability.
	However, this gross generalisation needs to be couched in assumptions		However, this gross generalisation needs to be couched in assumptions
	and constraints that are beyond the scope of this memo (and beyond my		and constraints that are beyond the scope of this memo (and beyond my
	ability to keep up with the literature).		ability to keep up with the literature).
	8.5. Packet Size and Fairness		8.5. Packet Size and Fairness
	The issue of how to take packet size into account and whether packet		The issue of how to take packet size into account is covered in
	size should be adjusted for in the network (AQM algorithm) or in the		[BytePktMark]. In summary, it advises that packet size should not be
	transport (rate control algorithm) will be covered in [BytePktMark].		adjusted for in the network (i.e. not in the AQM algorithm), which
			merely drops (marks) every packet with the current drop (marking)
			probability. Instead, the transport (rate control algorithm) should
			take account of the size of lost or ECN marked packets. Essentially
			an ECN marked packet should be treated by the transport as if every
			byte is ECN marked, just as every byte is dropped when a packet it
			dropped.
	8.6. XCP and router-based fairness schemes		8.6. XCP and router-based fairness schemes
	This document has focused on the fairness ideas we see in the		This document has focused on the fairness ideas we see in the
	production networks around us today. However, our most pressing		production networks around us today. However, our most pressing
	concern is that these broken ideas also pervade the community working		concern is that these broken ideas also pervade the community working
	on replacing the Internet architecture. It is well-known that TCP		on replacing the Internet architecture. It is well-known that TCP
	congestion control is running out of dynamic range and many proposals		congestion control is running out of dynamic range and many proposals
	for replacements that can take advantage of higher link capacities by		for replacements that can take advantage of higher link capacities by
	accelerating faster have been put forward. XCP was the first of a		accelerating faster have been put forward. XCP was the first of a
	family of router-based hi-speed congestion control mechanism, but it		family of router-based hi-speed congestion control mechanism, but it
	is particularly of interest because it claims to allow different		is particularly of interest because it claims to allow different
	fairness criteria to be configured.		fairness criteria to be configured.
	However, XCP fairness is based on the myopic flow-rate-based view		However, XCP fairness is based on the myopic flow-rate-based view
	that we have so roundly criticised in this document. For instance,		that we have so roundly criticised in this document. For instance,
	XCP claims to be able to achieve a weighted proportional fair rate		XCP claims to be able to achieve a weighted proportional fair rate
	allocation[XCP] S.6 by adding a weight field to each packet, but it		allocation ([XCP] S.6) by adding a weight field to each packet, but
	glosses over how anyone could regulate each user's choice of the		it glosses over how anyone could regulate each user's choice of the
	weight. If we compare weighted fair XCP with Kelly's original ATM-		weight. If we compare weighted fair XCP with Kelly's original ATM-
	based weighted proportional fairness, the weight parameter advises		based weighted proportional fairness, the weight parameter advises
	network equipment on what allocation it should give each flow, but		network equipment on what allocation it should give each flow, but
	there is no direct congestion information in the XCP protocol that		there is no direct congestion information in the XCP protocol that
	could be used at the ingress to make each source accountable for its		could be used at the ingress to make each source accountable for its
	choice of weight.		choice of weight.
	Further, we believe it will be necessary to be able to apply		Further, we believe it will be necessary to be able to apply
	different fairness criteria to different subsets of users of a		different fairness criteria to different subsets of users of a
	network and subsets across an internetwork as outlined in Section 6.		network and subsets across an internetwork as outlined in Section 6.
	We cannot immediately see how this would be feasible with router-		We cannot immediately see how this would be feasible with router-
	based approaches like XCP, where routers would seem to have to share		based approaches like XCP, where routers would seem to have to know
	information on the history of each user with potentially every other		what sort of fairness each IP address was keeping to, and each router
	router in the world (as explained in Section 5.1).		would seem to have to share information on the history of each user
			with potentially every other router in the world (as explained in
			Section 5.1).
	A combination of XCP's protocol fields could yield approximate		A combination of XCP's protocol fields could yield approximate
	congestion information to integrate each sender's congestion cost		congestion information to integrate each sender's congestion cost
	history at the access network close to the sender. This would allow		history at the access network close to the sender. This would allow
	the user's choice of weight to be regulated and enable different		the user's choice of weight to be regulated and enable different
	forms of fairness to be asserted locally. But one then has to		forms of fairness to be asserted locally. But one then has to
	question whether it would be simpler for the end system to do the		question whether it would be simpler for the end system to do the
	rate control, given it has to give routers all the information they		rate control, given it has to give routers all the information they
	need to arbitrate fairness between flows anyway.		need to arbitrate fairness between flows anyway.
	skipping to change at page 27, line 45		skipping to change at page 31, line 19
	and as sold commercially) would be interesting given features of the		and as sold commercially) would be interesting given features of the
	two approaches overlap even though they don't have the same goals.		two approaches overlap even though they don't have the same goals.
	But this subject would require a dedicated paper.		But this subject would require a dedicated paper.
	9. Implications for the RFC Series		9. Implications for the RFC Series
	This document points out that the question of cost-fairness between		This document points out that the question of cost-fairness between
	congestion controls sits above the transport layer as a policy		congestion controls sits above the transport layer as a policy
	concern. Applications would then exert policy control over		concern. Applications would then exert policy control over
	congestion control in transport protocols (e.g. by setting a		congestion control in transport protocols (e.g. by setting a
	weight). This implies that the IETF is not (and never has been) the		weight). This implies that the IETF should not be (and never has
	arbiter of cost-fairness between its protocols, but it should still		been) the arbiter of cost-fairness between its protocols, but it
	be responsible for their stability and perhaps their efficiency.		should still be responsible for their stability and perhaps their
	This would seem to have wide-ranging implications on the current		efficiency. This contrasts with the current position where the IETF
	approach to congestion control standardisation throughout the IETF's		takes responsibility for the fairness of its congestion control
	RFC series.		algorithms, because they are not under policy control. This would
			seem to have wide-ranging implications on the current approach to
			congestion control standardisation throughout the IETF's RFC series.
	RFCs on congestion control fall into the following categories with		RFCs on congestion control fall into the following categories with
	respect to who is mandated (or encouraged) to do what:		respect to who is mandated (or encouraged) to do what:
	o Those that specify a congestion control algorithm as a building		o Those that specify a congestion control algorithm as a building
	block without specifying where it should be used (e.g. TFRC		block without specifying where it should be used (e.g. TFRC
	[RFC3448]);		[RFC3448] and TFRC-SP [RFC4828]);
	o Those that specify the implementation of congestion control for a		o Those that specify the implementation of congestion control for a
	specific transport which often draw on building block congestion		specific transport which often draw on building block congestion
	controls such as TFRC above or TCP (e.g. TCP [RFC2581], SCTP		controls such as TFRC above or TCP (e.g. TCP [RFC2581], SCTP
	[RFC2960], the DCCP CCIDs [RFC4341][RFC4342] and the RTP profiles		[RFC2960], the DCCP CCIDs [RFC4341][RFC4342] and the RTP profiles
	such as that for RTP/AVP [RFC3551] and RTP/AVPF with earlier		such as that for RTP/AVP [RFC3551] and RTP/AVPF with earlier
	feedback [RFC4585] as well as a number of experimental unicast and		feedback [RFC4585] as well as a number of experimental unicast and
	multicast protocols);		multicast protocols);
	o Those that specify that hosts must implement a particular		o Those that specify that hosts must implement a particular
	skipping to change at page 28, line 26		skipping to change at page 32, line 4
	such as that for RTP/AVP [RFC3551] and RTP/AVPF with earlier		such as that for RTP/AVP [RFC3551] and RTP/AVPF with earlier
	feedback [RFC4585] as well as a number of experimental unicast and		feedback [RFC4585] as well as a number of experimental unicast and
	multicast protocols);		multicast protocols);
	o Those that specify that hosts must implement a particular		o Those that specify that hosts must implement a particular
	transport (e.g. the `Requirements for Internet Hosts' [RFC1122]);		transport (e.g. the `Requirements for Internet Hosts' [RFC1122]);
	o Those that specify what hosts must do if they implement certain		o Those that specify what hosts must do if they implement certain
	congestion control enhancements (e.g. the `Congestion Manager'		congestion control enhancements (e.g. the `Congestion Manager'
	[RFC3124]);		[RFC3124]);
	o Those that specify that applications must implement safe		o Those that specify that applications must implement safe
	congestion control behaviour (e.g. HTTP/1.1 [RFC2616] and RTP		congestion control behaviour (e.g. HTTP/1.1 [RFC2616] and RTP
	[RFC3550]);		[RFC3550]);
	o Those that specify the meaning of congestion notifications and how		o Those that specify the meaning of congestion notifications and how
	buffer implementations should generate them (e.g. recommendations		buffer implementations should generate them (e.g. recommendations
	on AQM [RFC2309] and explicit congestion notification [RFC3168]);		on AQM [RFC2309] and explicit congestion notification [RFC3168]);
	o Those that specify best current practice, guidelines and		o Those that specify best current practice, guidelines and
	principles for implementers of congestion control (e.g. the		principles for designers of congestion control (e.g. the `Gateway
	`Gateway Congestion Control Survey' [RFC1254], recommendations on		Congestion Control Survey' [RFC1254], recommendations on AQM
	AQM [RFC2309], `Congestion Control Principles' [RFC2914], `General		[RFC2309], `Congestion Control Principles' [RFC2914], `General
	Architectural and Policy Considerations' [RFC3426] and IAB		Architectural and Policy Considerations' [RFC3426] and IAB
	Concerns Regarding Congestion Control for Voice Traffic		Concerns Regarding Congestion Control for Voice Traffic
	[RFC3714]);		[RFC3714]);
	o Those that recommend how new transport protocols should interact		o Those that recommend how new transport protocols should interact
	with existing ones (e.g. recommendations on AQM [RFC2309],		with existing ones (e.g. recommendations on AQM [RFC2309],
	Criteria for Evaluating Reliable Multicast Transports [RFC2357]		Criteria for Evaluating Reliable Multicast Transports [RFC2357],
	and `Congestion Control Principles' [RFC2914]).		`Congestion Control Principles' [RFC2914] and guidelines for new
			RTP profiles [RFC3550]).
	Generally, the RFC series standardises congestion control by		Generally, the RFC series standardises congestion control by
	specifying what implementations of a particular transport protocol		specifying what implementations of a particular transport protocol
	should or must do in response to congestion events. RFCs generally		should or must do in response to congestion events. RFCs generally
	avoid mandating what users should do, or what networks should allow,		avoid mandating what users should do, or what networks should allow,
	which are considered policy concerns. For instance, a TCP		which are considered policy concerns. For instance, a TCP
	implementation must comply with the congestion control in RFC2581 to		implementation must comply with the congestion control in RFC2581 to
	be able to claim it is standard TCP, but the RFCs haven't told		be able to claim it is standard TCP, but the RFCs haven't told
	applications that they must use TCP and they certainly haven't told		applications that they must use TCP and they certainly haven't told
	users that they must only use applications that use TCP (or a TCP-		users that they must only use applications that use TCP (or a TCP-
	skipping to change at page 29, line 27		skipping to change at page 33, line 6
	must be available, not that applications must use it.		must be available, not that applications must use it.
	The RFCs that specify that applications (HTTP/1.1 and RTP) must		The RFCs that specify that applications (HTTP/1.1 and RTP) must
	implement safe congestion control behaviour are sufficiently broadly		implement safe congestion control behaviour are sufficiently broadly
	stated that they are still meaningful after a shift of the congestion		stated that they are still meaningful after a shift of the congestion
	control goal-posts.		control goal-posts.
	The RFCs that define congestion notification (RED [RFC2309] and ECN		The RFCs that define congestion notification (RED [RFC2309] and ECN
	[RFC3168]) are critical standards for cost-fairness and they are		[RFC3168]) are critical standards for cost-fairness and they are
	already in line with what is required (except for the uncertainty in		already in line with what is required (except for the uncertainty in
	RFC2309 over byte-mode packet marking, which will be addressed in		RFC2309 over byte-mode packet marking, is addressed in
	[BytePktMark]).		[BytePktMark]).
	The RFCs that specify best current practice, guidelines and		The RFCs that specify best current practice, guidelines and
	principles generally give excellent advice on congestion control.		principles generally give excellent advice on congestion control.
	However, we will have to deal with the RFCs that recommended that		However, we will have to deal with the RFCs that recommended that
	applications should use congestion control that results in a flow		applications should use congestion control that results in a flow
	rate similar to that TCP would achieve under the same conditions,		rate similar to that TCP would achieve under the same conditions,
	specifically [RFC2309][RFC2357] and [RFC2914]. For instance RFC2357		specifically [RFC2309][RFC2357] and [RFC2914]. For instance RFC2357
	says, "Note that congestion control mechanisms that operate on the		says, "Note that congestion control mechanisms that operate on the
	network more aggressively than TCP will face a great burden of proof		network more aggressively than TCP will face a great burden of proof
	that they don't threaten network stability."		that they don't threaten network stability."
	These RFCs were written in good faith based on the idea that the IETF		These RFCs were written in good faith based on the idea that the IETF
	is responsible for fairness between flow rates, but this memo has now		is responsible for fairness between flow rates, but this memo has now
	shown that there is nothing at all special about flow rates that		shown that there is nothing at all special about flow rates that
	happen to be equal when the number of flows from one user and flow		happen to be equal (when the number of flows from one user and flow
	durations are considered. We can safely assume that the IETF		durations are considered). We can safely assume that the IETF
	certainly does not believe it should have any control over the		certainly does not believe it should have any control over the
	duration of flows, or whether a user should open different flows		duration of flows, or whether a user should open different flows
	across different parts of the Internet at different times.		across different parts of the Internet at different times.
	Therefore we will have to update this guidance on fairness to take		Therefore we will have to update this guidance on fairness to take
	account of the desires of users and of networks for a fairer outcome		account of the desires of users and of networks for a fairer outcome
	than we have at present. This guidance will also have to address the		than we have at present. This guidance will also have to address the
	concerns of the users of transports that implement currently		concerns of the users of transports that implement currently
	standardised variants of flow-rate fairness.		standardised variants of flow-rate fairness.
	Some of these `legacy' flows would use more resources and others less		Some of these `legacy' flows would use more resources and others less
	if they were under policy control:		if they were under policy control:
	o A future network that protects careful users from aggressive users		o A future network that protects careful users from aggressive users
	might well curtail some legacy flows from over-aggressive users		might well curtail some legacy flows sent by over-aggressive users
	(e.g. they might be using application that open many TCP		(e.g. they might be using application that open many TCP
	connections that transfer for very long durations).		connections that transfer for very long durations).
	o Those legacy flows that use less than they would under policy		o Those legacy flows that use less than they would under policy
	control seem to be of concern, because they will receive a smaller		control seem to be of concern, because they will receive a smaller
	share of capacity than they would if other flows were not policy-		share of capacity than they would if other flows were not policy-
	controlled. However, they can upgrade to use policy control if		controlled. However, they can upgrade to use policy control if
	they choose, and they have an incentive to do so. The network		they choose, and they have an incentive to do so. The network
	will appear more congested than it used to for these flows, but		will appear more congested than it used to for these flows, but
	they should still _function_ ok, given they were designed to work		they should still _function_ OK, given they were designed to work
	over a best efforts service.		over a best efforts service.
	Nonetheless, we need to discuss this issue further and reach		Nonetheless, we need to discuss this issue further and reach
	community agreement on how best to handle the transition towards the		community agreement on how best to handle the transition towards the
	more rigorous form of fairness introduced in this memo.		different goal of the more rigorous form of fairness introduced in
			this memo, and the transition away from IETF control and towards user
			policy control of fairness.
	10. IANA Considerations		10. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	11. Security Considerations		11. Security Considerations
	The whole of Section 5.3 discusses how there are no known ways of		The whole of Section 5.3 discusses how there are no known ways of
	enforcing flow rate fairness securely in a non-co-operative		enforcing flow rate fairness securely in a non-cooperative
	environment like the current Internet, whereas practical, secure		environment like the current Internet, whereas practical, secure
	solutions have been proposed for enforcing cost-fairness.		solutions have been proposed for enforcing cost-fairness.
	12. Conclusions		12. Conclusions
	The outstanding barrier to realistic resource allocation for the		The outstanding barrier to realistic resource allocation for the
	Internet is purely religious. In much of the networking community		Internet is purely religious. In much of the networking community
	you have to put fairness in terms of flow rates, otherwise your work		you have to put fairness in terms of flow rates, otherwise your work
	is `obviously' irrelevant. At minimum, you are an outcast, if not a		is `obviously' irrelevant. At minimum, you are an outcast, if not a
	heretic. But actually basing fairness on flow rates is a false		heretic. But actually basing fairness on flow rates is a false
	god---it has no grounding in philosophy, science, or for that matter		god--it has no grounding in philosophy, science, or for that matter
	`commercial reality'.		`commercial reality'.
	It is a classic case of a hegemony where those living within the box		It is a classic case of a hegemony where those living within the box
	have been unaware of the existence of the box, let alone the world		have been unaware of the existence of the box, let alone the world
	outside the box. This memo was written from frustration that no-one		outside the box. This memo was written from frustration that no-one
	inside the box believed that voices outside the box should be		inside the box believed that voices outside the box should be
	listened to. We expect complaints about the blunt style of this		listened to. We expect complaints about the blunt style of this
	document, but it seemed the only way forward was to force the issue,		document, but it seemed the only way forward was to force the issue,
	by making the box look ridiculous in its own terms.		by making the box look ridiculous in its own terms.
	Cost fairness was derived from economic concepts of fairness back in		Cost fairness was derived from economic concepts of fairness back in
	1997. Flow rate fairness had been used in good faith as a guiding		1997. Flow rate fairness had been used in good faith as a guiding
	principle, but when it is seen through the wider angle of this		principle, but when it is seen through the wider angle of this
	economic analysis it is clearly broken, even on its own terms. The		economic analysis it is clearly broken, even on its own terms. The
	criticism is far more damning than merely whether allocations are		criticism is far more damning than merely whether allocations are
	fair. Both the thing being allocated (rate) and what it is allocated		fair. Both the thing being allocated (rate) and what it is allocated
	among (flows) now appear completely daft---both unrealistic and		among (flows) now appear completely daft--both unrealistic and
	impractical. However, the Internet community continued to judge		impractical. However, most of the Internet community continued to
	fairness using flow rates, apparently unaware that this approach had		judge fairness using flow rates, apparently unaware that this
	been shown to have no intellectual basis. In fact, flow rate		approach had been shown to have no intellectual basis. In fact, flow
	fairness algorithms are myopic in both space and time---they are		rate fairness algorithms are myopic in both space and time--they are
	completely unable to control fairness at all, because they don't		completely unable to control fairness at all, because they don't
	adjust depending on how many flows users create and for how long.		adjust depending on how many flows users create nor on how long flows
			last.
	To be clear, this accusation applies to the so-called `fairness' that		To be clear, this accusation applies to the so-called `fairness' that
	emerges from the TCP algorithm and the various fair queuing		emerges from the TCP algorithm and the various fair queuing
	algorithms used in production networks. And, more worryingly, this		algorithms used in production networks. And, more worryingly, this
	broken idea of flow rate fairness has carried over into the community		broken idea of flow rate fairness has carried over into the community
	working on replacing the Internet architecture.		working on replacing the Internet architecture.
	In real life, fairness generally concerns costs or benefits. Flow		In real life, fairness generally concerns costs or benefits. Flow
	rate doesn't come anywhere near being a good model of either. User		rate doesn't come anywhere near being a good model of either. User
	benefit per bit rate might be ten orders of magnitude different for		benefit per bit rate might be ten orders of magnitude different for
	skipping to change at page 31, line 49		skipping to change at page 35, line 31
	Worse, there is no evidence whatsoever that fairness between flows		Worse, there is no evidence whatsoever that fairness between flows
	relates in any way to fairness between any real-world entities that		relates in any way to fairness between any real-world entities that
	one would expect to treat fairly, such as people or organisations.		one would expect to treat fairly, such as people or organisations.
	If fairness is defined between flows, users can just create more		If fairness is defined between flows, users can just create more
	flows to get a larger allocation. Worse still, fairness between		flows to get a larger allocation. Worse still, fairness between
	flows is only defined instantaneously, which bears no relation to		flows is only defined instantaneously, which bears no relation to
	real-world fairness over time. Once the idea of fairness based on		real-world fairness over time. Once the idea of fairness based on
	integrating costs over time is understood, we cannot see any reason		integrating costs over time is understood, we cannot see any reason
	to take any form of instantaneous per-flow rate fairness seriously,		to take any form of instantaneous per-flow rate fairness seriously,
	ever again---whether max-min or TCP.		ever again--whether max-min or TCP.
	Even if a system is being designed somehow isolated from the economy,		Even if a system is being designed somehow isolated from the economy,
	where costs will never have to relate to real economic costs, we		where costs will never have to relate to real economic costs, we
	cannot see why anyone would adopt these forms of fairness that so		cannot see why anyone would adopt these forms of fairness that so
	badly relate to real-life fairness. For instance, how can people		badly relate to real-life fairness. For instance, how can people
	still be designing schemes to achieve max-min flow rate fairness		still be designing schemes to achieve max-min flow rate fairness
	years after Kelly's proof that users would have to value bit rate in		years after Kelly's proof that users would have to value bit rate in
	a really weird way in order for max-min fairness to be desirable?		a really weird way in order for max-min fairness to be desirable?
	In contrast, cost fairness promises realistic solutions to all these		In contrast, cost fairness promises realistic solutions to all these
	skipping to change at page 32, line 29		skipping to change at page 36, line 12
	position with reference to some previously respected fairness notions		position with reference to some previously respected fairness notions
	in philosophy or social science. In this memo, we have shown how the		in philosophy or social science. In this memo, we have shown how the
	whole ideology is unlikely to be up to such rigor.		whole ideology is unlikely to be up to such rigor.
	13. Acknowledgements		13. Acknowledgements
	Thanks are due to Scott Shenker for persuading me to write this,		Thanks are due to Scott Shenker for persuading me to write this,
	Louise Burness for insight into why people think the way they do, Ben		Louise Burness for insight into why people think the way they do, Ben
	Strulo for giving a better way of expressing it and Marc Wennink and		Strulo for giving a better way of expressing it and Marc Wennink and
	Damon Wischik for challenging the ideas. Also thanks to Arnaud		Damon Wischik for challenging the ideas. Also thanks to Arnaud
	Jacquet, Jon Crowcroft, Frank Kelly and Peter Key for their useful		Jacquet, Jon Crowcroft, Frank Kelly, Peter Key and Toby Moncaster for
	reviews. And thanks to Michael Welzl and Wes Eddy for their		their useful reviews. Thanks to Michael Welzl and Wes Eddy for their
	excellent survey of Congestion Control in the RFC Series		excellent survey of Congestion Control in the RFC Series
	[I-D.irtf-iccrg-cc-rfcs], on which Section 9 is based. However, the		[I-D.irtf-iccrg-cc-rfcs], on which Section 9 is based. And thanks to
	author alone shoulders the blame for any offence caused by the		the many people on the tsvwg mailing list who have raised questions
	bluntness of style.		or challenged assertions, in the process identifying where clarifying
			amendments were needed. However, the author alone shoulders the
			blame for any offence caused by the bluntness of style.
	14. Comments Solicited		14. Comments Solicited
	Comments and questions are encouraged and very welcome. They can be		Comments and questions are encouraged and very welcome. They can be
	addressed to the IETF Transport Area mailing list		addressed to the IETF Transport Area mailing list
	<tsv-area@ietf.org>, and/or to the authors.		<tsv-area@ietf.org>, and/or to the authors.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	skipping to change at page 33, line 44		skipping to change at page 37, line 28
	20230208.pdf>.		20230208.pdf>.
	[BufSizUp]		[BufSizUp]
	Ganjali, Y. and N. McKeown, "Update on Buffer Sizing in		Ganjali, Y. and N. McKeown, "Update on Buffer Sizing in
	Internet Routers", ACM SIGCOMM CCR 36, October 2006,		Internet Routers", ACM SIGCOMM CCR 36, October 2006,
	<http://www.sigcomm.org/ccr/drupal/?q=node/72>.		<http://www.sigcomm.org/ccr/drupal/?q=node/72>.
	[BytePktMark]		[BytePktMark]
	Briscoe, B., "Byte and Packet Congestion Notification",		Briscoe, B., "Byte and Packet Congestion Notification",
	draft-briscoe-tsvwg-byte-pkt-mark-00 (work in progress),		draft-briscoe-tsvwg-byte-pkt-mark-00 (work in progress),
	March 2007.		June 2007.
	(to appear---work in progress)
	[CheapPseud]		[CheapPseud]
	Friedman, E. and P. Resnick, "The Social Cost of Cheap		Friedman, E. and P. Resnick, "The Social Cost of Cheap
	Pseudonyms", Journal of Economics and Management		Pseudonyms", Journal of Economics and Management
	Strategy 10(2)173--199, 1998.		Strategy 10(2)173--199, 1998.
	[DCAC] Gibbens, R. and F. Kelly, "Distributed connection		[DCAC] Gibbens, R. and F. Kelly, "Distributed connection
	acceptance control for a connectionless network", Proc.		acceptance control for a connectionless network", Proc.
	International Teletraffic Congress (ITC16) pp941--952,		International Teletraffic Congress (ITC16) pp941--952,
	1999, <http://www.statslab.cam.ac.uk/~frank/dcac.html>.		1999, <http://www.statslab.cam.ac.uk/~frank/dcac.html>.
	[DeMaxMin]		[DeMaxMin]
	Jaffe, J., "A Decentralized, "Optimal", Multiple-User,		Jaffe, J., "A Decentralized, "Optimal", Multiple-User,
	Flow Control Algorithm", Proc. Fifth Int'l. Conf. On		Flow Control Algorithm", Proc. Fifth Int'l. Conf. On
	Computer Communications pp839--844, October 1980.		Computer Communications pp839--844, October 1980.
			[ECNFixedWireless]
			Siris, V., "Resource Control for Elastic Traffic in CDMA
			Networks", Proc. ACM MOBICOM'02 , September 2002, <http://
			www.ics.forth.gr/netlab/publications/
			resource_control_elastic_cdma.html>.
	[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the		[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the
	evolution of congestion control", Automatica 35(12)1969--		evolution of congestion control", Automatica 35(12)1969--
	1985, December 1999,		1985, December 1999,
	<http://www.statslab.cam.ac.uk/~frank/evol.html>.		<http://www.statslab.cam.ac.uk/~frank/evol.html>.
	[FAST] Jin, C., Wei, D., and S. Low, "FAST TCP: Motivation,		[FAST] Jin, C., Wei, D., and S. Low, "FAST TCP: Motivation,
	Architecture, Algorithms, and Performance", Proc. IEEE		Architecture, Algorithms, and Performance", Proc. IEEE
	Conference on Computer Communications (Infocom'04) ,		Conference on Computer Communications (Infocom'04) ,
	March 2004,		March 2004,
	<http://www.ieee-infocom.org/2004/Papers/52_2.PDF>.		<http://www.ieee-infocom.org/2004/Papers/52_2.PDF>.
	[FairFAQ] Briscoe, B., "Cost Fairness FAQ", Web page , October 2006,		[FairFAQ] Briscoe, B., "Cost Fairness FAQ", Web page , July 2007, <h
	<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/		ttp://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/
	2020comms/fairfaq.html>.		fairfaq.html>.
			[FairIdx] Jain, R., Chiu, D., and W. Hawe, "A Quantitative Measure
			Of Fairness And Discrimination For Resource Allocation In
			Shared Computer Systems", DEC Research Report TR-301,
			September 1984,
			<http://www.cs.wustl.edu/~jain/papers/fairness.htm>.
	[FairIntgr]		[FairIntgr]
	Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair		Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair
	Internet traffic integration: network flow models and		Internet traffic integration: network flow models and
	analysis", Annales des Telecommunications 59 pp1338--1352,		analysis", Annales des Telecommunications 59 pp1338--1352,
	2004, <http://citeseer.ist.psu.edu/641158.html>.		2004, <http://citeseer.ist.psu.edu/641158.html>.
	[FrRideP2p]		[FrRideP2p]
	Feldman, M., Papadimitriou, C., Chuang, J., and I. Stoica,		Feldman, M., Papadimitriou, C., Chuang, J., and I. Stoica,
	"FreeRiding and Whitewashing in Peer-to-Peer Systems",		"FreeRiding and Whitewashing in Peer-to-Peer Systems",
	skipping to change at page 35, line 22		skipping to change at page 39, line 17
	Sharing TCP", CCR 28(3) 53--69, July 1998, <http://		Sharing TCP", CCR 28(3) 53--69, July 1998, <http://
	www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html>.		www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html>.
	[NewArchReq]		[NewArchReq]
	Braden, R., Clark, D., Shenker, S., and J. Wroclawski,		Braden, R., Clark, D., Shenker, S., and J. Wroclawski,
	"Developing a Next-Generation Internet Architecture",		"Developing a Next-Generation Internet Architecture",
	DARPA white paper , July 2000,		DARPA white paper , July 2000,
	<http://www.isi.edu/newarch/DOCUMENTS/WhitePaper.pdf>.		<http://www.isi.edu/newarch/DOCUMENTS/WhitePaper.pdf>.
	[PCNcharter]		[PCNcharter]
	IESG Secretariat, "WG Review: Congestion and Pre-		IETF, "Congestion and Pre-Congestion Notification (pcn)",
	Congestion Notification (pcn)", Email archive , Feb 2007,		IETF w-g charter , Feb 2007,
	<http://www1.ietf.org/mail-archive/web/ietf-announce/		<http://www.ietf.org/html.charters/pcn-charter.html>.
	current/msg03418.html>.
	[PMP] Odlyzko, A., "A modest proposal for preventing Internet		[PMP] Odlyzko, A., "A modest proposal for preventing Internet
	congestion", AT&T technical report TR 97.35.1,		congestion", AT&T technical report TR 97.35.1,
	September 1997,		September 1997,
	<http://www.dtc.umn.edu/~odlyzko/doc/modest.proposal.pdf>.		<http://www.dtc.umn.edu/~odlyzko/doc/modest.proposal.pdf>.
	[PrCong] MacKie-Mason, J. and H. Varian, "Pricing Congestible		[PrCong] MacKie-Mason, J. and H. Varian, "Pricing Congestible
	Network Resources", IEEE Journal on Selected Areas in		Network Resources", IEEE Journal on Selected Areas in
	Communications, `Advances in the Fundamentals of		Communications, `Advances in the Fundamentals of
	Networking' 13(7)1141--1149, 1995, <http://		Networking' 13(7)1141--1149, 1995, <http://
	skipping to change at page 35, line 48		skipping to change at page 39, line 42
	[RFC0970] Nagle, J., "On packet switches with infinite storage",		[RFC0970] Nagle, J., "On packet switches with infinite storage",
	RFC 970, December 1985.		RFC 970, December 1985.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion		[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion
	Control Survey", RFC 1254, August 1991.		Control Survey", RFC 1254, August 1991.
			[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
			and W. Weiss, "An Architecture for Differentiated
			Services", RFC 2475, December 1998.
	[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion		[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
	Control", RFC 2581, April 1999.		Control", RFC 2581, April 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,		[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
	Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,		Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
	Zhang, L., and V. Paxson, "Stream Control Transmission		Zhang, L., and V. Paxson, "Stream Control Transmission
	skipping to change at page 36, line 47		skipping to change at page 40, line 46
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram Congestion Control Protocol (DCCP) Congestion
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
	March 2006.		March 2006.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	July 2006.		July 2006.
	[Re-TCP] Briscoe, B., Jacquet, A., Salvatori, A., and M. Koyabi,		[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
	"Re-ECN: Adding Accountability for Causing Congestion to		(TFRC): The Small-Packet (SP) Variant", RFC 4828,
	TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-02 (work in		April 2007.
	progress), June 2006.
			[Re-TCP] Briscoe, B., Jacquet, A., Salvatori, A., Koyabi, M., and
			T. Moncaster, "Re-ECN: Adding Accountability for Causing
			Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-04
			(work in progress), July 2007.
	[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,		[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
	Salvatori, A., Soppera, A., and M. Koyabe, "Policing		Salvatori, A., Soppera, A., and M. Koyabe, "Policing
	Congestion Response in an Internetwork Using Re-Feedback",		Congestion Response in an Internetwork Using Re-Feedback",
	ACM SIGCOMM CCR 35(4)277--288, August 2005, <http://		ACM SIGCOMM 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>.
	[Saul05] Saul, J., "The Collapse of Globalism and the Reinvention		[Saul05] Saul, J., "The Collapse of Globalism and the Reinvention
	of the World", Pub: Viking, Canada ISBN: 0-670-06367-3,		of the World", Pub: Viking, Canada ISBN: 0-670-06367-3,
	skipping to change at page 37, line 25		skipping to change at page 41, line 26
	[SelfMan] Kelly, F., "Models for a Self-Managed Internet",		[SelfMan] Kelly, F., "Models for a Self-Managed Internet",
	Philosophical Transactions of the Royal		Philosophical Transactions of the Royal
	Society 358(1773)2335--2348, August 2000,		Society 358(1773)2335--2348, August 2000,
	<http://www.statslab.cam.ac.uk/~frank/smi.html>.		<http://www.statslab.cam.ac.uk/~frank/smi.html>.
	[SovJstce]		[SovJstce]
	Siderenko, S., "Characteristics of Perceptions of Social		Siderenko, S., "Characteristics of Perceptions of Social
	Justice in the Contemporary USSR", Chapter in:		Justice in the Contemporary USSR", Chapter in:
	Transitional Agendas: Working Papers from the Summer		Transitional Agendas: Working Papers from the Summer
	School for Soviet Sociologists Ch3 pp41--45, 1991,		School for Soviet Sociologists, pub: Centre for Social
			Anthropology and Computing, University of Kent Ch3
			pp41--45, 1991,
	<http://lucy.ukc.ac.uk/csacpub/russian/siderenko.html>.		<http://lucy.ukc.ac.uk/csacpub/russian/siderenko.html>.
	[Swed90] Swedberg, R., "Economics and Sociology. Redefining their		[Swed90] Swedberg, R., "Economics and Sociology. Redefining their
	Boundaries: Conversations with Economists and		Boundaries: Conversations with Economists and
	Sociologists", Pub: Princeton University Press , 1990.		Sociologists", Pub: Princeton University Press , 1990.
	[TCPcc] Jacobson, V., "Congestion Avoidance and Control", Proc.		[TCPcc] Jacobson, V. and M. Karels, "Congestion Avoidance and
	ACM SIGCOMM'88 Symposium, Computer Communication		Control", Proc. ACM SIGCOMM'88 Symposium, Computer
	Review 18(4)314--329, August 1988,		Communication Review 18(4)314--329, Proc. ACM SIGCOMM'88
	<ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z>.		Symposium, Computer Communication Review 18(4)314--329,
			August 1988, <http://ee.lbl.gov/papers/congavoid.pdf>.
	[Tussle] Clark, D., Sollins, K., Wroclawski, J., and R. Braden,		[Tussle] Clark, D., Sollins, K., Wroclawski, J., and R. Braden,
	"Tussle in Cyberspace: Defining Tomorrow's Internet", ACM		"Tussle in Cyberspace: Defining Tomorrow's Internet", ACM
	SIGCOMM CCR 32(4)347--356, October 2002,		SIGCOMM CCR 32(4)347--356, October 2002,
	<http://www.acm.org/sigcomm/sigcomm2002/papers/		<http://www.acm.org/sigcomm/sigcomm2002/papers/
	tussle.pdf>.		tussle.pdf>.
	[UtilFair]		[UtilFair]
	Mazumdar, R., Mason, L., and C. Douligeris, "Fairness in		Mazumdar, R., Mason, L., and C. Douligeris, "Fairness in
	Network Optimal Flow Control: Optimality of Product		Network Optimal Flow Control: Optimality of Product
	Forms", IEEE Transactions on Communications 39(5)775--782,		Forms", IEEE Transactions on Communications 39(5)775--782,
	May 1991, <http://dionysos.cs.unipi.gr/~cdoulig/		May 1991, <http://dionysos.cs.unipi.gr/~cdoulig/
	Fairness%20in%20network%20optimal%20flow%20control%		Fairness%20in%20network%20optimal%20flow%20control%
	20optimality%20of%20product%20forms.pdf>.		20optimality%20of%20product%20forms.pdf>.
	[UtilFile]		[UtilFile]
	Key, P. and L. Massoulie, "User policies in a network		Key, P. and L. Massoulie, "User policies in a network
	implementing congestion pricing", Proc. Workshop on		implementing congestion pricing", Proc. Workshop on
	Internet Service Quality and Economics , December 1999,		Internet Service Quality and Economics , December 1999, <h
	<http://www.marengoresearch.com/isqe/index.htm>.		ttp://research.microsoft.com/research/network/
			publications/ISQElm.ps>.
	[WFQ] Demers, A., Keshav, S., and S. Shenker, "Analysis and		[WFQ] Demers, A., Keshav, S., and S. Shenker, "Analysis and
	Simulation of a Fair-Queueing Algorithm", ACM SIGCOMM		Simulation of a Fair-Queueing Algorithm", ACM SIGCOMM
	CCR 19(4)1--12, September 1989,		CCR 19(4)1--12, September 1989,
	<http://portal.acm.org/citation.cfm?id=75248>.		<http://portal.acm.org/citation.cfm?id=75248>.
	[WindowPropFair]		[WindowPropFair]
	Siris, V., "Service Differentiation and Performance of		Siris, V., "Service Differentiation and Performance of
	Weighted Window-Based Congestion Control and Packet		Weighted Window-Based Congestion Control and Packet
	Marking Algorithms in ECN Networks", Computer		Marking Algorithms in ECN Networks", Computer
End of changes. 108 change blocks.
	313 lines changed or deleted		489 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/