rfc1379.txt

RFC 的详细文档！

               [ y1 ]                                       [ ?? ]
         3.                --> <ACK(SYN),M=x2> -->   (data1->user_B,
                                                      cache.M[A]= x2)

               [ y1 ]                                       [ x2 ]
                               ...  (etc.)  ...


                        Figure 6. Server Host Crashed


   3.3  Accepting <SYN,ACK> Segments

      Transactions introduce a new hazard of erroneously accepting an
      old duplicate <SYN,ACK> segment.  To be acceptable, a <SYN,ACK>
      segment must arrive in SYN-SENT state, and its ACK field must
      acknowledge something that was sent.  In current TCPs the
      effective send window in SYN-SENT state is exactly one octet, and
      an acceptable <SYN,ACK> must exactly ACK this one octet.  The
      clock-driven selection of Initial Sequence Number (ISN) makes an
      erroneous acceptance exceedingly unlikely.  An old duplicate SYN
      could be accepted erroneously only if successive connection
      attempts occurred more often than once every 4 microseconds, or if
      the segment lifetime exceeded the 4 hour wraparound time for ISN



Braden                                                         [Page 11]

RFC 1379              Transaction TCP -- Concepts          November 1992


      selection.

      However, when TCP is used for transactions, data sent with the
      initial SYN increases the range of sequence numbers that have been
      sent.  This increases the danger of accepting an old duplicate
      <SYN,ACK> segment, and the consequences are more serious.  In the
      example in Figure 7, segments 1-3 form a normal transaction
      sequence, and segment 4 begins a new transaction (incarnation) for
      the same connection.  Segment #5 is a duplicate of segment #2 from
      the preceding transaction.  Although the new transaction has a
      larger ISN, the previous ACK value 402 falls into the new range
      [200,700) of sequence numbers that have been sent, so segment #5
      could be erroneously accepted and passed to the client as the
      response to the new request.

           _T_C_P__A                                       _T_C_P__B

         CLOSED                                                   LISTEN

      1.           --> <seq=100,SYN,data=300,FIN,M=x1> --> (TAO test OK)


      2.         <-- <seq=800,ack=402,SYN,data=350,FIN,M=y1> <--


      3. TIME-WAIT                      --> <ACK(FIN)> -->       CLOSED
         (short timeout)
         CLOSED

         (New Request)
      4.           --> <seq=200,SYN,data=500,FIN,M=x2> --> ...

                                            (Duplicate of segment #2)
      5.         <-- <seq=800,ack=402,SYN,data=300,FIN,M=y1> <--...
         (Acceptable!!)


               Figure 7: Old Duplicate <SYN,ACK> Causing Error


      Unfortunately, we cannot simply use TAO on the client side to
      detect and reject old duplicate <SYN,ACK> segments.  A TAO test at
      the client might fail for a valid <SYN,ACK> segment, due to out-
      of-order delivery, and this could result in permanent non-delivery
      of a valid transaction reply.

      Instead, we include a second M value, an echo of the client's M
      value from the initial <SYN> segment, in the <SYN,ACK> segment.  A



Braden                                                         [Page 12]

RFC 1379              Transaction TCP -- Concepts          November 1992


      specially-marked M value, SEG.M.ECHO, is used for this purpose.
      The client knows the value it sent in the initial <SYN> and can
      therefore positively validate the <SYN,ACK> using the echoed
      value.  This is illustrated in Figure 12, which is the same as
      Figure 4 with the addition of the echoed value on the <SYN,ACK>
      segment #2.

      It should be noted that TCP allows a simultaneous open sequence in
      which both sides send and receive an initial <SYN> (see Figure 8
      of [STD-007].  In this case, the TAO test must be performed on
      both sides to preserve the symmetry.  See [TTCP-FS] for an
      example.

4.  SHORTENING TIME-WAIT STATE

   Once a transaction has been initiated for a particular connection
   (pair of ports) between a given host pair, a new transaction for the
   same connection cannot take place for a time that is at least:

       RTT + SPT + TIME-WAIT_delay

   Since the client host can cycle among the 64512 available port
   numbers, an upper bound on the transaction rate between a particular
   host pair is:

   [1]    TRmax = 64512 /(RTT + TIME-WAIT_Delay)

   in transactions per second (Tps), where we assumed SPT is negligible.
   We must reduce TIME-WAIT_Delay to support high-rate TCP transaction
   processing.

   TIME-WAIT state performs two functions: (1) supporting the full-
   duplex reliable close of TCP, and (2) allowing old duplicate segments
   from an earlier connection incarnation to expire before they can
   cause an error (see Appendix to [RFC-1185]).  The first function
   impacts the application model of a TCP connection, which we would not
   want to change.  The second is part of the fundamental machinery of
   TCP reliable delivery; to safely truncate TIME-WAIT state, we must
   provide another means to exclude duplicate packets from earlier
   incarnations of the connection.

   To minimize the delay in TIME-WAIT state while performing both
   functions, we propose to set the TIME-WAIT delay to:

   [2]    TIME-WAIT_Delay = max( K*RTO, U )

   where U and K are constants and RTO is the dynamically-determined
   retransmission timeout, the measured RTT plus an allowance for the



Braden                                                         [Page 13]

RFC 1379              Transaction TCP -- Concepts          November 1992


   RTT variance [Jacobson88].  We choose K large enough so that there is
   high probability of the close completing successfully if at all
   possible; K = 8 seems reasonable.  This takes care of the first
   function of TIME-WAIT state.

   In a real implementation, there may be a minimum RTO value Tr,
   corresponding to the precision of RTO calculation.  For example, in
   the popular BSD implementation of TCP, the minimum RTO is Tr = 0.5
   second.  Assuming K = 8 and U = 0, Eqns [1] and [2] impose an upper
   limit of TRmax = 16K Tps on the transaction rate of these
   implementations.

   It is possible to have many short connections only if RTO is very
   small, in which case the TIME-WAIT delay [2] reduces to U.  To
   accelerate the close sequence, we need to reduce U below the MSL
   enforced by the IP layer, without introducing a hazard from old
   duplicate segments.  For this purpose, we introduce another monotonic
   number sequence; call it X.  X values are required to be monotonic
   between successive connection incarnations; depending upon the choice
   of the X space (see Section 5), X values may also increase during a
   connection.  A value from the X space is to be carried in every
   segment, and a segment is rejected if it is received with an X value
   smaller than the largest X value received.  This mechanism does not
   use a cache; the largest X value is maintained in the TCP connection
   control block (TCB) for each connection.

   The value of U depends upon the choice for the X space, discussed in
   the next section.  If X is time-like, U can be set to twice the time
   granularity (i.e, twice the minimum "tick" time) of X.  The TIME-WAIT
   delay will then ensure that current X values do not overlap the X
   values of earlier incarnations of the same connection.  Another
   consequence of time-like X values is the possibility that an open but
   idle connection might allow the X value to wrap its sign bit,
   resulting in a lockup of the connection.  To prevent this, a 24-day
   idle timer on each open connection could bypass the X check on the
   first segment following the idle period, for example.  In practice,
   many implementations have keep-alive mechanisms that prevent such
   long idle periods [RFC-1323].

   Referring back to Figure 4, our proposed transaction extension
   results in a minimum exchange of 3 packets.  Segment #3, the final
   ACK segment, does not increase transaction latency, but in
   combination with the TIME-WAIT delay of K*RTO it ensures that the
   server side of the connection will be closed before a new transaction
   is issued for this same pair of ports.  It also provides an RTT
   measurement for the server.

   We may ask whether it would be possible to further reduce the TIME-



Braden                                                         [Page 14]

RFC 1379              Transaction TCP -- Concepts          November 1992


   WAIT delay.  We might set K to zero; alternatively, we might allow
   the client TCP to start a new transaction request while the
   connection was still in TIME-WAIT state, with the new initial SYN
   acting as an implied acknowledgment of the previous FIN.  Appendix A
   summarizes the issues raised by these alternatives, which we call
   "truncating" TIME-WAIT state, and suggests some possible solutions.
   Further study would be required, but these solutions appear to bend
   the theory and/or implementations of the TCP protocol farther than we
   wish to bend them.

   We therefore propose using formula [2] with K=8 and retaining the
   final ACK(FIN) transmission.  To raise the transaction rate,
   therefore, we require small values of RTO and U.

5.  CHOOSING A MONOTONIC SEQUENCE

   For simplicity, we want the monotonic sequence X used for shortening
   TIME-WAIT state to be identical to the monotonic sequence M for
   bypassing the 3-way handshake.  Calling the common space M, we will
   send an M value SEG.M in each TCP segment.  Upon receipt of an
   initial SYN segment, SEG.M will be compared with a per-host cached
   value to authenticate the SYN without a 3-way handshake; this is the
   TAO mechanism.  Upon receipt of a non-SYN segment, SEG.M will be
   compared with the current value in the connection control block and
   used to discard old duplicates.

   Note that the situation with TIME-WAIT state differs from that of
   bypassing 3-way handshakes in two ways: (a) TIME-WAIT requires
   duplicate detection on every segment vs. only on SYN segments, and
   (b) TIME-WAIT applies to a single connection vs. being global across
   all connections.  This section discusses possible choices for the
   common monotonic sequence.

   The SEG.M values must satisfy the following requirements.

   *    The values must be monotonic; this requirement is defined more
        precisely below.

   *    Their granularity must be fine-grained enough to support a high
        rate of transaction processing; the M clock must "tick" at least
        once between successive transactions.

   *    Their range (wrap-around time) must be great enough to allow a
        realistic MSL to be enforced by the network.

   The TCP spec calls for an MSL of 120 secs.  Since much of the
   Internet does not carefully enforce this limit, it would be safer to
   have an MSL at least an order of magnitude larger.  We set as an



Braden                                                         [Page 15]

RFC 1379              Transaction TCP -- Concepts          November 1992


   objective an MSL of at least 2000 seconds.  If there were no TIME-
   WAIT delay, the ultimate limit on transaction rate would be set by
   speed-of-light delays in the network and by the latency of host
   operating systems.  As the bottleneck problems with interfacing CPUs
   to gigabit LANs are solved, we can imagine transaction durations as
   short as 1 microsecond.  Therefore, we set an ultimate performance
   goal of TRmax at least 10**6 Tps.

   A particular connection between hosts A and B is identified by the
   local and remote TCP "sockets", i.e., by the quadruplet: {A, B,
   Port.A, Port.B}.  Imagine that each host keeps a count CC of the
   number of TCP connections it has initiated.  We can use this CC
   number to distinguish different incarnations of the same connection.
   Then a particular SEG.M value may be labeled implicitly by 6
   quantities: {A, B, Port.A, Port.B, CC, n}, where n is the byte offset
   of that segment within the connection incarnation.

   To bypass the 3-way handshake, we require thgt SEG.M values on
   successive SYN segments from a host A to a host B be monotone
   increasing.  If CC' > CC, then we require that:

       SEG.M(A,B,Port.A,Port.B,CC',0) >  SEG.M(A,B,Port.A,Port.B,CC,0)

   for any legal values of Port.A and Port.B.

   To delete old duplicates (allowing TIME-WAIT state to be shortened),
   we require that SEG.M values be disjoint across different
   incarnations of the same connection.   If CC' > CC then

       SEG.M(A,B,Port.A,Port.B,CC',n') > SEG.M(A,B,Port.A,Port.B,CC,n),

   for any non-negative integers n and n'.

   We now consider four different choices for the common monotonic
   space: RFC-1323 timestamps, TCP sequence numbers, the connection
   count, and 64-bit TCP sequence numbers.  The results are summarized
   in Table I.

   5.1 Cached Timestamps