draft-ietf-tsvwg-initwin-02.txt   draft-ietf-tsvwg-initwin-03.txt 
Internet Engineering Task Force Mark Allman Internet Engineering Task Force Mark Allman
INTERNET DRAFT BBN/NASA GRC INTERNET DRAFT BBN/NASA GRC
File: draft-ietf-tsvwg-initwin-02.txt March, 2002 File: draft-ietf-tsvwg-initwin-03.txt April, 2002
Expires: September, 2002 Expires: October, 2002
Sally Floyd Sally Floyd
ICIR ICIR
Craig Partridge Craig Partridge
BBN Technologies BBN Technologies
Increasing TCP's Initial Window Increasing TCP's Initial Window
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 1, line 36 skipping to change at page 1, line 37
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies an increase in the permitted initial window This document specifies an optional standard for TCP to increase the
for TCP from one segment to roughly 4K bytes. This document also permitted initial window from one segment to roughly 4K bytes,
discusses the advantages and disadvantages of the change, outlining replacing RFC 2414. This document discusses the advantages and
experimental results that indicate the costs and benefits. disadvantages of the higher initial window. The document includes
discussion of experiments and simulations showing that the higher
initial window does not lead to congestion collapse. Finally, the
document provides guidance on implementation issues.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. TCP Modification 1. TCP Modification
This document specifies an increase in the permitted upper bound for This document updates [RFC2414] and specifies an increase in the
TCP's initial window from one segment to between two and four permitted upper bound for TCP's initial window from one segment to
segments. In most cases, this change results in an upper bound on between two and four segments. In most cases, this change results
the initial window of roughly 4K bytes (although given a large in an upper bound on the initial window of roughly 4K bytes
segment size, the permitted initial window of two segments may be (although given a large segment size, the permitted initial window
significantly larger than 4K bytes). The upper bound for the of two segments may be significantly larger than 4K bytes). The
initial window is given more precisely in (1): upper bound for the initial window is given more precisely in (1):
min (4*MSS, max (2*MSS, 4380 bytes)) (1) min (4*MSS, max (2*MSS, 4380 bytes)) (1)
Equivalently, the upper bound for the initial window size is based Equivalently, the upper bound for the initial window size is based
on the maximum segment size (MSS), as follows: on the maximum segment size (MSS), as follows:
If (MSS <= 1095 bytes) If (MSS <= 1095 bytes)
then win <= 4 * MSS; then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes) If (1095 bytes < MSS < 2190 bytes)
then win <= 4380; then win <= 4380;
skipping to change at page 10, line 38 skipping to change at page 10, line 40
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
Wroclawski, J., and L. Zhang, "Recommendations on Queue Wroclawski, J., and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC 2309, Management and Congestion Avoidance in the Internet", RFC 2309,
April 1998. April 1998.
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998.
[RFC2415] Poduri, K., and K. Nichols, "Simulation Studies of [RFC2415] Poduri, K., and K. Nichols, "Simulation Studies of
Increased Initial TCP Window Size", RFC 2415, September 1998. Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2416] Shepard, T., and C. Partridge, "When TCP Starts Up With [RFC2416] Shepard, T., and C. Partridge, "When TCP Starts Up With
Four Packets Into Only Three Buffers", RFC 2416, September 1998. Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens. TCP [RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens. TCP
Congestion Control, April 1999. RFC 2581. Congestion Control, April 1999. RFC 2581.
[RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission
skipping to change at page 11, line 27 skipping to change at page 11, line 34
EMail: floyd@icir.org EMail: floyd@icir.org
http://www.icir.org/floyd/ http://www.icir.org/floyd/
Craig Partridge Craig Partridge
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
EMail: craig@bbn.com EMail: craig@bbn.com
13. Appendix - Duplicate Segments 14. Appendix - Duplicate Segments
In the current environment (without Explicit Congestion Notification In the current environment (without Explicit Congestion Notification
[Flo94] [RFC2481]), all TCPs use segment drops as indications from [Flo94] [RFC2481]), all TCPs use segment drops as indications from
the network about the limits of available bandwidth. We argue here the network about the limits of available bandwidth. We argue here
that the change to a larger initial window should not result in the that the change to a larger initial window should not result in the
sender retransmitting a large number of duplicate segments that have sender retransmitting a large number of duplicate segments that have
already arrived at the receiver. already arrived at the receiver.
If one segment is dropped from the initial window, there are three If one segment is dropped from the initial window, there are three
different ways for TCP to recover: (1) Slow-starting from a window different ways for TCP to recover: (1) Slow-starting from a window
skipping to change at line 627 skipping to change at page 12, line 43
segments, then, in the absence of SACK, it is possible that one segments, then, in the absence of SACK, it is possible that one
duplicate segment will be sent, depending on the position of the duplicate segment will be sent, depending on the position of the
dropped segments. dropped segments.
The summary is that in the absence of SACK, there are some scenarios The summary is that in the absence of SACK, there are some scenarios
with multiple segment drops from the initial window where one with multiple segment drops from the initial window where one
duplicate segment will be transmitted. There are no scenarios where duplicate segment will be transmitted. There are no scenarios where
more that one duplicate segment will be transmitted. Our conclusion more that one duplicate segment will be transmitted. Our conclusion
is that the number of duplicate segments transmitted as a result of is that the number of duplicate segments transmitted as a result of
a larger initial window should be small. a larger initial window should be small.
15. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/