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.

   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].