< draft-ietf-tcpimpl-cong-control-04.txt		draft-ietf-tcpimpl-cong-control-05.txt >
	TCP Implementation Working Group M. Allman		TCP Implementation Working Group M. Allman
	INTERNET DRAFT NASA Lewis/Sterling Software		INTERNET DRAFT NASA Lewis/Sterling Software
	File: draft-ietf-tcpimpl-cong-control-04.txt V. Paxson		File: draft-ietf-tcpimpl-cong-control-05.txt V. Paxson
	LBNL		LBNL
	W. Stevens		W. Stevens
	Consultant		Consultant
	February, 1999		February, 1999
	TCP Congestion Control		TCP Congestion Control
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	rather than FlightSize, which in some implementations may		rather than FlightSize, which in some implementations may
	incidentally increase well beyond rwnd.		incidentally increase well beyond rwnd.
	Furthermore, upon a timeout cwnd MUST be set to no more than the		Furthermore, upon a timeout cwnd MUST be set to no more than the
	loss window, LW, which equals 1 full-sized segment (regardless of		loss window, LW, which equals 1 full-sized segment (regardless of
	the value of IW). Therefore, after retransmitting the dropped		the value of IW). Therefore, after retransmitting the dropped
	segment the TCP sender uses the slow start algorithm to increase the		segment the TCP sender uses the slow start algorithm to increase the
	window from 1 full-sized segment to the new value of ssthresh, at		window from 1 full-sized segment to the new value of ssthresh, at
	which point congestion avoidance again takes over.		which point congestion avoidance again takes over.
	3.3 Fast Retransmit/Fast Recovery		3.2 Fast Retransmit/Fast Recovery
	A TCP receiver SHOULD send an immediate duplicate ACK when an		A TCP receiver SHOULD send an immediate duplicate ACK when an
	out-of-order segment arrives. The purpose of this ACK is to inform		out-of-order segment arrives. The purpose of this ACK is to inform
	the sender that a segment was received out-of-order and which		the sender that a segment was received out-of-order and which
	sequence number is expected. From the sender's perspective,		sequence number is expected. From the sender's perspective,
	duplicate ACKs can be caused by a number of network problems.		duplicate ACKs can be caused by a number of network problems.
	First, they can be caused by dropped segments. In this case, all		First, they can be caused by dropped segments. In this case, all
	segments after the dropped segment will trigger duplicate ACKs.		segments after the dropped segment will trigger duplicate ACKs.
	Second, duplicate ACKs can be caused by the re-ordering of data		Second, duplicate ACKs can be caused by the re-ordering of data
	segments by the network (not a rare event along some network paths		segments by the network (not a rare event along some network paths
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	The delayed ACK algorithm specified in [Bra89] SHOULD be used by a		The delayed ACK algorithm specified in [Bra89] SHOULD be used by a
	TCP receiver. When used, a TCP receiver MUST NOT excessively delay		TCP receiver. When used, a TCP receiver MUST NOT excessively delay
	acknowledgments. Specifically, an ACK SHOULD be generated for at		acknowledgments. Specifically, an ACK SHOULD be generated for at
	least every second full-sized segment, and MUST be generated within		least every second full-sized segment, and MUST be generated within
	500 ms of the arrival of the first unacknowledged packet.		500 ms of the arrival of the first unacknowledged packet.
	The requirement that an ACK "SHOULD" be generated for at least every		The requirement that an ACK "SHOULD" be generated for at least every
	second full-sized segment is listed in [Bra89] in one place as a		second full-sized segment is listed in [Bra89] in one place as a
	SHOULD and another as a MUST. Here we unambiguously state it is a		SHOULD and another as a MUST. Here we unambiguously state it is a
	SHOULD. We also emphasize that this is a "strong" SHOULD, meaning		SHOULD. We also emphasize that this is a SHOULD, meaning that an
	that an implementor should indeed only deviate from this requirement		implementor should indeed only deviate from this requirement after
	after careful consideration of the implications. See the discussion		careful consideration of the implications. See the discussion of
	of "Stretch ACK violation" in [PAD+98] and the references therein		"Stretch ACK violation" in [PAD+98] and the references therein for a
	for a discussion of the possible performance problems with		discussion of the possible performance problems with generating ACKs
	generating ACKs less frequently than every second full-sized		less frequently than every second full-sized segment.
	segment.
	In some cases, the sender and receiver may not agree on what		In some cases, the sender and receiver may not agree on what
	constitutes a full-sized segment. An implementation is deemed to		constitutes a full-sized segment. An implementation is deemed to
	comply with this requirement if it sends at least one acknowledgment		comply with this requirement if it sends at least one acknowledgment
	every time it receives 2*RMSS bytes of new data from the sender,		every time it receives 2*RMSS bytes of new data from the sender,
	where RMSS is the Maximum Segment Size specified by the receiver to		where RMSS is the Maximum Segment Size specified by the receiver to
	the sender (or the default value of 536 bytes, per [Bra89], if the		the sender (or the default value of 536 bytes, per [Bra89], if the
	receiver does not specify an MSS option during connection		receiver does not specify an MSS option during connection
	establishment). The sender may be forced to use a segment size less		establishment). The sender may be forced to use a segment size less
	than RMSS due to the maximum transmission unit (MTU), the path MTU		than RMSS due to the maximum transmission unit (MTU), the path MTU
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 29 ¶
	avoidance phase.		avoidance phase.
	The Internet to a considerable degree relies on the correct		The Internet to a considerable degree relies on the correct
	implementation of these algorithms in order to preserve network		implementation of these algorithms in order to preserve network
	stability and avoid congestion collapse. An attacker could cause		stability and avoid congestion collapse. An attacker could cause
	TCP endpoints to respond more aggressively in the face of congestion		TCP endpoints to respond more aggressively in the face of congestion
	by forging excessive duplicate acknowledgments or excessive		by forging excessive duplicate acknowledgments or excessive
	acknowledgments for new data. Conceivably, such an attack could		acknowledgments for new data. Conceivably, such an attack could
	drive a portion of the network into congestion collapse.		drive a portion of the network into congestion collapse.
			6. Changes Relative to RFC 2001
			This document has been extensively rewritten editorially and it is
			not feasible to itemize the list of changes between the two
			documents. The intention of this document is not to change any of
			the recommendations given in RFC 2001, but to further clarify cases
			that were not discussed in detail in 2001. Specifically, this
			document suggests what TCP connections should do after a relatively
			long idle period, as well as specifying and clarifying some of the
			issues pertaining to TCP ACK generation. Finally, the allowable
			upper bound for the initial congestion window has also been raised
			from one to two segments.
	Acknowledgments		Acknowledgments
	The four algorithms that are described were developed by Van		The four algorithms that are described were developed by Van
	Jacobson.		Jacobson.
	Some of the text from this document is taken from "TCP/IP		Some of the text from this document is taken from "TCP/IP
	Illustrated, Volume 1: The Protocols" by W. Richard Stevens		Illustrated, Volume 1: The Protocols" by W. Richard Stevens
	(Addison-Wesley, 1994) and "TCP/IP Illustrated, Volume 2: The		(Addison-Wesley, 1994) and "TCP/IP Illustrated, Volume 2: The
	Implementation" by Gary R. Wright and W. Richard Stevens		Implementation" by Gary R. Wright and W. Richard Stevens
	(Addison-Wesley, 1995). This material is used with the permission		(Addison-Wesley, 1995). This material is used with the permission
	skipping to change at page 9, line 56 ¶		skipping to change at page 10, line 16 ¶
	[AFP98] M. Allman, S. Floyd, C. Partridge, Increasing TCP's Initial		[AFP98] M. Allman, S. Floyd, C. Partridge, Increasing TCP's Initial
	Window Size, September 1998. RFC 2414.		Window Size, September 1998. RFC 2414.
	[Bra89] B. Braden, ed., Requirements for Internet Hosts --		[Bra89] B. Braden, ed., Requirements for Internet Hosts --
	Communication Layers, RFC 1122, Oct. 1989.		Communication Layers, RFC 1122, Oct. 1989.
	[Bra97] S. Bradner, Key words for use in RFCs to Indicate		[Bra97] S. Bradner, Key words for use in RFCs to Indicate
	Requirement Levels, BCP 14, RFC 2119, March 1997.		Requirement Levels, BCP 14, RFC 2119, March 1997.
	[Cla82] D. Clark, Window and Acknowledgement Strategy in TCP, RFC		[Cla82] D. Clark, Window and Acknowledgment Strategy in TCP, RFC
	813. July 1982.		813. July 1982.
	[FF96] K. Fall, S. Floyd. Simulation-based Comparisons of Tahoe,		[FF96] K. Fall, S. Floyd. Simulation-based Comparisons of Tahoe,
	Reno and SACK TCP. Computer Communication Review, July 1996.		Reno and SACK TCP. Computer Communication Review, July 1996.
	ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.		ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
	[FH98] S. Floyd, T. Henderson. The NewReno Modification to TCP's		[FH98] S. Floyd, T. Henderson. The NewReno Modification to TCP's
	Fast Recovery Algorithm. Internet-Draft		Fast Recovery Algorithm. Internet-Draft
	draft-ietf-tcpimpl-newreno-00.txt, November 1998. (Work in		draft-ietf-tcpimpl-newreno-00.txt, November 1998. (Work in
	progress).		progress).
End of changes. 5 change blocks.
	10 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/