draft-ietf-tsvwg-byte-pkt-congest-10.txt		draft-ietf-tsvwg-byte-pkt-congest-11.txt
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe
	Internet-Draft BT		Internet-Draft BT
	Updates: 2309 (if approved) J. Manner		Updates: 2309 (if approved) J. Manner
	Intended status: BCP Aalto University		Intended status: BCP Aalto University
	Expires: November 24, 2013 May 23, 2013		Expires: February 2, 2014 August 1, 2013
	Byte and Packet Congestion Notification		Byte and Packet Congestion Notification
	draft-ietf-tsvwg-byte-pkt-congest-10		draft-ietf-tsvwg-byte-pkt-congest-11
	Abstract		Abstract
	This document provides recommendations of best current practice for		This document provides recommendations of best current practice for
	dropping or marking packets using any active queue management (AQM)		dropping or marking packets using any active queue management (AQM)
	algorithm, such as random early detection (RED), BLUE, pre-congestion		algorithm, including random early detection (RED), BLUE, pre-
	notification (PCN), etc. We give three strong recommendations: (1)		congestion notification (PCN) and newer schemes such as CoDel and
	packet size should be taken into account when transports read and		PIE. We give three strong recommendations: (1) packet size should be
	respond to congestion indications, (2) packet size should not be		taken into account when transports detect and respond to congestion
	taken into account when network equipment creates congestion signals		indications, (2) packet size should not be taken into account when
	(marking, dropping), and therefore (3) in the specific case of RED,		network equipment creates congestion signals (marking, dropping), and
	the byte-mode packet drop variant that drops fewer small packets		therefore (3) in the specific case of RED, the byte-mode packet drop
	should not be used. This memo updates RFC 2309 to deprecate		variant that drops fewer small packets should not be used. This memo
	deliberate preferential treatment of small packets in AQM algorithms.		updates RFC 2309 to deprecate deliberate preferential treatment of
			small packets in AQM algorithms.
	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
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on November 24, 2013.		This Internet-Draft will expire on February 2, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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		Provisions Relating to IETF Documents
	(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
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	Losses . . . . . . . . . . . . . . . . . . . . . . . . 23		Losses . . . . . . . . . . . . . . . . . . . . . . . . 23
	4.2.4. Congestion Notification: Summary of Conflicting		4.2.4. Congestion Notification: Summary of Conflicting
	Advice . . . . . . . . . . . . . . . . . . . . . . . . 23		Advice . . . . . . . . . . . . . . . . . . . . . . . . 23
	5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24		5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24
	5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24		5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24
	5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25		5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 25		6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26		8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27		10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 27		11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	11.2. Informative References . . . . . . . . . . . . . . . . . . 28		11.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. Survey of RED Implementation Status . . . . . . . . . 31		Appendix A. Survey of RED Implementation Status . . . . . . . . . 32
	Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32		Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 33
	B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33		B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 34
	B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36		B.2. Bit-Congestible and Packet-Congestible Indications . . . . 37
	Appendix C. Byte-mode Drop Complicates Policing Congestion		Appendix C. Byte-mode Drop Complicates Policing Congestion
	Response . . . . . . . . . . . . . . . . . . . . . . 37		Response . . . . . . . . . . . . . . . . . . . . . . 38
	Appendix D. Changes from Previous Versions . . . . . . . . . . . 38		Appendix D. Changes from Previous Versions . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	This memo concerns how we should correctly scale congestion control		This document provides recommendations of best current practice for
	functions with respect to packet size for the long term. It also		how we should correctly scale congestion control functions with
	recognises that expediency may be necessary to deal with existing		respect to packet size for the long term. It also recognises that
	widely deployed protocols that don't live up to the long term goal.		expediency may be necessary to deal with existing widely deployed
			protocols that don't live up to the long term goal.
	When signalling congestion, the problem of how (and whether) to take		When signalling congestion, the problem of how (and whether) to take
	packet sizes into account has exercised the minds of researchers and		packet sizes into account has exercised the minds of researchers and
	practitioners for as long as active queue management (AQM) has been		practitioners for as long as active queue management (AQM) has been
	discussed. Indeed, one reason AQM was originally introduced was to		discussed. Indeed, one reason AQM was originally introduced was to
	reduce the lock-out effects that small packets can have on large		reduce the lock-out effects that small packets can have on large
	packets in drop-tail queues. This memo aims to state the principles		packets in drop-tail queues. This memo aims to state the principles
	we should be using and to outline how these principles will affect		we should be using and to outline how these principles will affect
	future protocol design, taking into account the existing deployments		future protocol design, taking into account the existing deployments
	we have already.		we have already.
	skipping to change at page 4, line 39		skipping to change at page 4, line 40
	Encoding congestion notification into the wire protocol: When a		Encoding congestion notification into the wire protocol: When a
	congested network resource signals its level of congestion, should		congested network resource signals its level of congestion, should
	it drop / mark each packet dependent on the size of the particular		it drop / mark each packet dependent on the size of the particular
	packet in question?		packet in question?
	Decoding congestion notification from the wire protocol: When a		Decoding congestion notification from the wire protocol: When a
	transport interprets the notification in order to decide how much		transport interprets the notification in order to decide how much
	to respond to congestion, should it take into account the size of		to respond to congestion, should it take into account the size of
	each missing or marked packet?		each missing or marked packet?
	Consensus has emerged over the years concerning the first stage: if		Consensus has emerged over the years concerning the first stage,
	queues cannot be measured in time, whether they should be measured in		which Section 2.1 records in the RFC Series. In summary: If possible
	bytes or packets. Section 2.1 of this memo records this consensus in		it is best to measure congestion by time in the queue, but otherwise
	the RFC Series. In summary the choice solely depends on whether the		the choice between bytes and packets solely depends on whether the
	resource is congested by bytes or packets.		resource is congested by bytes or packets.
	The controversy is mainly around the last two stages: whether to		The controversy is mainly around the last two stages: whether to
	allow for the size of the specific packet notifying congestion i)		allow for the size of the specific packet notifying congestion i)
	when the network encodes or ii) when the transport decodes the		when the network encodes or ii) when the transport decodes the
	congestion notification.		congestion notification.
	Currently, the RFC series is silent on this matter other than a paper		Currently, the RFC series is silent on this matter other than a paper
	trail of advice referenced from [RFC2309], which conditionally		trail of advice referenced from [RFC2309], which conditionally
	recommends byte-mode (packet-size dependent) drop [pktByteEmail].		recommends byte-mode (packet-size dependent) drop [pktByteEmail].
	skipping to change at page 5, line 4		skipping to change at page 5, line 5
	resource is congested by bytes or packets.		resource is congested by bytes or packets.
	The controversy is mainly around the last two stages: whether to		The controversy is mainly around the last two stages: whether to
	allow for the size of the specific packet notifying congestion i)		allow for the size of the specific packet notifying congestion i)
	when the network encodes or ii) when the transport decodes the		when the network encodes or ii) when the transport decodes the
	congestion notification.		congestion notification.
	Currently, the RFC series is silent on this matter other than a paper		Currently, the RFC series is silent on this matter other than a paper
	trail of advice referenced from [RFC2309], which conditionally		trail of advice referenced from [RFC2309], which conditionally
	recommends byte-mode (packet-size dependent) drop [pktByteEmail].		recommends byte-mode (packet-size dependent) drop [pktByteEmail].
	Reducing drop of small packets certainly has some tempting		Reducing drop of small packets certainly has some tempting
	advantages: i) it drops less control packets, which tend to be small		advantages: i) it drops less control packets, which tend to be small
	and ii) it makes TCP's bit-rate less dependent on packet size.		and ii) it makes TCP's bit-rate less dependent on packet size.
	However, there are ways of addressing these issues at the transport		However, there are ways of addressing these issues at the transport
	layer, rather than reverse engineering network forwarding to fix the		layer, rather than reverse engineering network forwarding to fix the
	problems.		problems.
	This memo updates [RFC2309] to deprecate deliberate preferential		This memo updates [RFC2309] to deprecate deliberate preferential
	treatment of small packets in AQM algorithms. It recommends that (1)		treatment of packets in AQM algorithms solely because of their size.
	packet size should be taken into account when transports read		It recommends that (1) packet size should be taken into account when
	congestion indications, (2) not when network equipment writes them.		transports detect and respond to congestion indications, (2) not when
	This memo also adds to the congestion control principles enumerated		network equipment creates them. This memo also adds to the
	in BCP 41 [RFC2914].		congestion control principles enumerated in BCP 41 [RFC2914].
	In the particular case of Random early Detection (RED), this means		In the particular case of Random early Detection (RED), this means
	that the byte-mode packet drop variant should not be used to drop		that the byte-mode packet drop variant should not be used to drop
	fewer small packets, because that creates a perverse incentive for		fewer small packets, because that creates a perverse incentive for
	transports to use tiny segments, consequently also opening up a DoS		transports to use tiny segments, consequently also opening up a DoS
	vulnerability. Fortunately all the RED implementers who responded to		vulnerability. Fortunately all the RED implementers who responded to
	our admittedly limited survey (Section 4.2.4) have not followed the		our admittedly limited survey (Section 4.2.4) have not followed the
	earlier advice to use byte-mode drop, so the position this memo		earlier advice to use byte-mode drop, so the position this memo
	argues for seems to already exist in implementations.		argues for seems to already exist in implementations.
	skipping to change at page 6, line 13		skipping to change at page 6, line 13
	recommendations for the Internet community.		recommendations for the Internet community.
	1.1. Terminology and Scoping		1.1. Terminology and Scoping
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	This memo applies to the design of all AQM algorithms, for example,		This memo applies to the design of all AQM algorithms, for example,
	Random Early Detection (RED) [RFC2309], BLUE [BLUE02], Pre-Congestion		Random Early Detection (RED) [RFC2309], BLUE [BLUE02], Pre-Congestion
	Notification (PCN) [RFC5670], Controlled Delay (CoDel) [CoDel12] and		Notification (PCN) [RFC5670], Controlled Delay (CoDel)
	the Proportional Integral controller Enhanced (PIE)		[I-D.nichols-tsvwg-codel] and the Proportional Integral controller
	[I-D.pan-tsvwg-pie]. Throughout, RED is used as a concrete example		Enhanced (PIE) [I-D.pan-tsvwg-pie]. Throughout, RED is used as a
	because it is a widely known and deployed AQM algorithm. There is no		concrete example because it is a widely known and deployed AQM
	intention to imply that the advice is any less applicable to the		algorithm. There is no intention to imply that the advice is any
	other algorithms, nor that RED is preferred.		less applicable to the other algorithms, nor that RED is preferred.
	Congestion Notification: Congestion notification is a changing		Congestion Notification: Congestion notification is a changing
	signal that aims to communicate the probability that the network		signal that aims to communicate the probability that the network
	resource(s) will not be able to forward the level of traffic load		resource(s) will not be able to forward the level of traffic load
	offered (or that there is an impending risk that they will not be		offered (or that there is an impending risk that they will not be
	able to).		able to).
	The `impending risk' qualifier is added, because AQM systems set a		The `impending risk' qualifier is added, because AQM systems set a
	virtual limit smaller than the actual limit to the resource, then		virtual limit smaller than the actual limit to the resource, then
	notify when this virtual limit is exceeded in order to avoid		notify when this virtual limit is exceeded in order to avoid
	skipping to change at page 19, line 31		skipping to change at page 19, line 31
	how complicated the buffering scheme is, ultimately a transmission		how complicated the buffering scheme is, ultimately a transmission
	line is nearly always bit-congestible so the number of bytes queued		line is nearly always bit-congestible so the number of bytes queued
	up waiting for the line measures how congested the line is, and it is		up waiting for the line measures how congested the line is, and it is
	rarely important to measure how congested the buffering system is.		rarely important to measure how congested the buffering system is.
	4.1.2. Congestion Measurement without a Queue		4.1.2. Congestion Measurement without a Queue
	AQM algorithms are nearly always described assuming there is a queue		AQM algorithms are nearly always described assuming there is a queue
	for a congested resource and the algorithm can use the queue length		for a congested resource and the algorithm can use the queue length
	to determine the probability that it will drop or mark each packet.		to determine the probability that it will drop or mark each packet.
	But not all congested resources lead to queues. For instance,		But not all congested resources lead to queues. For instance, power
	wireless spectrum is usually regarded as bit-congestible (for a given		limited resources are usually bit-congestible if energy is primarily
	coding scheme). But wireless link protocols do not always maintain a		required for transmission rather than header processing, but it is
	queue that depends on spectrum interference. Similarly, power		rare for a link protocol to build a queue as it approaches maximum
	limited resources are also usually bit-congestible if energy is		power.
	primarily required for transmission rather than header processing,
	but it is rare for a link protocol to build a queue as it approaches
	maximum power.
	Nonetheless, AQM algorithms do not require a queue in order to work.		Nonetheless, AQM algorithms do not require a queue in order to work.
	For instance spectrum congestion can be modelled by signal quality		For instance spectrum congestion can be modelled by signal quality
	using target bit-energy-to-noise-density ratio. And, to model radio		using target bit-energy-to-noise-density ratio. And, to model radio
	power exhaustion, transmission power levels can be measured and		power exhaustion, transmission power levels can be measured and
	compared to the maximum power available. [ECNFixedWireless] proposes		compared to the maximum power available. [ECNFixedWireless] proposes
	a practical and theoretically sound way to combine congestion		a practical and theoretically sound way to combine congestion
	notification for different bit-congestible resources at different		notification for different bit-congestible resources at different
	layers along an end to end path, whether wireless or wired, and		layers along an end to end path, whether wireless or wired, and
	whether with or without queues.		whether with or without queues.
			In wireless protocols that use request to send / clear to send (RTS /
			CTS) control, such as some variants of IEEE802.11, it is reasonable
			to base an AQM on the time spent waiting for transmission
			opportunities (TXOPs) even though wireless spectrum is usually
			regarded as congested by bits (for a given coding scheme). This is
			because requests for TXOPs queue up as the spectrum gets congested by
			all the bits being transferred. So the time that TXOPs are queued
			directly reflects bit congestion of the spectrum.
	4.2. Congestion Notification Advice		4.2. Congestion Notification Advice
	4.2.1. Network Bias when Encoding		4.2.1. Network Bias when Encoding
	4.2.1.1. Advice on Packet Size Bias in RED		4.2.1.1. Advice on Packet Size Bias in RED
	The previously mentioned email [pktByteEmail] referred to by		The previously mentioned email [pktByteEmail] referred to by
	[RFC2309] advised that most scarce resources in the Internet were		[RFC2309] advised that most scarce resources in the Internet were
	bit-congestible, which is still believed to be true (Section 1.1).		bit-congestible, which is still believed to be true (Section 1.1).
	But it went on to offer advice that is updated by this memo. It said		But it went on to offer advice that is updated by this memo. It said
	skipping to change at page 25, line 29		skipping to change at page 25, line 34
	The IRTF Internet congestion control research group (ICCRG) has set		The IRTF Internet congestion control research group (ICCRG) has set
	itself the task of reaching consensus on generic forwarding		itself the task of reaching consensus on generic forwarding
	mechanisms that are necessary and sufficient to support the		mechanisms that are necessary and sufficient to support the
	Internet's future congestion control requirements (the first		Internet's future congestion control requirements (the first
	challenge in [RFC6077]). The research question of whether packet		challenge in [RFC6077]). The research question of whether packet
	congestion might become common and what to do if it does may in the		congestion might become common and what to do if it does may in the
	future be explored in the IRTF (the "Challenge 3: Packet Size" in		future be explored in the IRTF (the "Challenge 3: Packet Size" in
	[RFC6077]).		[RFC6077]).
			Note that sometimes it seems that resources might be congested by
			neither bits nor packets, e.g. where the queue for access to a
			wireless medium is in units of transmission opportunities. However,
			the root cause of congestion of the underlying spectrum is overload
			of bits (see Section 4.1.2).
	6. Security Considerations		6. Security Considerations
	This memo recommends that queues do not bias drop probability towards		This memo recommends that queues do not bias drop probability due to
	small packets as this creates a perverse incentive for transports to		packets size. For instance dropping small packets less often than
	break down their flows into tiny segments. One of the benefits of		large creates a perverse incentive for transports to break down their
	implementing AQM was meant to be to remove this perverse incentive		flows into tiny segments. One of the benefits of implementing AQM
	that drop-tail queues gave to small packets.		was meant to be to remove this perverse incentive that drop-tail
			queues gave to small packets.
	In practice, transports cannot all be trusted to respond to		In practice, transports cannot all be trusted to respond to
	congestion. So another reason for recommending that queues do not		congestion. So another reason for recommending that queues do not
	bias drop probability towards small packets is to avoid the		bias drop probability towards small packets is to avoid the
	vulnerability to small packet DDoS attacks that would otherwise		vulnerability to small packet DDoS attacks that would otherwise
	result. One of the benefits of implementing AQM was meant to be to		result. One of the benefits of implementing AQM was meant to be to
	remove drop-tail's DoS vulnerability to small packets, so we		remove drop-tail's DoS vulnerability to small packets, so we
	shouldn't add it back again.		shouldn't add it back again.
	If most queues implemented AQM with byte-mode drop, the resulting		If most queues implemented AQM with byte-mode drop, the resulting
	skipping to change at page 26, line 26		skipping to change at page 26, line 37
	This document has no actions for IANA.		This document has no actions for IANA.
	8. Conclusions		8. Conclusions
	This memo identifies the three distinct stages of the congestion		This memo identifies the three distinct stages of the congestion
	notification process where implementations need to decide whether to		notification process where implementations need to decide whether to
	take packet size into account. The recommendations provided in		take packet size into account. The recommendations provided in
	Section 2 of this memo are different in each case:		Section 2 of this memo are different in each case:
	o When network equipment measures the length of a queue, whether it		o When network equipment measures the length of a queue, if it is
	counts in bytes or packets depends on whether the network resource		not feasible to use time it is recommended to count in bytes if
	is congested respectively by bytes or by packets.		the network resource is congested by bytes, or to count in packets
			if is congested by packets.
	o When network equipment decides whether to drop (or mark) a packet,		o When network equipment decides whether to drop (or mark) a packet,
	it is recommended that the size of the particular packet should		it is recommended that the size of the particular packet should
	not be taken into account		not be taken into account
	o However, when a transport algorithm responds to a dropped or		o However, when a transport algorithm responds to a dropped or
	marked packet, the size of the rate reduction should be		marked packet, the size of the rate reduction should be
	proportionate to the size of the packet.		proportionate to the size of the packet.
	In summary, the answers are 'it depends', 'no' and 'yes' respectively		In summary, the answers are 'it depends', 'no' and 'yes' respectively
	skipping to change at page 27, line 26		skipping to change at page 27, line 38
	congestible. We need to know the likelihood that this assumption		congestible. We need to know the likelihood that this assumption
	will prevail longer term and, if it might not, what protocol changes		will prevail longer term and, if it might not, what protocol changes
	will be needed to cater for a mix of the two. The IRTF Internet		will be needed to cater for a mix of the two. The IRTF Internet
	Congestion Control Research Group (ICCRG) is currently working on		Congestion Control Research Group (ICCRG) is currently working on
	these problems [RFC6077].		these problems [RFC6077].
	9. Acknowledgements		9. Acknowledgements
	Thank you to Sally Floyd, who gave extensive and useful review		Thank you to Sally Floyd, who gave extensive and useful review
	comments. Also thanks for the reviews from Philip Eardley, David		comments. Also thanks for the reviews from Philip Eardley, David
	Black, Fred Baker, Toby Moncaster, Arnaud Jacquet and Mirja		Black, Fred Baker, David Taht, Toby Moncaster, Arnaud Jacquet and
	Kuehlewind as well as helpful explanations of different hardware		Mirja Kuehlewind as well as helpful explanations of different
	approaches from Larry Dunn and Fred Baker. We are grateful to Bruce		hardware approaches from Larry Dunn and Fred Baker. We are grateful
	Davie and his colleagues for providing a timely and efficient survey		to Bruce Davie and his colleagues for providing a timely and
	of RED implementation in Cisco's product range. Also grateful thanks		efficient survey of RED implementation in Cisco's product range.
	to Toby Moncaster, Will Dormann, John Regnault, Simon Carter and		Also grateful thanks to Toby Moncaster, Will Dormann, John Regnault,
	Stefaan De Cnodder who further helped survey the current status of		Simon Carter and Stefaan De Cnodder who further helped survey the
	RED implementation and deployment and, finally, thanks to the		current status of RED implementation and deployment and, finally,
	anonymous individuals who responded.		thanks to the anonymous individuals who responded.
	Bob Briscoe and Jukka Manner were partly funded by Trilogy, a		Bob Briscoe and Jukka Manner were partly funded by Trilogy, a
	research project (ICT- 216372) supported by the European Community		research project (ICT- 216372) supported by the European Community
	under its Seventh Framework Programme. The views expressed here are		under its Seventh Framework Programme. The views expressed here are
	those of the authors only.		those of the authors only.
	10. Comments Solicited		10. 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 mailing list		addressed to the IETF Transport Area working group mailing list
	<tsvwg@ietf.org>, and/or to the authors.		<tsvwg@ietf.org>, and/or to the authors.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to		[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels", BCP 14, RFC 2119,		Indicate Requirement Levels", BCP 14,
	March 1997.		RFC 2119, March 1997.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black,
	Addition of Explicit Congestion Notification		"The Addition of Explicit Congestion
	(ECN) to IP", RFC 3168, September 2001.		Notification (ECN) to IP", RFC 3168,
			September 2001.
	11.2. Informative References		11.2. Informative References
	[BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D. Saha,		[BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D.
	"The BLUE active queue management algorithms",		Saha, "The BLUE active queue management
	IEEE/ACM Transactions on Networking 10(4) 513--		algorithms", IEEE/ACM Transactions on
	528, August 2002,		Networking 10(4) 513--528, August 2002, <h
	<http://dx.doi.org/10.1109/TNET.2002.801399>.		ttp://dx.doi.org/10.1109/
			TNET.2002.801399>.
	[CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le Boudec,		[CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le
	"Congestion Control for Flows with Variable		Boudec, "Congestion Control for Flows with
	Packet Size", ACM CCR 34(2) 137--151, 2004,		Variable Packet Size", ACM CCR 34(2) 137--
	<http://doi.acm.org/10.1145/997150.997162>.		151, 2004,
			<http://doi.acm.org/10.1145/
			997150.997162>.
	[CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker,		[CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker,
	"Approximate Fair Dropping for Variable Length		"Approximate Fair Dropping for Variable
	Packets", IEEE Micro 21(1):48--56, January-		Length Packets", IEEE Micro 21(1):48--56,
	February 2001, <http://www.stanford.edu/~balaji/		January-February 2001, <http://
	papers/01approximatefair.pdf}>.		www.stanford.edu/~balaji/papers/
			01approximatefair.pdf}>.
	[CoDel12] Nichols, K. and V. Jacobson, "Controlling Queue		[DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-
	Delay", ACM Queue 10(5), May 2012,		Resource TCP/AQM for Processing-
	<http://queue.acm.org/detail.cfm?id=2209336>.		Constrained Networks", IEEE/ACM
			Transactions on Networking Vol 16, issue
			2, April 2008, <http://dx.doi.org/10.1109/
			TNET.2007.900415>.
	[DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-Resource		[DupTCP] Wischik, D., "Short messages", Royal
	TCP/AQM for Processing-Constrained Networks",		Society workshop on networks: modelling
	IEEE/ACM Transactions on Networking Vol 16,		and control , September 2007, <http://
	issue 2, April 2008,		www.cs.ucl.ac.uk/staff/ucacdjw/Research/
	<http://dx.doi.org/10.1109/TNET.2007.900415>.		shortmsg.html>.
	[DupTCP] Wischik, D., "Short messages", Royal Society		[ECNFixedWireless] Siris, V., "Resource Control for Elastic
	workshop on networks: modelling and control ,		Traffic in CDMA Networks", Proc. ACM
	September 2007, <http://www.cs.ucl.ac.uk/staff/		MOBICOM'02 , September 2002, <http://
	ucacdjw/Research/shortmsg.html>.		www.ics.forth.gr/netlab/publications/
			resource_control_elastic_cdma.html>.
	[ECNFixedWireless] Siris, V., "Resource Control for Elastic Traffic		[Evol_cc] Gibbens, R. and F. Kelly, "Resource
	in CDMA Networks", Proc. ACM MOBICOM'02 ,		pricing and the evolution of congestion
	September 2002, <http://www.ics.forth.gr/netlab/		control", Automatica 35(12)1969--1985,
	publications/		December 1999, <http://
	resource_control_elastic_cdma.html>.		www.statslab.cam.ac.uk/~frank/evol.html>.
	[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and		[I-D.nichols-tsvwg-codel] Nichols, K. and V. Jacobson, "Controlled
	the evolution of congestion control",		Delay Active Queue Management",
	Automatica 35(12)1969--1985, December 1999,		draft-nichols-tsvwg-codel-01 (work in
	<http://www.statslab.cam.ac.uk/~frank/		progress), February 2013.
	evol.html>.
	[I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and M.		[I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and
	Prabhu, "PIE: A Lightweight Control Scheme To		M. Prabhu, "PIE: A Lightweight Control
	Address the Bufferbloat Problem",		Scheme To Address the Bufferbloat
	draft-pan-tsvwg-pie-00 (work in progress),		Problem", draft-pan-tsvwg-pie-00 (work in
	December 2012.		progress), December 2012.
	[IOSArch] Bollapragada, V., White, R., and C. Murphy,		[IOSArch] Bollapragada, V., White, R., and C.
	"Inside Cisco IOS Software Architecture", Cisco		Murphy, "Inside Cisco IOS Software
	Press: CCIE Professional Development ISBN13:		Architecture", Cisco Press: CCIE
	978-1-57870-181-0, July 2000.		Professional Development ISBN13: 978-1-
			57870-181-0, July 2000.
	[PktSizeEquCC] Vasallo, P., "Variable Packet Size Equation-		[PktSizeEquCC] Vasallo, P., "Variable Packet Size
	Based Congestion Control", ICSI Technical		Equation-Based Congestion Control", ICSI
	Report tr-00-008, 2000, <http://		Technical Report tr-00-008, 2000, <http://
	http.icsi.berkeley.edu/ftp/global/pub/		http.icsi.berkeley.edu/ftp/global/pub/
	techreports/2000/tr-00-008.pdf>.		techreports/2000/tr-00-008.pdf>.
	[RED93] Floyd, S. and V. Jacobson, "Random Early		[RED93] Floyd, S. and V. Jacobson, "Random Early
	Detection (RED) gateways for Congestion		Detection (RED) gateways for Congestion
	Avoidance", IEEE/ACM Transactions on		Avoidance", IEEE/ACM Transactions on
	Networking 1(4) 397--413, August 1993,		Networking 1(4) 397--413, August 1993, <ht
	<http://www.icir.org/floyd/papers/red/red.html>.		tp://www.icir.org/floyd/papers/red/
			red.html>.
	[REDbias] Eddy, W. and M. Allman, "A Comparison of RED's		[REDbias] Eddy, W. and M. Allman, "A Comparison of
	Byte and Packet Modes", Computer Networks 42(3)		RED's Byte and Packet Modes", Computer
	261--280, June 2003, <http://www.ir.bbn.com/		Networks 42(3) 261--280, June 2003, <http:
	documents/articles/redbias.ps>.		//www.ir.bbn.com/documents/articles/
			redbias.ps>.
	[REDbyte] De Cnodder, S., Elloumi, O., and K. Pauwels,		[REDbyte] De Cnodder, S., Elloumi, O., and K.
	"RED behavior with different packet sizes",		Pauwels, "RED behavior with different
	Proc. 5th IEEE Symposium on Computers and		packet sizes", Proc. 5th IEEE Symposium on
	Communications (ISCC) 793--799, July 2000,		Computers and Communications (ISCC) 793--
	<http://www.icir.org/floyd/red/Elloumi99.pdf>.		799, July 2000, <http://www.icir.org/
			floyd/red/Elloumi99.pdf>.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,		[RFC2309] Braden, B., Clark, D., Crowcroft, J.,
	Deering, S., Estrin, D., Floyd, S., Jacobson,		Davie, B., Deering, S., Estrin, D., Floyd,
	V., Minshall, G., Partridge, C., Peterson, L.,		S., Jacobson, V., Minshall, G., Partridge,
	Ramakrishnan, K., Shenker, S., Wroclawski, J.,		C., Peterson, L., Ramakrishnan, K.,
	and L. Zhang, "Recommendations on Queue		Shenker, S., Wroclawski, J., and L. Zhang,
	Management and Congestion Avoidance in the		"Recommendations on Queue Management and
	Internet", RFC 2309, April 1998.		Congestion Avoidance in the Internet",
			RFC 2309, April 1998.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D.
	"Definition of the Differentiated Services Field		Black, "Definition of the Differentiated
	(DS Field) in the IPv4 and IPv6 Headers",		Services Field (DS Field) in the IPv4 and
	RFC 2474, December 1998.		IPv6 Headers", RFC 2474, December 1998.
	[RFC2914] Floyd, S., "Congestion Control Principles",		[RFC2914] Floyd, S., "Congestion Control
	BCP 41, RFC 2914, September 2000.		Principles", BCP 41, RFC 2914,
			September 2000.
	[RFC3426] Floyd, S., "General Architectural and Policy		[RFC3426] Floyd, S., "General Architectural and
	Considerations", RFC 3426, November 2002.		Policy Considerations", RFC 3426,
			November 2002.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and		[RFC3550] Schulzrinne, H., Casner, S., Frederick,
	V. Jacobson, "RTP: A Transport Protocol for		R., and V. Jacobson, "RTP: A Transport
	Real-Time Applications", STD 64, RFC 3550,		Protocol for Real-Time Applications",
	July 2003.		STD 64, RFC 3550, July 2003.
	[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding		[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns
	Congestion Control for Voice Traffic in the		Regarding Congestion Control for Voice
	Internet", RFC 3714, March 2004.		Traffic in the Internet", RFC 3714,
			March 2004.
	[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate		[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly
	Control (TFRC): The Small-Packet (SP) Variant",		Rate Control (TFRC): The Small-Packet (SP)
	RFC 4828, April 2007.		Variant", RFC 4828, April 2007.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J.		[RFC5348] Floyd, S., Handley, M., Padhye, J., and J.
	Widmer, "TCP Friendly Rate Control (TFRC):		Widmer, "TCP Friendly Rate Control (TFRC):
	Protocol Specification", RFC 5348,		Protocol Specification", RFC 5348,
	September 2008.		September 2008.
	[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.		[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and
	Ramakrishnan, "Adding Explicit Congestion		K. Ramakrishnan, "Adding Explicit
	Notification (ECN) Capability to TCP's SYN/ACK		Congestion Notification (ECN) Capability
	Packets", RFC 5562, June 2009.		to TCP's SYN/ACK Packets", RFC 5562,
			June 2009.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of		[RFC5670] Eardley, P., "Metering and Marking
	PCN-Nodes", RFC 5670, November 2009.		Behaviour of PCN-Nodes", RFC 5670,
			November 2009.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP		[RFC5681] Allman, M., Paxson, V., and E. Blanton,
	Congestion Control", RFC 5681, September 2009.		"TCP Congestion Control", RFC 5681,
			September 2009.
	[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar,		[RFC5690] Floyd, S., Arcia, A., Ros, D., and J.
	"Adding Acknowledgement Congestion Control to		Iyengar, "Adding Acknowledgement
	TCP", RFC 5690, February 2010.		Congestion Control to TCP", RFC 5690,
			February 2010.
	[RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B.		[RFC6077] Papadimitriou, D., Welzl, M., Scharf, M.,
	Briscoe, "Open Research Issues in Internet		and B. Briscoe, "Open Research Issues in
	Congestion Control", RFC 6077, February 2011.		Internet Congestion Control", RFC 6077,
			February 2011.
	[RFC6679] Westerlund, M., Johansson, I., Perkins, C.,		[RFC6679] Westerlund, M., Johansson, I., Perkins,
	O'Hanlon, P., and K. Carlberg, "Explicit		C., O'Hanlon, P., and K. Carlberg,
	Congestion Notification (ECN) for RTP over UDP",		"Explicit Congestion Notification (ECN)
	RFC 6679, August 2012.		for RTP over UDP", RFC 6679, August 2012.
	[RFC6789] Briscoe, B., Woundy, R., and A. Cooper,		[RFC6789] Briscoe, B., Woundy, R., and A. Cooper,
	"Congestion Exposure (ConEx) Concepts and Use		"Congestion Exposure (ConEx) Concepts and
	Cases", RFC 6789, December 2012.		Use Cases", RFC 6789, December 2012.
	[Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: Dismantling a		[Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness:
	Religion", ACM CCR 37(2)63--74, April 2007,		Dismantling a Religion", ACM
	<http://portal.acm.org/citation.cfm?id=1232926>.		CCR 37(2)63--74, April 2007, <http://
			portal.acm.org/citation.cfm?id=1232926>.
	[gentle_RED] Floyd, S., "Recommendation on using the		[gentle_RED] Floyd, S., "Recommendation on using the
	"gentle_" variant of RED", Web page ,		"gentle_" variant of RED", Web page ,
	March 2000,		March 2000, <http://www.icir.org/floyd/
	<http://www.icir.org/floyd/red/gentle.html>.		red/gentle.html>.
	[pBox] Floyd, S. and K. Fall, "Promoting the Use of		[pBox] Floyd, S. and K. Fall, "Promoting the Use
	End-to-End Congestion Control in the Internet",		of End-to-End Congestion Control in the
	IEEE/ACM Transactions on Networking 7(4) 458--		Internet", IEEE/ACM Transactions on
	472, August 1999,		Networking 7(4) 458--472, August 1999, <ht
	<http://www.aciri.org/floyd/end2end-paper.html>.		tp://www.aciri.org/floyd/
			end2end-paper.html>.
	[pktByteEmail] Floyd, S., "RED: Discussions of Byte and Packet		[pktByteEmail] Floyd, S., "RED: Discussions of Byte and
	Modes", email , March 1997, <http://		Packet Modes", email , March 1997, <http:/
	www-nrg.ee.lbl.gov/floyd/REDaveraging.txt>.		/www-nrg.ee.lbl.gov/floyd/
			REDaveraging.txt>.
	Appendix A. Survey of RED Implementation Status		Appendix A. Survey of RED Implementation Status
	This Appendix is informative, not normative.		This Appendix is informative, not normative.
	In May 2007 a survey was conducted of 84 vendors to assess how widely		In May 2007 a survey was conducted of 84 vendors to assess how widely
	drop probability based on packet size has been implemented in RED		drop probability based on packet size has been implemented in RED
	Table 3. About 19% of those surveyed replied, giving a sample size		Table 3. About 19% of those surveyed replied, giving a sample size
	of 16. Although in most cases we do not have permission to identify		of 16. Although in most cases we do not have permission to identify
	the respondents, we can say that those that have responded include		the respondents, we can say that those that have responded include
	skipping to change at page 39, line 5		skipping to change at page 40, line 5
	across different size flows [Rate_fair_Dis].		across different size flows [Rate_fair_Dis].
	Appendix D. Changes from Previous Versions		Appendix D. Changes from Previous Versions
	To be removed by the RFC Editor on publication.		To be removed by the RFC Editor on publication.
	Full incremental diffs between each version are available at		Full incremental diffs between each version are available at
	<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/>		<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/>
	(courtesy of the rfcdiff tool):		(courtesy of the rfcdiff tool):
			From -10 to -11: Following a further WGLC:
			* Abstract: clarified that advice applies to all AQMs including
			newer ones
			* Abstract & Intro: changed 'read' to 'detect', because you don't
			read losses, you detect them.
			* S.1. Introduction: Disambiguated summary of advice on queue
			measurement.
			* Clarified that the doc deprecates any preference based solely
			on packet size, it's not only against preferring smaller
			packets.
			* S.4.1.2. Congestion Measurement without a Queue: Explained
			that a queue of TXOPs represents a queue into spectrum
			congested by too many bits.
			* S.5.2: Bit- & Packet-congestible Network: Referred to
			explanation in S.4.1.2 to make the point that TXOPs are not a
			primary unit of workload like bits and packets are, even though
			you get queues of TXOPs.
			* 6. Security: Disambiguated 'bias towards'.
			* 8. Conclusions: Made consistent with recommendation to use
			time if possible for queue measurement.
	From -09 to -10: Following IESG review:		From -09 to -10: Following IESG review:
	* Updates 2309: Left header unchanged reflecting eventual IESG		* Updates 2309: Left header unchanged reflecting eventual IESG
	consensus [Sean Turner, Pete Resnick].		consensus [Sean Turner, Pete Resnick].
	* S.1 Intro: This memo adds to the congestion control principles		* S.1 Intro: This memo adds to the congestion control principles
	enumerated in BCP 41 [Pete Resnick]		enumerated in BCP 41 [Pete Resnick]
	* Abstract, S.1, S.1.1, s.1.2 Intro, Scoping and Example: Made		* Abstract, S.1, S.1.1, s.1.2 Intro, Scoping and Example: Made
	applicability to all AQMs clearer listing some more example		applicability to all AQMs clearer listing some more example
End of changes. 54 change blocks.
	201 lines changed or deleted		269 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/