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.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/