RFC 2883 (rfc2883) - Page 1 of 17

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

Alternative Format: Original Text Document
Next >
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 [RFC 2018] 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
Next >