< draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt		draft-briscoe-tsvwg-re-ecn-tcp-motivation-02.txt >
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe, Ed.
	Internet-Draft BT & UCL		Internet-Draft A. Jacquet
	Intended status: Informational A. Jacquet		Intended status: Informational BT
	Expires: March 22, 2010 T. Moncaster		Expires: April 28, 2011 T. Moncaster
			Moncaster.com
	A. Smith		A. Smith
	BT		BT
	September 18, 2009		October 25, 2010
	Re-ECN: A Framework for adding Congestion Accountability to TCP/IP		Re-ECN: A Framework for adding Congestion Accountability to TCP/IP
	draft-briscoe-tsvwg-re-ecn-tcp-motivation-01		draft-briscoe-tsvwg-re-ecn-tcp-motivation-02
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 22, 2010.
	Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.
	Abstract		Abstract
	This document describes the framework to support a new protocol for		This document describes the framework to support a new protocol for
	explicit congestion notification (ECN), termed re-ECN, which can be		explicit congestion notification (ECN), termed re-ECN, which can be
	deployed incrementally around unmodified routers. Re-ECN allows		deployed incrementally around unmodified routers. Re-ECN allows
	accurate congestion monitoring throughout the network thus enabling		accurate congestion monitoring throughout the network thus enabling
	the upstream party at any trust boundary in the internetwork to be		the upstream party at any trust boundary in the internetwork to be
	held responsible for the congestion they cause, or allow to be		held responsible for the congestion they cause, or allow to be
	caused. So, networks can introduce straightforward accountability		caused. So, networks can introduce straightforward accountability
	for congestion and policing mechanisms for incoming traffic from end-		for congestion and policing mechanisms for incoming traffic from end-
	customers or from neighbouring network domains. As well as giving		customers or from neighbouring network domains. As well as giving
	the motivation for re-ECN this document also gives examples of		the motivation for re-ECN this document also gives examples of
	mechanisms that can use the protocol to ensure data sources respond		mechanisms that can use the protocol to ensure data sources respond
	correctly to congestion. And it describes example mechanisms that		correctly to congestion. And it describes example mechanisms that
	ensure the dominant selfish strategy of both network domains and end-		ensure the dominant selfish strategy of both network domains and end-
	points will be to use the protocol honestly.		points will be to use the protocol honestly.
	Authors' Statement: Status (to be removed by the RFC Editor)		Status of This Memo
	Although the re-ECN protocol is intended to make a simple but far-		This Internet-Draft is submitted in full conformance with the
	reaching change to the Internet architecture, the most immediate		provisions of BCP 78 and BCP 79.
	priority for the authors is to delay any move of the ECN nonce to
	Proposed Standard status. The argument for this position is		Internet-Drafts are working documents of the Internet Engineering
	developed in Appendix E.		Task Force (IETF). Note that other groups may also distribute
			working documents as Internet-Drafts. The list of current Internet-
			Drafts is at http://datatracker.ietf.org/drafts/current/.
			Internet-Drafts are draft documents valid for a maximum of six months
			and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			This Internet-Draft will expire on April 28, 2011.
			Copyright Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Re-ECN Protocol in Brief . . . . . . . . . . . . . . . . . 5		1.2. Re-ECN Protocol in Brief . . . . . . . . . . . . . . . . . 5
	1.3. The Re-ECN Framework . . . . . . . . . . . . . . . . . . . 7		1.3. The Re-ECN Framework . . . . . . . . . . . . . . . . . . . 6
	1.4. Solving Hard Problems . . . . . . . . . . . . . . . . . . 7		1.4. Solving Hard Problems . . . . . . . . . . . . . . . . . . 7
	1.5. The Rest of this Document . . . . . . . . . . . . . . . . 9		1.5. The Rest of this Document . . . . . . . . . . . . . . . . 8
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 9		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Policing Congestion Response . . . . . . . . . . . . . . . 10		3.1. Policing Congestion Response . . . . . . . . . . . . . . . 9
	3.1.1. The Policing Problem . . . . . . . . . . . . . . . . . 10		3.1.1. The Policing Problem . . . . . . . . . . . . . . . . . 9
	3.1.2. The Case Against Bottleneck Policing . . . . . . . . . 11		3.1.2. The Case Against Bottleneck Policing . . . . . . . . . 10
	4. Re-ECN Incentive Framework . . . . . . . . . . . . . . . . . . 12		4. Re-ECN Incentive Framework . . . . . . . . . . . . . . . . . . 11
	4.1. Revealing Congestion Along the Path . . . . . . . . . . . 12		4.1. Revealing Congestion Along the Path . . . . . . . . . . . 11
	4.1.1. Positive and Negative Flows . . . . . . . . . . . . . 13		4.1.1. Positive and Negative Flows . . . . . . . . . . . . . 13
	4.2. Incentive Framework Overview . . . . . . . . . . . . . . . 14		4.2. Incentive Framework Overview . . . . . . . . . . . . . . . 13
	4.3. Egress Dropper . . . . . . . . . . . . . . . . . . . . . . 18		4.3. Egress Dropper . . . . . . . . . . . . . . . . . . . . . . 17
	4.4. Ingress Policing . . . . . . . . . . . . . . . . . . . . . 19		4.4. Ingress Policing . . . . . . . . . . . . . . . . . . . . . 19
	4.5. Inter-domain Policing . . . . . . . . . . . . . . . . . . 21		4.5. Inter-domain Policing . . . . . . . . . . . . . . . . . . 21
	4.6. Inter-domain Fail-safes . . . . . . . . . . . . . . . . . 25		4.6. Inter-domain Fail-safes . . . . . . . . . . . . . . . . . 24
	4.7. The Case against Classic Feedback . . . . . . . . . . . . 25		4.7. The Case against Classic Feedback . . . . . . . . . . . . 25
	4.8. Simulations . . . . . . . . . . . . . . . . . . . . . . . 27		4.8. Simulations . . . . . . . . . . . . . . . . . . . . . . . 26
	5. Other Applications of Re-ECN . . . . . . . . . . . . . . . . . 27		5. Other Applications of Re-ECN . . . . . . . . . . . . . . . . . 26
	5.1. DDoS Mitigation . . . . . . . . . . . . . . . . . . . . . 27		5.1. DDoS Mitigation . . . . . . . . . . . . . . . . . . . . . 26
	5.2. End-to-end QoS . . . . . . . . . . . . . . . . . . . . . . 28		5.2. End-to-end QoS . . . . . . . . . . . . . . . . . . . . . . 28
	5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 29		5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 28
	5.4. Inter-Provider Service Monitoring . . . . . . . . . . . . 29		5.4. Inter-Provider Service Monitoring . . . . . . . . . . . . 28
	6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 29		6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 28
	7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 30		7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 29
	7.1. Incremental Deployment Features . . . . . . . . . . . . . 30		7.1. Incremental Deployment Features . . . . . . . . . . . . . 29
	7.2. Incremental Deployment Incentives . . . . . . . . . . . . 30		7.2. Incremental Deployment Incentives . . . . . . . . . . . . 30
	8. Architectural Rationale . . . . . . . . . . . . . . . . . . . 35		8. Architectural Rationale . . . . . . . . . . . . . . . . . . . 34
	9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 38		9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 37
	9.1. Policing Rate Response to Congestion . . . . . . . . . . . 38		9.1. Policing Rate Response to Congestion . . . . . . . . . . . 37
	9.2. Congestion Notification Integrity . . . . . . . . . . . . 39		9.2. Congestion Notification Integrity . . . . . . . . . . . . 38
	9.3. Identifying Upstream and Downstream Congestion . . . . . . 40		9.3. Identifying Upstream and Downstream Congestion . . . . . . 39
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 40		10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41		12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
	14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 41		14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 40
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 41		15.1. Normative References . . . . . . . . . . . . . . . . . . . 40
	15.2. Informative References . . . . . . . . . . . . . . . . . . 42		15.2. Informative References . . . . . . . . . . . . . . . . . . 40
	Appendix A. Example Egress Dropper Algorithm . . . . . . . . . . 44		Appendix A. Example Egress Dropper Algorithm . . . . . . . . . . 43
	Appendix B. Policer Designs to ensure Congestion		Appendix B. Policer Designs to ensure Congestion
	Responsiveness . . . . . . . . . . . . . . . . . . . 44		Responsiveness . . . . . . . . . . . . . . . . . . . 43
			B.1. Per-user Policing . . . . . . . . . . . . . . . . . . . . 43
			B.2. Per-flow Rate Policing . . . . . . . . . . . . . . . . . . 45
			Appendix C. Downstream Congestion Metering Algorithms . . . . . . 47
			C.1. Bulk Downstream Congestion Metering Algorithm . . . . . . 47
			C.2. Inflation Factor for Persistently Negative Flows . . . . . 48
			Appendix D. Re-TTL . . . . . . . . . . . . . . . . . . . . . . . 49
			Appendix E. Argument for holding back the ECN nonce . . . . . . . 49
	B.1. Per-user Policing . . . . . . . . . . . . . . . . . . . . 44		Authors' Statement: Status (to be removed by the RFC Editor)
	B.2. Per-flow Rate Policing . . . . . . . . . . . . . . . . . . 46
	Appendix C. Downstream Congestion Metering Algorithms . . . . . . 48		Although the re-ECN protocol is intended to make a simple but far-
	C.1. Bulk Downstream Congestion Metering Algorithm . . . . . . 48		reaching change to the Internet architecture, the most immediate
	C.2. Inflation Factor for Persistently Negative Flows . . . . . 49		priority for the authors is to delay any move of the ECN nonce to
	Appendix D. Re-TTL . . . . . . . . . . . . . . . . . . . . . . . 50		Proposed Standard status. The argument for this position is
	Appendix E. Argument for holding back the ECN nonce . . . . . . . 51		developed in Appendix E.
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document aims to:		This document aims to:
	o Describe the motivation for wanting to introduce re-ECN;		o Describe the motivation for wanting to introduce re-ECN;
	o Provide a very brief description of the protocol;		o Provide a very brief description of the protocol;
	o The framework within which the protocol sits;		o The framework within which the protocol sits;
	skipping to change at page 40, line 39		skipping to change at page 39, line 38
	Purple [Purple] proposes that queues should use the CWR flag in the		Purple [Purple] proposes that queues should use the CWR flag in the
	TCP header of ECN-capable flows to work out path congestion and		TCP header of ECN-capable flows to work out path congestion and
	therefore downstream congestion in a similar way to re-ECN. However,		therefore downstream congestion in a similar way to re-ECN. However,
	because CWR is in the transport layer, it is not always visible to		because CWR is in the transport layer, it is not always visible to
	network layer routers and policers. Purple's motivation was to		network layer routers and policers. Purple's motivation was to
	improve AQM, not policing. But, of course, nodes trying to avoid a		improve AQM, not policing. But, of course, nodes trying to avoid a
	policer would not be expected to allow CWR to be visible.		policer would not be expected to allow CWR to be visible.
	10. Security Considerations		10. Security Considerations
	Security concerns are discussed in the protocol document. What goes		Nearly the whole of this document concerns security.
	here?
	11. IANA Considerations		11. IANA Considerations
	This memo includes no request to IANA (yet). See protocol document		This memo includes no request to IANA.
	for discussion on possible IANA considerations.
	12. Conclusions		12. Conclusions
	{ToDo:}		{ToDo:}
	13. Acknowledgements		13. Acknowledgements
	Sebastien Cazalet and Andrea Soppera contributed to the idea of re-		Sebastien Cazalet and Andrea Soppera contributed to the idea of re-
	feedback. All the following have given helpful comments: Andrea		feedback. All the following have given helpful comments: Andrea
	Soppera, David Songhurst, Peter Hovell, Louise Burness, Phil Eardley,		Soppera, David Songhurst, Peter Hovell, Louise Burness, Phil Eardley,
	skipping to change at page 41, line 36		skipping to change at page 40, line 27
	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 working group's mailing list		addressed to the IETF Transport Area working group's mailing list
	<tsvwg@ietf.org>, and/or to the authors.		<tsvwg@ietf.org>, and/or to the authors.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
	of Explicit Congestion Notification (ECN) to IP",		Addition of Explicit Congestion Notification (ECN)
	RFC 3168, September 2001.		to IP", RFC 3168, September 2001.
	[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram		15.2. Informative References
	Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
	[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion		[Bauer06] Bauer, S., Faratin, P., and R. Beverly, "Assessing
	Control Protocol (DCCP) Congestion Control ID 2: TCP-like		the assumptions underlying mechanism design for the
	Congestion Control", RFC 4341, March 2006.		Internet", Proc. Workshop on the Economics of
			Networked Systems (NetEcon06) , June 2006, <http://
			www.cs.duke.edu/nicl/netecon06/papers/
			ne06-assessing.pdf>.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[CLoop_pol] Salvatori, A., "Closed Loop Traffic Policing",
	Datagram Congestion Control Protocol (DCCP) Congestion		Politecnico Torino and Institut Eurecom Masters
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Thesis , September 2005.
	March 2006.
	15.2. Informative References		[ECN-Deploy] Floyd, S., "ECN (Explicit Congestion Notification)
			in TCP/IP; Implementation and Deployment of ECN",
			Web-page , May 2004, <http://www.icir.org/floyd/
			ecn.html#implementations>.
	[Bauer06] Bauer, S., Faratin, P., and R. Beverly, "Assessing the		[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the
	assumptions underlying mechanism design for the Internet",		evolution of congestion control",
	Proc. Workshop on the Economics of Networked Systems		Automatica 35(12)1969--1985, December 1999,
	(NetEcon06) , June 2006, <http://www.cs.duke.edu/nicl/		<http://www.statslab.cam.ac.uk/~frank/evol.html>.
	netecon06/papers/ne06-assessing.pdf>.
	[CLoop_pol]		[ITU-T.I.371] ITU-T, "Traffic Control and Congestion Control in
	Salvatori, A., "Closed Loop Traffic Policing", Politecnico		B-ISDN", ITU-T Rec. I.371 (03/04), March 2004.
	Torino and Institut Eurecom Masters Thesis ,
	September 2005.
	[ECN-Deploy]		[Jiang02] Jiang, H. and D. Dovrolis, "The Macroscopic
	Floyd, S., "ECN (Explicit Congestion Notification) in		Behavior of the TCP Congestion Avoidance
	TCP/IP; Implementation and Deployment of ECN", Web-page ,		Algorithm", ACM SIGCOMM CCR 32(3)75-88, July 2002,
	May 2004,		<http://doi.acm.org/10.1145/571697.571725>.
	<http://www.icir.org/floyd/ecn.html#implementations>.
	[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and the		[Mathis97] Mathis, M., Semke, J., Mahdavi, J., and T. Ott,
	evolution of congestion control", Automatica 35(12)1969--		"The Macroscopic Behavior of the TCP Congestion
	1985, December 1999,		Avoidance Algorithm", ACM SIGCOMM CCR 27(3)67--82,
	<http://www.statslab.cam.ac.uk/~frank/evol.html>.		July 1997,
			<http://doi.acm.org/10.1145/263932.264023>.
	[ITU-T.I.371]		[Purple] Pletka, R., Waldvogel, M., and S. Mannal, "PURPLE:
	ITU-T, "Traffic Control and Congestion Control in		Predictive Active Queue Management Utilizing
	{B-ISDN}", ITU-T Rec. I.371 (03/04), March 2004.		Congestion Information", Proc. Local Computer
			Networks (LCN 2003) , October 2003.
	[Jiang02] Jiang, H. and D. Dovrolis, "The Macroscopic Behavior of		[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S.,
	the TCP Congestion Avoidance Algorithm", ACM SIGCOMM		O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
	CCR 32(3)75-88, July 2002,		"Resource ReSerVation Protocol (RSVP) Version 1
	<http://doi.acm.org/10.1145/571697.571725>.		Applicability Statement Some Guidelines on
			Deployment", RFC 2208, September 1997.
	[Mathis97]		[RFC3514] Bellovin, S., "The Security Flag in the IPv4
	Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The		Header", RFC 3514, April 2003.
	Macroscopic Behavior of the TCP Congestion Avoidance
	Algorithm", ACM SIGCOMM CCR 27(3)67--82, July 1997,
	<http://doi.acm.org/10.1145/263932.264023>.
	[Purple] Pletka, R., Waldvogel, M., and S. Mannal, "PURPLE:		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
	Predictive Active Queue Management Utilizing Congestion		Explicit Congestion Notification (ECN) Signaling
	Information", Proc. Local Computer Networks (LCN 2003) ,		with Nonces", RFC 3540, June 2003.
	October 2003.
	[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,		[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
	M., Romanow, A., Weinrib, A., and L. Zhang, "Resource		Congestion Control for Voice Traffic in the
	ReSerVation Protocol (RSVP) Version 1 Applicability		Internet", RFC 3714, March 2004.
	Statement Some Guidelines on Deployment", RFC 2208,
	September 1997.
	[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
	RFC 3514, April 2003.		Congestion Control Protocol (DCCP)", RFC 4340,
			March 2006.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Control Protocol (DCCP) Congestion
	RFC 3540, June 2003.		Control ID 2: TCP-like Congestion Control",
			RFC 4341, March 2006.
	[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Control for Voice Traffic in the Internet", RFC 3714,		Datagram Congestion Control Protocol (DCCP)
	March 2004.		Congestion Control ID 3: TCP-Friendly Rate Control
			(TFRC)", RFC 4342, March 2006.
	[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)		[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
	Architecture", RFC 5559, January 2008.		Architecture", RFC 5559, June 2009.
	[Re-PCN] Briscoe, B., "Emulating Border Flow Policing using Re-ECN		[Re-PCN] Briscoe, B., "Emulating Border Flow Policing using
	on Bulk Data", draft-briscoe-re-pcn-border-cheat-02 (work		Re-PCN on Bulk Data",
	in progress), February 2008.		draft-briscoe-re-pcn-border-cheat-03 (work in
			progress), October 2009.
	[Re-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,		[Re-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A.
	"Re-ECN: Adding Accountability for Causing Congestion to		Smith, "Re-ECN: Adding Accountability for Causing
	TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-07 (work in		Congestion to TCP/IP",
	progress), March 2009.		draft-briscoe-tsvwg-re-ecn-tcp-09 (work in
			progress), October 2010.
	[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,
	Congestion Response in an Internetwork Using Re-Feedback",		"Policing Congestion Response in an Internetwork
	ACM SIGCOMM CCR 35(4)277--288, August 2005, <http://		Using Re-Feedback", ACM SIGCOMM CCR 35(4)277--288,
	www.acm.org/sigs/sigcomm/sigcomm2005/		August 2005, <http://www.acm.org/sigs/sigcomm/
	techprog.html#session8>.		sigcomm2005/techprog.html#session8>.
	[Savage99]		[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T.
	Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,		Anderson, "TCP congestion control with a
	"TCP congestion control with a misbehaving receiver", ACM		misbehaving receiver", ACM SIGCOMM CCR 29(5),
	SIGCOMM CCR 29(5), October 1999,		October 1999,
	<http://citeseer.ist.psu.edu/savage99tcp.html>.		<http://citeseer.ist.psu.edu/savage99tcp.html>.
	[Smart_rtg]		[Smart_rtg] Goldenberg, D., Qiu, L., Xie, H., Yang, Y., and Y.
	Goldenberg, D., Qiu, L., Xie, H., Yang, Y., and Y. Zhang,		Zhang, "Optimizing Cost and Performance for
	"Optimizing Cost and Performance for Multihoming", ACM		Multihoming", ACM SIGCOMM CCR 34(4)79--92,
	SIGCOMM CCR 34(4)79--92, October 2004,		October 2004,
	<http://citeseer.ist.psu.edu/698472.html>.		<http://citeseer.ist.psu.edu/698472.html>.
	[Steps_DoS]		[Steps_DoS] Handley, M. and A. Greenhalgh, "Steps towards a
	Handley, M. and A. Greenhalgh, "Steps towards a DoS-		DoS-resistant Internet Architecture", Proc. ACM
	resistant Internet Architecture", Proc. ACM SIGCOMM		SIGCOMM workshop on Future directions in network
	workshop on Future directions in network architecture		architecture (FDNA'04) pp 49--56, August 2004.
	(FDNA'04) pp 49--56, August 2004.
	[Tussle] Clark, D., Sollins, K., Wroclawski, J., and R. Braden,		[Tussle] Clark, D., Sollins, K., Wroclawski, J., and R.
	"Tussle in Cyberspace: Defining Tomorrow's Internet", ACM		Braden, "Tussle in Cyberspace: Defining Tomorrow's
	SIGCOMM CCR 32(4)347--356, October 2002,		Internet", ACM SIGCOMM CCR 32(4)347--356,
	<http://www.acm.org/sigcomm/sigcomm2002/papers/		October 2002, <http://www.acm.org/sigcomm/
	tussle.pdf>.		sigcomm2002/papers/tussle.pdf>.
	[XCHOKe] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar, A.,		[XCHOKe] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar,
	Saran, H., and R. Shorey, "XCHOKe: Malicious Source		A., Saran, H., and R. Shorey, "XCHOKe: Malicious
	Control for Congestion Avoidance at Internet Gateways",		Source Control for Congestion Avoidance at Internet
	Proceedings of IEEE International Conference on Network		Gateways", Proceedings of IEEE International
	Protocols (ICNP-02) , November 2002,		Conference on Network Protocols (ICNP-02) ,
	<http://www.cc.gatech.edu/~akumar/xchoke.pdf>.		November 2002,
			<http://www.cc.gatech.edu/~akumar/xchoke.pdf>.
	[pBox] Floyd, S. and K. Fall, "Promoting the Use of End-to-End		[pBox] Floyd, S. and K. Fall, "Promoting the Use of End-
	Congestion Control in the Internet", IEEE/ACM Transactions		to-End Congestion Control in the Internet", IEEE/
	on Networking 7(4) 458--472, August 1999,		ACM Transactions on Networking 7(4) 458--472,
	<http://www.aciri.org/floyd/end2end-paper.html>.		August 1999,
			<http://www.aciri.org/floyd/end2end-paper.html>.
	[relax-fairness]		[relax-fairness] Briscoe, B., Moncaster, T., and L. Burness,
	Briscoe, B., "Transport Protocols Don't Have To Do		"Problem Statement: Transport Protocols Don't Have
	Fairness", draft-briscoe-tsvwg-relax-fairness-01 (work in		To Do Fairness",
	progress), July 2008.		draft-briscoe-tsvwg-relax-fairness-01 (work in
			progress), July 2008.
	Appendix A. Example Egress Dropper Algorithm		Appendix A. Example Egress Dropper Algorithm
	{ToDo: Write up the basic algorithm with flow state, then the		{ToDo: Write up the basic algorithm with flow state, then the
	aggregated one.}		aggregated one.}
	Appendix B. Policer Designs to ensure Congestion Responsiveness		Appendix B. Policer Designs to ensure Congestion Responsiveness
	B.1. Per-user Policing		B.1. Per-user Policing
	skipping to change at page 53, line 7		skipping to change at page 52, line 7
	The authors are aware that Re-ECN must prove it has the potential it		The authors are aware that Re-ECN must prove it has the potential it
	claims if it is to displace the nonce. Therefore, every effort has		claims if it is to displace the nonce. Therefore, every effort has
	been made to complete a comprehensive specification of Re-ECN so that		been made to complete a comprehensive specification of Re-ECN so that
	its potential can be assessed. We therefore seek the opinion of the		its potential can be assessed. We therefore seek the opinion of the
	Internet community on whether the Re-ECN protocol is sufficiently		Internet community on whether the Re-ECN protocol is sufficiently
	useful to warrant standards action.		useful to warrant standards action.
	Authors' Addresses		Authors' Addresses
	Bob Briscoe		Bob Briscoe (editor)
	BT & UCL		BT
	B54/77, Adastral Park		B54/77, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 645196		Phone: +44 1473 645196
	Email: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/		URI: http://bobbriscoe.net/
	Arnaud Jacquet		Arnaud Jacquet
	BT		BT
	B54/70, Adastral Park		B54/70, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 647284		Phone: +44 1473 647284
	Email: arnaud.jacquet@bt.com		EMail: arnaud.jacquet@bt.com
	URI:		URI:
	Toby Moncaster		Toby Moncaster
	BT		Moncaster.com
	B54/70, Adastral Park		Dukes
	Martlesham Heath		Layer Marney
	Ipswich IP5 3RE		Colchester CO5 9UZ
	UK		UK
	Phone: +44 1473 648734		EMail: toby@moncaster.com
	Email: toby.moncaster@bt.com
	Alan Smith		Alan Smith
	BT		BT
	B54/76, Adastral Park		B54/76, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 640404		Phone: +44 1473 640404
	Email: alan.p.smith@bt.com		EMail: alan.p.smith@bt.com
End of changes. 53 change blocks.
	216 lines changed or deleted		213 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/