< draft-mathis-conex-abstract-mech-00a.txt		draft-mathis-conex-abstract-mech-00b.txt >
	Congestion Exposure (ConEx) M. Mathis		Congestion Exposure (ConEx) M. Mathis
	Working Group Google		Working Group Google
	Internet-Draft October 14, 2010		Internet-Draft B. Briscoe
	Intended status: Informational		Intended status: Informational BT
	Expires: April 17, 2011		Expires: April 17, 2011 October 14, 2010
	ConEx Concepts and Abstract Mechanism		Congestion Exposure (ConEx) Concepts and Abstract Mechanism
	draft-mathis-conex-abstract-mech-00a		draft-mathis-conex-abstract-mech-00b
	Abstract		Abstract
	This document describes and abstract mechanism by which senders		This document describes an abstract mechanism by which senders inform
	inform the network about the congestion encountered by previous		the network about the congestion encountered by packets earlier in
	packets on the same flow. Today, the network may signal congestion		the same flow. Today, the network may signal congestion to the
	by ECN markings or by dropping packets, and the receiver passes this		receiver by ECN markings or by dropping packets, and the receiver may
	information back to the sender in transport-layer acknowledgments.		pass this information back to the sender in transport-layer feedback.
	The mechanism to be developed by the CONEX WG will enable the sender		The mechanism to be developed by the ConEx WG will enable the sender
	to also relay the congestion information back into the network in-		to also relay this congestion information back into the network in-
	band at the IP layer, such that the total level of congestion is		band at the IP layer, such that the total level of congestion is
	visible to all IP devices along the path, from where it could, for		visible to all IP devices along the path, from where it could, for
	example, be provided as input to traffic management.		example, be provided as input to traffic management.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Requirements for the Congestion Exposure Signal . . . . . . . . 4		2. Requirements for the Congestion Exposure Signal . . . . . . . 5
	3. Representing Congestion Exposure . . . . . . . . . . . . . . . 5		3. Representing Congestion Exposure . . . . . . . . . . . . . . . 7
	3.1. One Simple Encoding . . . . . . . . . . . . . . . . . . . . 6		3.1. One Simple Encoding . . . . . . . . . . . . . . . . . . . 7
	3.2. ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 6		3.2. ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. ECN Changes . . . . . . . . . . . . . . . . . . . . . . 7		3.2.1. ECN Changes . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Abstract Encoding . . . . . . . . . . . . . . . . . . . . . 7		3.3. Abstract Encoding . . . . . . . . . . . . . . . . . . . . 9
	3.3.1. Separate Bits . . . . . . . . . . . . . . . . . . . . . 7		3.3.1. Separate Bits . . . . . . . . . . . . . . . . . . . . 9
	3.3.2. Enumerated Encoding . . . . . . . . . . . . . . . . . . 8		3.3.2. Enumerated Encoding . . . . . . . . . . . . . . . . . 9
	4. Congestion Exposure Components . . . . . . . . . . . . . . . . 8		4. Congestion Exposure Components . . . . . . . . . . . . . . . . 9
	4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 8		4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Audit . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2.1. Audit . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Policers and Shapers . . . . . . . . . . . . . . . . . 8		4.2.2. Policers and Shapers . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9		9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	One of the required functions of a transport protocol is controlling		One of the required functions of a transport protocol is controlling
	congestion in the network. There are three techniques in use today		congestion in the network. There are three techniques in use today
	for signaling congestion:		for the network to signal congestion to a transport:
	o The most common congestion signal is packet loss. When congested,		o The most common congestion signal is packet loss. When congested,
	the network simply discards some packets either as part of an		the network simply discards some packets either as part of an
	explicit control function [RFC2309] or as the consequence of a		explicit control function [RFC2309] or as the consequence of a
	queue overflow or other resource starvation. The transport		queue overflow or other resource starvation. The transport
	receiver detects that some data is missing and signals such		receiver detects that some data is missing and signals such
	through transport acknowledgments to the transport sender (e.g.		through transport acknowledgments to the transport sender (e.g.
	TCP SACK options). The sender retransmits the missing data (if a		TCP SACK options). The sender performs the appropriate congestion
	reliable protocol) and then performs the mandatory congestion		control rate reduction (e.g. [RFC5681] for TCP) and, if it is a
	control adjustment [RFC5681].		reliable transport, it retransmits the missing data.
	o Some experimental transport protocols and TCP variants [Vegas,		o If the transport supports explicit congestion notification (ECN)
	I-D.ietf-ledbat-congestion...] sense queuing delays in the network		[RFC3168] or pre-congestion notification (PCN) [RFC5670] , the
	before the network itself signals congestion. From the		transport sender indicates this by setting an ECN-capable
	perspective of this document, these algorithm and related		transport (ECT) codepoint in every packet. Network devices can
	techniques prevent congestion, therefore they are out of scope and		then explicitly signal congestion to the receiver by setting ECN
	are not discussed further in this document.		bits in the IP header of such packets. The transport receiver
			communicates these ECN signals back to the sender, which then
			performs the appropriate congestion control rate reduction.
	o With Explicit Congestion Notification (ECN) [RFC3168], network		o Some experimental transport protocols and TCP variants [Vegas]
	devices explicitly indicate congestion by setting ECN bits in the		sense queuing delays in the network and reduce their rate before
	IP header. The transport receiver communicates these signals back		the network has to signal congestion using loss or ECN. A purely
	to the sender, which then performs the mandatory congestion		delay-sensing transport will tend to be pushed out by other
	control adjustment.		competing transports that do not back off until they have driven
			the queue into loss. Therefore, modern delay-sensing algorithms
			use delay in some combination with loss to signal congestion (e.g.
			LEDBAT [I-D.ietf-ledbat-congestion], Compound
			[I-D.sridharan-tcpm-ctcp]). In the rest of this document, we will
			confine the discussion to concrete signals of congestion such as
			loss and ECN. We will not discuss delay-sensing further, because
			it can only avoid these more concrete signals of congestion in
			some circumstances.
	In all cases the congestion signals follow the route indicated in		In all cases the congestion signals follow the route indicated in
	Figure 1. A congested network device sends a signal in the data		Figure 1. A congested network device sends a signal in the data
	stream on the forward path to the transport receiver, the receiver		stream on the forward path to the transport receiver, the receiver
	passes it back to the sender through transport level acknowledgments,		passes it back to the sender through transport level feedback, and
	and the sender makes some congestion control adjustment.		the sender makes some congestion control adjustment.
	This document proposes to extend the capabilities of the Internet		This document proposes to extend the capabilities of the Internet
	suite with the addition of a Congestion Exposure Signal that relays		protocol suite with the addition of a Congestion Exposure Signal
	the congestion information from the Transport Sender back through the		that, to a first approximation, relays the congestion information
	network layer. That signal is shown Figure 1. It would be visible		from the transport sender back through the internetwork layer. That
	to all network layer devices along the forward (data) path and is		signal is shown in Figure 1. It would be visible to all internetwork
	intended to support a number of new policy mechanism that might be		layer devices along the forward (data) path and is intended to
			support a number of new policy-controlled mechanisms that might be
	used to manage traffic.		used to manage traffic.
			123456789012345678901234567890123456789012345678901234567890123456789
	1234567890123456789012345678901234567890123456789012345678901234567890		+---------+ +---------+
	----------- ------------- -----------		| |<==Feedback Path==============================<| |
	| | |(Congested)| | |		| |<--Transport Layer returned Congestion Signal-<| |
	| |>==Data=Path=>| Network |>=====Data=Path=====>| |		| | | |
	|Transport| | Device |>-Congestion-Signal->|Transport|		|Transport| |Transport|
	| Sender | ------------- | Receiver|		| Sender |>-(new)-IP layer Congestion Exposure Signal--->| Receiver|
	| | | |		| | (Carried in Data Packet Headers) | |
	| |<====ACK=Path==================================<| |		| | +-----------+ | |
	| |<---Transport Layer returned Congestion Signal-<| |		| |>=Data=Path=>|(Congested)|>=====Data=Path=====>| |
	| | | |		| | | Network |>-Congestion-Signal->| |
	| |>-(new)-IP layer Congestion Exposure Signal---->| |		| | | Device | | |
	----------- (Carried in Data Packets) -----------		+---------+ +-----------+ +---------+
	Not shown are policy devices along the data path that observe the		Not shown are policy devices along the data path that observe the
	Congestion Exposure Signal, and use the information to monitor or		Congestion Exposure Signal, and use the information to monitor or
	manage traffic. These are discussed in Section 4.2.		manage traffic. These are discussed in Section 4.2.
	Figure 1		Figure 1
	1.1. Requirements Language		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
			ConEx signals in IP packet headers from the sender to the network
			{ToDo: These are placeholders for whatever words we decide to use}:
			Re-Echo Loss (aka Black-Loss) The transport has experienced a loss.
			Re-Echo ECN (aka Black-ECN) The transport has experienced an ECN
			mark
			Pre-Echo (aka Green) The transport is building up credit to allow
			for any future delay in expected ConEx signals
			Neutral (aka Grey) The transport is ConEx-capable
			Not-ConEx (aka White) The transport is not ConEx-capable
	2. Requirements for the Congestion Exposure Signal		2. Requirements for the Congestion Exposure Signal
	a. The Congestion Exposure Signal must be visible to the network		a. The Congestion Exposure Signal SHOULD be visible to internetwork
	layer along the entire path from the transport sender to the		layer devices along the entire path from the transport sender to
	transport receiver. Equivalently, it must be present in the IPv4		the transport receiver. Equivalently, it SHOULD be present in
	or IPv6 header. A corollary of this is that existing (legacy)		the IPv4 or IPv6 header, and in the outermost IP header if using
	networking gear must at the very minimum pass the Congestion		IP in IP tunnelling. The Congestion Exposure Signal SHOULD be
	Exposures Signal without modification.		immutable once set by the transport sender. A corollary of these
			requirements is that existing (legacy) networking gear SHOULD
			pass the Congestion Exposure Signal silently without
			modification.
	b. The Congestion Exposure Signal must be useful under only partial		b. The Congestion Exposure Signal SHOULD be useful under only
	deployment. A minimal deployment must only require changes to		partial deployment. A minimal deployment SHOULD only require
	the transport senders. Furthermore, partial deployment should		changes to transport senders. Furthermore, partial deployment
	create incentives for additional deployment, both in terms of		SHOULD create incentives for additional deployment, both in terms
	enabling Congestion Exposure on more devices and adding richer		of enabling Congestion Exposure on more devices and adding richer
	features to existing devices. It is anticipated that ConEx		features to existing devices. Nonetheless, ConEx deployment need
	deployment will be asymptotic, and some residual class of hosts		never be universal, and it is anticipated that some hosts and
	and network equipment will never fully support the Congestion		some transports may never support the Congestion Exposure
	Exposure Protocol.		Protocol and some networks may never use the Congestion Exposure
			Signals.
	c. The Congestion Exposure Signal must be timely and accurate. It		c. The Congestion Exposure Signal SHOULD be accurate. In
	must not be delayed by significantly more than one RTT from the		potentially hostile environments such as the public Internet, it
	congestion event which triggered the signal. There must be		SHOULD be possible for techniques to be deployed to audit the
	techniques to audit the Congestion Exposure Signal by comparing		Congestion Exposure Signal by comparing it to the actual
	it to the actual congestion signals on the forward data path.		congestion signals on the forward data path. The auditing
	The auditing mechanism must have a capability for providing		mechanism must have a capability for providing sufficient
	strong disincentives for miss-reporting congestion, such as by		disincentives against misreported congestion, such as by
	throttling traffic that reports less congestion than it is		throttling traffic that reports less congestion than it is
	actually experiencing.		actually experiencing.
			d. The Congestion Exposure Signal SHOULD be timely. There will be a
			delay between the time when an auditing device sees an actual
			congestion signal and when it sees the subsequent Congestion
			Exposure Signal from the sender. The minimum delay will be one
			round trip, but it may be much longer depending on the
			transport's choice of feedback delay (consider RTCP [RFC3550] for
			example). It is not practical to expect auditing devices in the
			network to make allowance for such feedback delays. Instead, the
			sender MUST be able to send Congestion Exposure signals in
			advance, as 'credit' for any audit device to hold as a balance
			against the risk of congestion during the feedback delay. This
			design choice simplifies auditing devices and correctly makes the
			transport responsible for both minimising feedback delay and
			minimising sharp increases in packets in flight that would risk
			causing excessive congestion to others. This issue is discussed
			in more detail in Section 4.2.1.
	It is important to note that the auditing requirement implies a		It is important to note that the auditing requirement implies a
	number of additional constraints: The basic auditing technique is to		number of additional constraints: The basic auditing technique is to
	count both congestion signals and Congestion Exposure Signals		count both actual congestion signals and Congestion Exposure Signals
	someplace along the data path. For congestion signaled by ECN, this		someplace along the data path:
	is most accurate when done near the transport receiver. The total
	number of ECN marks seen near the receiver should always be equal to
	or less than the number of Congestion Exposure Signals seen one RTT
	later.
	Auditing loss based Congestion Exposure can most easily be		o For congestion signaled by ECN, auditing is most accurate when
	implemented near the sender, since down stream losses appear as		located near the transport receiver. Within any flow or aggregate
	duplicate data for all reliable protocols (and duplicate sequence		of flows, the total volume of ECN marked data seen near the
	numbers for TCP). The auditor can detect losses by observing both		receiver should always be equal to or less than the volume of data
	the original transmission and the retransmission after the loss.		tagged with Congestion Exposure Signals.
	(This method does assume that IPsec is not in use).
	Given that loss based and ECN based Congestion Exposure are best		o For congestion signaled by loss, totally accurate auditing is not
	audited at different locations, it is likely that they will need to		believed to be possible in the general case, because it involves a
	have distinct encodings. In addition the simplest mechanism to		network node detecting the absence of some packets, when it cannot
	address the one RTT delay between the congestion event and the		necessarily see the transport protocol sequence numbers and when
	Congestion Exposure Signal is to pre-mark some packets with a special		the missing packets might simply be taking a different route. But
	Congestion Exposure credit prior any true congestion marks. This		there are common cases where sufficient audit accuracy should be
	technique is described in more detail in Section 4.2.1.		possible:
			* For non-IPsec traffic conforming to standard TCP sequence
			numbering on a single path, the auditor could detect losses by
			observing both the original transmission and the retransmission
			after the loss. Such auditing would be most accurate near the
			sender.
			* For networks designed so that losses predominantly occur under
			the management of one IP-aware node on the path, the auditor
			could be located at this bottleneck. It could simply compare
			Congestion Exposure Signals with actual local losses. Most
			consumer access networks are design to this model, e.g. the
			radio network controller (RNC) in a cellular network or the
			broadband remote access server (BRAS) in a digital subscriber
			line (DSL) network. Unlike the above TCP-specific solution,
			this would work for IP packets carrying any transport layer
			protocol, and whether encrypted or not.
			The accuracy of an auditor at one predominant bottleneck might
			still be sufficient, even if losses occasionally occurred at
			other nodes in the network (e.g. border gateways). Although
			the auditor at the predominant bottleneck would not always be
			able to detect losses at other nodes, transports would not know
			where losses were occurring either. Therefore any transport
			would not know which losses it could cheat on without getting
			caught, and which ones it couldn't.
			Given that loss-based and ECN-based Congestion Exposure might
			sometimes be best audited at different locations, have distinct
			encodings would widen the design space for the auditing function.
			{Bob: Got to here making suggested changes.}
	3. Representing Congestion Exposure		3. Representing Congestion Exposure
	Most protocol specifications start with a description of packet		Most protocol specifications start with a description of packet
	formats and code points with their associated meanings. This		formats and code points with their associated meanings. This
	document does not: It is already known that choosing the encoding for		document does not: It is already known that choosing the encoding for
	the Congestion Exposure Signal is likely to entail some engineering		the Congestion Exposure Signal is likely to entail some engineering
	compromises that have the potential to reduce the protocol's		compromises that have the potential to reduce the protocol's
	usefulness in some settings. Rather than making these engineering		usefulness in some settings. Rather than making these engineering
	choices prematurely, this document side steps the encoding problem by		choices prematurely, this document side steps the encoding problem by
	describing an abstract representation of Congestion Exposure Signal.		describing an abstract representation of Congestion Exposure Signal.
	All of the elements of the protocol can be defined in terms of this		All of the elements of the protocol can be defined in terms of this
	abstract representation. Most important, the preliminary use cases		abstract representation. Most important, the preliminary use cases
	for the protocol are described in terms of the abstract		for the protocol are described in terms of the abstract
	representation in companion documents.		representation in companion documents.
	Once we have some example use cases we can evaluate different		Once we have some example use cases we can evaluate different
	encoding schemes. Since theses schemes are likely to include some		encoding schemes. Since these schemes are likely to include some
	conflated code points, some information will be lost resulting in		conflated code points, some information will be lost resulting in
	weakening or disabling some of the algorithms and eliminating some		weakening or disabling some of the algorithms and eliminating some
	use cases.		use cases.
	The goal of this approach is to be as complete as possible for		The goal of this approach is to be as complete as possible for
	discovering the potential usage and capabilities of the Congestion		discovering the potential usage and capabilities of the Congestion
	Exposure protocol, so we have some hope of of making optimal design		Exposure protocol, so we have some hope of making optimal design
	decisions when choosing the encoding.		decisions when choosing the encoding.
	3.1. One Simple Encoding		3.1. One Simple Encoding
	As an aid to the reader, it might be helpful to describe one simple		As an aid to the reader, it might be helpful to describe one simple
	encoding of the Congestion Exposure protocol: set IPv4 header bit 48		encoding of the Congestion Exposure protocol: set IPv4 header bit 48
	(aka the "evil bit" [RFC3514]) on all retransmissions or once per ECN		(aka the "evil bit" [RFC3514]) on all retransmissions or once per ECN
	signaled window reduction. Clearly network devices along the forward		signaled window reduction. Clearly network devices along the forward
	path can see this bit and act on it. For example they can count		path can see this bit and act on it. For example they can count
	marked and unmarked packets to estimate the congestion levels along		marked and unmarked packets to estimate the congestion levels along
	skipping to change at page 9, line 11		skipping to change at page 10, line 32
	6. Security Considerations		6. Security Considerations
	{ToDo:}		{ToDo:}
	7. Conclusions		7. Conclusions
	{ToDo:}		{ToDo:}
	8. Acknowledgements		8. Acknowledgements
	{ToDo:}		This document was improved by review comments from Toby Moncaster.
	9. Comments Solicited		9. 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 Congestion Exposure (ConEx) working group		addressed to the IETF Congestion Exposure (ConEx) working group
	mailing list <conex@ietf.org>, and/or to the authors.		mailing list <conex@ietf.org>, and/or to the authors.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	skipping to change at page 9, line 51		skipping to change at page 11, line 28
	Causing Congestion to TCP/IP",		Causing Congestion to TCP/IP",
	draft-briscoe-tsvwg-re-ecn-tcp-08		draft-briscoe-tsvwg-re-ecn-tcp-08
	(work in progress), September 2009.		(work in progress), September 2009.
	[I-D.ietf-ledbat-congestion] Shalunov, S. and G. Hazel, "Low		[I-D.ietf-ledbat-congestion] Shalunov, S. and G. Hazel, "Low
	Extra Delay Background Transport		Extra Delay Background Transport
	(LEDBAT)",		(LEDBAT)",
	draft-ietf-ledbat-congestion-02		draft-ietf-ledbat-congestion-02
	(work in progress), July 2010.		(work in progress), July 2010.
			[I-D.sridharan-tcpm-ctcp] Sridharan, M., Tan, K., Bansal, D.,
			and D. Thaler, "Compound TCP: A New
			TCP Congestion Control for High-
			Speed and Long Distance Networks",
			draft-sridharan-tcpm-ctcp-02 (work
			in progress), November 2008.
	[RFC2309] Braden, B., Clark, D., Crowcroft,		[RFC2309] Braden, B., Clark, D., Crowcroft,
	J., Davie, B., Deering, S., Estrin,		J., Davie, B., Deering, S., Estrin,
	D., Floyd, S., Jacobson, V.,		D., Floyd, S., Jacobson, V.,
	Minshall, G., Partridge, C.,		Minshall, G., Partridge, C.,
	Peterson, L., Ramakrishnan, K.,		Peterson, L., Ramakrishnan, K.,
	Shenker, S., Wroclawski, J., and L.		Shenker, S., Wroclawski, J., and L.
	Zhang, "Recommendations on Queue		Zhang, "Recommendations on Queue
	Management and Congestion Avoidance		Management and Congestion Avoidance
	in the Internet", RFC 2309,		in the Internet", RFC 2309,
	April 1998.		April 1998.
	skipping to change at page 10, line 27		skipping to change at page 12, line 11
	[RFC3514] Bellovin, S., "The Security Flag in		[RFC3514] Bellovin, S., "The Security Flag in
	the IPv4 Header", RFC 3514,		the IPv4 Header", RFC 3514,
	April 2003.		April 2003.
	[RFC3540] Spring, N., Wetherall, D., and D.		[RFC3540] Spring, N., Wetherall, D., and D.
	Ely, "Robust Explicit Congestion		Ely, "Robust Explicit Congestion
	Notification (ECN) Signaling with		Notification (ECN) Signaling with
	Nonces", RFC 3540, June 2003.		Nonces", RFC 3540, June 2003.
			[RFC3550] Schulzrinne, H., Casner, S.,
			Frederick, R., and V. Jacobson,
			"RTP: A Transport Protocol for
			Real-Time Applications", STD 64,
			RFC 3550, July 2003.
			[RFC5670] Eardley, P., "Metering and Marking
			Behaviour of PCN-Nodes", RFC 5670,
			November 2009.
	[RFC5681] Allman, M., Paxson, V., and E.		[RFC5681] Allman, M., Paxson, V., and E.
	Blanton, "TCP Congestion Control",		Blanton, "TCP Congestion Control",
	RFC 5681, September 2009.		RFC 5681, September 2009.
	[Refb-dis] Briscoe, B., "Re-feedback: Freedom		[Refb-dis] Briscoe, B., "Re-feedback: Freedom
	with Accountability for Causing		with Accountability for Causing
	Congestion in a Connectionless		Congestion in a Connectionless
	Internetwork", UCL PhD		Internetwork", UCL PhD
	Dissertation , 2009, <http://		Dissertation , 2009, <http://
	bobbriscoe.net/projects/refb/		bobbriscoe.net/projects/refb/
	skipping to change at page 11, line 5		skipping to change at page 13, line 5
	[Vegas] Brakmo, L. and L. Peterson, "TCP		[Vegas] Brakmo, L. and L. Peterson, "TCP
	Vegas: End-to-End Congestion		Vegas: End-to-End Congestion
	Avoidance on a Global Internet",		Avoidance on a Global Internet",
	IEEE Journal on Selected Areas in		IEEE Journal on Selected Areas in
	Communications 13(8)1465--80,		Communications 13(8)1465--80,
	October 1995, <http://		October 1995, <http://
	ieeexplore.ieee.org/iel1/49/9740/		ieeexplore.ieee.org/iel1/49/9740/
	00464716.pdf?arnumber=464716>.		00464716.pdf?arnumber=464716>.
	Author's Address		Authors' Addresses
	Matt Mathis		Matt Mathis
	Google		Google
	Phone:		Phone:
	Fax:		Fax:
	EMail: mattmathis at google.com		EMail: mattmathis at google.com
	URI:		URI:
			Bob Briscoe
			BT
			B54/77, Adastral Park
			Martlesham Heath
			Ipswich IP5 3RE
			UK
			Phone: +44 1473 645196
			EMail: bob.briscoe@bt.com
			URI: http://bobbriscoe.net/
End of changes. 27 change blocks.
	116 lines changed or deleted		206 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/