rfc1185.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,179 行 · 第 1/4 页

      TCP's quiet time of one MSL upon system startup handles the loss
      of connection state in a system crash/restart.  For an
      explanation, see for example "When to Keep Quiet" in the TCP
      protocol specification [Postel81].  The MSL that is required here
      does not depend upon the transfer speed.  The current TCP MSL of 2
      minutes seems acceptable as an operational compromise, as many
      host systems take this long to boot after a crash.

      However, the timestamp option may be used to ease the MSL
      requirements (or to provide additional security against data
      corruption).  If timestamps are being used and if the timestamp
      clock can be guaranteed to be monotonic over a system
      crash/restart, i.e., if the first value of the sender's timestamp
      clock after a crash/restart can be guaranteed to be greater than
      the last value before the restart, then a quiet time will be
      unnecessary.

      To dispense totally with the quiet time would seem to require that
      the host clock be synchronized to a time source that is stable
      over the crash/restart period, with an accuracy of one timestamp
      clock tick or better.  Fortunately, we can back off from this
      strict requirement.  Suppose that the clock is always re-
      synchronized to within N timestamp clock ticks and that booting



Jacobson, Braden & Zhang                                       [Page 11]

RFC 1185               TCP over High-Speed Paths            October 1990


      (extended with a quiet time, if necessary) takes more than N
      ticks.  This will guarantee monotonicity of the timestamps, which
      can then be used to reject old duplicates even without an enforced
      MSL.

   3.2  Closing and Reopening a Connection

      When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
      state ties up the socket pair for 4 minutes (see Section 3.5 of
      [Postel81].  Applications built upon TCP that close one connection
      and open a new one (e.g., an FTP data transfer connection using
      Stream mode) must choose a new socket pair each time.  This delay
      serves two different purposes:

      (a)  Implement the full-duplex reliable close handshake of TCP.

           The proper time to delay the final close step is not really
           related to the MSL; it depends instead upon the RTO for the
           FIN segments and therefore upon the RTT of the path.*
           Although there is no formal upper-bound on RTT, common
           network engineering practice makes an RTT greater than 1
           minute very unlikely.  Thus, the 4 minute delay in TIME-WAIT
           state works satisfactorily to provide a reliable full-duplex
           TCP close.  Note again that this is independent of MSL
           enforcement and network speed.

           The TIME-WAIT state could cause an indirect performance
           problem if an application needed to repeatedly close one
           connection and open another at a very high frequency, since
           the number of available TCP ports on a host is less than
           2**16.  However, high network speeds are not the major
           contributor to this problem; the RTT is the limiting factor
           in how quickly connections can be opened and closed.
           Therefore, this problem will no worse at high transfer
           speeds.

      (b)  Allow old duplicate segements to expire.

           Suppose that a host keeps a cache of the last timestamp
           received from each remote host.  This can be used to reject
           old duplicate segments from earlier incarnations of the
_________________________
*Note: It could be argued that the side that is sending  a  FIN  knows
what  degree  of reliability it needs, and therefore it should be able
to  determine  the  length  of  the  TIME-WAIT  delay  for  the  FIN's
recipient.   This could be accomplished with an appropriate TCP option
in FIN segments.




Jacobson, Braden & Zhang                                       [Page 12]

RFC 1185               TCP over High-Speed Paths            October 1990


           connection, if the timestamp clock can be guaranteed to have
           ticked at least once since the old conennection was open.
           This requires that the TIME-WAIT delay plus the RTT together
           must be at least one tick of the sender's timestamp clock.

           Note that this is a variant on the mechanism proposed by
           Garlick, Rom, and Postel (see the appendix), which required
           each host to maintain connection records containing the
           highest sequence numbers on every connection.  Using
           timestamps instead, it is only necessary to keep one quantity
           per remote host, regardless of the number of simultaneous
           connections to that host.

      We conclude that if all hosts used the TCP timestamp algorithm
      described in Section 2, enforcement of a maximum segment lifetime
      would be unnecessary and the quiet time at system startup could be
      shortened or removed.  In any case, the timestamp mechanism can
      provide additional security against old duplicates from earlier
      connection incarnations.   However, a 4 minute TIME-WAIT delay
      (unrelated to MSL enforcement or network speed) must be retained
      to provide the reliable close handshake of TCP.

4. CONCLUSIONS

   We have presented a mechanism, based upon the TCP timestamp echo
   option of RFC-1072, that will allow very high TCP transfer rates
   without reliability problems due to old duplicate segments on the
   same connection.  This mechanism also provides additional security
   against intrusion of old duplicates from earlier incarnations of the
   same connection.  If the timestamp mechanism were used by all hosts,
   the quiet time at system startup could be eliminated and enforcement
   of a maximum segment lifetime (MSL) would no longer be necessary.

REFERENCES

   [Cerf76]  Cerf, V., "TCP Resynchronization", Tech Note #79, Digital
   Systems Lab, Stanford, January 1976.

   [Dalal74]  Dalal, Y., "More on Selecting Sequence Numbers", INWG
   Protocol Note #4, October 1974.

   [Garlick77]  Garlick, L., R. Rom, and J. Postel, "Issues in Reliable
   Host-to-Host Protocols", Proc. Second Berkeley Workshop on
   Distributed Data Management and Computer Networks, May 1977.

   [Hamming77]  Hamming, R., "Digital Filters", ISBN 0-13-212571-4,
   Prentice Hall, Englewood Cliffs, N.J., 1977.




Jacobson, Braden & Zhang                                       [Page 13]

RFC 1185               TCP over High-Speed Paths            October 1990


   [Jacobson88]  Jacobson, V., and R. Braden, "TCP Extensions for
   Long-Delay Paths", RFC 1072, LBL and USC/Information Sciences
   Institute, October 1988.

   [Jacobson90]  Jacobson, V., "4BSD Header Prediction", ACM Computer
   Communication Review, April 1990.

   [McKenzie89]  McKenzie, A., "A Problem with the TCP Big Window
   Option", RFC 1110, BBN STC, August 1989.

   [Postel81]  Postel, J., "Transmission Control Protocol", RFC 793,
   DARPA, September 1981.

   [Tomlinson74]  Tomlinson, R., "Selecting Sequence Numbers", INWG
   Protocol Note #2, September 1974.

   [Watson81]  Watson, R., "Timer-based Mechanisms in Reliable
   Transport Protocol Connection Management", Computer Networks,
   Vol. 5, 1981.
































Jacobson, Braden & Zhang                                       [Page 14]

RFC 1185               TCP over High-Speed Paths            October 1990


APPENDIX -- Protection against Old Duplicates in TCP

   During the development of TCP, a great deal of effort was devoted to
   the problem of protecting a TCP connection from segments left from
   earlier incarnations of the same connection.  Several different
   mechanisms were proposed for this purpose [Tomlinson74] [Dalal74]
   [Cerf76] [Garlick77].

   The connection parameters that are required in this discussion are:

           Tc = Connection duration in seconds.

           Nc = Total number of bytes sent on connection.

           B = Effective bandwidth of connection = Nc/Tc.

   Tomlinson proposed a scheme with two parts: a clock-driven selection
   of ISN (Initial Sequence Number) for a connection, and a
   resynchronization procedure [Tomlinson74]. The clock-driven scheme
   chooses:

      ISN = (integer(R*t)) mod 2**32                 [2]

   where t is the current time relative to an arbitrary origin, and R is
   a constant.  R was intended to be chosen so that ISN will advance
   faster than sequence numbers will be used up on the connection.
   However, at high speeds this will not be true; the consequences of
   this will be discussed below.

   The clock-driven choice of ISN in formula [2] guarantees freedom from
   old duplicates matching a reopened connection if the original
   connection was "short-lived" and "slow".  By "short-lived", we mean a
   connection that stayed open for a time Tc less than the time to cycle
   the ISN, i.e., Tc < 2**32/R seconds.  By "slow", we mean that the
   effective transfer rate B is less than R.

   This is illustrated in Figure 1, where sequence numbers are plotted
   against time.  The asterisks show the ISN lines from formula [2],
   while the circles represent the trajectories of several short-lived
   incarnations of the same connection, each terminating at the "x".

        Note: allowing rapid reuse of connections was believed to be an
        important goal during the early TCP development.  This
        requirement was driven by the hope that TCP would serve as a
        basis for user-level transaction protocols as well as
        connection-oriented protocols.  The paradigm discussed was the
        "Christmas Tree" or "Kamikazee" segment that contained SYN and
        FIN bits as well as data.  Enthusiasm for this was somewhat



Jacobson, Braden & Zhang                                       [Page 15]

RFC 1185               TCP over High-Speed Paths            October 1990


        dampened when it was observed that the 3-way SYN handshake and
        the FIN handshake mean that 5 packets are required for a minimum
        exchange. Furthermore, the TIME-WAIT state delay implies that
        the same connection really cannot be reopened immediately.  No
        further work has been done in this area, although existing
        applications (especially SMTP) often generate very short TCP
        sessions.  The reuse problem is generally avoided by using a
        different port pair for each connection.


        |- 2**32       ISN             ISN
        |              *               *
        |             *               *
        |            *               *
        |           *x              *
        |          o               *
    ^   |         *               *
    |   |        *  x            *
        |       * o             *
    S   |      *o              *
    e   |     o               *
    q   |    *               *
        |   *               *
    #   |  * x             *
        | *o              *
        |o_______________*____________
                         ^         Time -->
                       4.55hrs


     Figure 1.  Clock-Driven ISN  avoiding duplication on
                short-Lived, slow connections.


   However, clock-driven ISN selection does not protect against old
   duplicate packets for a long-lived or fast connection:  the
   connection may close (or crash) just as the ISN has cycled around and
   reached the same value again.  If the connection is then reopened, a
   datagram still in transit from the old connection may fall into the