rfc2414.txt

RFC 的详细文档！

   [Nic97]     Kathleen Nichols.  Improving Network Simulation with
               Feedback.  Com21, Inc. Technical Report.  Available from
               http://www.com21.com/pages/papers/068.pdf.

   [PN98]      Poduri, K., and K. Nichols, "Simulation Studies of
               Increased Initial TCP Window Size", RFC 2415, September
               1998.

   [Pos82]     Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
               821, August 1982.

   [RF97]      Ramakrishnan, K., and S. Floyd, "A Proposal to Add
               Explicit Congestion Notification (ECN) to IPv6 and to
               TCP", Work in Progress.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2309]   Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
               S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
               Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
               S., Wroclawski, J., and L.  Zhang, "Recommendations on
               Queue Management and Congestion Avoidance in the
               Internet", RFC 2309, April 1998.

   [S97]       Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
               Retransmit, and Fast Recovery Algorithms", RFC 2001,
               January 1997.

   [SP97]      Shepard, T., and C. Partridge, "When TCP Starts Up With
               Four Packets Into Only Three Buffers", RFC 2416,
               September 1998.



Allman, et. al.               Experimental                     [Page 10]

RFC 2414            Increasing TCP's Initial Window       September 1998


12.  Author's Addresses

   Mark Allman
   NASA Lewis Research Center/Sterling Software
   21000 Brookpark Road
   MS 54-2
   Cleveland, OH 44135

   EMail: [e-mail]
   http://gigahertz.lerc.nasa.gov/~mallman/


   Sally Floyd
   Lawrence Berkeley National Laboratory
   One Cyclotron Road
   Berkeley, CA 94720

   EMail: [e-mail]


   Craig Partridge
   BBN Technologies
   10 Moulton Street
   Cambridge, MA 02138

   EMail: [e-mail]

























Allman, et. al.               Experimental                     [Page 11]

RFC 2414            Increasing TCP's Initial Window       September 1998


13.  Appendix - Duplicate Segments

   In the current environment (without Explicit Congestion Notification
   [Flo94] [RF97]), all TCPs use segment drops as indications from the
   network about the limits of available bandwidth.  We argue here that
   the change to a larger initial window should not result in the sender
   retransmitting a large number of duplicate segments that have already
   been received at the receiver.

   If one segment is dropped from the initial window, there are three
   different ways for TCP to recover: (1) Slow-starting from a window of
   one segment, as is done after a retransmit timeout, or after Fast
   Retransmit in Tahoe TCP; (2) Fast Recovery without selective
   acknowledgments (SACK), as is done after three duplicate ACKs in Reno
   TCP; and (3) Fast Recovery with SACK, for TCP where both the sender
   and the receiver support the SACK option [MMFR96].  In all three
   cases, if a single segment is dropped from the initial window, no
   duplicate segments (i.e., segments that have already been received at
   the receiver) are transmitted.  Note that for a TCP sending four
   512-byte segments in the initial window, a single segment drop will
   not require a retransmit timeout, but can be recovered from using the
   Fast Retransmit algorithm (unless the retransmit timer expires
   prematurely).  In addition, a single segment dropped from an initial
   window of three segments might be repaired using the fast retransmit
   algorithm, depending on which segment is dropped and whether or not
   delayed ACKs are used.  For example, dropping the first segment of a
   three segment initial window will always require waiting for a
   timeout.  However, dropping the third segment will always allow
   recovery via the fast retransmit algorithm, as long as no ACKs are
   lost.

   Next we consider scenarios where the initial window contains two to
   four segments, and at least two of those segments are dropped.  If
   all segments in the initial window are dropped, then clearly no
   duplicate segments are retransmitted, as the receiver has not yet
   received any segments.  (It is still a possibility that these dropped
   segments used scarce bandwidth on the way to their drop point; this
   issue was discussed in Section 5.)

   When two segments are dropped from an initial window of three
   segments, the sender will only send a duplicate segment if the first
   two of the three segments were dropped, and the sender does not
   receive a packet with the SACK option acknowledging the third
   segment.

   When two segments are dropped from an initial window of four
   segments, an examination of the six possible scenarios (which we
   don't go through here) shows that, depending on the position of the



Allman, et. al.               Experimental                     [Page 12]

RFC 2414            Increasing TCP's Initial Window       September 1998


   dropped packets, in the absence of SACK the sender might send one
   duplicate segment.  There are no scenarios in which the sender sends
   two duplicate segments.

   When three segments are dropped from an initial window of four
   segments, then, in the absence of SACK, it is possible that one
   duplicate segment will be sent, depending on the position of the
   dropped segments.

   The summary is that in the absence of SACK, there are some scenarios
   with multiple segment drops from the initial window where one
   duplicate segment will be transmitted.  There are no scenarios where
   more that one duplicate segment will be transmitted.  Our conclusion
   is that the number of duplicate segments transmitted as a result of a
   larger initial window should be small.




































Allman, et. al.               Experimental                     [Page 13]

RFC 2414            Increasing TCP's Initial Window       September 1998


14.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Allman, et. al.               Experimental                     [Page 14]