TCP Selective Acknowledgment Options
RFC 2018

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                        M. Mathis
Request for Comments: 2018                                  J. Mahdavi
Category: Standards Track                                          PSC
                                                              S. Floyd
                                                                  LBNL
                                                            A. Romanow
                                                      Sun Microsystems
                                                          October 1996

                  TCP Selective Acknowledgment Options

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.

Abstract

   TCP may experience poor performance when multiple packets are lost
   from one window of data.   With the limited information available
   from cumulative acknowledgments, a TCP sender can only learn about a
   single lost packet per round trip time.  An aggressive sender could
   choose to retransmit packets early, but such retransmitted segments
   may have already been successfully received.

   A Selective Acknowledgment (SACK) mechanism, combined with a
   selective repeat retransmission policy, can help to overcome these
   limitations.  The receiving TCP sends back SACK packets to the sender
   informing the sender of data that has been received. The sender can
   then retransmit only the missing data segments.

   This memo proposes an implementation of SACK and discusses its
   performance and related issues.

Acknowledgements

   Much of the text in this document is taken directly from RFC1072 "TCP
   Extensions for Long-Delay Paths" by Bob Braden and Van Jacobson.  The
   authors would like to thank Kevin Fall (LBNL), Christian Huitema
   (INRIA), Van Jacobson (LBNL), Greg Miller (MITRE), Greg Minshall
   (Ipsilon), Lixia Zhang (XEROX PARC and UCLA), Dave Borman (BSDI),
   Allison Mankin (ISI) and others for their review and constructive
   comments.

Mathis, et. al.             Standards Track                     [Page 1]
RFC 2018         TCP Selective Acknowledgement Options      October 1996

1.  Introduction

   Multiple packet losses from a window of data can have a catastrophic
   effect on TCP throughput. TCP [Postel81] uses a cumulative
   acknowledgment scheme in which received segments that are not at the
   left edge of the receive window are not acknowledged.  This forces
   the sender to either wait a roundtrip time to find out about each
   lost packet, or to unnecessarily retransmit segments which have been
   correctly received [Fall95].  With the cumulative acknowledgment
   scheme, multiple dropped segments generally cause TCP to lose its
   ACK-based clock, reducing overall throughput.

   Selective Acknowledgment (SACK) is a strategy which corrects this
   behavior in the face of multiple dropped segments.  With selective
   acknowledgments, the data receiver can inform the sender about all
   segments that have arrived successfully, so the sender need
   retransmit only the segments that have actually been lost.

   Several transport protocols, including NETBLT [Clark87], XTP
   [Strayer92], RDP [Velten84], NADIR [Huitema81], and VMTP [Cheriton88]
   have used selective acknowledgment.  There is some empirical evidence
   in favor of selective acknowledgments -- simple experiments with RDP
   have shown that disabling the selective acknowledgment facility
   greatly increases the number of retransmitted segments over a lossy,
   high-delay Internet path [Partridge87]. A recent simulation study by
   Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of TCP
   with SACK over the non-SACK Tahoe and Reno TCP implementations.

   RFC1072 [VJ88] describes one possible implementation of SACK options
   for TCP.  Unfortunately, it has never been deployed in the Internet,
   as there was disagreement about how SACK options should be used in
   conjunction with the TCP window shift option (initially described
   RFC1072 and revised in [Jacobson92]).

   We propose slight modifications to the SACK options as proposed in
   RFC1072.  Specifically, sending a selective acknowledgment for the
   most recently received data reduces the need for long SACK options
   [Keshav94, Mathis95].  In addition, the SACK option now carries full
   32 bit sequence numbers.  These two modifications represent the only
   changes to the proposal in RFC1072.  They make SACK easier to
   implement and address concerns about robustness.

   The selective acknowledgment extension uses two TCP options. The
   first is an enabling option, "SACK-permitted", which may be sent in a
   SYN segment to indicate that the SACK option can be used once the