draft-ietf-tsvwg-byte-pkt-congest-06.txt		draft-ietf-tsvwg-byte-pkt-congest-07.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: August 23, 2012 February 20, 2012		Expires: August 23, 2012 February 20, 2012
	Byte and Packet Congestion Notification		Byte and Packet Congestion Notification
	draft-ietf-tsvwg-byte-pkt-congest-06		draft-ietf-tsvwg-byte-pkt-congest-07
	Abstract		Abstract
	This memo concerns dropping or marking packets using active queue		This memo concerns dropping or marking packets using active queue
	management (AQM) such as random early detection (RED) or pre-		management (AQM) such as random early detection (RED) or pre-
	congestion notification (PCN). We give three strong recommendations:		congestion notification (PCN). We give three strong recommendations:
	(1) packet size should be taken into account when transports read and		(1) packet size should be taken into account when transports read and
	respond to congestion indications, (2) packet size should not be		respond to congestion indications, (2) packet size should not be
	taken into account when network equipment creates congestion signals		taken into account when network equipment creates congestion signals
	(marking, dropping), and therefore (3) the byte-mode packet drop		(marking, dropping), and therefore (3) the byte-mode packet drop
	skipping to change at page 9, line 51		skipping to change at page 9, line 51
	on the size of the packet in question. As the example in Section 1.2		on the size of the packet in question. As the example in Section 1.2
	illustrates, to drop any bit with probability 0.1% it is only		illustrates, to drop any bit with probability 0.1% it is only
	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 TCP:		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 NOT use byte-mode drop, which
	deflates RED's drop probability for smaller packet sizes. RED's		deflates RED's drop probability for smaller packet sizes. RED's
	byte-mode drop has no enduring advantages. It is more complex,		byte-mode drop has no enduring advantages. It is more complex,
	it creates the perverse incentive to fragment segments into tiny		it creates the perverse incentive to fragment segments into tiny
	pieces and it reopens the vulnerability to floods of small-		pieces and it reopens the vulnerability to floods of small-
	packets that drop-tail queues suffered from and AQM was designed		packets that drop-tail queues suffered from and AQM was designed
	to remove.		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
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	packet.		packet.
	Therefore, the IETF transport area should continue its programme of;		Therefore, the IETF transport area should continue 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.
	Corollaries:		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.
	skipping to change at page 28, line 45		skipping to change at page 28, line 45
	www.statslab.cam.ac.uk/~frank/		www.statslab.cam.ac.uk/~frank/
	evol.html>.		evol.html>.
	[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-06		draft-ietf-avtcore-ecn-for-rtp-06
	(work in progress), February 2012.		(work in progress), February 2012.
	[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., Moncaster,		[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.
	T., and J. Leslie, "ConEx Concepts		Cooper, "ConEx Concepts and Use
	and Use Cases",		Cases",
	draft-ietf-conex-concepts-uses-00		draft-ietf-conex-concepts-uses-03
	(work in progress), November 2010.		(work in progress), October 2011.
	[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",
	skipping to change at page 39, line 5		skipping to change at page 39, 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 -06 to -07:
			* A mix-up with the corollaries and their naming in 2.1 to 2.3
			fixed.
	From -05 to -06:		From -05 to -06:
	* Primarily editorial fixes.		* Primarily editorial fixes.
	From -04 to -05:		From -04 to -05:
	* Changed from Informational to BCP and highlighted non-normative		* Changed from Informational to BCP and highlighted non-normative
	sections and appendices		sections and appendices
	* Removed language about consensus		* Removed language about consensus
End of changes. 5 change blocks.
	8 lines changed or deleted		13 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/