rfc2525.txt

RFC 的详细文档！

Network Working Group                                          V. Paxson
Request for Comments: 2525                                        Editor
Category: Informational                                     ACIRI / ICSI
                                                               M. Allman
                            NASA Glenn Research Center/Sterling Software
                                                               S. Dawson
                                          Real-Time Computing Laboratory
                                                               W. Fenner
                                                              Xerox PARC
                                                               J. Griner
                                              NASA Glenn Research Center
                                                              I. Heavens
                                                    Spider Software Ltd.
                                                                K. Lahey
                                           NASA Ames Research Center/MRJ
                                                                J. Semke
                                        Pittsburgh Supercomputing Center
                                                                 B. Volz
                                            Process Software Corporation
                                                              March 1999


                   Known TCP Implementation Problems

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Table of Contents

   1.  INTRODUCTION....................................................2
   2.  KNOWN IMPLEMENTATION PROBLEMS...................................3
     2.1  No initial slow start........................................3
     2.2  No slow start after retransmission timeout...................6
     2.3  Uninitialized CWND...........................................9
     2.4  Inconsistent retransmission.................................11
     2.5  Failure to retain above-sequence data.......................13
     2.6  Extra additive constant in congestion avoidance.............17
     2.7  Initial RTO too low.........................................23
     2.8  Failure of window deflation after loss recovery.............26
     2.9  Excessively short keepalive connection timeout..............28
     2.10 Failure to back off retransmission timeout..................31



Paxson, et. al.              Informational                      [Page 1]

RFC 2525              TCP Implementation Problems             March 1999


     2.11 Insufficient interval between keepalives....................34
     2.12 Window probe deadlock.......................................36
     2.13 Stretch ACK violation.......................................40
     2.14 Retransmission sends multiple packets.......................43
     2.15 Failure to send FIN notification promptly...................45
     2.16 Failure to send a RST after Half Duplex Close...............47
     2.17 Failure to RST on close with data pending...................50
     2.18 Options missing from TCP MSS calculation....................54
   3.  SECURITY CONSIDERATIONS........................................56
   4.  ACKNOWLEDGEMENTS...............................................56
   5.  REFERENCES.....................................................57
   6.  AUTHORS' ADDRESSES.............................................58
   7.  FULL COPYRIGHT STATEMENT.......................................60

1. Introduction

   This memo catalogs a number of known TCP implementation problems.
   The goal in doing so is to improve conditions in the existing
   Internet by enhancing the quality of current TCP/IP implementations.
   It is hoped that both performance and correctness issues can be
   resolved by making implementors aware of the problems and their
   solutions.  In the long term, it is hoped that this will provide a
   reduction in unnecessary traffic on the network, the rate of
   connection failures due to protocol errors, and load on network
   servers due to time spent processing both unsuccessful connections
   and retransmitted data.  This will help to ensure the stability of
   the global Internet.

   Each problem is defined as follows:

   Name of Problem
      The name associated with the problem.  In this memo, the name is
      given as a subsection heading.

   Classification
      One or more problem categories for which the problem is
      classified:  "congestion control", "performance", "reliability",
      "resource management".

   Description
      A definition of the problem, succinct but including necessary
      background material.

   Significance
      A brief summary of the sorts of environments for which the problem
      is significant.





Paxson, et. al.              Informational                      [Page 2]

RFC 2525              TCP Implementation Problems             March 1999


   Implications
      Why the problem is viewed as a problem.

   Relevant RFCs
      The RFCs defining the TCP specification with which the problem
      conflicts.  These RFCs often qualify behavior using terms such as
      MUST, SHOULD, MAY, and others written capitalized.  See RFC 2119
      for the exact interpretation of these terms.

   Trace file demonstrating the problem
      One or more ASCII trace files demonstrating the problem, if
      applicable.

   Trace file demonstrating correct behavior
      One or more examples of how correct behavior appears in a trace,
      if applicable.

   References
      References that further discuss the problem.

   How to detect
      How to test an implementation to see if it exhibits the problem.
      This discussion may include difficulties and subtleties associated
      with causing the problem to manifest itself, and with interpreting
      traces to detect the presence of the problem (if applicable).

   How to fix
      For known causes of the problem, how to correct the
      implementation.

2. Known implementation problems

2.1.

   Name of Problem
      No initial slow start

   Classification
      Congestion control

   Description
      When a TCP begins transmitting data, it is required by RFC 1122,
      4.2.2.15, to engage in a "slow start" by initializing its
      congestion window, cwnd, to one packet (one segment of the maximum
      size).  (Note that an experimental change to TCP, documented in
      [RFC2414], allows an initial value somewhat larger than one
      packet.)  It subsequently increases cwnd by one packet for each
      ACK it receives for new data.  The minimum of cwnd and the



Paxson, et. al.              Informational                      [Page 3]

RFC 2525              TCP Implementation Problems             March 1999


      receiver's advertised window bounds the highest sequence number
      the TCP can transmit.  A TCP that fails to initialize and
      increment cwnd in this fashion exhibits "No initial slow start".

   Significance
      In congested environments, detrimental to the performance of other
      connections, and possibly to the connection itself.

   Implications
      A TCP failing to slow start when beginning a connection results in
      traffic bursts that can stress the network, leading to excessive
      queueing delays and packet loss.

      Implementations exhibiting this problem might do so because they
      suffer from the general problem of not including the required
      congestion window.  These implementations will also suffer from
      "No slow start after retransmission timeout".

      There are different shades of "No initial slow start".  From the
      perspective of stressing the network, the worst is a connection
      that simply always sends based on the receiver's advertised
      window, with no notion of a separate congestion window.  Another
      form is described in "Uninitialized CWND" below.

   Relevant RFCs
      RFC 1122 requires use of slow start.  RFC 2001 gives the specifics
      of slow start.

   Trace file demonstrating it
      Made using tcpdump [Jacobson89] recording at the connection
      responder.  No losses reported by the packet filter.

   10:40:42.244503 B > A: S 1168512000:1168512000(0) win 32768
                           <mss 1460,nop,wscale 0> (DF) [tos 0x8]
   10:40:42.259908 A > B: S 3688169472:3688169472(0)
                           ack 1168512001 win 32768 <mss 1460>
   10:40:42.389992 B > A: . ack 1 win 33580 (DF) [tos 0x8]
   10:40:42.664975 A > B: P 1:513(512) ack 1 win 32768
   10:40:42.700185 A > B: . 513:1973(1460) ack 1 win 32768
   10:40:42.718017 A > B: . 1973:3433(1460) ack 1 win 32768
   10:40:42.762945 A > B: . 3433:4893(1460) ack 1 win 32768
   10:40:42.811273 A > B: . 4893:6353(1460) ack 1 win 32768
   10:40:42.829149 A > B: . 6353:7813(1460) ack 1 win 32768
   10:40:42.853687 B > A: . ack 1973 win 33580 (DF) [tos 0x8]
   10:40:42.864031 B > A: . ack 3433 win 33580 (DF) [tos 0x8]






Paxson, et. al.              Informational                      [Page 4]

RFC 2525              TCP Implementation Problems             March 1999


      After the third packet, the connection is established.  A, the
      connection responder, begins transmitting to B, the connection
      initiator.  Host A quickly sends 6 packets comprising 7812 bytes,
      even though the SYN exchange agreed upon an MSS of 1460 bytes
      (implying an initial congestion window of 1 segment corresponds to
      1460 bytes), and so A should have sent at most 1460 bytes.

      The ACKs sent by B to A in the last two lines indicate that this
      trace is not a measurement error (slow start really occurring but
      the corresponding ACKs having been dropped by the packet filter).

      A second trace confirmed that the problem is repeatable.

   Trace file demonstrating correct behavior
      Made using tcpdump recording at the connection originator.  No
      losses reported by the packet filter.

   12:35:31.914050 C > D: S 1448571845:1448571845(0)
                            win 4380 <mss 1460>
   12:35:32.068819 D > C: S 1755712000:1755712000(0)
                            ack 1448571846 win 4096
   12:35:32.069341 C > D: . ack 1 win 4608
   12:35:32.075213 C > D: P 1:513(512) ack 1 win 4608
   12:35:32.286073 D > C: . ack 513 win 4096
   12:35:32.287032 C > D: . 513:1025(512) ack 1 win 4608
   12:35:32.287506 C > D: . 1025:1537(512) ack 1 win 4608
   12:35:32.432712 D > C: . ack 1537 win 4096
   12:35:32.433690 C > D: . 1537:2049(512) ack 1 win 4608
   12:35:32.434481 C > D: . 2049:2561(512) ack 1 win 4608
   12:35:32.435032 C > D: . 2561:3073(512) ack 1 win 4608
   12:35:32.594526 D > C: . ack 3073 win 4096
   12:35:32.595465 C > D: . 3073:3585(512) ack 1 win 4608
   12:35:32.595947 C > D: . 3585:4097(512) ack 1 win 4608
   12:35:32.596414 C > D: . 4097:4609(512) ack 1 win 4608
   12:35:32.596888 C > D: . 4609:5121(512) ack 1 win 4608
   12:35:32.733453 D > C: . ack 4097 win 4096

   References
      This problem is documented in [Paxson97].

   How to detect
      For implementations always manifesting this problem, it shows up
      immediately in a packet trace or a sequence plot, as illustrated
      above.







Paxson, et. al.              Informational                      [Page 5]

RFC 2525              TCP Implementation Problems             March 1999


   How to fix
      If the root problem is that the implementation lacks a notion of a
      congestion window, then unfortunately this requires significant
      work to fix.  However, doing so is important, as such
      implementations also exhibit "No slow start after retransmission
      timeout".

2.2.

   Name of Problem
      No slow start after retransmission timeout

   Classification
      Congestion control

   Description
      When a TCP experiences a retransmission timeout, it is required by
      RFC 1122, 4.2.2.15, to engage in "slow start" by initializing its
      congestion window, cwnd, to one packet (one segment of the maximum
      size).  It subsequently increases cwnd by one packet for each ACK
      it receives for new data until it reaches the "congestion