draft-ietf-tcpm-ecnsyn-00.txt		draft-ietf-tcpm-ecnsyn-01.txt
	Internet Engineering Task Force A. Kuzmanovic		Internet Engineering Task Force A. Kuzmanovic
	INTERNET DRAFT Northwestern University		INTERNET DRAFT Northwestern University
	draft-ietf-tcpm-ecnsyn-00.txt S. Floyd		draft-ietf-tcpm-ecnsyn-01.txt S. Floyd
	ICIR		ICIR
	K.K. Ramakrishnan		K.K. Ramakrishnan
	AT&T		AT&T
	January, 2006		October, 2006
	Adding Explicit Congestion Notification (ECN) Capability to TCP's		Adding Explicit Congestion Notification (ECN) Capability to TCP's
	SYN/ACK Packets		SYN/ACK Packets
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to		Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to
	the TCP connection, avoiding the severe penalty of a retransmit		the TCP connection, avoiding the severe penalty of a retransmit
	timeout for a connection that has not yet started placing a load on		timeout for a connection that has not yet started placing a load on
	the network. The sender of the SYN/ACK packet must respond to an ECN		the network. The sender of the SYN/ACK packet must respond to an ECN
	mark by reducing its initial congestion window from two, three, or		mark by reducing its initial congestion window from two, three, or
	four segments to one segment, reducing the subsequent load from that		four segments to one segment, reducing the subsequent load from that
	connection on the network.		connection on the network.
	NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.		NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
	Changes from draft-ietf-twvsg-ecnsyn:		Changes from draft-ietf-tcpm-ecnsyn-00:
			* Only updating the revision number.
			Changes from draft-ietf-twvsg-ecnsyn-00:
	* Changed name of draft to draft-ietf-tcpm-ecnsyn.		* Changed name of draft to draft-ietf-tcpm-ecnsyn.
	* Added a discussion in Section 3 of "Response to		* Added a discussion in Section 3 of "Response to
	ECN-marking of SYN/ACK packets". Based on		ECN-marking of SYN/ACK packets". Based on
	suggestions from Mark Allman.		suggestions from Mark Allman.
	* Added a discussion to the Conclusions about adding		* Added a discussion to the Conclusions about adding
	ECN-capability to relevant set-up packets in other		ECN-capability to relevant set-up packets in other
	protocols. From a suggestion from Wesley Eddy.		protocols. From a suggestion from Wesley Eddy.
	skipping to change at page 9, line 12		skipping to change at page 9, line 12
	packets should generally be low. In this case, the benefit of making		packets should generally be low. In this case, the benefit of making
	SYN/ACK packets ECN-Capable should be similarly moderate. However,		SYN/ACK packets ECN-Capable should be similarly moderate. However,
	for a congested router with a Drop Tail queue in units of packets or		for a congested router with a Drop Tail queue in units of packets or
	with an AQM mechanism in packet mode, and with no priority queueing		with an AQM mechanism in packet mode, and with no priority queueing
	for smaller packets, small and large packets should have the same		for smaller packets, small and large packets should have the same
	probability of being dropped or marked. In such a case, making		probability of being dropped or marked. In such a case, making
	SYN/ACK packets ECN-Capable should be of significant benefit.		SYN/ACK packets ECN-Capable should be of significant benefit.
	We believe that there are a wide range of behaviors in the real world		We believe that there are a wide range of behaviors in the real world
	in terms of the drop or mark behavior at routers as a function of		in terms of the drop or mark behavior at routers as a function of
	packet size [Tools, Section 10]. We note that all of these		packet size [Tools] (Section 10). We note that all of these
	alternatives listed above are available in the NS simulator (Drop		alternatives listed above are available in the NS simulator (Drop
	Tail queues are by default in units of packets, while the default for		Tail queues are by default in units of packets, while the default for
	RED queue management has been changed from packet mode to byte mode).		RED queue management has been changed from packet mode to byte mode).
	Response to ECN-marking of SYN/ACK packets:		Response to ECN-marking of SYN/ACK packets:
	One question is why TCP SYN/ACK packets should be treated differently		One question is why TCP SYN/ACK packets should be treated differently
	from other packets in terms of the packet sender's response to an		from other packets in terms of the packet sender's response to an
	ECN-marked packet. Section 5 of RFC 3168 specifies the following:		ECN-marked packet. Section 5 of RFC 3168 specifies the following:
	"Upon the receipt by an ECN-Capable transport of a single CE packet,		"Upon the receipt by an ECN-Capable transport of a single CE packet,
	skipping to change at page 13, line 14		skipping to change at page 13, line 14
	6. Security Considerations		6. Security Considerations
	TCP packets carrying the ECT codepoint in IP headers can be marked		TCP packets carrying the ECT codepoint in IP headers can be marked
	rather than dropped by ECN-capable routers. This raises several		rather than dropped by ECN-capable routers. This raises several
	security concerns that we discuss below.		security concerns that we discuss below.
	"Bad" middleboxes:		"Bad" middleboxes:
	There is a small but decreasing number of middleboxes that drop or		There is a small but decreasing number of middleboxes that drop or
	reset SYN and SYN/ACK packets based on the ECN-related flags in the		reset SYN and SYN/ACK packets based on the ECN-related flags in the
	TCP header [MAF05,RFC3360]. While there is no evidence that any		TCP header [MAF05], [RFC3360]. While there is no evidence that any
	middleboxes drop SYN/ACK packets that contain an ECN-Capable		middleboxes drop SYN/ACK packets that contain an ECN-Capable
	codepoint in the *IP header*, such behavior cannot be excluded.		codepoint in the *IP header*, such behavior cannot be excluded.
	Thus, as specified in Section 2, if a SYN/ACK packet with the ECT		Thus, as specified in Section 2, if a SYN/ACK packet with the ECT
	codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet		codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet
	without the ECN-Capable codepoint.		without the ECN-Capable codepoint.
	Congestion collapse:		Congestion collapse:
	Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-		Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-
	marked instead of dropped at an ECN-capable router, the concern is		marked instead of dropped at an ECN-capable router, the concern is
	whether this can either invoke congestion, or worsen performance in		whether this can either invoke congestion, or worsen performance in
	skipping to change at page 14, line 13		skipping to change at page 14, line 13
	retransmission-based reliability in their setup phase (e.g., SCTP,		retransmission-based reliability in their setup phase (e.g., SCTP,
	DCCP, HIP, and the like).		DCCP, HIP, and the like).
	8. Acknowledgements		8. Acknowledgements
	We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi		We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi
	Sarolahti for feedback on earlier versions of this draft.		Sarolahti for feedback on earlier versions of this draft.
	9. Normative References		9. Normative References
			[RFC 2119] S. Bradner, Key words for use in RFCs to Indicate
			Requirement Levels, RFC 2119, March 1997.
	[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of		[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
	Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed		Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
	Standard, September 2001.		Standard, September 2001.
	[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's		[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
	Initial Window, RFC 3390, October 2002.		Initial Window, RFC 3390, October 2002.
	10. Informative References		10. Informative References
	[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,		[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
	skipping to change at page 15, line 16		skipping to change at page 15, line 18
	3360, August 2002.		3360, August 2002.
	[SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP}		[SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP}
	Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001.		Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001.
	[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also		[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also
	<http://cr.yp.to/syncookies.html>		<http://cr.yp.to/syncookies.html>
	[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of		[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
	Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-		Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-
	tools-00, work in progress, September 2005.		tools-02, work in progress, June 2006.
	11. IANA Considerations		11. IANA Considerations
	There are no IANA considerations regarding this document.		There are no IANA considerations regarding this document.
	AUTHORS' ADDRESSES		AUTHORS' ADDRESSES
	Aleksandar Kuzmanovic		Aleksandar Kuzmanovic
	Phone: +1 (847) 467-5519		Phone: +1 (847) 467-5519
	Northwestern University		Northwestern University
End of changes. 7 change blocks.
	6 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/