< draft-briscoe-tsvwg-re-ecn-tcp-08.txt		draft-briscoe-tsvwg-re-ecn-tcp-09.txt >
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe, Ed.
	Internet-Draft A. Jacquet		Internet-Draft A. Jacquet
	Intended status: Standards Track T. Moncaster		Intended status: Standards Track BT
	Expires: April 3, 2010 A. Smith		Expires: April 28, 2011 T. Moncaster
			Moncaster.com
			A. Smith
	BT		BT
	September 30, 2009		October 25, 2010
	Re-ECN: Adding Accountability for Causing Congestion to TCP/IP		Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
	draft-briscoe-tsvwg-re-ecn-tcp-08		draft-briscoe-tsvwg-re-ecn-tcp-09
	Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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 April 3, 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 introduces a new protocol for explicit congestion		This document introduces a new protocol for explicit congestion
	notification (ECN), termed re-ECN, which can be deployed		notification (ECN), termed re-ECN, which can be deployed
	incrementally around unmodified routers. The protocol works by		incrementally around unmodified routers. The protocol works by
	arranging an extended ECN field in each packet so that, as it crosses		arranging an extended ECN field in each packet so that, as it crosses
	any interface in an internetwork, it will carry a truthful prediction		any interface in an internetwork, it will carry a truthful prediction
	of congestion on the remainder of its path. The purpose of this		of congestion on the remainder of its path. The purpose of this
	document is to specify the re-ECN protocol at the IP layer and to		document is to specify the re-ECN protocol at the IP layer and to
	give guidelines on any consequent changes required to transport		give guidelines on any consequent changes required to transport
	protocols. It includes the changes required to TCP both as an		protocols. It includes the changes required to TCP both as an
	example and as a specification. It briefly gives examples of		example and as a specification. It briefly 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 these are described more fully in a		correctly to congestion, but these are described more fully in a
	companion document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation].		companion document.
	Authors' Statement: Status (to be removed by the RFC Editor)
	Although the re-ECN protocol is intended to make a simple but far-
	reaching change to the Internet architecture, the most immediate
	priority for the authors is to delay any move of the ECN nonce to
	Proposed Standard status. The argument for this position is
	developed in Appendix E.
	Changes from previous drafts (to be removed by the RFC Editor)
	Full diffs from all previous verisons (created using the rfcdiff
	tool) are available at <http://www.bobbriscoe.net/pubs.html#retcp>
	From -07 to -08 (current version):
	Minor changes and consistency checks.		Status of This Memo
	References updated.		This Internet-Draft is submitted in full conformance with the
			provisions of BCP 78 and BCP 79.
	From -06 to -07:		Internet-Drafts are working documents of the Internet Engineering
			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/.
	Major changes made following splitting this protocol document from		Internet-Drafts are draft documents valid for a maximum of six months
	the related motivations document		and may be updated, replaced, or obsoleted by other documents at any
	[I-D.briscoe-tsvwg-re-ecn-tcp-motivation].		time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	Significant re-ordering of remaining text.		This Internet-Draft will expire on April 28, 2011.
	New terminology introduced for clarity.		Copyright Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	Minor editorial changes throughout.		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
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Simplified Re-ECN Protocol . . . . . . . . . . . . . . . . 7		4.1. Simplified Re-ECN Protocol . . . . . . . . . . . . . . . . 6
	4.1.1. Congestion Control and Policing the Protocol . . . . . 7		4.1.1. Congestion Control and Policing the Protocol . . . . . 7
	4.1.2. Background and Applicability . . . . . . . . . . . . . 8		4.1.2. Background and Applicability . . . . . . . . . . . . . 7
	4.2. Re-ECN Abstracted Network Layer Wire Protocol (IPv4 or		4.2. Re-ECN Abstracted Network Layer Wire Protocol (IPv4 or
	v6) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		v6) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Re-ECN Protocol Operation . . . . . . . . . . . . . . . . 10		4.3. Re-ECN Protocol Operation . . . . . . . . . . . . . . . . 10
	4.4. Positive and Negative Flows . . . . . . . . . . . . . . . 12		4.4. Positive and Negative Flows . . . . . . . . . . . . . . . 12
	5. Network Layer . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Network Layer . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Re-ECN IPv4 Wire Protocol . . . . . . . . . . . . . . . . 13		5.1. Re-ECN IPv4 Wire Protocol . . . . . . . . . . . . . . . . 13
	5.2. Re-ECN IPv6 Wire Protocol . . . . . . . . . . . . . . . . 15		5.2. Re-ECN IPv6 Wire Protocol . . . . . . . . . . . . . . . . 15
	5.3. Router Forwarding Behaviour . . . . . . . . . . . . . . . 16		5.3. Router Forwarding Behaviour . . . . . . . . . . . . . . . 16
	5.4. Justification for Setting the First SYN to FNE . . . . . . 17		5.4. Justification for Setting the First SYN to FNE . . . . . . 17
	5.5. Control and Management . . . . . . . . . . . . . . . . . . 18		5.5. Control and Management . . . . . . . . . . . . . . . . . . 18
	skipping to change at page 4, line 4		skipping to change at page 3, line 11
	Partial ACKs . . . . . . . . . . . . . . . . . . . . . 31		Partial ACKs . . . . . . . . . . . . . . . . . . . . . 31
	6.2. Other Transports . . . . . . . . . . . . . . . . . . . . . 31		6.2. Other Transports . . . . . . . . . . . . . . . . . . . . . 31
	6.2.1. General Guidelines for Adding Re-ECN to Other		6.2.1. General Guidelines for Adding Re-ECN to Other
	Transports . . . . . . . . . . . . . . . . . . . . . . 32		Transports . . . . . . . . . . . . . . . . . . . . . . 32
	6.2.2. Guidelines for adding Re-ECN to RSVP or NSIS . . . . . 32		6.2.2. Guidelines for adding Re-ECN to RSVP or NSIS . . . . . 32
	6.2.3. Guidelines for adding Re-ECN to DCCP . . . . . . . . . 32		6.2.3. Guidelines for adding Re-ECN to DCCP . . . . . . . . . 32
	6.2.4. Guidelines for adding Re-ECN to SCTP . . . . . . . . . 33		6.2.4. Guidelines for adding Re-ECN to SCTP . . . . . . . . . 33
	7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 33		7. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 33
	8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 34		8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 34
	8.1. Congestion Notification Integrity . . . . . . . . . . . . 34		8.1. Congestion Notification Integrity . . . . . . . . . . . . 34
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 35		9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37		11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
	13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 38		13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 38
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 38		14.1. Normative References . . . . . . . . . . . . . . . . . . . 38
	14.2. Informative References . . . . . . . . . . . . . . . . . . 39		14.2. Informative References . . . . . . . . . . . . . . . . . . 39
	Appendix A. Precise Re-ECN Protocol Operation . . . . . . . . . . 42		Appendix A. Precise Re-ECN Protocol Operation . . . . . . . . . . 41
	Appendix B. Justification for Two Codepoints Signifying Zero		Appendix B. Justification for Two Codepoints Signifying Zero
	Worth Packets . . . . . . . . . . . . . . . . . . . . 44		Worth Packets . . . . . . . . . . . . . . . . . . . . 42
	Appendix C. ECN Compatibility . . . . . . . . . . . . . . . . . . 45		Appendix C. ECN Compatibility . . . . . . . . . . . . . . . . . . 44
	Appendix D. Packet Marking with FNE During Flow Start . . . . . . 46		Appendix D. Packet Marking with FNE During Flow Start . . . . . . 45
	Appendix E. Argument for holding back the ECN nonce . . . . . . . 48		Appendix E. Argument for holding back the ECN nonce . . . . . . . 47
	Appendix F. Alternative Terminology Used in Other Documents . . . 50		Appendix F. Alternative Terminology Used in Other Documents . . . 49
			Authors' Statement: Status (to be removed by the RFC Editor)
			Although the re-ECN protocol is intended to make a simple but far-
			reaching change to the Internet architecture, the most immediate
			priority for the authors is to delay any move of the ECN nonce to
			Proposed Standard status. The argument for this position is
			developed in Appendix E.
			Changes from previous drafts (to be removed by the RFC Editor)
			Full diffs from all previous verisons (created using the rfcdiff
			tool) are available at <http://www.bobbriscoe.net/pubs.html#retcp>
			From -08 to -09 (current version):
			Re-issued to keep alive for reference by ConEx working group.
			Hardly any changes to content, even where it is out of date,
			except references updated.
			From -07 to -08:
			Minor changes and consistency checks.
			References updated.
			From -06 to -07:
			Major changes made following splitting this protocol document from
			the related motivations document [I-D.tsvwg-re-ecn-motivation].
			Significant re-ordering of remaining text.
			New terminology introduced for clarity.
			Minor editorial changes throughout.
	1. Introduction		1. Introduction
	This document provides a complete specification for the addition of		This document provides a complete specification for the addition of
	the re-ECN protocol to IP and guidelines on how to add it to		the re-ECN protocol to IP and guidelines on how to add it to
	transport layer protocols, including a complete specification of re-		transport layer protocols, including a complete specification of re-
	ECN in TCP as an example. The motivation behind this proposal is		ECN in TCP as an example. The motivation behind this proposal is
	given in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation], but we include a		given in [I-D.tsvwg-re-ecn-motivation], but we include a brief
	brief summary here.		summary here.
	Re-ECN is intended to allow senders to inform the network of the		Re-ECN is intended to allow senders to inform the network of the
	level of congestion they expect their flows to see. This information		level of congestion they expect their flows to see. This information
	is currently only visible at the transport layer. ECN [RFC3168]		is currently only visible at the transport layer. ECN [RFC3168]
	reveals the upstream congestion state of any path by monitoring the		reveals the upstream congestion state of any path by monitoring the
	rate of CE marks. The receiver then informs the sender when they		rate of CE marks. The receiver then informs the sender when they
	have seen a marked packet. Re-ECN builds on ECN by providing new		have seen a marked packet. Re-ECN builds on ECN by providing new
	codepoints that allow the sender to declare the level of congestion		codepoints that allow the sender to declare the level of congestion
	they expect on the forward path. It is closely related to ECN and		they expect on the forward path. It is closely related to ECN and
	indeed we define a compatability mode to allow a re-ECN sender to		indeed we define a compatability mode to allow a re-ECN sender to
	skipping to change at page 6, line 48		skipping to change at page 6, line 38
	o Cancelled packet - a Positive Packet that has been congestion		o Cancelled packet - a Positive Packet that has been congestion
	marked by an ECN or re-ECN queue.		marked by an ECN or re-ECN queue.
	o Cautious packet - a packet that has been marked by the sender to		o Cautious packet - a packet that has been marked by the sender to
	indeiate the expected level of congestion along its path. In		indeiate the expected level of congestion along its path. In
	general Cautious packets should be used when there is insufficient		general Cautious packets should be used when there is insufficient
	feedback to be confident about the congestion state of the		feedback to be confident about the congestion state of the
	network.*		network.*
	o * the difference between positive and cautious packets is		* the difference between positive and cautious packets is
	explained in detail later in the document along with guidelines on		explained in detail later in the document along with guidelines on
	the use of Cautious packets.		the use of Cautious packets.
	All the above terms have related IP codepoints as defined in		All the above terms have related IP codepoints as defined in
	(Section 5).		(Section 5).
	4. Protocol Overview		4. Protocol Overview
	4.1. Simplified Re-ECN Protocol		4.1. Simplified Re-ECN Protocol
	skipping to change at page 8, line 6		skipping to change at page 7, line 41
	is being applied by the sender.		is being applied by the sender.
	In general we assume that there will be a policer at the network		In general we assume that there will be a policer at the network
	ingress which can rate limit traffic based on the amount of		ingress which can rate limit traffic based on the amount of
	congestion declared.		congestion declared.
	At the network egress there is a droper which can impose sanctions on		At the network egress there is a droper which can impose sanctions on
	flows that incorrectly declare congestion.		flows that incorrectly declare congestion.
	Policers and droppers are explained in more detail in		Policers and droppers are explained in more detail in
	[I-D.briscoe-tsvwg-re-ecn-tcp-motivation].		[I-D.tsvwg-re-ecn-motivation].
	4.1.2. Background and Applicability		4.1.2. Background and Applicability
	The re-ECN protocol makes no changes and has no effect on the TCP		The re-ECN protocol makes no changes and has no effect on the TCP
	congestion control algorithm or on other rate responses to		congestion control algorithm or on other rate responses to
	congestion. Re-ECN is not a new congestion control protocol, rather		congestion. Re-ECN is not a new congestion control protocol, rather
	it is orthogonal to congestion control itself. Re-ECN is concerned		it is orthogonal to congestion control itself. Re-ECN is concerned
	with revealing information about congestion so that users and		with revealing information about congestion so that users and
	networks can be held accountable for the congestion they cause, or		networks can be held accountable for the congestion they cause, or
	allow to be caused.		allow to be caused.
	skipping to change at page 9, line 37		skipping to change at page 9, line 26
	definition of the actual position of the RE flag in the IPv4 & v6		definition of the actual position of the RE flag in the IPv4 & v6
	headers until Section 5. When we don't need to choose between IPv4		headers until Section 5. When we don't need to choose between IPv4
	and v6 wire protocols it will suffice call it the RE flag.		and v6 wire protocols it will suffice call it the RE flag.
	Unlike the ECN field, the RE flag is intended to be set by the sender		Unlike the ECN field, the RE flag is intended to be set by the sender
	and SHOULD remain unchanged along the path, although it can be read		and SHOULD remain unchanged along the path, although it can be read
	by network elements that understand the re-ECN protocol. It is		by network elements that understand the re-ECN protocol. It is
	feasible that a network element MAY change the setting of the RE		feasible that a network element MAY change the setting of the RE
	flag, perhaps acting as a proxy for an end-point, but such a protocol		flag, perhaps acting as a proxy for an end-point, but such a protocol
	would have to be defined in another specification		would have to be defined in another specification
	(e.g. [I-D.briscoe-re-pcn-border-cheat]).		(e.g. [I-D.re-pcn-border-cheat]).
	Although the RE flag is a separate, single bit field, it can be read		Although the RE flag is a separate, single bit field, it can be read
	as an extension to the two-bit ECN field; the three concatenated bits		as an extension to the two-bit ECN field; the three concatenated bits
	in what we will call the extended ECN field (EECN) giving eight		in what we will call the extended ECN field (EECN) giving eight
	codepoints. We will use the RFC3168 names of the ECN codepoints to		codepoints. We will use the RFC3168 names of the ECN codepoints to
	describe settings of the ECN field when the RE flag setting is "don't		describe settings of the ECN field when the RE flag setting is "don't
	care", but we also define the following six extended ECN codepoint		care", but we also define the following six extended ECN codepoint
	names for when we need to be more specific.		names for when we need to be more specific.
	One of re-ECN's codepoints is an alternative use of the codepoint set		One of re-ECN's codepoints is an alternative use of the codepoint set
	skipping to change at page 16, line 20		skipping to change at page 16, line 20
	5.3. Router Forwarding Behaviour		5.3. Router Forwarding Behaviour
	Re-ECN works well without modifying the forwarding behaviour of any		Re-ECN works well without modifying the forwarding behaviour of any
	routers. However, below, two OPTIONAL changes to forwarding		routers. However, below, two OPTIONAL changes to forwarding
	behaviour are defined which respectively enhance performance and		behaviour are defined which respectively enhance performance and
	improve a router's discrimination against flooding attacks. They are		improve a router's discrimination against flooding attacks. They are
	both OPTIONAL additions that we propose MAY apply by default to all		both OPTIONAL additions that we propose MAY apply by default to all
	Diffserv per-hop scheduling behaviours (PHBs) [RFC2475] and ECN		Diffserv per-hop scheduling behaviours (PHBs) [RFC2475] and ECN
	marking behaviours [RFC3168]. Specifications for PHBs MAY define		marking behaviours [RFC3168]. Specifications for PHBs MAY define
	different forwarding behaviours from this default, but this is not		different forwarding behaviours from this default, but this is not
	required. [I-D.briscoe-re-pcn-border-cheat] is one example.		required. [I-D.re-pcn-border-cheat] is one example.
	FNE indicates ECT:		FNE indicates ECT:
	The FNE codepoint tells a router to assume that the packet was		The FNE codepoint tells a router to assume that the packet was
	sent by an ECN-capable transport (see Section 5.4). Therefore an		sent by an ECN-capable transport (see Section 5.4). Therefore an
	FNE packet MAY be marked rather than dropped. Note that the FNE		FNE packet MAY be marked rather than dropped. Note that the FNE
	codepoint has been intentionally chosen so that, to RFC3168		codepoint has been intentionally chosen so that, to RFC3168
	compliant routers (which do not inspect the RE flag) an FNE packet		compliant routers (which do not inspect the RE flag) an FNE packet
	appears to be Not-ECT so it will be dropped by legacy AQM		appears to be Not-ECT so it will be dropped by legacy AQM
	algorithms.		algorithms.
	A network operator MUST NOT configure a queue to ECN mark rather		A network operator MUST NOT configure a queue to ECN mark rather
	than drop FNE packets unless it can guarantee that FNE packets		than drop FNE packets unless it can guarantee that FNE packets
	will be rate limited, either locally or upstream. The ingress		will be rate limited, either locally or upstream. The ingress
	policers discussed in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]		policers discussed in [I-D.tsvwg-re-ecn-motivation] would count as
	would count as rate limiters for this purpose.		rate limiters for this purpose.
	Preferential Drop: If a re-ECN capable router queue experiences very		Preferential Drop: If a re-ECN capable router queue experiences very
	high load so that it has to drop arriving packets (e.g. a DoS		high load so that it has to drop arriving packets (e.g. a DoS
	attack), it MAY preferentially drop packets within the same		attack), it MAY preferentially drop packets within the same
	Diffserv PHB using the preference order for extended ECN		Diffserv PHB using the preference order for extended ECN
	codepoints given in Table 3. Preferential dropping can be		codepoints given in Table 3. Preferential dropping can be
	difficult to implement on some hardware, but if feasible it would		difficult to implement on some hardware, but if feasible it would
	discriminate against attack traffic if done as part of the overall		discriminate against attack traffic if done as part of the overall
	policing framework of [I-D.briscoe-tsvwg-re-ecn-tcp-motivation].		policing framework of [I-D.tsvwg-re-ecn-motivation]. If nowhere
	If nowhere else, routers at the egress of a network SHOULD		else, routers at the egress of a network SHOULD implement
	implement preferential drop (stronger than the MAY above). For		preferential drop (stronger than the MAY above). For simplicity,
	simplicity, preferences 4 & 5 MAY be merged into one preference		preferences 4 & 5 MAY be merged into one preference level.
	level.
			The tabulated drop preferences are arranged to preserve packets
			with more positive worth (Section 4.4), given senders of positive
			packets must have honestly declared downstream congestion. A full
			treatment of this is provided in the companion document desribing
			the motivation and architecture for re-ECN
			[I-D.tsvwg-re-ecn-motivation] particularly when the application of
			re-ECN to protect against DDoS attacks is described.
	+-------+-----+------------+-------+------------+-------------------+		+-------+-----+------------+-------+------------+-------------------+
	| ECN | RE | Extended | Worth | Drop Pref | Re-ECN meaning |		| ECN | RE | Extended | Worth | Drop Pref | Re-ECN meaning |
	| field | bit | ECN | | (1 = drop | |		| field | bit | ECN | | (1 = drop | |
	| | | codepoint | | 1st) | |		| | | codepoint | | 1st) | |
	+-------+-----+------------+-------+------------+-------------------+		+-------+-----+------------+-------+------------+-------------------+
	| 01 | 0 | Re-Echo | +1 | 5/4 | Re-echoed |		| 01 | 0 | Re-Echo | +1 | 5/4 | Re-echoed |
	| | | | | | congestion and |		| | | | | | congestion and |
	| | | | | | RECT |		| | | | | | RECT |
	| 00 | 1 | FNE | +1 | 4 | Feedback not |		| 00 | 1 | FNE | +1 | 4 | Feedback not |
	skipping to change at page 17, line 30		skipping to change at page 17, line 38
	| 11 | 1 | CE(-1) | -1 | 3 | Congestion |		| 11 | 1 | CE(-1) | -1 | 3 | Congestion |
	| | | | | | experienced |		| | | | | | experienced |
	| 10 | 1 | --CU-- | n/a | 2 | Currently Unused |		| 10 | 1 | --CU-- | n/a | 2 | Currently Unused |
	| 10 | 0 | --- | n/a | 2 | RFC3168 ECN use |		| 10 | 0 | --- | n/a | 2 | RFC3168 ECN use |
	| | | | | | only |		| | | | | | only |
	| 00 | 0 | Not-RECT | n/a | 1 | Not |		| 00 | 0 | Not-RECT | n/a | 1 | Not |
	| | | | | | Re-ECN-capable |		| | | | | | Re-ECN-capable |
	| | | | | | transport |		| | | | | | transport |
	+-------+-----+------------+-------+------------+-------------------+		+-------+-----+------------+-------+------------+-------------------+
	Table 3: Drop Preference of EECN Codepoints (Sorted by `Worth')		Table 3: Drop Preference of EECN Codepoints (Sorted by `Worth')
	The above drop preferences are arranged to preserve packets with
	more positive worth (Section 4.4), given senders of positive
	packets must have honestly declared downstream congestion. A full
	treatment of this is provided in the companion document desribing
	the motivation and architecture for re-ECN
	[I-D.briscoe-tsvwg-re-ecn-tcp-motivation] particularly when the
	application of re-ECN to protect against DDoS attacks is
	described.
	5.4. Justification for Setting the First SYN to FNE		5.4. Justification for Setting the First SYN to FNE
	the initial SYN MUST be set to FNE by Re-ECT client A (Section 6.1.4)		the initial SYN MUST be set to FNE by Re-ECT client A (Section 6.1.4)
	and (Section 5.3) says a queue MAY optionally treat an FNE packet as		and (Section 5.3) says a queue MAY optionally treat an FNE packet as
	ECN capable, so an initial SYN may be marked CE(-1) rather than		ECN capable, so an initial SYN may be marked CE(-1) rather than
	dropped. This seems dangerous, because the sender has not yet		dropped. This seems dangerous, because the sender has not yet
	established whether the receiver is a RFC3168 one that does not		established whether the receiver is a RFC3168 one that does not
	understand congestion marking. It also seems to allow malicious		understand congestion marking. It also seems to allow malicious
	senders to take advantage of ECN marking to avoid so much drop when		senders to take advantage of ECN marking to avoid so much drop when
	skipping to change at page 19, line 19		skipping to change at page 19, line 19
	not aware of. Otherwise, spoof messages could be sent by malicious		not aware of. Otherwise, spoof messages could be sent by malicious
	sources to slow down a sender (c.f. ICMP source quench).		sources to slow down a sender (c.f. ICMP source quench).
	However, the need for this message type is not yet confirmed, as we		However, the need for this message type is not yet confirmed, as we
	are considering how to prevent it being used by malicious senders to		are considering how to prevent it being used by malicious senders to
	scan for droppers and to test their threshold settings. {ToDo:		scan for droppers and to test their threshold settings. {ToDo:
	Complete this section.}		Complete this section.}
	5.5.2. Rate Response Control		5.5.2. Rate Response Control
	As discussed in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation] the		As discussed in [I-D.tsvwg-re-ecn-motivation] the sender's access
	sender's access operator will be expected to use bulk per-user		operator will be expected to use bulk per-user policing, but they
	policing, but they might choose to introduce a per-flow policer. In		might choose to introduce a per-flow policer. In cases where
	cases where operators do introduce per-flow policing, there may be a		operators do introduce per-flow policing, there may be a need for a
	need for a sender to send a request to the ingress policer asking for		sender to send a request to the ingress policer asking for permission
	permission to apply a non-default response to congestion (where TCP-		to apply a non-default response to congestion (where TCP-friendly is
	friendly is assumed to be the default). This would require the		assumed to be the default). This would require the sender to know
	sender to know what message format(s) to use and to be able to		what message format(s) to use and to be able to discover how to
	discover how to address the policer. The required control		address the policer. The required control protocol(s) are outside
	protocol(s) are outside the scope of this document, but will require		the scope of this document, but will require definition elsewhere.
	definition elsewhere.
	The policer is likely to be local to the sender and inline, probably		The policer is likely to be local to the sender and inline, probably
	at the ingress interface to the internetwork. So, discovery should		at the ingress interface to the internetwork. So, discovery should
	not be hard. A variety of control protocols already exist for some		not be hard. A variety of control protocols already exist for some
	widely used rate-responses to congestion. For instance DCCP		widely used rate-responses to congestion. For instance DCCP
	congestion control identifiers (CCIDs [RFC4340]) fulfil this role and		congestion control identifiers (CCIDs [RFC4340]) fulfil this role and
	so does QoS signalling (e.g. and RSVP request for controlled load		so does QoS signalling (e.g. and RSVP request for controlled load
	service is equivalent to a request for no rate response to		service is equivalent to a request for no rate response to
	congestion, but with admission control).		congestion, but with admission control).
	skipping to change at page 28, line 21		skipping to change at page 28, line 21
	merely ECN-capable. This is because FNE indicates the transport is		merely ECN-capable. This is because FNE indicates the transport is
	ECN capable.		ECN capable.
	The original ECN specification [RFC3168] required SYNs and SYN ACKs		The original ECN specification [RFC3168] required SYNs and SYN ACKs
	to use the Not-ECT codepoint of the ECN field. The aim was to		to use the Not-ECT codepoint of the ECN field. The aim was to
	prevent well-known DoS attacks such as SYN flooding being able to		prevent well-known DoS attacks such as SYN flooding being able to
	gain from the advantage that ECN capability afforded over drop at		gain from the advantage that ECN capability afforded over drop at
	ECN-capable routers.		ECN-capable routers.
	For a SYN ACK, Kuzmanovic [RFC5562] has shown that this caution was		For a SYN ACK, Kuzmanovic [RFC5562] has shown that this caution was
	unnecessary, and proposes to allow a SYN ACK to be ECN-capable to		unnecessary, and allows a SYN ACK to be ECN-capable to improve
	improve performance. By stipulating the FNE codepoint for the		performance. By stipulating the FNE codepoint for the initial SYN,
	initial SYN, we comply with RFC3168 in word but not in spirit,		we comply with RFC3168 in word but not in spirit, because we have
	because we have indeed set the ECN field to Not-ECT, but we have		indeed set the ECN field to Not-ECT, but we have extended the ECN
	extended the ECN field with another bit. And it will be seen		field with another bit. And it will be seen (Section 5.3) that we
	(Section 5.3) that we have defined one setting of that bit to mean an		have defined one setting of that bit to mean an ECN-capable
	ECN-capable transport. Therefore, by proposing that the FNE		transport. Therefore, by proposing that the FNE codepoint MUST be
	codepoint MUST be used on the initial SYN of a connection, we have		used on the initial SYN of a connection, we have gone further by
	gone further by proposing to make the initial SYN ECN-capable too.		proposing to make the initial SYN ECN-capable too. Section 5.4
	Section 5.4 justifies deciding to make the initial SYN ECN-capable.		justifies deciding to make the initial SYN ECN-capable.
	Once a TCP half connection is in RECN mode or RECN-Co mode, FNE will		Once a TCP half connection is in RECN mode or RECN-Co mode, FNE will
	have already been set on the initial SYN and possibly the SYN ACK as		have already been set on the initial SYN and possibly the SYN ACK as
	above. But each re-ECN sender will have to set FNE cautiously on a		above. But each re-ECN sender will have to set FNE cautiously on a
	few data packets as well, given a number of packets will usually have		few data packets as well, given a number of packets will usually have
	to be sent before sufficient congestion feedback is received. The		to be sent before sufficient congestion feedback is received. The
	behaviour will be different depending on the mode of the half-		behaviour will be different depending on the mode of the half-
	connection:		connection:
	RECN mode: Given the constraints on TCP's initial window [RFC3390]		RECN mode: Given the constraints on TCP's initial window [RFC3390]
	skipping to change at page 32, line 38		skipping to change at page 32, line 38
	o UDP fire and forget (e.g. DNS)		o UDP fire and forget (e.g. DNS)
	o UDP streaming with no feedback		o UDP streaming with no feedback
	o UDP streaming with feedback		o UDP streaming with feedback
	}		}
	6.2.2. Guidelines for adding Re-ECN to RSVP or NSIS		6.2.2. Guidelines for adding Re-ECN to RSVP or NSIS
	A separate I-D has been submitted [I-D.briscoe-re-pcn-border-cheat]		A separate I-D has been submitted [I-D.re-pcn-border-cheat]
	describing how re-ECN can be used in an edge-to-edge rather than end-		describing how re-ECN can be used in an edge-to-edge rather than end-
	to-end scenario. It can then be used by downstream networks to		to-end scenario. It can then be used by downstream networks to
	police whether upstream networks are blocking new flow reservations		police whether upstream networks are blocking new flow reservations
	when downstream congestion is too high, even though the congestion is		when downstream congestion is too high, even though the congestion is
	in other operators' downstream networks. This relates to current		in other operators' downstream networks. This relates to current
	IETF work on Admission Control over Diffserv using Pre-Congestion		IETF work on Admission Control over Diffserv using Pre-Congestion
	Notification (PCN) [RFC5559].		Notification (PCN) [RFC5559].
	6.2.3. Guidelines for adding Re-ECN to DCCP		6.2.3. Guidelines for adding Re-ECN to DCCP
	skipping to change at page 38, line 20		skipping to change at page 38, line 20
	13. Comments Solicited		13. 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.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words		[I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of Explicit
	for use in RFCs to		Congestion Notification",
	Indicate Requirement		draft-ietf-tsvwg-ecn-tunnel-10 (work
	Levels", BCP 14, RFC 2119,		in progress), August 2010.
	March 1997.
	[RFC2581] Allman, M., Paxson, V.,		[RFC2119] Bradner, S., "Key words for use in
	and W. Stevens, "TCP		RFCs to Indicate Requirement Levels",
	Congestion Control",		BCP 14, RFC 2119, March 1997.
	RFC 2581, April 1999.
	[RFC3168] Ramakrishnan, K., Floyd,		[RFC2581] Allman, M., Paxson, V., and W.
	S., and D. Black, "The		Stevens, "TCP Congestion Control",
	Addition of Explicit		RFC 2581, April 1999.
	Congestion Notification
	(ECN) to IP", RFC 3168,
	September 2001.
	[RFC3390] Allman, M., Floyd, S., and		[RFC3168] Ramakrishnan, K., Floyd, S., and D.
	C. Partridge, "Increasing		Black, "The Addition of Explicit
	TCP's Initial Window",		Congestion Notification (ECN) to IP",
	RFC 3390, October 2002.		RFC 3168, September 2001.
	[RFC4340] Kohler, E., Handley, M.,		[RFC3390] Allman, M., Floyd, S., and C.
	and S. Floyd, "Datagram		Partridge, "Increasing TCP's Initial
	Congestion Control		Window", RFC 3390, October 2002.
	Protocol (DCCP)",
	RFC 4340, March 2006.
	[RFC4341] Floyd, S. and E. Kohler,		[RFC4302] Kent, S., "IP Authentication Header",
	"Profile for Datagram		RFC 4302, December 2005.
	Congestion Control
	Protocol (DCCP) Congestion
	Control ID 2: TCP-like
	Congestion Control",
	RFC 4341, March 2006.
	[RFC4342] Floyd, S., Kohler, E., and		[RFC4305] Eastlake, D., "Cryptographic Algorithm
	J. Padhye, "Profile for		Implementation Requirements for
	Datagram Congestion		Encapsulating Security Payload (ESP)
	Control Protocol (DCCP)		and Authentication Header (AH)",
	Congestion Control ID 3:		RFC 4305, December 2005.
	TCP-Friendly Rate Control
	(TFRC)", RFC 4342,
	March 2006.
	[RFC4960] Stewart, R., "Stream		[RFC4340] Kohler, E., Handley, M., and S. Floyd,
	Control Transmission		"Datagram Congestion Control Protocol
	Protocol", RFC 4960,		(DCCP)", RFC 4340, March 2006.
	September 2007.
	14.2. Informative References		[RFC4341] Floyd, S. and E. Kohler, "Profile for
			Datagram Congestion Control Protocol
			(DCCP) Congestion Control ID 2: TCP-
			like Congestion Control", RFC 4341,
			March 2006.
	[ARI05] Adams, J., Roberts, L.,		[RFC4342] Floyd, S., Kohler, E., and J. Padhye,
	and A. IJsselmuiden,		"Profile for Datagram Congestion
	"Changing the Internet to		Control Protocol (DCCP) Congestion
	Support Real-Time Content		Control ID 3: TCP-Friendly Rate
	Supply from a Large		Control (TFRC)", RFC 4342, March 2006.
	Fraction of Broadband
	Residential Users", BT
	Technology Journal
	(BTTJ) 23(2), April 2005.
	[I-D.briscoe-re-pcn-border-cheat] Briscoe, B., "Emulating		[RFC4960] Stewart, R., "Stream Control
	Border Flow Policing using		Transmission Protocol", RFC 4960,
	Re-PCN on Bulk Data", draf		September 2007.
	t-briscoe-re-pcn-border-
	cheat-02 (work in
	progress), September 2008.
	[I-D.briscoe-tsvwg-re-ecn-tcp-motivation] Briscoe, B., Jacquet, A.,		[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S.,
	Moncaster, T., and A.		and K. Ramakrishnan, "Adding Explicit
	Smith, "Re-ECN: A		Congestion Notification (ECN)
	Framework for adding		Capability to TCP's SYN/ACK Packets",
	Congestion Accountability		RFC 5562, June 2009.
	to TCP/IP", draft-briscoe-
	tsvwg-re-ecn-tcp-
	motivation-01 (work in
	progress), September 2009.
	[I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling		14.2. Informative References
	of Explicit Congestion
	Notification", draft-ietf-
	tsvwg-ecn-tunnel-03 (work
	in progress), July 2009.
	[RFC2309] Braden, B., Clark, D.,		[ARI05] Adams, J., Roberts, L., and A.
	Crowcroft, J., Davie, B.,		IJsselmuiden, "Changing the Internet
	Deering, S., Estrin, D.,		to Support Real-Time Content Supply
	Floyd, S., Jacobson, V.,		from a Large Fraction of Broadband
	Minshall, G., Partridge,		Residential Users", BT Technology
	C., Peterson, L.,		Journal (BTTJ) 23(2), April 2005.
	Ramakrishnan, K., Shenker,
	S., Wroclawski, J., and L.
	Zhang, "Recommendations on
	Queue Management and
	Congestion Avoidance in
	the Internet", RFC 2309,
	April 1998.
	[RFC2475] Blake, S., Black, D.,		[I-D.re-pcn-border-cheat] Briscoe, B., "Emulating Border Flow
	Carlson, M., Davies, E.,		Policing using Re-PCN on Bulk Data",
	Wang, Z., and W. Weiss,		draft-briscoe-re-pcn-border-cheat-03
	"An Architecture for		(work in progress), October 2009.
	Differentiated Services",
	RFC 2475, December 1998.
	[RFC2988] Paxson, V. and M. Allman,		[I-D.tsvwg-re-ecn-motivation] Briscoe, B., Jacquet, A., Moncaster,
	"Computing TCP's		T., and A. Smith, "Re-ECN: A Framework
	Retransmission Timer",		for adding Congestion Accountability
	RFC 2988, November 2000.		to TCP/IP", draft-briscoe-tsvwg-re-
			ecn-tcp-motivation-02 (work in
			progress), October 2010.
	[RFC3124] Balakrishnan, H. and S.		[RFC2309] Braden, B., Clark, D., Crowcroft, J.,
	Seshan, "The Congestion		Davie, B., Deering, S., Estrin, D.,
	Manager", RFC 3124,		Floyd, S., Jacobson, V., Minshall, G.,
	June 2001.		Partridge, C., Peterson, L.,
			Ramakrishnan, K., Shenker, S.,
			Wroclawski, J., and L. Zhang,
			"Recommendations on Queue Management
			and Congestion Avoidance in the
			Internet", RFC 2309, April 1998.
	[RFC3514] Bellovin, S., "The		[RFC2475] Blake, S., Black, D., Carlson, M.,
	Security Flag in the IPv4		Davies, E., Wang, Z., and W. Weiss,
	Header", RFC 3514, April 1		"An Architecture for Differentiated
	2003.		Services", RFC 2475, December 1998.
	[RFC3540] Spring, N., Wetherall, D.,		[RFC2988] Paxson, V. and M. Allman, "Computing
	and D. Ely, "Robust		TCP's Retransmission Timer", RFC 2988,
	Explicit Congestion		November 2000.
	Notification (ECN)
	Signaling with Nonces",
	RFC 3540, June 2003.
	[RFC4301] Kent, S. and K. Seo,		[RFC3124] Balakrishnan, H. and S. Seshan, "The
	"Security Architecture for		Congestion Manager", RFC 3124,
	the Internet Protocol",		June 2001.
	RFC 4301, December 2005.
	[RFC4302] Kent, S., "IP		[RFC3514] Bellovin, S., "The Security Flag in
	Authentication Header",		the IPv4 Header", RFC 3514,
	RFC 4302, December 2005.		April 2003.
	[RFC4305] Eastlake, D.,		[RFC3540] Spring, N., Wetherall, D., and D. Ely,
	"Cryptographic Algorithm		"Robust Explicit Congestion
	Implementation		Notification (ECN) Signaling with
	Requirements for		Nonces", RFC 3540, June 2003.
	Encapsulating Security
	Payload (ESP) and
	Authentication Header
	(AH)", RFC 4305,
	December 2005.
	[RFC5129] Davie, B., Briscoe, B.,		[RFC4301] Kent, S. and K. Seo, "Security
	and J. Tay, "Explicit		Architecture for the Internet
	Congestion Marking in		Protocol", RFC 4301, December 2005.
	MPLS", RFC 5129,
	January 2008.
	[RFC5559] Eardley, P., "Pre-		[RFC5129] Davie, B., Briscoe, B., and J. Tay,
	Congestion Notification		"Explicit Congestion Marking in MPLS",
	(PCN) Architecture",		RFC 5129, January 2008.
	RFC 5559, June 2009.
	[RFC5562] Kuzmanovic, A., Mondal,		[RFC5559] Eardley, P., "Pre-Congestion
	A., Floyd, S., and K.		Notification (PCN) Architecture",
	Ramakrishnan, "Adding		RFC 5559, June 2009.
	Explicit Congestion
	Notification (ECN)
	Capability to TCP's SYN/
	ACK Packets", RFC 5562,
	June 2009.
	[Re-fb] Briscoe, B., Jacquet, A.,		[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-
	Di Cairano-Gilfedder, C.,		Gilfedder, C., Salvatori, A., Soppera,
	Salvatori, A., Soppera,		A., and M. Koyabe, "Policing
	A., and M. Koyabe,		Congestion Response in an Internetwork
	"Policing Congestion		Using Re-Feedback", ACM SIGCOMM
	Response in an		CCR 35(4)277--288, August 2005, <http:
	Internetwork Using Re-
	Feedback", ACM SIGCOMM
	CCR 35(4)277--288,
	August 2005, <http://
	www.acm.org/sigs/sigcomm/
	sigcomm2005/
	techprog.html#session8>.
	[Savage99] Savage, S., Cardwell, N.,		//www.acm.org/sigs/sigcomm/
	Wetherall, D., and T.		sigcomm2005/techprog.html#session8>.
	Anderson, "TCP congestion
	control with a misbehaving
	receiver", ACM SIGCOMM
	CCR 29(5), October 1999, <
	http://
	citeseer.ist.psu.edu/
	savage99tcp.html>.
	[Steps_DoS] Handley, M. and A.		[Savage99] Savage, S., Cardwell, N., Wetherall,
	Greenhalgh, "Steps towards		D., and T. Anderson, "TCP congestion
	a DoS-resistant Internet		control with a misbehaving receiver",
	Architecture", Proc. ACM		ACM SIGCOMM CCR 29(5), October 1999, <
	SIGCOMM workshop on Future		http://citeseer.ist.psu.edu/
	directions in network		savage99tcp.html>.
	architecture (FDNA'04) pp
	49--56, August 2004.
	[tcp-rcv-cheat] Moncaster, T., Briscoe,		[Steps_DoS] Handley, M. and A. Greenhalgh, "Steps
	B., and A. Jacquet, "A TCP		towards a DoS-resistant Internet
	Test to Allow Senders to		Architecture", Proc. ACM SIGCOMM
	Identify Receiver Non-		workshop on Future directions in
	Compliance", draft-		network architecture (FDNA'04) pp
	moncaster-tcpm-rcv-cheat-		49--56, August 2004.
	02 (work in progress),
	November 2007.		[tcp-rcv-cheat] Moncaster, T., Briscoe, B., and A.
			Jacquet, "A TCP Test to Allow Senders
			to Identify Receiver Non-Compliance",
			draft-moncaster-tcpm-rcv-cheat-02
			(work in progress), November 2007.
	Appendix A. Precise Re-ECN Protocol Operation		Appendix A. Precise Re-ECN Protocol Operation
	{ToDo: fix this}		{ToDo: fix this}
	The protocol operation in the middle described in Section 4.3 was an		The protocol operation in the middle described in Section 4.3 was an
	approximation. In fact, standard ECN router marking combines 1% and		approximation. In fact, standard ECN router marking combines 1% and
	2% marking into slightly less than 3% whole-path marking, because		2% marking into slightly less than 3% whole-path marking, because
	routers deliberately mark CE whether or not it has already been		routers deliberately mark CE whether or not it has already been
	marked by another router upstream. So the combined marking fraction		marked by another router upstream. So the combined marking fraction
	skipping to change at page 50, line 29		skipping to change at page 49, line 21
	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.
	Appendix F. Alternative Terminology Used in Other Documents		Appendix F. Alternative Terminology Used in Other Documents
	A number of alternative terms have been used in various documents		A number of alternative terms have been used in various documents
	describign re-feedback and re-ECN. These are set out in the		describing re-feedback and re-ECN. These are set out in the
	following table		following table
	+-------------------+---------------+-------------------------------+		+-------------------+---------------+-------------------------------+
	| Current | EECN | Colour |		| Current | EECN | Colour |
	| Terminology | codepoint | |		| Terminology | codepoint | |
	+-------------------+---------------+-------------------------------+		+-------------------+---------------+-------------------------------+
	| Cautious | FNE | Green |		| Cautious | FNE | Green |
	| Positive | Re-Echo | Black |		| Positive | Re-Echo | Black |
	| Neutral | RECT | Grey |		| Neutral | RECT | Grey |
	| Negative | CE(-1) | Red |		| Negative | CE(-1) | Red |
	skipping to change at page 51, line 7		skipping to change at page 50, line 7
	| Legacy ECN | ECT(0) | White |		| Legacy ECN | ECT(0) | White |
	| Currently Unused | --CU-- | Currently unused |		| Currently Unused | --CU-- | Currently unused |
	| | | |		| | | |
	| Legacy | Not-ECT | White |		| Legacy | Not-ECT | White |
	+-------------------+---------------+-------------------------------+		+-------------------+---------------+-------------------------------+
	Table 7: Alternative re-ECN Terminology		Table 7: Alternative re-ECN Terminology
	Authors' Addresses		Authors' Addresses
	Bob Briscoe		Bob Briscoe (editor)
	BT		BT
	B54/77, Adastral Park		B54/77, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 645196		Phone: +44 1473 645196
	EMail: bob.briscoe@bt.com		EMail: bob.briscoe@bt.com
	URI: http://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. 63 change blocks.
	321 lines changed or deleted		253 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/