rfc1072.txt

RFC 的详细文档！

3. TCP SELECTIVE ACKNOWLEDGMENT OPTIONS

   To minimize the impact on the TCP protocol, the selective
   acknowledgment extension uses the form of two new TCP options. The
   first is an enabling option, "SACK-permitted", that may be sent in a
   SYN segment to indicate that the the SACK option may be used once the
   connection is established.  The other is the SACK option itself,
   which may be sent over an established connection once permission has
   been given by SACK-permitted.

   The SACK option is to be included in a segment sent from a TCP that
   is receiving data to the TCP that is sending that data; we will refer
   to these TCP's as the data receiver and the data sender,
   respectively.  We will consider a particular simplex data flow; any
   data flowing in the reverse direction over the same connection can be
   treated independently.

3.1  SACK-Permitted Option

      This two-byte option may be sent in a SYN by a TCP that has been
      extended to receive (and presumably process) the SACK option once
      the connection has opened.










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


      TCP Sack-Permitted Option:

      Kind: 4

             +---------+---------+
             | Kind=4  | Length=2|
             +---------+---------+

3.2  SACK Option

      The SACK option is to be used to convey extended acknowledgment
      information over an established connection.  Specifically, it is
      to be sent by a data receiver to inform the data transmitter of
      non-contiguous blocks of data that have been received and queued.
      The data receiver is awaiting the receipt of data in later
      retransmissions to fill the gaps in sequence space between these
      blocks.  At that time, the data receiver will acknowledge the data
      normally by advancing the left window edge in the Acknowledgment
      Number field of the TCP header.

      It is important to understand that the SACK option will not change
      the meaning of the Acknowledgment Number field, whose value will
      still specify the left window edge, i.e., one byte beyond the last
      sequence number of fully-received data.  The SACK option is
      advisory; if it is ignored, TCP acknowledgments will continue to
      function as specified in the protocol.

      However, SACK will provide additional information that the data
      transmitter can use to optimize retransmissions.  The TCP data
      receiver may include the SACK option in an acknowledgment segment
      whenever it has data that is queued and unacknowledged.  Of
      course, the SACK option may be sent only when the TCP has received
      the SACK-permitted option in the SYN segment for that connection.

      TCP SACK Option:

      Kind: 5

      Length: Variable


       +--------+--------+--------+--------+--------+--------+...---+
       | Kind=5 | Length | Relative Origin |   Block Size    |      |
       +--------+--------+--------+--------+--------+--------+...---+


      This option contains a list of the blocks of contiguous sequence
      space occupied by data that has been received and queued within



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


      the window.  Each block is contiguous and isolated; that is, the
      octets just below the block,

             Acknowledgment Number + Relative Origin -1,

      and just above the block,

             Acknowledgment Number + Relative Origin + Block Size,

      have not been received.

      Each contiguous block of data queued at the receiver is defined in
      the SACK option by two 16-bit integers:


      *    Relative Origin

           This is the first sequence number of this block, relative to
           the Acknowledgment Number field in the TCP header (i.e.,
           relative to the data receiver's left window edge).


      *    Block Size

           This is the size in octets of this block of contiguous data.


      A SACK option that specifies n blocks will have a length of 4*n+2
      octets, so the 44 bytes available for TCP options can specify a
      maximum of 10 blocks.  Of course, if other TCP options are
      introduced, they will compete for the 44 bytes, and the limit of
      10 may be reduced in particular segments.

      There is no requirement on the order in which blocks can appear in
      a single SACK option.

         Note: requiring that the blocks be ordered would allow a
         slightly more efficient algorithm in the transmitter; however,
         this does not seem to be an important optimization.

3.3  SACK with Window Scaling

      If window scaling is in effect, then 16 bits may not be sufficient
      for the SACK option fields that define the origin and length of a
      block.  There are two possible ways to handle this:

      (1)  Expand the SACK origin and length fields to 24 or 32 bits.




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


      (2)  Scale the SACK fields by the same factor as the window.


      The first alternative would significantly reduce the number of
      blocks possible in a SACK option; therefore, we have chosen the
      second alternative, scaling the SACK information as well as the
      window.

      Scaling the SACK information introduces some loss of precision,
      since a SACK option must report queued data blocks whose origins
      and lengths are multiples of the window scale factor rcv.scale.
      These reported blocks must be equal to or smaller than the actual
      blocks of queued data.

      Specifically, suppose that the receiver has a contiguous block of
      queued data that occupies sequence numbers L, L+1, ... L+N-1, and
      that the window scale factor is S = rcv.scale.  Then the
      corresponding block that will be reported in a SACK option will
      be:

         Relative Origin = int((L+S-1)/S)

         Block Size = int((L+N)/S) - (Relative Origin)

      where the function int(x) returns the greatest integer contained
      in x.

      The resulting loss of precision is not a serious problem for the
      sender.  If the data-sending TCP keeps track of the boundaries of
      all segments in its retransmission queue, it will generally be
      able to infer from the imprecise SACK data which full segments
      don't need to be retransmitted.  This will fail only if S is
      larger than the maximum segment size, in which case some segments
      may be retransmitted unnecessarily.  If the sending TCP does not
      keep track of transmitted segment boundaries, the imprecision of
      the scaled SACK quantities will only result in retransmitting a
      small amount of unneeded sequence space.  On the average, the data
      sender will unnecessarily retransmit J*S bytes of the sequence
      space for each SACK received; here J is the number of blocks
      reported in the SACK, and S = snd.scale.

3.4  SACK Option Examples

      Assume the left window edge is 5000 and that the data transmitter
      sends a burst of 8 segments, each containing 500 data bytes.
      Unless specified otherwise, we assume that the scale factor S = 1.





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


           Case 1: The first 4 segments are received but the last 4 are
           dropped.

           The data receiver will return a normal TCP ACK segment
           acknowledging sequence number 7000, with no SACK option.


           Case 2:  The first segment is dropped but the remaining 7 are
           received.

           The data receiver will return a TCP ACK segment that
           acknowledges sequence number 5000 and contains a SACK option
           specifying one block of queued data:

                   Relative Origin = 500;  Block Size = 3500


           Case 3:  The 2nd, 4th, 6th, and 8th (last) segments are
           dropped.

           The data receiver will return a TCP ACK segment that
           acknowledges sequence number 5500 and contains a SACK option
           specifying the 3 blocks:

                   Relative Origin =  500;  Block Size = 500
                   Relative Origin = 1500;  Block Size = 500
                   Relative Origin = 2500;  Block Size = 500


           Case 4: Same as Case 3, except Scale Factor S = 16.

           The SACK option would specify the 3 scaled blocks:

                   Relative Origin =   32;  Block Size = 30
                   Relative Origin =   94;  Block Size = 31
                   Relative Origin =  157;  Block Size = 30

           These three reported blocks have sequence numbers 512 through
           991, 1504 through 1999, and 2512 through 2992, respectively.


3.5  Generating the SACK Option

      Let us assume that the data receiver maintains a queue of valid
      segments that it has neither passed to the user nor acknowledged
      because of earlier missing data, and that this queue is ordered by
      starting sequence number.  Computation of the SACK option can be
      done with one pass down this queue.  Segments that occupy



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


      contiguous sequence space are aggregated into a single SACK block,
      and each gap in the sequence space (except a gap that is
      terminated by the right window edge) triggers the start of a new
      SACK block.  If this algorithm defines more than 10 blocks, only
      the first 10 can be included in the option.

3.6  Interpreting the SACK Option

      The data transmitter is assumed to have a retransmission queue
      that contains the segments that have been transmitted but not yet
      acknowledged, in sequence-number order.  If the data transmitter
      performs re-packetization before retransmission, the block
      boundaries in a SACK option that it receives may not fall on
      boundaries of segments in the retransmission queue; however, this
      does not pose a serious difficulty for the transmitter.

      Let us suppose that for each segment in the retransmission queue
      there is a (new) flag bit "ACK'd", to be used to indicate that
      this particular segment has been entirely acknowledged.  When a
      segment is first transmitted, it will be entered into the
      retransmission queue with its ACK'd bit off.  If the ACK'd bit is
      subsequently turned on (as the result of processing a received
      SACK option), the data transmitter will skip this segment during
      any later retransmission.  However, the segment will not be
      dequeued and its buffer freed until the left window edge is
      advanced over it.

      When an acknowledgment segment arrives containing a SACK option,
      the data transmitter will turn on the ACK'd bits for segments that
      have been selectively acknowleged.  More specifically, for each
      block in the SACK option, the data transmitter will turn on the
      ACK'd flags for all segments in the retransmission queue that are
      wholly contained within that block.  This requires straightforward
      sequence number comparisons.