Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions
RFC 3708

Network Working Group                                         E. Blanton
Request for Comments: 3708                             Purdue University
Category: Experimental                                         M. Allman
                                                                    ICIR
                                                           February 2004

      Using TCP Duplicate Selective Acknowledgement (DSACKs) and
         Stream Control Transmission Protocol (SCTP) Duplicate
        Transmission Sequence Numbers (TSNs) to Detect Spurious
                            Retransmissions

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   TCP and Stream Control Transmission Protocol (SCTP) provide
   notification of duplicate segment receipt through Duplicate Selective
   Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number
   (TSN) notification, respectively.  This document presents
   conservative methods of using this information to identify
   unnecessary retransmissions for various applications.

1.  Introduction

   TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate
   segment receipt through duplicate selective acknowledgment (DSACK)
   [RFC2883] and Duplicate TSN notifications, respectively.  Using this
   information, a TCP or SCTP sender can generally determine when a
   retransmission was sent in error.  This document presents two methods
   for using duplicate notifications.  The first method is simple and
   can be used for accounting applications.  The second method is a
   conservative algorithm to disambiguate unnecessary retransmissions
   from loss events for the purpose of undoing unnecessary congestion
   control changes.

Blanton & Allman              Experimental                      [Page 1]
RFC 3708           TCP DSACKs and SCTP Duplicate TSNs      February 2004

   This document is intended to outline reasonable and safe algorithms
   for detecting spurious retransmissions and discuss some of the
   considerations involved.  It is not intended to describe the only
   possible method for achieving the goal, although the guidelines in
   this document should be taken into consideration when designing
   alternate algorithms.  Additionally, this document does not outline
   what a TCP or SCTP sender may do after a spurious retransmission is
   detected.  A number of proposals have been developed (e.g.,
   [RFC3522], [SK03], [BDA03]), but it is not yet clear which of these
   proposals are appropriate.  In addition, they all rely on detecting
   spurious retransmits and so can share the algorithm specified in this
   document.

   Finally, we note that to simplify the text much of the following
   discussion is in terms of TCP DSACKs, while applying to both TCP and
   SCTP.

   Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Counting Duplicate Notifications

   For certain applications a straight count of duplicate notifications
   will suffice.  For instance, if a stack simply wants to know (for
   some reason) the number of spuriously retransmitted segments,
   counting all duplicate notifications for retransmitted segments
   should work well.  Another application of this strategy is to monitor
   and adapt transport algorithms so that the transport is not sending
   large amounts of spurious data into the network.  For instance,
   monitoring duplicate notifications could be used by the Early
   Retransmit [AAAB03] algorithm to determine whether fast
   retransmitting [RFC2581] segments with a lower than normal duplicate
   ACK threshold is working, or if segment reordering is causing
   spurious retransmits.

   More speculatively, duplicate notification has been proposed as an
   integral part of estimating TCP's total loss rate [AEO03] for the
   purposes of mitigating the impact of corruption-based losses on
   transport protocol performance.  [EOA03] proposes altering the
   transport's congestion response to the fraction of losses that are
   actually due to congestion by requiring the network to provide the
   corruption-based loss rate and making the transport sender estimate
   the total loss rate.  Duplicate notifications are a key part of
   estimating the total loss rate accurately [AEO03].