draft-briscoe-tsvwg-re-ecn-tcp-07.txt		draft-briscoe-tsvwg-re-ecn-tcp-08.txt
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe
	Internet-Draft BT & UCL		Internet-Draft A. Jacquet
	Intended status: Standards Track A. Jacquet		Intended status: Standards Track T. Moncaster
	Expires: September 4, 2009 T. Moncaster		Expires: April 3, 2010 A. Smith
	A. Smith
	BT		BT
	March 3, 2009		September 30, 2009
	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-07		draft-briscoe-tsvwg-re-ecn-tcp-08
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79. This document may contain material
	have been or will be disclosed, and any of which he or she becomes		from IETF Documents or IETF Contributions published or made publicly
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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		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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	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 4, 2009.		This Internet-Draft will expire on April 3, 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
	skipping to change at page 2, line 19		skipping to change at page 2, line 25
	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,and these are described more fully in a
	companion document [re-ecn-motive].		companion document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation].
	Authors' Statement: Status (to be removed by the RFC Editor)		Authors' Statement: Status (to be removed by the RFC Editor)
	Although the re-ECN protocol is intended to make a simple but far-		Although the re-ECN protocol is intended to make a simple but far-
	reaching change to the Internet architecture, the most immediate		reaching change to the Internet architecture, the most immediate
	priority for the authors is to delay any move of the ECN nonce to		priority for the authors is to delay any move of the ECN nonce to
	Proposed Standard status. The argument for this position is		Proposed Standard status. The argument for this position is
	developed in Appendix E.		developed in Appendix E.
	Changes from previous drafts (to be removed by the RFC Editor)		Changes from previous drafts (to be removed by the RFC Editor)
	Full diffs created using the rfcdiff tool are available at		Full diffs from all previous verisons (created using the rfcdiff
	<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#retcp>		tool) are available at <http://www.bobbriscoe.net/pubs.html#retcp>
	From -06 to -07 (current version):		From -07 to -08 (current version):
			Minor changes and consistency checks.
			References updated.
			From -06 to -07:
	Major changes made following splitting this protocol document from		Major changes made following splitting this protocol document from
	the related motivations document [re-ecn-motive].		the related motivations document
			[I-D.briscoe-tsvwg-re-ecn-tcp-motivation].
	Significant re-ordering of remaining text.		Significant re-ordering of remaining text.
	New terminology introduced for clarity.		New terminology introduced for clarity.
	Minor editorial changes throughout.		Minor editorial changes throughout.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 3, line 38		skipping to change at page 3, line 44
	6. Transport Layers . . . . . . . . . . . . . . . . . . . . . . . 21		6. Transport Layers . . . . . . . . . . . . . . . . . . . . . . . 21
	6.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		6.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.1.1. RECN mode: Full Re-ECN capable transport . . . . . . . 22		6.1.1. RECN mode: Full Re-ECN capable transport . . . . . . . 22
	6.1.2. RECN-Co mode: Re-ECT Sender with a RFC3168		6.1.2. RECN-Co mode: Re-ECT Sender with a RFC3168
	compliant ECN Receiver . . . . . . . . . . . . . . . . 24		compliant ECN Receiver . . . . . . . . . . . . . . . . 24
	6.1.3. Capability Negotiation . . . . . . . . . . . . . . . . 26		6.1.3. Capability Negotiation . . . . . . . . . . . . . . . . 26
	6.1.4. Extended ECN (EECN) Field Settings during Flow		6.1.4. Extended ECN (EECN) Field Settings during Flow
	Start or after Idle Periods . . . . . . . . . . . . . 27		Start or after Idle Periods . . . . . . . . . . . . . 27
	6.1.5. Pure ACKS, Retransmissions, Window Probes and		6.1.5. Pure ACKS, Retransmissions, Window Probes and
	Partial ACKs . . . . . . . . . . . . . . . . . . . . . 31		Partial ACKs . . . . . . . . . . . . . . . . . . . . . 31
	6.2. Other Transports . . . . . . . . . . . . . . . . . . . . . 32		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 . . . . . . . . . 33		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 . . . . . . . . . . 41		Appendix A. Precise Re-ECN Protocol Operation . . . . . . . . . . 42
	Appendix B. Justification for Two Codepoints Signifying Zero		Appendix B. Justification for Two Codepoints Signifying Zero
	Worth Packets . . . . . . . . . . . . . . . . . . . . 43		Worth Packets . . . . . . . . . . . . . . . . . . . . 44
	Appendix C. ECN Compatibility . . . . . . . . . . . . . . . . . . 44		Appendix C. ECN Compatibility . . . . . . . . . . . . . . . . . . 45
	Appendix D. Packet Marking with FNE During Flow Start . . . . . . 45		Appendix D. Packet Marking with FNE During Flow Start . . . . . . 46
	Appendix E. Argument for holding back the ECN nonce . . . . . . . 47		Appendix E. Argument for holding back the ECN nonce . . . . . . . 48
	Appendix F. Alternative Terminology Used in Other Documents . . . 49		Appendix F. Alternative Terminology Used in Other Documents . . . 50
	1. Introduction		1. Introduction
	This document aims to provide a complete specification of the		This document provides a complete specification for the addition of
	addition of the re-ECN protocol to IP and guidelines on how to add it		the re-ECN protocol to IP and guidelines on how to add it to
	to transport layer protocols, including a complete specification of		transport layer protocols, including a complete specification of re-
	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 [re-ecn-motive], but we include a brief summary here.		given in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation], but we include a
			brief 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 5, line 43		skipping to change at page 5, line 44
	re-ECN can solve are much more recognisable than this rather generic		re-ECN can solve are much more recognisable than this rather generic
	statement: mitigating distributed denial of service (DDoS);		statement: mitigating distributed denial of service (DDoS);
	simplifying differentiation of quality of service (QoS); policing		simplifying differentiation of quality of service (QoS); policing
	compliance to congestion control; and so on.		compliance to congestion control; and so on.
	It is important to add a few key points.		It is important to add a few key points.
	o In any stnadard network it always takes one round trip before any		o In any stnadard network it always takes one round trip before any
	feedback is received. For this reason a sender must make a		feedback is received. For this reason a sender must make a
	conservative prediction by transmitting IP packets with a special		conservative prediction by transmitting IP packets with a special
	Cautious marking.		Cautious marking when it is unsure of the state of the network.
	o It should be noted that the prediction is carried in-band in		o It should be noted that the prediction is carried in-band in
	normal data packets and for many transports feedback can be		normal data packets and for many transports feedback can be
	carried in the normal acknowledgements or control packets.		carried in the normal acknowledgements or control packets.
	o The re-ECN protocol is independent of the transport. In TCP,		o The re-ECN protocol is independent of the transport. In TCP,
	acknowledgments are used to convey the feedback from receiver to		acknowledgments are used to convey the feedback from receiver to
	sender. This memo concentrates on TCP as an example transport		sender. This memo concentrates on TCP as an example transport
	protocol, however the re-ECN protocol is compatible with any		protocol, however the re-ECN protocol is compatible with any
	transport where feedback can be sent from receiver to sender.		transport where feedback can be sent from receiver to sender.
	skipping to change at page 7, line 19		skipping to change at page 7, line 21
	We describe here the simplified re-ECN protocol. To simplify the		We describe here the simplified re-ECN protocol. To simplify the
	description we assume packets and segments are synonymous.		description we assume packets and segments are synonymous.
	Packets are sent from a sender to a receiver. In Figure 1 the queues		Packets are sent from a sender to a receiver. In Figure 1 the queues
	(Q1 and Q2) are ECN enabled as per RFC 3168 [RFC3168]. If congestion		(Q1 and Q2) are ECN enabled as per RFC 3168 [RFC3168]. If congestion
	occurs then packets are marked with the congestion experienced (CE)		occurs then packets are marked with the congestion experienced (CE)
	flag exactly as in the ECN protocol [RFC3168]; the routers do not		flag exactly as in the ECN protocol [RFC3168]; the routers do not
	need to be modified and do not need to know the re-ECN protocol. The		need to be modified and do not need to know the re-ECN protocol. The
	receiver constantly informs the sender of the current count of		receiver constantly informs the sender of the current count of
	Positive packets it has seen. The sender uses this information		Negative packets it has seen. The sender uses this information
	determine how many Positive packets it must send into the network.		determine how many Positive packets it must send into the network.
	The receiver's aim is to balance the number of bytes that have been		The receiver's aim is to balance the number of bytes that have been
	congestion marked with the number of Positive bytes it has sent.		congestion marked with the number of Positive bytes it has sent.
	+--------- Feedback----------+		+--------- Feedback----------+
	| |		| |
	v |		v |
	+---+ +----+ +----+ +---+		+---+ +----+ +----+ +---+
	| | | | | | | |		| | | | | | | |
	| S |--->| Q1 |--->| Q2 |--->| R |		| S |--->| Q1 |--->| Q2 |--->| R |
	skipping to change at page 8, line 4		skipping to change at page 8, line 6
	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].
	[re-ecn-motive].
	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.
	Re-ECN builds on ECN so we briefly recap the essentials of the ECN		Re-ECN builds on ECN so we briefly recap the essentials of the ECN
	protocol [RFC3168]. Two bits in the IP protocol (v4 or v6) are		protocol [RFC3168]. Two bits in the IP protocol (v4 or v6) are
	assigned to the ECN field. The sender clears the field to "00" (Not-		assigned to the ECN field. The sender clears the field to "00" (Not-
	ECT) if either end-point transport is not ECN-capable. Otherwise it		ECT) if either end-point transport is not ECN-capable. Otherwise it
	indicates an ECN-capable transport (ECT) using either of the two		indicates an ECN-capable transport (ECT) using either of the two
	skipping to change at page 9, line 35		skipping to change at page 9, line 36
	defines a new re-ECN extension (RE) flag. We will defer the		defines a new re-ECN extension (RE) flag. We will defer the
	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 (e.g. [Re-PCN]).		would have to be defined in another specification
			(e.g. [I-D.briscoe-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
	aside in RFC3168 for the ECN nonce (ECT(1)). Transports using re-ECN		aside in RFC3168 for the ECN nonce (ECT(1)). Transports using re-ECN
	do not need to use the ECN nonce as long as the sender is also		do not need to use the ECN nonce as long as the sender is also
	checking for transport protocol compliance		checking for transport protocol compliance [tcp-rcv-cheat]. The case
	[I-D.moncaster-tcpm-rcv-cheat]. The case for doing this is given in		for doing this is given in Appendix E. Two re-ECN codepoints are
	Appendix E. Two re-ECN codepoints are given compatible uses to those		given compatible uses to those defined in RFC3168 (Not-ECT and CE).
	defined in RFC3168 (Not-ECT and CE). The other codepoint used by		The other codepoint used by RFC3168 (ECT(0)) isn't used for re-ECN.
	RFC3168 (ECT(0)) isn't used for re-ECN. Altogether this leave one		Altogether this leave one codepoint of the eight unused by ECN or re-
	codepoint of the eight unused by ECN or re-ECN and available for		ECN and available for future use.
	future use.
	+--------+-------------+-------+-----------+------------------------+		+--------+-------------+-------+-----------+------------------------+
	| ECN | RFC3168 | RE | EECN | re-ECN meaning |		| ECN | RFC3168 | RE | EECN | re-ECN meaning |
	| field | codepoint | flag | codepoint | |		| field | codepoint | flag | codepoint | |
	+--------+-------------+-------+-----------+------------------------+		+--------+-------------+-------+-----------+------------------------+
	| 00 | Not-ECT | 0 | Not-ECT | Not re-ECN-capable |		| 00 | Not-ECT | 0 | Not-ECT | Not re-ECN-capable |
	| | | | | transport (Legacy) |		| | | | | transport (Legacy) |
	| 00 | --- | 1 | FNE | Feedback not |		| 00 | --- | 1 | FNE | Feedback not |
	| | | | | established (Cautious) |		| | | | | established (Cautious) |
	| 01 | ECT(1) | 0 | Re-Echo | Re-echoed congestion |		| 01 | ECT(1) | 0 | Re-Echo | Re-echoed congestion |
	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. [Re-PCN] is one example.		required. [I-D.briscoe-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 [re-ecn-motive] would count as rate limiters		policers discussed in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]
	for this purpose.		would count as 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 [re-ecn-motive]. If nowhere else, routers		policing framework of [I-D.briscoe-tsvwg-re-ecn-tcp-motivation].
	at the egress of a network SHOULD implement preferential drop		If nowhere else, routers at the egress of a network SHOULD
	(stronger than the MAY above). For simplicity, preferences 4 & 5		implement preferential drop (stronger than the MAY above). For
	MAY be merged into one preference level.		simplicity, preferences 4 & 5 MAY be merged into one preference
			level.
	+-------+-----+------------+-------+------------+-------------------+		+-------+-----+------------+-------+------------+-------------------+
	| 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 36		skipping to change at page 17, line 36
	| | | | | | 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		The above drop preferences are arranged to preserve packets with
	more positive worth (Section 4.4), given senders of positive		more positive worth (Section 4.4), given senders of positive
	packets must have honestly declared downstream congestion. A full		packets must have honestly declared downstream congestion. A full
	treatment of this is provided in the companion document desribing		treatment of this is provided in the companion document desribing
	the motivation and architecture for re-ECN [re-ecn-motive]		the motivation and architecture for re-ECN
	particularly when the application of re-ECN to protect against		[I-D.briscoe-tsvwg-re-ecn-tcp-motivation] particularly when the
	DDoS attacks is described.		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 [re-ecn-motive] the sender's access operator will be		As discussed in [I-D.briscoe-tsvwg-re-ecn-tcp-motivation] the
	expected to use bulk per-user policing, but they might choose to		sender's access operator will be expected to use bulk per-user
	introduce a per-flow policer. In cases where operators do introduce		policing, but they might choose to introduce a per-flow policer. In
	per-flow policing, there may be a need for a sender to send a request		cases where operators do introduce per-flow policing, there may be a
	to the ingress policer asking for permission to apply a non-default		need for a sender to send a request to the ingress policer asking for
	response to congestion (where TCP-friendly is assumed to be the		permission to apply a non-default response to congestion (where TCP-
	default). This would require the sender to know what message		friendly is assumed to be the default). This would require the
	format(s) to use and to be able to discover how to address the		sender to know what message format(s) to use and to be able to
	policer. The required control protocol(s) are outside the scope of		discover how to address the policer. The required control
	this document, but will require definition elsewhere.		protocol(s) are outside the scope of this document, but will require
			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).
	5.6. IP in IP Tunnels		5.6. IP in IP Tunnels
	For re-ECN to work correctly through IP in IP tunnels, it needs		For re-ECN to work correctly through IP in IP tunnels, it needs
	slightly different tunnel handling to regular ECN [RFC3168].		slightly different tunnel handling to regular ECN [RFC3168].
	Currently there is some incosistency between how the handling of IP		Currently there is some incosistency between how the handling of IP
	in IP tunnels is defined in [RFC3168] and how it is defined in		in IP tunnels is defined in [RFC3168] and how it is defined in
	[RFC4301], but re-ECN would work fine with the IPsec behaviour. This		[RFC4301], but re-ECN would work fine with the IPsec behaviour. This
	inconsistency is addressed in a new Internet Draft [ECN-tunnel] that		inconsistency is addressed in a new Internet Draft
	proposes to update RFC3168 tunnel behaviour to bring it into line		[I-D.ietf-tsvwg-ecn-tunnel] that proposes to update RFC3168 tunnel
	with IPsec. Ideally, for re-ECN to work through a tunnel, the tunnel		behaviour to bring it into line with IPsec. Ideally, for re-ECN to
	entry should copy both the RE flag and the ECN field from the inner		work through a tunnel, the tunnel entry should copy both the RE flag
	to the outer IP header. Then at the tunnel exit, any congestion		and the ECN field from the inner to the outer IP header. Then at the
	marking of the outer ECN field should overwrite the inner ECN field		tunnel exit, any congestion marking of the outer ECN field should
	(unless the inner field is Not-ECT in which case an alarm should be		overwrite the inner ECN field (unless the inner field is Not-ECT in
	raised). The RE flag shouldn't change along a path, so the outer RE		which case an alarm should be raised). The RE flag shouldn't change
	flag should be the same as the inner. If it isn't a management alarm		along a path, so the outer RE flag should be the same as the inner.
	should be raised. This behaviour is the same as the full-		If it isn't a management alarm should be raised. This behaviour is
	functionality variant of [RFC3168] at tunnel exit, but different at		the same as the full-functionality variant of [RFC3168] at tunnel
	tunnel entry.		exit, but different at tunnel entry.
	If tunnels are left as they are specified in [RFC3168], whether the		If tunnels are left as they are specified in [RFC3168], whether the
	limited or full-functionality variants are used, a problem arises		limited or full-functionality variants are used, a problem arises
	with re-ECN if a tunnel crosses an inter-domain boundary, because the		with re-ECN if a tunnel crosses an inter-domain boundary, because the
	difference between positive and negative markings will not be		difference between positive and negative markings will not be
	correctly accounted for. In a limited functionality ECN tunnel, the		correctly accounted for. In a limited functionality ECN tunnel, the
	flow will appear to be RFC3168 compliant traffic, and therefore may		flow will appear to be RFC3168 compliant traffic, and therefore may
	be wrongly rate limited. In a full-functionality ECN tunnel, the		be wrongly rate limited. In a full-functionality ECN tunnel, the
	result will depend whether the tunnel entry copies the inner RE flag		result will depend whether the tunnel entry copies the inner RE flag
	to the outer header or the RE flag in the outer header is always		to the outer header or the RE flag in the outer header is always
	cleared. If the former, the flow will tend to be too positive when		cleared. If the former, the flow will tend to be too positive when
	accounted for at borders. If the latter, it will be too negative.		accounted for at borders. If the latter, it will be too negative.
	If the rules set out in [ECN-tunnel] are followed then this will not		If the rules set out in [I-D.ietf-tsvwg-ecn-tunnel] are followed then
	be an issue.		this will not be an issue.
	5.7. Non-Issues		5.7. Non-Issues
	The following issues might seem to cause unfavourable interactions		The following issues might seem to cause unfavourable interactions
	with re-ECN, but we will explain why they don't:		with re-ECN, but we will explain why they don't:
	o Various link layers support explicit congestion notification, such		o Various link layers support explicit congestion notification, such
	as Frame Relay and ATM. Explicit congestion notification is		as Frame Relay and ATM. Explicit congestion notification is
	proposed to be added to other link layers, such as Ethernet		proposed to be added to other link layers, such as Ethernet
	(802.3ar Ethernet congestion management) and MPLS [RFC5129];		(802.3ar Ethernet congestion management) and MPLS [RFC5129];
	skipping to change at page 28, line 22		skipping to change at page 28, line 20
	responding to a SYN from a Re-ECT client or from a client that is		responding to a SYN from a Re-ECT client or from a client that is
	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 [I-D.ietf-tcpm-ecnsyn] has shown that this		For a SYN ACK, Kuzmanovic [RFC5562] has shown that this caution was
	caution was unnecessary, and proposes to allow a SYN ACK to be ECN-		unnecessary, and proposes to allow a SYN ACK to be ECN-capable to
	capable to improve performance. By stipulating the FNE codepoint for		improve performance. By stipulating the FNE codepoint for the
	the initial SYN, we comply with RFC3168 in word but not in spirit,		initial SYN, we comply with RFC3168 in word but not in spirit,
	because we have indeed set the ECN field to Not-ECT, but we have		because we have indeed set the ECN field to Not-ECT, but we have
	extended the ECN field with another bit. And it will be seen		extended the ECN field with another bit. And it will be seen
	(Section 5.3) that we have defined one setting of that bit to mean an		(Section 5.3) that we have defined one setting of that bit to mean an
	ECN-capable transport. Therefore, by proposing that the FNE		ECN-capable transport. Therefore, by proposing that the FNE
	codepoint MUST be used on the initial SYN of a connection, we have		codepoint MUST be used on the initial SYN of a connection, we have
	gone further by proposing to make the initial SYN ECN-capable too.		gone further by proposing to make the initial SYN ECN-capable too.
	Section 5.4 justifies deciding to make the initial SYN ECN-capable.		Section 5.4 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
	skipping to change at page 32, line 41		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 [Re-PCN] describing how re-ECN can		A separate I-D has been submitted [I-D.briscoe-re-pcn-border-cheat]
	be used in an edge-to-edge rather than end-to-end scenario. It can		describing how re-ECN can be used in an edge-to-edge rather than end-
	then be used by downstream networks to police whether upstream		to-end scenario. It can then be used by downstream networks to
	networks are blocking new flow reservations when downstream		police whether upstream networks are blocking new flow reservations
	congestion is too high, even though the congestion is in other		when downstream congestion is too high, even though the congestion is
	operators' downstream networks. This relates to current IETF work on		in other operators' downstream networks. This relates to current
	Admission Control over Diffserv using Pre-Congestion Notification		IETF work on Admission Control over Diffserv using Pre-Congestion
	(PCN) [PCN-arch].		Notification (PCN) [RFC5559].
	6.2.3. Guidelines for adding Re-ECN to DCCP		6.2.3. Guidelines for adding Re-ECN to DCCP
	Beside adjusting the initial features negotiation sequence, operating		Beside adjusting the initial features negotiation sequence, operating
	re-ECN in DCCP [RFC4340] could be achieved by defining a new option		re-ECN in DCCP [RFC4340] could be achieved by defining a new option
	to be added to acknowledgments, that would include a multibit field		to be added to acknowledgments, that would include a multibit field
	where the destination could copy its ECC.		where the destination could copy its ECC.
	6.2.4. Guidelines for adding Re-ECN to SCTP		6.2.4. Guidelines for adding Re-ECN to SCTP
	skipping to change at page 38, line 26		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 for use in		[RFC2119] Bradner, S., "Key words
	RFCs to Indicate Requirement Levels",		for use in RFCs to
	BCP 14, RFC 2119, March 1997.		Indicate Requirement
			Levels", BCP 14, RFC 2119,
			March 1997.
	[RFC2581] Allman, M., Paxson, V., and W.		[RFC2581] Allman, M., Paxson, V.,
	Stevens, "TCP Congestion Control",		and W. Stevens, "TCP
	RFC 2581, April 1999.		Congestion Control",
			RFC 2581, April 1999.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D.		[RFC3168] Ramakrishnan, K., Floyd,
	Black, "The Addition of Explicit		S., and D. Black, "The
	Congestion Notification (ECN) to IP",		Addition of Explicit
	RFC 3168, September 2001.		Congestion Notification
			(ECN) to IP", RFC 3168,
			September 2001.
	[RFC3390] Allman, M., Floyd, S., and C.		[RFC3390] Allman, M., Floyd, S., and
	Partridge, "Increasing TCP's Initial		C. Partridge, "Increasing
	Window", RFC 3390, October 2002.		TCP's Initial Window",
			RFC 3390, October 2002.
	[RFC4340] Kohler, E., Handley, M., and S.		[RFC4340] Kohler, E., Handley, M.,
	Floyd, "Datagram Congestion Control		and S. Floyd, "Datagram
	Protocol (DCCP)", RFC 4340,		Congestion Control
	March 2006.		Protocol (DCCP)",
			RFC 4340, March 2006.
	[RFC4341] Floyd, S. and E. Kohler, "Profile for		[RFC4341] Floyd, S. and E. Kohler,
	Datagram Congestion Control Protocol		"Profile for Datagram
	(DCCP) Congestion Control ID 2: TCP-		Congestion Control
	like Congestion Control", RFC 4341,		Protocol (DCCP) Congestion
	March 2006.		Control ID 2: TCP-like
			Congestion Control",
			RFC 4341, March 2006.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye,		[RFC4342] Floyd, S., Kohler, E., and
	"Profile for Datagram Congestion		J. Padhye, "Profile for
	Control Protocol (DCCP) Congestion		Datagram Congestion
	Control ID 3: TCP-Friendly Rate		Control Protocol (DCCP)
	Control (TFRC)", RFC 4342,		Congestion Control ID 3:
	March 2006.		TCP-Friendly Rate Control
			(TFRC)", RFC 4342,
			March 2006.
	[RFC4960] Stewart, R., "Stream Control		[RFC4960] Stewart, R., "Stream
	Transmission Protocol", RFC 4960,		Control Transmission
	September 2007.		Protocol", RFC 4960,
			September 2007.
	14.2. Informative References		14.2. Informative References
	[ARI05] Adams, J., Roberts, L., and A.		[ARI05] Adams, J., Roberts, L.,
	IJsselmuiden, "Changing the Internet		and A. IJsselmuiden,
	to Support Real-Time Content Supply		"Changing the Internet to
	from a Large Fraction of Broadband		Support Real-Time Content
	Residential Users", BT Technology		Supply from a Large
	Journal (BTTJ) 23(2), April 2005.		Fraction of Broadband
			Residential Users", BT
			Technology Journal
			(BTTJ) 23(2), April 2005.
	[ECN-tunnel] Briscoe, B., "Layered Encapsulation		[I-D.briscoe-re-pcn-border-cheat] Briscoe, B., "Emulating
	of Congestion Notification",		Border Flow Policing using
	draft-briscoe-tsvwg-ecn-tunnel-00		Re-PCN on Bulk Data", draf
	(work in progress), June 2007.		t-briscoe-re-pcn-border-
			cheat-02 (work in
			progress), September 2008.
	[I-D.ietf-tcpm-ecnsyn] Kuzmanovic, A., "Adding Explicit		[I-D.briscoe-tsvwg-re-ecn-tcp-motivation] Briscoe, B., Jacquet, A.,
	Congestion Notification (ECN)		Moncaster, T., and A.
	Capability to TCP's SYN/ACK		Smith, "Re-ECN: A
	Packets", draft-ietf-tcpm-ecnsyn-05		Framework for adding
	(work in progress), February 2008.		Congestion Accountability
			to TCP/IP", draft-briscoe-
			tsvwg-re-ecn-tcp-
			motivation-01 (work in
			progress), September 2009.
	[I-D.moncaster-tcpm-rcv-cheat] Moncaster, T., "A TCP Test to Allow		[I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling
	Senders to Identify Receiver Non-		of Explicit Congestion
	Compliance",		Notification", draft-ietf-
	draft-moncaster-tcpm-rcv-cheat-02		tsvwg-ecn-tunnel-03 (work
	(work in progress), November 2007.		in progress), July 2009.
	[PCN-arch] Eardley, P., Babiarz, J., Chan, K.,		[RFC2309] Braden, B., Clark, D.,
	Charny, A., Geib, R., Karagiannis,		Crowcroft, J., Davie, B.,
	G., Menth, M., and T. Tsou, "Pre-		Deering, S., Estrin, D.,
	Congestion Notification		Floyd, S., Jacobson, V.,
	Architecture",		Minshall, G., Partridge,
	draft-ietf-pcn-architecture-03 (work		C., Peterson, L.,
	in progress), February 2008.		Ramakrishnan, K., Shenker,
			S., Wroclawski, J., and L.
			Zhang, "Recommendations on
			Queue Management and
			Congestion Avoidance in
			the Internet", RFC 2309,
			April 1998.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J.,		[RFC2475] Blake, S., Black, D.,
	Davie, B., Deering, S., Estrin, D.,		Carlson, M., Davies, E.,
	Floyd, S., Jacobson, V., Minshall,		Wang, Z., and W. Weiss,
	G., Partridge, C., Peterson, L.,		"An Architecture for
	Ramakrishnan, K., Shenker, S.,		Differentiated Services",
	Wroclawski, J., and L. Zhang,		RFC 2475, December 1998.
	"Recommendations on Queue Management
	and Congestion Avoidance in the
	Internet", RFC 2309, April 1998.
	[RFC2475] Blake, S., Black, D., Carlson, M.,		[RFC2988] Paxson, V. and M. Allman,
	Davies, E., Wang, Z., and W. Weiss,		"Computing TCP's
	"An Architecture for Differentiated		Retransmission Timer",
	Services", RFC 2475, December 1998.		RFC 2988, November 2000.
	[RFC2988] Paxson, V. and M. Allman, "Computing		[RFC3124] Balakrishnan, H. and S.
	TCP's Retransmission Timer",		Seshan, "The Congestion
	RFC 2988, November 2000.		Manager", RFC 3124,
			June 2001.
	[RFC3124] Balakrishnan, H. and S. Seshan, "The		[RFC3514] Bellovin, S., "The
	Congestion Manager", RFC 3124,		Security Flag in the IPv4
	June 2001.		Header", RFC 3514, April 1
			2003.
	[RFC3514] Bellovin, S., "The Security Flag in		[RFC3540] Spring, N., Wetherall, D.,
	the IPv4 Header", RFC 3514,		and D. Ely, "Robust
	April 2003.		Explicit Congestion
			Notification (ECN)
			Signaling with Nonces",
			RFC 3540, June 2003.
	[RFC3540] Spring, N., Wetherall, D., and D.		[RFC4301] Kent, S. and K. Seo,
	Ely, "Robust Explicit Congestion		"Security Architecture for
	Notification (ECN) Signaling with		the Internet Protocol",
	Nonces", RFC 3540, June 2003.		RFC 4301, December 2005.
	[RFC4301] Kent, S. and K. Seo, "Security		[RFC4302] Kent, S., "IP
	Architecture for the Internet		Authentication Header",
	Protocol", RFC 4301, December 2005.		RFC 4302, December 2005.
	[RFC4302] Kent, S., "IP Authentication Header",		[RFC4305] Eastlake, D.,
	RFC 4302, December 2005.		"Cryptographic Algorithm
			Implementation
			Requirements for
			Encapsulating Security
			Payload (ESP) and
			Authentication Header
			(AH)", RFC 4305,
			December 2005.
	[RFC4305] Eastlake, D., "Cryptographic		[RFC5129] Davie, B., Briscoe, B.,
	Algorithm Implementation Requirements		and J. Tay, "Explicit
	for Encapsulating Security Payload		Congestion Marking in
	(ESP) and Authentication Header		MPLS", RFC 5129,
	(AH)", RFC 4305, December 2005.		January 2008.
	[RFC5129] Davie, B., Briscoe, B., and J. Tay,		[RFC5559] Eardley, P., "Pre-
	"Explicit Congestion Marking in		Congestion Notification
	MPLS", RFC 5129, January 2008.		(PCN) Architecture",
			RFC 5559, June 2009.
	[Re-PCN] Briscoe, B., "Emulating Border Flow		[RFC5562] Kuzmanovic, A., Mondal,
	Policing using Re-ECN on Bulk Data",		A., Floyd, S., and K.
	draft-briscoe-re-pcn-border-cheat-01		Ramakrishnan, "Adding
	(work in progress), February 2008.		Explicit Congestion
			Notification (ECN)
			Capability to TCP's SYN/
			ACK Packets", RFC 5562,
			June 2009.
	[Re-fb] Briscoe, B., Jacquet, A., Di Cairano-		[Re-fb] Briscoe, B., Jacquet, A.,
	Gilfedder, C., Salvatori, A.,		Di Cairano-Gilfedder, C.,
	Soppera, A., and M. Koyabe, "Policing		Salvatori, A., Soppera,
	Congestion Response in an		A., and M. Koyabe,
	Internetwork Using Re-Feedback", ACM		"Policing Congestion
	SIGCOMM CCR 35(4)277--288,		Response in an
	August 2005, <http://www.acm.org/		Internetwork Using Re-
	sigs/sigcomm/sigcomm2005/		Feedback", ACM SIGCOMM
	techprog.html#session8>.		CCR 35(4)277--288,
			August 2005, <http://
			www.acm.org/sigs/sigcomm/
			sigcomm2005/
			techprog.html#session8>.
	[Savage99] Savage, S., Cardwell, N., Wetherall,		[Savage99] Savage, S., Cardwell, N.,
	D., and T. Anderson, "TCP congestion		Wetherall, D., and T.
	control with a misbehaving receiver",		Anderson, "TCP congestion
	ACM SIGCOMM CCR 29(5), October 1999,		control with a misbehaving
	<http://citeseer.ist.psu.edu/		receiver", ACM SIGCOMM
	savage99tcp.html>.		CCR 29(5), October 1999, <
			http://
			citeseer.ist.psu.edu/
			savage99tcp.html>.
	[Steps_DoS] Handley, M. and A. Greenhalgh, "Steps		[Steps_DoS] Handley, M. and A.
	towards a DoS-resistant Internet		Greenhalgh, "Steps towards
	Architecture", Proc. ACM SIGCOMM		a DoS-resistant Internet
	workshop on Future directions in		Architecture", Proc. ACM
	network architecture (FDNA'04) pp		SIGCOMM workshop on Future
	49--56, August 2004.		directions in network
			architecture (FDNA'04) pp
			49--56, August 2004.
	[re-ecn-motive] Briscoe, B., "Re-ECN: The Motivation		[tcp-rcv-cheat] Moncaster, T., Briscoe,
	for Adding Congestion Accountability		B., and A. Jacquet, "A TCP
	to TCP/IP", draft-briscoe-tsvwg-re-		Test to Allow Senders to
	ecn-tcp-motivation-00 (work in		Identify Receiver Non-
	progress), February 2009.		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 24		skipping to change at page 51, line 8
	| 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
	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://www.cs.ucl.ac.uk/staff/B.Briscoe/
	Arnaud Jacquet		Arnaud Jacquet
	skipping to change at page 52, line 4		skipping to change at line 2392
	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
	Full Copyright Statement
	Copyright (C) The IETF Trust (2009).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgements
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA). This document was produced
	using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
	RFC-2629 XML format.
End of changes. 60 change blocks.
	216 lines changed or deleted		287 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/