rfc1323.txt

RFC 的详细文档！

              To make this more quantitative, any clock faster than 1
              tick/sec will reject old duplicate segments for link
              speeds of ~8 Gbps.  A 1ms timestamp clock will work at
              link speeds up to 8 Tbps (8*10**12) bps!

         (b)  The timestamp clock must not be "too fast".

              Its recycling time must be greater than MSL seconds.
              Since the clock (timestamp) is 32 bits and the worst-case
              MSL is 255 seconds, the maximum acceptable clock frequency
              is one tick every 59 ns.

              However, it is desirable to establish a much longer
              recycle period, in order to handle outdated timestamps on
              idle connections (see Section 4.2.3), and to relax the MSL
              requirement for preventing sequence number wrap-around.
              With a 1 ms timestamp clock, the 32-bit timestamp will
              wrap its sign bit in 24.8 days.  Thus, it will reject old
              duplicates on the same connection if MSL is 24.8 days or
              less.  This appears to be a very safe figure; an MSL of
              24.8 days or longer can probably be assumed by the gateway
              system without requiring precise MSL enforcement by the
              TTL value in the IP layer.

         Based upon these considerations, we choose a timestamp clock
         frequency in the range 1 ms to 1 sec per tick.  This range also
         matches the requirements of the RTTM mechanism, which does not
         need much more resolution than the granularity of the
         retransmit timer, e.g., tens or hundreds of milliseconds.

         The PAWS mechanism also puts a strong monotonicity requirement
         on the sender's timestamp clock.  The method of implementation
         of the timestamp clock to meet this requirement depends upon
         the system hardware and software.

         *    Some hosts have a hardware clock that is guaranteed to be
              monotonic between hardware resets.



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


         *    A clock interrupt may be used to simply increment a binary
              integer by 1 periodically.

         *    The timestamp clock may be derived from a system clock
              that is subject to being abruptly changed, by adding a
              variable offset value.  This offset is initialized to
              zero.  When a new timestamp clock value is needed, the
              offset can be adjusted as necessary to make the new value
              equal to or larger than the previous value (which was
              saved for this purpose).


      4.2.3  Outdated Timestamps

         If a connection remains idle long enough for the timestamp
         clock of the other TCP to wrap its sign bit, then the value
         saved in TS.Recent will become too old; as a result, the PAWS
         mechanism will cause all subsequent segments to be rejected,
         freezing the connection (until the timestamp clock wraps its
         sign bit again).

         With the chosen range of timestamp clock frequencies (1 sec to
         1 ms), the time to wrap the sign bit will be between 24.8 days
         and 24800 days.  A TCP connection that is idle for more than 24
         days and then comes to life is exceedingly unusual.  However,
         it is undesirable in principle to place any limitation on TCP
         connection lifetimes.

         We therefore require that an implementation of PAWS include a
         mechanism to "invalidate" the TS.Recent value when a connection
         is idle for more than 24 days.  (An alternative solution to the
         problem of outdated timestamps would be to send keepalive
         segments at a very low rate, but still more often than the
         wrap-around time for timestamps, e.g., once a day.  This would
         impose negligible overhead.  However, the TCP specification has
         never included keepalives, so the solution based upon
         invalidation was chosen.)

         Note that a TCP does not know the frequency, and therefore, the
         wraparound time, of the other TCP, so it must assume the worst.
         The validity of TS.Recent needs to be checked only if the basic
         PAWS timestamp check fails, i.e., only if SEG.TSval <
         TS.Recent.  If TS.Recent is found to be invalid, then the
         segment is accepted, regardless of the failure of the timestamp
         check, and rule R3 updates TS.Recent with the TSval from the
         new segment.

         To detect how long the connection has been idle, the TCP may



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


         update a clock or timestamp value associated with the
         connection whenever TS.Recent is updated, for example.  The
         details will be implementation-dependent.

      4.2.4  Header Prediction

         "Header prediction" [Jacobson90a] is a high-performance
         transport protocol implementation technique that is most
         important for high-speed links.  This technique optimizes the
         code for the most common case, receiving a segment correctly
         and in order.  Using header prediction, the receiver asks the
         question, "Is this segment the next in sequence?"  This
         question can be answered in fewer machine instructions than the
         question, "Is this segment within the window?"

         Adding header prediction to our timestamp procedure leads to
         the following recommended sequence for processing an arriving
         TCP segment:

         H1)  Check timestamp (same as step R1 above)

         H2)  Do header prediction: if segment is next in sequence and
              if there are no special conditions requiring additional
              processing, accept the segment, record its timestamp, and
              skip H3.

         H3)  Process the segment normally, as specified in RFC-793.
              This includes dropping segments that are outside the win-
              dow and possibly sending acknowledgments, and queueing
              in-window, out-of-sequence segments.

         Another possibility would be to interchange steps H1 and H2,
         i.e., to perform the header prediction step H2 FIRST, and
         perform H1 and H3 only when header prediction fails.  This
         could be a performance improvement, since the timestamp check
         in step H1 is very unlikely to fail, and it requires interval
         arithmetic on a finite field, a relatively expensive operation.
         To perform this check on every single segment is contrary to
         the philosophy of header prediction.  We believe that this
         change might reduce CPU time for TCP protocol processing by up
         to 5-10% on high-speed networks.

         However, putting H2 first would create a hazard: a segment from
         2**32 bytes in the past might arrive at exactly the wrong time
         and be accepted mistakenly by the header-prediction step.  The
         following reasoning has been introduced [Jacobson90b] to show
         that the probability of this failure is negligible.




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


              If all segments are equally likely to show up as old
              duplicates, then the probability of an old duplicate
              exactly matching the left window edge is the maximum
              segment size (MSS) divided by the size of the sequence
              space.  This ratio must be less than 2**-16, since MSS
              must be < 2**16; for example, it will be (2**12)/(2**32) =
              2**-20 for an FDDI link.  However, the older a segment is,
              the less likely it is to be retained in the Internet, and
              under any reasonable model of segment lifetime the
              probability of an old duplicate exactly at the left window
              edge must be much smaller than 2**-16.

              The 16 bit TCP checksum also allows a basic unreliability
              of one part in 2**16.  A protocol mechanism whose
              reliability exceeds the reliability of the TCP checksum
              should be considered "good enough", i.e., it won't
              contribute significantly to the overall error rate.  We
              therefore believe we can ignore the problem of an old
              duplicate being accepted by doing header prediction before
              checking the timestamp.

         However, this probabilistic argument is not universally
         accepted, and the consensus at present is that the performance
         gain does not justify the hazard in the general case.  It is
         therefore recommended that H2 follow H1.

   4.3.  Duplicates from Earlier Incarnations of Connection

      The PAWS mechanism protects against errors due to sequence number
      wrap-around on high-speed connection.  Segments from an earlier
      incarnation of the same connection are also a potential cause of
      old duplicate errors.  In both cases, the TCP mechanisms to
      prevent such errors depend upon the enforcement of a maximum
      segment lifetime (MSL) by the Internet (IP) layer (see Appendix of
      RFC-1185 for a detailed discussion).  Unlike the case of sequence
      space wrap-around, the MSL required to prevent old duplicate
      errors from earlier incarnations does not depend upon the transfer
      rate.  If the IP layer enforces the recommended 2 minute MSL of
      TCP, and if the TCP rules are followed, TCP connections will be
      safe from earlier incarnations, no matter how high the network
      speed.  Thus, the PAWS mechanism is not required for this case.

      We may still ask whether the PAWS mechanism can provide additional
      security against old duplicates from earlier connections, allowing
      us to relax the enforcement of MSL by the IP layer.  Appendix B
      explores this question, showing that further assumptions and/or
      mechanisms are required, beyond those of PAWS.  This is not part
      of the current extension.



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


5.  CONCLUSIONS AND ACKNOWLEDGMENTS

   This memo presented a set of extensions to TCP to provide efficient
   operation over large-bandwidth*delay-product paths and reliable
   operation over very high-speed paths.  These extensions are designed
   to provide compatible interworking with TCP's that do not implement
   the extensions.

   These mechanisms are implemented using new TCP options for scaled
   windows and timestamps.  The timestamps are used for two distinct
   mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect
   Against Wrapped Sequences).

   The Window Scale option was originally suggested by Mike St. Johns of
   USAF/DCA.  The present form of the option was suggested by Mike
   Karels of UC Berkeley in response to a more cumbersome scheme defined
   by Van Jacobson.  Lixia Zhang helped formulate the PAWS mechanism
   description in RFC-1185.

   Finally, much of this work originated as the result of discussions
   within the End-to-End Task Force on the theoretical limitations of
   transport protocols in general and TCP in particular.  More recently,
   task force members and other on the end2end-interest list have made
   valuable contributions by pointing out flaws in the algorithms and
   the documentation.  The authors are grateful for all these
   contributions.

6.  REFERENCES

      [Clark87]  Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
      Data Transfer Protocol", RFC 998, MIT, March 1987.

      [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.

      [Cheriton88]  Cheriton, D., "VMTP: Versatile Message Transaction
      Protocol", RFC 1045, Stanford University, February 1988.

      [Jacobson88a] Jacobson, V., "Congestion Avoidance and Control",
      SIGCOMM '88, Stanford, CA., August 1988.

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



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


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

      [Jacobson90b]  Jacobson, V., Braden, R., and Zhang, L., "TCP
      Extension for High-Speed Paths", RFC-1185, LBL and USC/Information
      Sciences Institute, October 1990.

      [Jacobson90c]  Jacobson, V., "Modified TCP congestion avoidance
      algorithm", Message to end2end-interest mailing list, April 1990.

      [Jain86]  Jain, R., "Divergence of Timeout Algorithms for Packet
      Retransmissions", Proc. Fifth Phoenix Conf