draft-ietf-tcpimpl-cong-control-03.txt   draft-ietf-tcpimpl-cong-control-04.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-03.txt V. Paxson File: draft-ietf-tcpimpl-cong-control-04.txt V. Paxson
LBNL LBNL
W. Stevens W. Stevens
Consultant Consultant
December, 1998 February, 1999
TCP Congestion Control TCP Congestion Control
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026. Internet-Draft.
and its working groups. Note that other groups may also distribute Internet-Drafts are working documents of the Internet Engineering
working documents as Internet-Drafts. Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in reference material or to cite them other than as ``work in
progress.'' progress.''
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
skipping to change at page 8, line 30 skipping to change at page 8, line 32
Out-of-order data segments SHOULD be acknowledged immediately, in Out-of-order data segments SHOULD be acknowledged immediately, in
order to accelerate loss recovery. To trigger the fast retransmit order to accelerate loss recovery. To trigger the fast retransmit
algorithm, the receiver SHOULD send an immediate duplicate ACK when algorithm, the receiver SHOULD send an immediate duplicate ACK when
it receives a data segment above a gap in the sequence space. To it receives a data segment above a gap in the sequence space. To
provide feedback to senders recovering from losses, the receiver provide feedback to senders recovering from losses, the receiver
SHOULD send an immediate ACK when it receives a data segment that SHOULD send an immediate ACK when it receives a data segment that
fills in all or part of a gap in the sequence space. fills in all or part of a gap in the sequence space.
A TCP receiver MUST NOT generate more than one ACK for every A TCP receiver MUST NOT generate more than one ACK for every
incoming segment, other than to update the offered window as the incoming segment, other than to update the offered window as the
receiving application consumes new data. receiving application consumes new data [page 42, Pos81][Cla82].
4.4 Loss Recovery Mechanisms 4.3 Loss Recovery Mechanisms
A number of loss recovery algorithms that augment fast retransmit A number of loss recovery algorithms that augment fast retransmit
and fast recovery have been suggested by TCP researchers. While and fast recovery have been suggested by TCP researchers. While
some of these algorithms are based on the TCP selective some of these algorithms are based on the TCP selective
acknowledgment (SACK) option [MMFR96], such as [FF96,MM96a,MM96b], acknowledgment (SACK) option [MMFR96], such as [FF96,MM96a,MM96b],
others do not require SACKs [Hoe96,FF96,FH98]. The non-SACK others do not require SACKs [Hoe96,FF96,FH98]. The non-SACK
algorithms use "partial acknowledgments" (ACKs which cover new data, algorithms use "partial acknowledgments" (ACKs which cover new data,
but not all the data outstanding when loss was detected) to trigger but not all the data outstanding when loss was detected) to trigger
retransmissions. While this document does not standardize any of retransmissions. While this document does not standardize any of
the specific algorithms that may improve fast retransmit/fast the specific algorithms that may improve fast retransmit/fast
skipping to change at page 9, line 54 skipping to change at page 9, line 56
[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
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).
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical [Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical
skipping to change at page 11, line 21 skipping to change at page 11, line 26
The Implementation, Addison-Wesley, 1995. The Implementation, Addison-Wesley, 1995.
Author's Address: Author's Address:
Mark Allman Mark Allman
NASA Lewis Research Center/Sterling Software NASA Lewis Research Center/Sterling Software
21000 Brookpark Rd. MS 54-2 21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135 Cleveland, OH 44135
216-433-6586 216-433-6586
mallman@lerc.nasa.gov mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman http://roland.lerc.nasa.gov/~mallman
Vern Paxson Vern Paxson
Network Research Group Network Research Group
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
Berkeley, CA 94720 Berkeley, CA 94720
USA USA
510-486-7504 510-486-7504
vern@ee.lbl.gov vern@ee.lbl.gov
W. Richard Stevens W. Richard Stevens
 End of changes. 8 change blocks. 
10 lines changed or deleted 14 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/