RFC 1185 (rfc1185) - Page 2 of 21

TCP Extension for High-Speed Paths

RFC 1185               TCP over High-Speed Paths            October 1990


   domain of its application to higher speeds.

   There is no one-line answer to the question: "How fast can TCP go?".
   The issues are reliability and performance, and these depend upon the
   round-trip delay and the maximum time that segments may be queued in
   the Internet, as well as upon the transmission speed.  We must think
   through these relationships very carefully if we are to successfully
   extend TCP's domain.

   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.  RFC-1072 proposed a set of TCP extensions to improve TCP
   efficiency for "LFNs" (long fat networks), i.e., networks with large
   bandwidth*delay products.

   On the other hand, high transfer rate can threaten TCP reliability by
   violating the assumptions behind the TCP mechanism for duplicate
   detection and sequencing.  The present memo specifies a solution for
   this problem, extending TCP reliability to transfer rates well beyond
   the foreseeable upper limit of bandwidth.

   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, was delivered to the receiver at the wrong moment
   so that its sequence numbers fell 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 lock up the connection so that
   no further progress can be made and a RST is required to
   resynchronize the two ends.

   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 may be delayed in
        queues.  Section 2 discusses this case and proposes a mechanism
        to reject old duplicates on the current connection.

   (2)  Segment from an earlier connection incarnation




Jacobson, Braden & Zhang