draft-ietf-tsvwg-byte-pkt-congest-08.txt		draft-ietf-tsvwg-byte-pkt-congest-09.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: February 14, 2013 August 13, 2012		Expires: May 11, 2013 November 7, 2012
	Byte and Packet Congestion Notification		Byte and Packet Congestion Notification
	draft-ietf-tsvwg-byte-pkt-congest-08		draft-ietf-tsvwg-byte-pkt-congest-09
	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 active queue management (AQM) such		dropping or marking packets using active queue management (AQM) such
	as random early detection (RED) or pre-congestion notification (PCN).		as random early detection (RED) or pre-congestion notification (PCN).
	We give three strong recommendations: (1) packet size should be taken		We give three strong recommendations: (1) packet size should be taken
	into account when transports read and respond to congestion		into account when transports read and respond to congestion
	indications, (2) packet size should not be taken into account when		indications, (2) packet size should not be taken into account when
	network equipment creates congestion signals (marking, dropping), and		network equipment creates congestion signals (marking, dropping), and
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 February 14, 2013.		This Internet-Draft will expire on May 11, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 16		skipping to change at page 3, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology and Scoping . . . . . . . . . . . . . . . . . 6		1.1. Terminology and Scoping . . . . . . . . . . . . . . . . . 6
	1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop . . 7		1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop . . 7
	2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8		2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Recommendation on Queue Measurement . . . . . . . . . . . 9		2.1. Recommendation on Queue Measurement . . . . . . . . . . . 9
	2.2. Recommendation on Encoding Congestion Notification . . . . 9		2.2. Recommendation on Encoding Congestion Notification . . . . 9
	2.3. Recommendation on Responding to Congestion . . . . . . . . 10		2.3. Recommendation on Responding to Congestion . . . . . . . . 10
	2.4. Recommendation on Handling Congestion Indications when		2.4. Recommendation on Handling Congestion Indications when
	Splitting or Merging Packets . . . . . . . . . . . . . . . 11		Splitting or Merging Packets . . . . . . . . . . . . . . . 11
	3. Motivating Arguments . . . . . . . . . . . . . . . . . . . . . 11		3. Motivating Arguments . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Avoiding Perverse Incentives to (Ab)use Smaller Packets . 12		3.1. Avoiding Perverse Incentives to (Ab)use Smaller Packets . 12
	3.2. Small != Control . . . . . . . . . . . . . . . . . . . . . 13		3.2. Small != Control . . . . . . . . . . . . . . . . . . . . . 13
	3.3. Transport-Independent Network . . . . . . . . . . . . . . 13		3.3. Transport-Independent Network . . . . . . . . . . . . . . 13
	3.4. Scaling Congestion Control with Packet Size . . . . . . . 14		3.4. Partial Deployment of AQM . . . . . . . . . . . . . . . . 15
	3.5. Implementation Efficiency . . . . . . . . . . . . . . . . 16		3.5. Implementation Efficiency . . . . . . . . . . . . . . . . 16
	4. A Survey and Critique of Past Advice . . . . . . . . . . . . . 16		4. A Survey and Critique of Past Advice . . . . . . . . . . . . . 16
	4.1. Congestion Measurement Advice . . . . . . . . . . . . . . 16		4.1. Congestion Measurement Advice . . . . . . . . . . . . . . 17
	4.1.1. Fixed Size Packet Buffers . . . . . . . . . . . . . . 17		4.1.1. Fixed Size Packet Buffers . . . . . . . . . . . . . . 17
	4.1.2. Congestion Measurement without a Queue . . . . . . . . 18		4.1.2. Congestion Measurement without a Queue . . . . . . . . 18
	4.2. Congestion Notification Advice . . . . . . . . . . . . . . 19		4.2. Congestion Notification Advice . . . . . . . . . . . . . . 19
	4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19		4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19
	4.2.2. Transport Bias when Decoding . . . . . . . . . . . . . 21		4.2.2. Transport Bias when Decoding . . . . . . . . . . . . . 21
	4.2.3. Making Transports Robust against Control Packet		4.2.3. Making Transports Robust against Control Packet
	Losses . . . . . . . . . . . . . . . . . . . . . . . . 22		Losses . . . . . . . . . . . . . . . . . . . . . . . . 22
	4.2.4. Congestion Notification: Summary of Conflicting		4.2.4. Congestion Notification: Summary of Conflicting
	Advice . . . . . . . . . . . . . . . . . . . . . . . . 22		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 . . . . . . . . . . . . 24		5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 24
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 24		6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25		8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27		10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 27		11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	11.2. Informative References . . . . . . . . . . . . . . . . . . 27		11.2. Informative References . . . . . . . . . . . . . . . . . . 27
	Appendix A. Survey of RED Implementation Status . . . . . . . . . 31		Appendix A. Survey of RED Implementation Status . . . . . . . . . 31
	Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32		Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32
	B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33		B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33
	B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36		B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36
	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 memo concerns how we should correctly scale congestion control
	functions with packet size for the long term. It also recognises		functions with packet size for the long term. It also recognises
	that expediency may be necessary to deal with existing widely		that expediency may be necessary to deal with existing widely
	deployed protocols that don't live up to the long term goal.		deployed protocols that don't live up to the long term goal.
	When notifying congestion, the problem of how (and whether) to take		When notifying 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
	skipping to change at page 10, line 5		skipping to change at page 10, line 5
	necessary to drop every packet with probability 0.1% without regard		necessary to drop every packet with probability 0.1% without regard
	to the size of each packet.		to the size of each packet.
	This approach ensures the network layer offers sufficient congestion		This approach ensures the network layer offers sufficient congestion
	information for all known and future transport protocols and also		information for all known and future transport protocols and also
	ensures no perverse incentives are created that would encourage		ensures no perverse incentives are created that would encourage
	transports to use inappropriately small packet sizes.		transports to use inappropriately small packet sizes.
	What this advice means for the case of RED:		What this advice means for the case of RED:
	1. AQM algorithms such as RED SHOULD NOT use byte-mode drop, which		1. AQM algorithms such as RED SHOULD use packet-mode drop, ie they
	deflates RED's drop probability for smaller packet sizes. RED's		SHOULD NOT use byte-mode drop. The latter is more complex, it
	byte-mode drop has no enduring advantages. It is more complex,		creates the perverse incentive to fragment segments into tiny
	it creates the perverse incentive to fragment segments into tiny		pieces and it is vulnerable to floods of small packets.
	pieces and it reopens the vulnerability to floods of small-
	packets that drop-tail queues suffered from and AQM was designed
	to remove.
	2. If a vendor has implemented byte-mode drop, and an operator has		2. If a vendor has implemented byte-mode drop, and an operator has
	turned it on, it is RECOMMENDED to turn it off. Note that RED as		turned it on, it is RECOMMENDED to turn it off, after
	a whole SHOULD NOT be turned off, as without it, a drop tail		establishing if there are any implications on the relative
	queue also biases against large packets. But note also that		performance of applications using different packet sizes.
	turning off byte-mode drop may alter the relative performance of		RED as a whole SHOULD NOT be turned off. Without RED, a drop
	applications using different packet sizes, so it would be		tail queue biases against large packets and is vulnerable to
	advisable to establish the implications before turning it off.		floods of small packets.
	Note well that RED's byte-mode queue drop is completely		Note well that RED's byte-mode queue drop is completely orthogonal to
	orthogonal to byte-mode queue measurement and should not be		byte-mode queue measurement and should not be confused with it. If a
	confused with it. If a RED implementation has a byte-mode but		RED implementation has a byte-mode but does not specify what sort of
	does not specify what sort of byte-mode, it is most probably		byte-mode, it is most probably byte-mode queue measurement, which is
	byte-mode queue measurement, which is fine. However, if in		fine. However, if in doubt, the vendor should be consulted.
	doubt, the vendor should be consulted.
	A survey (Appendix A) showed that there appears to be little, if any,		A survey (Appendix A) showed that there appears to be little, if any,
	installed base of the byte-mode drop variant of RED. This suggests		installed base of the byte-mode drop variant of RED. This suggests
	that deprecating byte-mode drop will have little, if any, incremental		that deprecating byte-mode drop will have little, if any, incremental
	deployment impact.		deployment impact.
	2.3. Recommendation on Responding to Congestion		2.3. Recommendation on Responding to Congestion
	When a transport detects that a packet has been lost or congestion		When a transport detects that a packet has been lost or congestion
	marked, it SHOULD consider the strength of the congestion indication		marked, it SHOULD consider the strength of the congestion indication
	as proportionate to the size in octets (bytes) of the missing or		as proportionate to the size in octets (bytes) of the missing or
	marked packet.		marked packet.
	In other words, when a packet indicates congestion (by being lost or		In other words, when a packet indicates congestion (by being lost or
	marked) it can be considered conceptually as if there is a congestion		marked) it can be considered conceptually as if there is a congestion
	indication on every octet of the packet, not just one indication per		indication on every octet of the packet, not just one indication per
	packet.		packet.
	Therefore, the IETF transport area should continue its programme of;		To be clear, the above recommendation solely describes how a
			transport should interpret the meaning of a congestion indication.
			It makes no recommendation on whether a transport should act
			differently based on this interpretation. It merely aids
			interoperablity between transports, if they choose to make their
			actions depend on the strength of congestion indications.
			This definition will be useful as the the IETF transport area
			continues its programme of;
	o updating host-based congestion control protocols to take account		o updating host-based congestion control protocols to take account
	of packet size		of packet size
	o making transports less sensitive to losing control packets like		o making transports less sensitive to losing control packets like
	SYNs and pure ACKs.		SYNs and pure ACKs.
	What this advice means for the case of TCP:		What this advice means for the case of TCP:
	1. If two TCP flows with different packet sizes are required to run		1. If two TCP flows with different packet sizes are required to run
	at equal bit rates under the same path conditions, this should be		at equal bit rates under the same path conditions, this should be
	done by altering TCP (Section 4.2.2), not network equipment (the		done by altering TCP (Section 4.2.2), not network equipment (the
	latter affects other transports besides TCP).		latter affects other transports besides TCP).
	2. If it is desired to improve TCP performance by reducing the		2. If it is desired to improve TCP performance by reducing the
	chance that a SYN or a pure ACK will be dropped, this should be		chance that a SYN or a pure ACK will be dropped, this should be
	done by modifying TCP (Section 4.2.3), not network equipment.		done by modifying TCP (Section 4.2.3), not network equipment.
			To be clear, we are not recommending at all that TCPs under
			equivalent conditions should aim for equal bit-rates. We are merely
			saying that anyone trying to do such a thing should modify their TCP
			algorithm, not the network.
	2.4. Recommendation on Handling Congestion Indications when Splitting		2.4. Recommendation on Handling Congestion Indications when Splitting
	or Merging Packets		or Merging Packets
	Packets carrying congestion indications may be split or merged in		Packets carrying congestion indications may be split or merged in
	some circumstances (e.g. at a RTCP transcoder or during IP fragment		some circumstances (e.g. at a RTCP transcoder or during IP fragment
	reassembly). Splitting and merging only make sense in the context of		reassembly). Splitting and merging only make sense in the context of
	ECN, not loss.		ECN, not loss.
	The general rule to follow is that the number of octets in packets		The general rule to follow is that the number of octets in packets
	with congestion indications SHOULD be equivalent before and after		with congestion indications SHOULD be equivalent before and after
	skipping to change at page 13, line 40		skipping to change at page 13, line 48
	packets (see 'Making Transports Robust against Control Packet Losses'		packets (see 'Making Transports Robust against Control Packet Losses'
	in Section 4.2.3).		in Section 4.2.3).
	3.3. Transport-Independent Network		3.3. Transport-Independent Network
	TCP congestion control ensures that flows competing for the same		TCP congestion control ensures that flows competing for the same
	resource each maintain the same number of segments in flight,		resource each maintain the same number of segments in flight,
	irrespective of segment size. So under similar conditions, flows		irrespective of segment size. So under similar conditions, flows
	with different segment sizes will get different bit-rates.		with different segment sizes will get different bit-rates.
	One motivation for the network biasing congestion notification by		To counter this effect it seems tempting not to follow our
	packet size is to counter this effect and try to equalise the bit-		recommendation, and instead for the network to bias congestion
	rates of flows with different packet sizes. However, in order to do		notification by packet size in order to equalise the bit-rates of
	this, the queuing algorithm has to make assumptions about the		flows with different packet sizes. However, in order to do this, the
	transport, which become embedded in the network. Specifically:		queuing algorithm has to make assumptions about the transport, which
			become embedded in the network. Specifically:
	o The queuing algorithm has to assume how aggressively the transport		o The queuing algorithm has to assume how aggressively the transport
	will respond to congestion (see Section 4.2.4). If the network		will respond to congestion (see Section 4.2.4). If the network
	assumes the transport responds as aggressively as TCP NewReno, it		assumes the transport responds as aggressively as TCP NewReno, it
	will be wrong for Compound TCP and differently wrong for Cubic		will be wrong for Compound TCP and differently wrong for Cubic
	TCP, etc. To achieve equal bit-rates, each transport then has to		TCP, etc. To achieve equal bit-rates, each transport then has to
	guess what assumption the network made, and work out how to		guess what assumption the network made, and work out how to
	replace this assumed aggressiveness with its own aggressiveness.		replace this assumed aggressiveness with its own aggressiveness.
	o Also, if the network biases congestion notification by packet size		o Also, if the network biases congestion notification by packet size
	it has to assume a baseline packet size--all proposed algorithms		it has to assume a baseline packet size--all proposed algorithms
	use the local MTU. Then transports have to guess which link was		use the local MTU (for example see the byte-mode loss probability
	congested and what its local MTU was, in order to know how to		formula in Table 1). Then if the non-Reno transports mentioned
	tailor their congestion response to that link.		above are trying to reverse engineer what the network assumed,
			they also have to guess the MTU of the congested link.
	Even though reducing the drop probability of small packets (e.g.		Even though reducing the drop probability of small packets (e.g.
	RED's byte-mode drop) helps ensure TCP flows with different packet		RED's byte-mode drop) helps ensure TCP flows with different packet
	sizes will achieve similar bit rates, we argue this correction should		sizes will achieve similar bit rates, we argue this correction should
	be made to any future transport protocols based on TCP, not to the		be made to any future transport protocols based on TCP, not to the
	network in order to fix one transport, no matter how predominant it		network in order to fix one transport, no matter how predominant it
	is. Effectively, favouring small packets is reverse engineering of		is. Effectively, favouring small packets is reverse engineering of
	network equipment around one particular transport protocol (TCP),		network equipment around one particular transport protocol (TCP),
	contrary to the excellent advice in [RFC3426], which asks designers		contrary to the excellent advice in [RFC3426], which asks designers
	to question "Why are you proposing a solution at this layer of the		to question "Why are you proposing a solution at this layer of the
	skipping to change at page 14, line 41		skipping to change at page 15, line 5
	scenarios.		scenarios.
	When the network does not take account of packet size, it allows		When the network does not take account of packet size, it allows
	transport protocols to choose whether to take account of packet size		transport protocols to choose whether to take account of packet size
	or not. However, if the network were to bias congestion notification		or not. However, if the network were to bias congestion notification
	by packet size, transport protocols would have no choice; those that		by packet size, transport protocols would have no choice; those that
	did not take account of packet size themselves would unwittingly		did not take account of packet size themselves would unwittingly
	become dependent on packet size, and those that already took account		become dependent on packet size, and those that already took account
	of packet size would end up taking account of it twice.		of packet size would end up taking account of it twice.
	3.4. Scaling Congestion Control with Packet Size		3.4. Partial Deployment of AQM
	Having so far justified only our recommendations for the network,		In overview, the argument in this section runs as follows:
	this section focuses on the host. We construct a scaling argument to
	justify the recommendation that a host should respond to a dropped or
	marked packet in proportion to its size, not just as a single
	congestion event.
	The argument assumes that we have already sufficiently justified our		o Because the network does not and cannot always drop packets in
	recommendation that the network should not take account of packet		proportion to their size, it shouldn't be given the task of making
	size.		drop signals depend on packet size at all.
	Also, we assume bit-congestible links are the predominant source of		o Transports on the other hand don't always want to make their rate
	congestion. As the Internet stands, it is hard if not impossible to		response proportional to the size of dropped packets, but if they
	know whether congestion notification is from a bit-congestible or a		want to, they always can.
	packet-congestible resource (see Appendix B.2) so we have to assume
	the most prevalent case (see Section 1.1). If this assumption is
	wrong, and particular congestion indications are actually due to
	overload of packet-processing, there is no issue of safety at stake.
	Any congestion control that triggers a multiplicative decrease in
	response to a congestion indication will bring packet processing back
	to its operating point just as quickly. The only issue at stake is
	that the resource could be utilised more efficiently if packet-
	congestion could be separately identified.
	Imagine a bit-congestible link shared by many flows, so that each		The argument is similar to the end-to-end argument that says "Don't
	busy period tends to cause packets to be lost from different flows.		do X in the network if end-systems can do X by themselves, and they
	Consider further two sources that have the same data rate but break		want to be able to choose whether to do X anyway." Actually the
	the load into large packets in one application (A) and small packets		following argument is stronger; in addition it says "Don't give the
	in the other (B). Of course, because the load is the same, there		network task X that could be done by the end-systems, if X is not
	will be proportionately more packets in the small packet flow (B).		deployed on all network nodes, and end-systems won't be able to tell
			whether their network is doing X, or whether they need to do X
			themselves." In this case, the X in question is "making the response
			to congestion depend on packet size".
	If a congestion control scales with packet size it should respond in		We will now re-run this argument taking each step in more depth. The
	the same way to the same congestion notification, irrespective of the		argument applies solely to drop, not to ECN marking.
	size of the packets containing the bytes that contribute to
	congestion.
	A bit-congestible queue suffering congestion has to drop or mark the		A queue drops packets for either of two reasons: a) to signal to host
	same excess bytes whether they are in a few large packets (A) or many		congestion controls that they should reduce the load and b) because
	small packets (B). So for the same amount of congestion overload,		there is no buffer left to store the packets. Active queue
	the same amount of bytes has to be shed to get the load back to its		management tries to use drops as a signal for hosts to slow down
	operating point. For smaller packets (B) more packets will have to		(case a) so that drop due to buffer exhaustion (case b) should not be
	be discarded to shed the same bytes.		necessary.
	If both the transports interpret each drop/mark as a single loss		AQM is not universally deployed in every queue in the Internet; many
	event irrespective of the size of the packet dropped, the flow of		cheap ethernet bridges, software firewalls, NATs on consumer devices,
	smaller packets (B) will respond more times to the same congestion.		etc implement simple tail-drop buffers. Even if AQM were universal,
	On the other hand, if a transport responds proportionately less when		it has to be able to cope with buffer exhaustion (by switching to a
	smaller packets are dropped/marked, overall it will be able to		behaviour like tail-drop), in order to cope with unresponsive or
	respond the same to the same amount of congestion.		excessive transports. For these reasons networks will sometimes be
			dropping packets as a last resort (case b) rather than under AQM
			control (case a).
	Therefore, for a congestion control to scale with packet size it		When buffers are exhausted (case b), they don't naturally drop
	should respond to dropped or marked bytes (as TFRC-SP [RFC4828]		packets in proportion to their size. The network can only reduce the
	effectively does), instead of dropped or marked packets (as TCP		probability of dropping smaller packets if it has enough space to
	does).		store them somewhere while it waits for a larger packet that it can
			drop. If the buffer is exhausted, it does not have this choice.
			Admittedly tail-drop does naturally drop somewhat fewer small
			packets, but exactly how few depends more on the mix of sizes than
			the size of the packet in question. Nonetheless, in general, if we
			wanted networks to do size-dependent drop, we would need universal
			deployment of (packet-size dependent) AQM code, which is currently
			unrealistic.
	For the avoidance of doubt, this is not a recommendation that TCP		A host transport cannot know whether any particular drop was a
	should be changed so that it scales with packet size. It is a		deliberate signal from an AQM or a sign of a queue shedding packets
	recommendation that any future transport protocol proposal should		due to buffer exhaustion. Therefore, because the network cannot
	respond to dropped or marked bytes if it wishes to claim that it is		universally do size-dependent drop, it should not do it all.
	scalable.
			Whereas universality is desirable in the network, diversity is
			desirable between different transport layer protocols - some, like
			NewReno TCP [RFC5681], may not choose to make their rate response
			proportionate to the size of each dropped packet, while others will
			(e.g. TFRC-SP [RFC4828]).
	3.5. Implementation Efficiency		3.5. Implementation Efficiency
	Allowing for packet size at the transport rather than in the network		Biasing against large packets typically requires an extra multiply
	ensures that neither the network nor the transport needs to do a		and divide in the network (see the example byte-mode drop formula in
	multiply operation--multiplication by packet size is effectively		Table 1). Allowing for packet size at the transport rather than in
	achieved as a repeated add when the transport adds to its count of		the network ensures that neither the network nor the transport needs
	marked bytes as each congestion event is fed to it. This isn't a		to do a multiply operation--multiplication by packet size is
	principled reason in itself, but it is a happy consequence of the		effectively achieved as a repeated add when the transport adds to its
	other principled reasons.		count of marked bytes as each congestion event is fed to it. Also
			the work to do the biasing is spread over many hosts, rather than
			concentrated in just the congested network element. These aren't
			principled reasons in themselves, but they are a happy consequence of
			the other principled reasons.
	4. A Survey and Critique of Past Advice		4. A Survey and Critique of Past Advice
	This section is informative, not normative.		This section is informative, not normative.
	The original 1993 paper on RED [RED93] proposed two options for the		The original 1993 paper on RED [RED93] proposed two options for the
	RED active queue management algorithm: packet mode and byte mode.		RED active queue management algorithm: packet mode and byte mode.
	Packet mode measured the queue length in packets and dropped (or		Packet mode measured the queue length in packets and dropped (or
	marked) individual packets with a probability independent of their		marked) individual packets with a probability independent of their
	size. Byte mode measured the queue length in bytes and marked an		size. Byte mode measured the queue length in bytes and marked an
	skipping to change at page 28, line 38		skipping to change at page 29, line 4
	[I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I.,		[I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I.,
	Perkins, C., O'Hanlon, P., and K.		Perkins, C., O'Hanlon, P., and K.
	Carlberg, "Explicit Congestion		Carlberg, "Explicit Congestion
	Notification (ECN) for RTP over UDP",		Notification (ECN) for RTP over UDP",
	draft-ietf-avtcore-ecn-for-rtp-08		draft-ietf-avtcore-ecn-for-rtp-08
	(work in progress), May 2012.		(work in progress), May 2012.
	[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.		[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.
	Cooper, "ConEx Concepts and Use		Cooper, "ConEx Concepts and Use
	Cases",		Cases",
	draft-ietf-conex-concepts-uses-04
	(work in progress), March 2012.		(work in progress), March 2012.
	[IOSArch] Bollapragada, V., White, R., and C.		[IOSArch] Bollapragada, V., White, R., and C.
	Murphy, "Inside Cisco IOS Software		Murphy, "Inside Cisco IOS Software
	Architecture", Cisco Press: CCIE		Architecture", Cisco Press: CCIE
	Professional Development ISBN13: 978-		Professional Development ISBN13: 978-
	1-57870-181-0, July 2000.		1-57870-181-0, July 2000.
	[PktSizeEquCC] Vasallo, P., "Variable Packet Size		[PktSizeEquCC] Vasallo, P., "Variable Packet Size
	Equation-Based Congestion Control",		Equation-Based Congestion Control",
End of changes. 29 change blocks.
	100 lines changed or deleted		116 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/