RFC 2883 (rfc2883) - Page 2 of 17


An Extension to the Selective Acknowledgement (SACK) Option for TCP



Alternative Format: Original Text Document



RFC 2883                     SACK Extension                    July 2000


2. Introduction

   The Selective Acknowledgement (SACK) option defined in RFC 2018 is
   used by the TCP data receiver to acknowledge non-contiguous blocks of
   data not covered by the Cumulative Acknowledgement field.  However,
   RFC 2018 does not specify the use of the SACK option when duplicate
   segments are received.  This note specifies the use of the SACK
   option when acknowledging the receipt of a duplicate packet [F99].
   We use the term D-SACK (for duplicate-SACK) to refer to a SACK block
   that reports a duplicate segment.

   This document does not make any changes to TCP's use of the
   cumulative acknowledgement field, or to the TCP receiver's decision
   of *when* to send an acknowledgement packet.  This document only
   concerns the contents of the SACK option when an acknowledgement is
   sent.

   This extension is compatible with current implementations of the SACK
   option in TCP.  That is, if one of the TCP end-nodes does not
   implement this D-SACK extension and the other TCP end-node does, we
   believe that this use of the D-SACK extension by one of the end nodes
   will not introduce problems.

   The use of D-SACK does not require separate negotiation between a TCP
   sender and receiver that have already negotiated SACK capability.
   The absence of separate negotiation for D-SACK means that the TCP
   receiver could send D-SACK blocks when the TCP sender does not
   understand this extension to SACK.  In this case, the TCP sender will
   simply discard any D-SACK blocks, and process the other SACK blocks
   in the SACK option field as it normally would.





















Floyd, et al.               Standards Track