datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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

Document type: RFC - Proposed Standard (July 2000; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 2883 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                           S. Floyd
Request for Comments: 2883                                         ACIRI
Category: Standards Track                                     J. Mahdavi
                                                                  Novell
                                                               M. Mathis
                                        Pittsburgh Supercomputing Center
                                                             M. Podolsky
                                                             UC Berkeley
                                                               July 2000

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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This note defines an extension of the Selective Acknowledgement
   (SACK) Option [RFC2018] for TCP.  RFC 2018 specified the use of the
   SACK option for acknowledging out-of-sequence data not covered by
   TCP's cumulative acknowledgement field.  This note extends RFC 2018
   by specifying the use of the SACK option for acknowledging duplicate
   packets.  This note suggests that when duplicate packets are
   received, the first block of the SACK option field can be used to
   report the sequence numbers of the packet that triggered the
   acknowledgement.  This extension to the SACK option allows the TCP
   sender to infer the order of packets received at the receiver,
   allowing the sender to infer when it has unnecessarily retransmitted
   a packet.  A TCP sender could then use this information for more
   robust operation in an environment of reordered packets [BPS99], ACK
   loss, packet replication, and/or early retransmit timeouts.

1.  Conventions and Acronyms

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [B97].

Floyd, et al.               Standards Track                     [Page 1]
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                     [Page 2]
RFC 2883                     SACK Extension                    July 2000

3. The Sack Option Format as defined in RFC 2018

   The SACK option as defined in RFC 2018 is as follows:

                            +--------+--------+
                            | Kind=5 | Length |
          +--------+--------+--------+--------+
          |      Left Edge of 1st Block       |
          +--------+--------+--------+--------+
          |      Right Edge of 1st Block      |
          +--------+--------+--------+--------+

[include full document text]