rfc1323.txt

RFC 的详细文档！

Network Working Group                                        V. Jacobson
Request for Comments: 1323                                           LBL
Obsoletes: RFC 1072, RFC 1185                                  R. Braden
                                                                     ISI
                                                               D. Borman
                                                           Cray Research
                                                                May 1992


                  TCP Extensions for High Performance

Status of This Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo presents a set of TCP extensions to improve performance
   over large bandwidth*delay product paths and to provide reliable
   operation over very high-speed paths.  It defines new TCP options for
   scaled windows and timestamps, which are designed to provide
   compatible interworking with TCP's that do not implement the
   extensions.  The timestamps are used for two distinct mechanisms:
   RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
   Sequences).  Selective acknowledgments are not included in this memo.

   This memo combines and supersedes RFC-1072 and RFC-1185, adding
   additional clarification and more detailed specification.  Appendix C
   summarizes the changes from the earlier RFCs.

TABLE OF CONTENTS

   1.  Introduction .................................................  2
   2.  TCP Window Scale Option ......................................  8
   3.  RTTM -- Round-Trip Time Measurement .......................... 11
   4.  PAWS -- Protect Against Wrapped Sequence Numbers ............. 17
   5.  Conclusions and Acknowledgments .............................. 25
   6.  References ................................................... 25
   APPENDIX A: Implementation Suggestions ........................... 27
   APPENDIX B: Duplicates from Earlier Connection Incarnations ...... 27
   APPENDIX C: Changes from RFC-1072, RFC-1185 ...................... 30
   APPENDIX D: Summary of Notation .................................. 31
   APPENDIX E: Event Processing ..................................... 32
   Security Considerations .......................................... 37



Jacobson, Braden, & Borman                                      [Page 1]

RFC 1323          TCP Extensions for High Performance           May 1992


   Authors' Addresses ............................................... 37

1. INTRODUCTION

   The TCP protocol [Postel81] was designed to operate reliably over
   almost any transmission medium regardless of transmission rate,
   delay, corruption, duplication, or reordering of segments.
   Production TCP implementations currently adapt to transfer rates in
   the range of 100 bps to 10**7 bps and round-trip delays in the range
   1 ms to 100 seconds.  Recent work on TCP performance has shown that
   TCP can work well over a variety of Internet paths, ranging from 800
   Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a].

   The introduction of fiber optics is resulting in ever-higher
   transmission speeds, and the fastest paths are moving out of the
   domain for which TCP was originally engineered.  This memo defines a
   set of modest extensions to TCP to extend the domain of its
   application to match this increasing network capability.  It is based
   upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].

   There is no one-line answer to the question: "How fast can TCP go?".
   There are two separate kinds of issues, performance and reliability,
   and each depends upon different parameters.  We discuss each in turn.

   1.1  TCP Performance

      TCP performance depends not upon the transfer rate itself, but
      rather upon the product of the transfer rate and the round-trip
      delay.  This "bandwidth*delay product" measures the amount of data
      that would "fill the pipe"; it is the buffer space required at
      sender and receiver to obtain maximum throughput on the TCP
      connection over the path, i.e., the amount of unacknowledged data
      that TCP must handle in order to keep the pipeline full.  TCP
      performance problems arise when the bandwidth*delay product is
      large.  We refer to an Internet path operating in this region as a
      "long, fat pipe", and a network containing this path as an "LFN"
      (pronounced "elephan(t)").

      High-capacity packet satellite channels (e.g., DARPA's Wideband
      Net) are LFN's.  For example, a DS1-speed satellite channel has a
      bandwidth*delay product of 10**6 bits or more; this corresponds to
      100 outstanding TCP segments of 1200 bytes each.  Terrestrial
      fiber-optical paths will also fall into the LFN class; for
      example, a cross-country delay of 30 ms at a DS3 bandwidth
      (45Mbps) also exceeds 10**6 bits.

      There are three fundamental performance problems with the current
      TCP over LFN paths:



Jacobson, Braden, & Borman                                      [Page 2]

RFC 1323          TCP Extensions for High Performance           May 1992


      (1)  Window Size Limit

           The TCP header uses a 16 bit field to report the receive
           window size to the sender.  Therefore, the largest window
           that can be used is 2**16 = 65K bytes.

           To circumvent this problem, Section 2 of this memo defines a
           new TCP option, "Window Scale", to allow windows larger than
           2**16.  This option defines an implicit scale factor, which
           is used to multiply the window size value found in a TCP
           header to obtain the true window size.

      (2)  Recovery from Losses

           Packet losses in an LFN can have a catastrophic effect on
           throughput.  Until recently, properly-operating TCP
           implementations would cause the data pipeline to drain with
           every packet loss, and require a slow-start action to
           recover.  Recently, the Fast Retransmit and Fast Recovery
           algorithms [Jacobson90c] have been introduced.  Their
           combined effect is to recover from one packet loss per
           window, without draining the pipeline.  However, more than
           one packet loss per window typically results in a
           retransmission timeout and the resulting pipeline drain and
           slow start.

           Expanding the window size to match the capacity of an LFN
           results in a corresponding increase of the probability of
           more than one packet per window being dropped.  This could
           have a devastating effect upon the throughput of TCP over an
           LFN.  In addition, if a congestion control mechanism based
           upon some form of random dropping were introduced into
           gateways, randomly spaced packet drops would become common,
           possible increasing the probability of dropping more than one
           packet per window.

           To generalize the Fast Retransmit/Fast Recovery mechanism to
           handle multiple packets dropped per window, selective
           acknowledgments are required.  Unlike the normal cumulative
           acknowledgments of TCP, selective acknowledgments give the
           sender a complete picture of which segments are queued at the
           receiver and which have not yet arrived.  Some evidence in
           favor of selective acknowledgments has been published
           [NBS85], and selective acknowledgments have been included in
           a number of experimental Internet protocols -- VMTP
           [Cheriton88], NETBLT [Clark87], and RDP [Velten84], and
           proposed for OSI TP4 [NBS85].  However, in the non-LFN
           regime, selective acknowledgments reduce the number of



Jacobson, Braden, & Borman                                      [Page 3]

RFC 1323          TCP Extensions for High Performance           May 1992


           packets retransmitted but do not otherwise improve
           performance, making their complexity of questionable value.
           However, selective acknowledgments are expected to become
           much more important in the LFN regime.

           RFC-1072 defined a new TCP "SACK" option to send a selective
           acknowledgment.  However, there are important technical
           issues to be worked out concerning both the format and
           semantics of the SACK option.  Therefore, SACK has been
           omitted from this package of extensions.  It is hoped that
           SACK can "catch up" during the standardization process.

      (3)  Round-Trip Measurement

           TCP implements reliable data delivery by retransmitting
           segments that are not acknowledged within some retransmission
           timeout (RTO) interval.  Accurate dynamic determination of an
           appropriate RTO is essential to TCP performance.  RTO is
           determined by estimating the mean and variance of the
           measured round-trip time (RTT), i.e., the time interval
           between sending a segment and receiving an acknowledgment for
           it [Jacobson88a].

           Section 4 introduces a new TCP option, "Timestamps", and then
           defines a mechanism using this option that allows nearly
           every segment, including retransmissions, to be timed at
           negligible computational cost.  We use the mnemonic RTTM
           (Round Trip Time Measurement) for this mechanism, to
           distinguish it from other uses of the Timestamps option.


   1.2 TCP Reliability

      Now we turn from performance to reliability.  High transfer rate
      enters TCP performance through the bandwidth*delay product.
      However, high transfer rate alone can threaten TCP reliability by
      violating the assumptions behind the TCP mechanism for duplicate
      detection and sequencing.

      An especially serious kind of error may result from an accidental
      reuse of TCP sequence numbers in data segments.  Suppose that an
      "old duplicate segment", e.g., a duplicate data segment that was
      delayed in Internet queues, is delivered to the receiver at the
      wrong moment, so that its sequence numbers falls somewhere within
      the current window.  There would be no checksum failure to warn of
      the error, and the result could be an undetected corruption of the
      data.  Reception of an old duplicate ACK segment at the
      transmitter could be only slightly less serious: it is likely to



Jacobson, Braden, & Borman                                      [Page 4]

RFC 1323          TCP Extensions for High Performance           May 1992


      lock up the connection so that no further progress can be made,
      forcing an RST on the connection.

      TCP reliability depends upon the existence of a bound on the
      lifetime of a segment: the "Maximum Segment Lifetime" or MSL.  An
      MSL is generally required by any reliable transport protocol,
      since every sequence number field must be finite, and therefore
      any sequence number may eventually be reused.  In the Internet
      protocol suite, the MSL bound is enforced by an IP-layer
      mechanism, the "Time-to-Live" or TTL field.

      Duplication of sequence numbers might happen in either of two
      ways:

      (1)  Sequence number wrap-around on the current connection

           A TCP sequence number contains 32 bits.  At a high enough
           transfer rate, the 32-bit sequence space may be "wrapped"
           (cycled) within the time that a segment is delayed in queues.

      (2)  Earlier incarnation of the connection

           Suppose that a connection terminates, either by a proper
           close sequence or due to a host crash, and the same
           connection (i.e., using the same pair of sockets) is
           immediately reopened.  A delayed segment from the terminated
           connection could fall within the current window for the new
           incarnation and be accepted as valid.

      Duplicates from earlier incarnations, Case (2), are avoided by
      enforcing the current fixed MSL of the TCP spec, as explained in
      Section 5.3 and Appendix B.   However, case (1), avoiding the
      reuse of sequence numbers within the same connection, requires an
      MSL bound that depends upon the transfer rate, and at high enough
      rates, a new mechanism is required.

      More specifically, if the maximum effective bandwidth at which TCP
      is able to transmit over a particular path is B bytes per second,
      then the following constraint must be satisfied for error-free
      operation:

          2**31 / B  > MSL (secs)                     [1]

      The following table shows the value for Twrap = 2**31/B in
      seconds, for some important values of the bandwidth B:






Jacobson, Braden, & Borman                                      [Page 5]

RFC 1323          TCP Extensions for High Performance           May 1992