rfc1072.txt

中、英文RFC文档大全打包下载完全版 .

4.  TCP ECHO OPTIONS

   A simple method for measuring the RTT of a segment would be: the
   sender places a timestamp in the segment and the receiver returns
   that timestamp in the corresponding ACK segment. When the ACK segment
   arrives at the sender, the difference between the current time and
   the timestamp is the RTT.  To implement this timing method, the
   receiver must simply reflect or echo selected data (the timestamp)
   from the sender's segments.  This idea is the basis of the "TCP Echo"
   and "TCP Echo Reply" options.





Jacobson & Braden                                              [Page 11]

RFC 1072          TCP Extensions for Long-Delay Paths       October 1988


4.1  TCP Echo and TCP Echo Reply Options

      TCP Echo Option:

      Kind: 6

      Length: 6

          +--------+--------+--------+--------+--------+--------+
          | Kind=6 | Length |   4 bytes of info to be echoed    |
          +--------+--------+--------+--------+--------+--------+

   This option carries four bytes of information that the receiving TCP
   may send back in a subsequent TCP Echo Reply option (see below).  A
   TCP may send the TCP Echo option in any segment, but only if a TCP
   Echo option was received in a SYN segment for the connection.

   When the TCP echo option is used for RTT measurement, it will be
   included in data segments, and the four information bytes will define
   the time at which the data segment was transmitted in any format
   convenient to the sender.

   TCP Echo Reply Option:

   Kind: 7

   Length: 6

       +--------+--------+--------+--------+--------+--------+
       | Kind=7 | Length |    4 bytes of echoed info         |
       +--------+--------+--------+--------+--------+--------+


   A TCP that receives a TCP Echo option containing four information
   bytes will return these same bytes in a TCP Echo Reply option.

   This TCP Echo Reply option must be returned in the next segment
   (e.g., an ACK segment) that is sent. If more than one Echo option is
   received before a reply segment is sent, the TCP must choose only one
   of the options to echo, ignoring the others; specifically, it must
   choose the newest segment with the oldest sequence number (see next
   section.)

   To use the TCP Echo and Echo Reply options, a TCP must send a TCP
   Echo option in its own SYN segment and receive a TCP Echo option in a
   SYN segment from the other TCP.  A TCP that does not implement the
   TCP Echo or Echo Reply options must simply ignore any TCP Echo
   options it receives.  However, a TCP should not receive one of these



Jacobson & Braden                                              [Page 12]

RFC 1072          TCP Extensions for Long-Delay Paths       October 1988


   options in a non-SYN segment unless it included a TCP Echo option in
   its own SYN segment.

4.2  Using the Echo Options

   If we wish to use the Echo/Echo Reply options for RTT measurement, we
   have to define what the receiver does when there is not a one-to-one
   correspondence between data and ACK segments.  Assuming that we want
   to minimize the state kept in the receiver (i.e., the number of
   unprocessed Echo options), we can plan on a receiver remembering the
   information value from at most one Echo between ACKs.  There are
   three situations to consider:

   (A)  Delayed ACKs.

        Many TCP's acknowledge only every Kth segment out of a group of
        segments arriving within a short time interval; this policy is
        known generally as "delayed ACK's".  The data-sender TCP must
        measure the effective RTT, including the additional time due to
        delayed ACK's, or else it will retransmit unnecessarily.  Thus,
        when delayed ACK's are in use, the receiver should reply with
        the Echo option information from the earliest unacknowledged
        segment.

   (B)  A hole in the sequence space (segment(s) have been lost).

        The sender will continue sending until the window is filled, and
        we may be generating ACKs as these out-of-order segments arrive
        (e.g., for the SACK information or to aid "fast retransmit").
        An Echo Reply option will tell the sender the RTT of some
        recently sent segment (since the ACK can only contain the
        sequence number of the hole, the sender may not be able to
        determine which segment, but that doesn't matter).  If the loss
        was due to congestion, these RTTs may be particularly valuable
        to the sender since they reflect the network characteristics
        immediately after the congestion.

   (C)  A filled hole in the sequence space.

        The segment that fills the hole represents the most recent
        measurement of the network characteristics.  On the other hand,
        an RTT computed from an earlier segment would probably include
        the sender's retransmit time-out, badly biasing the sender's
        average RTT estimate.


   Case (A) suggests the receiver should remember and return the Echo
   option information from the oldest unacknowledged segment.  Cases (B)



Jacobson & Braden                                              [Page 13]

RFC 1072          TCP Extensions for Long-Delay Paths       October 1988


   and (C) suggest that the option should come from the most recent
   unacknowledged segment.  An algorithm that covers all three cases is
   for the receiver to return the Echo option information from the
   newest segment with the oldest sequence number, as specified earlier.

   A model implementation of these options is as follows.


   (1)  Receiver Implementation

        A 32-bit slot for Echo option data, rcv.echodata, is added to
        the receiver connection state, together with a flag,
        rcv.echopresent, that indicates whether there is anything in the
        slot.  When the receiver generates a segment, it checks
        rcv.echopresent and, if it is set, adds an echo-reply option
        containing rcv.echodata to the outgoing segment then clears
        rcv.echopresent.

        If an incoming segment is in the window and contains an echo
        option, the receiver checks rcv.echopresent.  If it isn't set,
        the value of the echo option is copied to rcv.echodata and
        rcv.echopresent is set.  If rcv.echopresent is already set, the
        receiver checks whether the segment is at the left edge of the
        window.  If so, the segment's echo option value is copied to
        rcv.echodata (this is situation (C) above).  Otherwise, the
        segment's echo option is ignored.


   (2)  Sender Implementation

        The sender's connection state has a single flag bit,
        snd.echoallowed, added.  If snd.echoallowed is set or if the
        segment contains a SYN, the sender is free to add a TCP Echo
        option (presumably containing the current time in some units
        convenient to the sender) to every outgoing segment.

        Snd.echoallowed should be set if a SYN is received with a TCP
        Echo option (presumably, a host that implements the option will
        attempt to use it to time the SYN segment).


5.  CONCLUSIONS AND ACKNOWLEDGMENTS

We have proposed five new TCP options for scaled windows, selective
acknowledgments, and round-trip timing, in order to provide efficient
operation over large-bandwidth*delay-product paths.  These extensions
are designed to provide compatible interworking with TCP's that do not
implement the extensions.



Jacobson & Braden                                              [Page 14]

RFC 1072          TCP Extensions for Long-Delay Paths       October 1988


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 proposed by Van
Jacobson.  Gerd Beling of FGAN (West Germany) contributed the initial
definition of the SACK option.

All three options have evolved through discussion with the End-to-End
Task Force, and the authors are grateful to the other members of the
Task Force for their advice and encouragement.

6.  REFERENCES

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

      [Jain86]  Jain, R., "Divergence of Timeout Algorithms for Packet
      Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm.,
      Scottsdale, Arizona, March 1986.

      [Karn87]  Karn, P. and C. Partridge, "Estimating Round-Trip Times
      in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT,
      August 1987.

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

      [Nagle84]  Nagle, J., "Congestion Control in IP/TCP
      Internetworks", RFC 896, FACC, January 1984.

      [NBS85]  Colella, R., Aronoff, R., and K. Mills, "Performance
      Improvements for ISO Transport", Ninth Data Comm Symposium,
      published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5,
      September 1985.

      [Partridge87]  Partridge, C., "Private Communication", February
      1987.

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

      [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data
      Protocol", RFC 908, BBN, July 1984.

      [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", to
      be presented at SIGCOMM '88, Stanford, CA., August 1988.

      [Zhang86]  Zhang, L., "Why TCP Timers Don't Work Well", Proc.



Jacobson & Braden                                              [Page 15]

RFC 1072          TCP Extensions for Long-Delay Paths       October 1988


      SIGCOMM '86, Stowe, Vt., August 1986.


















































Jacobson & Braden                                              [Page 16]