rfc1323.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

           Ethernet      10Mbps    1.25MBps    1700 (~30 mins)

           DS3           45Mbps     5.6MBps    380

           FDDI         100Mbps    12.5MBps    170

           Gigabit        1Gbps     125MBps    17


      It is clear that wrap-around of the sequence space is not a
      problem for 56kbps packet switching or even 10Mbps Ethernets.  On
      the other hand, at DS3 and FDDI speeds, Twrap is comparable to the
      2 minute MSL assumed by the TCP specification [Postel81].  Moving
      towards gigabit speeds, Twrap becomes too small for reliable
      enforcement by the Internet TTL mechanism.

      The 16-bit window field of TCP limits the effective bandwidth B to
      2**16/RTT, where RTT is the round-trip time in seconds
      [McKenzie89].  If the RTT is large enough, this limits B to a
      value that meets the constraint [1] for a large MSL value.  For
      example, consider a transcontinental backbone with an RTT of 60ms
      (set by the laws of physics).  With the bandwidth*delay product
      limited to 64KB by the TCP window size, B is then limited to
      1.1MBps, no matter how high the theoretical transfer rate of the
      path.  This corresponds to cycling the sequence number space in
      Twrap= 2000 secs, which is safe in today's Internet.

      It is important to understand that the culprit is not the larger
      window but rather the high bandwidth.  For example, consider a
      (very large) FDDI LAN with a diameter of 10km.  Using the speed of
      light, we can compute the RTT across the ring as
      (2*10**4)/(3*10**8) = 67 microseconds, and the delay*bandwidth
      product is then 833 bytes.  A TCP connection across this LAN using
      a window of only 833 bytes will run at the full 100mbps and can
      wrap the sequence space in about 3 minutes, very close to the MSL
      of TCP.  Thus, high speed alone can cause a reliability problem
      with sequence number wrap-around, even without extended windows.

      Watson's Delta-T protocol [Watson81] includes network-layer
      mechanisms for precise enforcement of an MSL.  In contrast, the IP



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


      mechanism for MSL enforcement is loosely defined and even more
      loosely implemented in the Internet.  Therefore, it is unwise to
      depend upon active enforcement of MSL for TCP connections, and it
      is unrealistic to imagine setting MSL's smaller than the current
      values (e.g., 120 seconds specified for TCP).

      A possible fix for the problem of cycling the sequence space would
      be to increase the size of the TCP sequence number field.  For
      example, the sequence number field (and also the acknowledgment
      field) could be expanded to 64 bits.  This could be done either by
      changing the TCP header or by means of an additional option.

      Section 5 presents a different mechanism, which we call PAWS
      (Protect Against Wrapped Sequence numbers), to extend TCP
      reliability to transfer rates well beyond the foreseeable upper
      limit of network bandwidths.  PAWS uses the TCP Timestamps option
      defined in Section 4 to protect against old duplicates from the
      same connection.

   1.3 Using TCP options

      The extensions defined in this memo all use new TCP options.  We
      must address two possible issues concerning the use of TCP
      options: (1) compatibility and (2) overhead.

      We must pay careful attention to compatibility, i.e., to
      interoperation with existing implementations.  The only TCP option
      defined previously, MSS, may appear only on a SYN segment.  Every
      implementation should (and we expect that most will) ignore
      unknown options on SYN segments.  However, some buggy TCP
      implementation might be crashed by the first appearance of an
      option on a non-SYN segment.  Therefore, for each of the
      extensions defined below, TCP options will be sent on non-SYN
      segments only when an exchange of options on the SYN segments has
      indicated that both sides understand the extension.  Furthermore,
      an extension option will be sent in a <SYN,ACK> segment only if
      the corresponding option was received in the initial <SYN>
      segment.

      A question may be raised about the bandwidth and processing
      overhead for TCP options.  Those options that occur on SYN
      segments are not likely to cause a performance concern.  Opening a
      TCP connection requires execution of significant special-case
      code, and the processing of options is unlikely to increase that
      cost significantly.

      On the other hand, a Timestamps option may appear in any data or
      ACK segment, adding 12 bytes to the 20-byte TCP header.  We



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


      believe that the bandwidth saved by reducing unnecessary
      retransmissions will more than pay for the extra header bandwidth.

      There is also an issue about the processing overhead for parsing
      the variable byte-aligned format of options, particularly with a
      RISC-architecture CPU.  To meet this concern, Appendix A contains
      a recommended layout of the options in TCP headers to achieve
      reasonable data field alignment.  In the spirit of Header
      Prediction, a TCP can quickly test for this layout and if it is
      verified then use a fast path.  Hosts that use this canonical
      layout will effectively use the options as a set of fixed-format
      fields appended to the TCP header.  However, to retain the
      philosophical and protocol framework of TCP options, a TCP must be
      prepared to parse an arbitrary options field, albeit with less
      efficiency.

      Finally, we observe that most of the mechanisms defined in this
      memo are important for LFN's and/or very high-speed networks.  For
      low-speed networks, it might be a performance optimization to NOT
      use these mechanisms.  A TCP vendor concerned about optimal
      performance over low-speed paths might consider turning these
      extensions off for low-speed paths, or allow a user or
      installation manager to disable them.


2. TCP WINDOW SCALE OPTION

   2.1  Introduction

      The window scale extension expands the definition of the TCP
      window to 32 bits and then uses a scale factor to carry this 32-
      bit value in the 16-bit Window field of the TCP header (SEG.WND in
      RFC-793).  The scale factor is carried in a new TCP option, Window
      Scale.  This option is sent only in a SYN segment (a segment with
      the SYN bit on), hence the window scale is fixed in each direction
      when a connection is opened.  (Another design choice would be to
      specify the window scale in every TCP segment.  It would be
      incorrect to send a window scale option only when the scale factor
      changed, since a TCP option in an acknowledgement segment will not
      be delivered reliably (unless the ACK happens to be piggy-backed
      on data in the other direction).  Fixing the scale when the
      connection is opened has the advantage of lower overhead but the
      disadvantage that the scale factor cannot be changed during the
      connection.)

      The maximum receive window, and therefore the scale factor, is
      determined by the maximum receive buffer space.  In a typical
      modern implementation, this maximum buffer space is set by default



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


      but can be overridden by a user program before a TCP connection is
      opened.  This determines the scale factor, and therefore no new
      user interface is needed for window scaling.

   2.2  Window Scale Option

      The three-byte Window Scale option may be sent in a SYN segment by
      a TCP.  It has two purposes: (1) indicate that the TCP is prepared
      to do both send and receive window scaling, and (2) communicate a
      scale factor to be applied to its receive window.  Thus, a TCP
      that is prepared to scale windows should send the option, even if
      its own scale factor is 1.  The scale factor is limited to a power
      of two and encoded logarithmically, so it may be implemented by
      binary shift operations.


      TCP Window Scale Option (WSopt):

         Kind: 3 Length: 3 bytes

                +---------+---------+---------+
                | Kind=3  |Length=3 |shift.cnt|
                +---------+---------+---------+


         This option is an offer, not a promise; both sides must send
         Window Scale options in their SYN segments to enable window
         scaling in either direction.  If window scaling is enabled,
         then the TCP that sent this option will right-shift its true
         receive-window values by 'shift.cnt' bits for transmission in
         SEG.WND.  The value 'shift.cnt' may be zero (offering to scale,
         while applying a scale factor of 1 to the receive window).

         This option may be sent in an initial <SYN> segment (i.e., a
         segment with the SYN bit on and the ACK bit off).  It may also
         be sent in a <SYN,ACK> segment, but only if a Window Scale op-
         tion was received in the initial <SYN> segment.  A Window Scale
         option in a segment without a SYN bit should be ignored.

         The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment
         itself is never scaled.

   2.3  Using the Window Scale Option

      A model implementation of window scaling is as follows, using the
      notation of RFC-793 [Postel81]:

      *    All windows are treated as 32-bit quantities for storage in



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


           the connection control block and for local calculations.
           This includes the send-window (SND.WND) and the receive-
           window (RCV.WND) values, as well as the congestion window.

      *    The connection state is augmented by two window shift counts,
           Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
           incoming and outgoing window fields, respectively.

      *    If a TCP receives a <SYN> segment containing a Window Scale
           option, it sends its own Window Scale option in the <SYN,ACK>
           segment.

      *    The Window Scale option is sent with shift.cnt = R, where R
           is the value that the TCP would like to use for its receive
           window.

      *    Upon receiving a SYN segment with a Window Scale option
           containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and
           sets Rcv.Wind.Scale to R; otherwise, it sets both
           Snd.Wind.Scale and Rcv.Wind.Scale to zero.

      *    The window field (SEG.WND) in the header of every incoming
           segment, with the exception of SYN segments, is left-shifted
           by Snd.Wind.Scale bits before updating SND.WND:

              SND.WND = SEG.WND << Snd.Wind.Scale

           (assuming the other conditions of RFC793 are met, and using
           the "C" notation "<<" for left-shift).

      *    The window field (SEG.WND) of every outgoing segment, with
           the exception of SYN segments, is right-shifted by
           Rcv.Wind.Scale bits:

              SEG.WND = RCV.WND >> Rcv.Wind.Scale.


      TCP determines if a data segment is "old" or "new" by testing
      whether its sequence number is within 2**31 bytes of the left edge
      of the window, and if it is not, discarding the data as "old".  To
      insure that new data is never mistakenly considered old and vice-
      versa, the left edge of the sender's window has to be at most
      2**31 away from the right edge of the receiver's window.
      Similarly with the sender's right edge and receiver's left edge.
      Since the right and left edges of either the sender's or
      receiver's window differ by the window size, and since the sender
      and receiver windows can be out of phase by at most the window
      size, the above constraints imply that 2 * the max window size



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


      must be less than 2**31, or

           max window < 2**30

      Since the max window is 2**S (where S is the scaling shift count)
      times at most 2**16 - 1 (the maximum unscaled window), the maximum
      window is guaranteed to be < 2*30 if S <= 14.  Thus, the shift
      count must be limited to 14 (which allows windows of 2**30 = 1
      Gbyte).  If a Window Scale option is received with a shift.cnt
      value exceeding 14, the TCP should log the error but use 14
      instead of the specified value.

      The scale factor applies only to the Window field as transmitted
      in the TCP header; each TCP using extended windows will maintain
      the window values locally as 32-bit numbers.  For example, the
      "congestion window" computed by Slow Start and Congestion
      Avoidance is not affected by the scale factor, so window scaling
      will not introduce quantization into the congestion window.

3.  RTTM: ROUND-TRIP TIME MEASUREMENT