draft-briscoe-tsvwg-re-ecn-tcp-motivation-00.txt		draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe
	Internet-Draft BT & UCL		Internet-Draft BT & UCL
	Intended status: Informational A. Jacquet		Intended status: Informational A. Jacquet
	Expires: September 3, 2009 T. Moncaster		Expires: March 22, 2010 T. Moncaster
	A. Smith		A. Smith
	BT		BT
	March 2, 2009		September 18, 2009
	Re-ECN: The Motivation 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-00		draft-briscoe-tsvwg-re-ecn-tcp-motivation-01
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 3, 2009.		This Internet-Draft will expire on March 22, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	This document describes the motivation for 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
	skipping to change at page 31, line 46		skipping to change at page 31, line 46
	* ECN `only' gives a performance improvement. Making a product a		* ECN `only' gives a performance improvement. Making a product a
	bit faster (whether the product is a device or a network),		bit faster (whether the product is a device or a network),
	isn't usually a sufficient selling point to be worth the cost		isn't usually a sufficient selling point to be worth the cost
	of co-ordinating across the industry to deploy it. Network		of co-ordinating across the industry to deploy it. Network
	operators tend to avoid re-configuring a working network unless		operators tend to avoid re-configuring a working network unless
	launching a new product.		launching a new product.
	ECN and Re-ECN for Edge-to-edge Assured QoS:		ECN and Re-ECN for Edge-to-edge Assured QoS:
	We believe the proposal to provide assured QoS sessions using a		We believe the proposal to provide assured QoS sessions using a
	form of ECN called pre-congestion notification (PCN) [PCN-arch] is		form of ECN called pre-congestion notification (PCN) [RFC5559] is
	most likely to break the deadlock in ECN deployment first. It		most likely to break the deadlock in ECN deployment first. It
	only requires edge-to-edge deployment so it does not require		only requires edge-to-edge deployment so it does not require
	endpoint support. It can be deployed in a single network, then		endpoint support. It can be deployed in a single network, then
	grow incrementally to interconnected networks. And it provides a		grow incrementally to interconnected networks. And it provides a
	different `product' (internetworked assured QoS), rather than		different `product' (internetworked assured QoS), rather than
	merely making an existing product a bit faster.		merely making an existing product a bit faster.
	Not only could this assured QoS application kick-start ECN		Not only could this assured QoS application kick-start ECN
	deployment, it could also carry re-ECN deployment with it; because		deployment, it could also carry re-ECN deployment with it; because
	re-ECN can enable the assured QoS region to expand to a large		re-ECN can enable the assured QoS region to expand to a large
	skipping to change at page 42, line 49		skipping to change at page 42, line 49
	the TCP Congestion Avoidance Algorithm", ACM SIGCOMM		the TCP Congestion Avoidance Algorithm", ACM SIGCOMM
	CCR 32(3)75-88, July 2002,		CCR 32(3)75-88, July 2002,
	<http://doi.acm.org/10.1145/571697.571725>.		<http://doi.acm.org/10.1145/571697.571725>.
	[Mathis97]		[Mathis97]
	Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The		Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The
	Macroscopic Behavior of the TCP Congestion Avoidance		Macroscopic Behavior of the TCP Congestion Avoidance
	Algorithm", ACM SIGCOMM CCR 27(3)67--82, July 1997,		Algorithm", ACM SIGCOMM CCR 27(3)67--82, July 1997,
	<http://doi.acm.org/10.1145/263932.264023>.		<http://doi.acm.org/10.1145/263932.264023>.
	[PCN-arch]
	Eardley, P., Babiarz, J., Chan, K., Charny, A., Geib, R.,
	Karagiannis, G., Menth, M., and T. Tsou, "Pre-Congestion
	Notification Architecture", draft-ietf-pcn-architecture-09
	(work in progress), February 2008.
	[Purple] Pletka, R., Waldvogel, M., and S. Mannal, "PURPLE:		[Purple] Pletka, R., Waldvogel, M., and S. Mannal, "PURPLE:
	Predictive Active Queue Management Utilizing Congestion		Predictive Active Queue Management Utilizing Congestion
	Information", Proc. Local Computer Networks (LCN 2003) ,		Information", Proc. Local Computer Networks (LCN 2003) ,
	October 2003.		October 2003.
	[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,		[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,
	M., Romanow, A., Weinrib, A., and L. Zhang, "Resource		M., Romanow, A., Weinrib, A., and L. Zhang, "Resource
	ReSerVation Protocol (RSVP) Version 1 Applicability		ReSerVation Protocol (RSVP) Version 1 Applicability
	Statement Some Guidelines on Deployment", RFC 2208,		Statement Some Guidelines on Deployment", RFC 2208,
	September 1997.		September 1997.
	skipping to change at page 43, line 28		skipping to change at page 43, line 22
	RFC 3514, April 2003.		RFC 3514, April 2003.
	[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit		[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
	Congestion Notification (ECN) Signaling with Nonces",		Congestion Notification (ECN) Signaling with Nonces",
	RFC 3540, June 2003.		RFC 3540, June 2003.
	[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion		[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
	Control for Voice Traffic in the Internet", RFC 3714,		Control for Voice Traffic in the Internet", RFC 3714,
	March 2004.		March 2004.
			[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
			Architecture", RFC 5559, January 2008.
	[Re-PCN] Briscoe, B., "Emulating Border Flow Policing using Re-ECN		[Re-PCN] Briscoe, B., "Emulating Border Flow Policing using Re-ECN
	on Bulk Data", draft-briscoe-re-pcn-border-cheat-02 (work		on Bulk Data", draft-briscoe-re-pcn-border-cheat-02 (work
	in progress), February 2008.		in progress), February 2008.
	[Re-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,		[Re-TCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,
	"Re-ECN: Adding Accountability for Causing Congestion to		"Re-ECN: Adding Accountability for Causing Congestion to
	TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-06 (work in		TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-07 (work in
	progress), July 2007.		progress), March 2009.
	[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>.
	[Savage99]		[Savage99]
	Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,		Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
End of changes. 9 change blocks.
	15 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/