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