Summary

  • A duplicate notice can show that one retransmission was unnecessary without showing that every segment in the same window arrived safely.
  • RFC 3708 permits a congestion-state undo conclusion only after all retransmitted units in the previous window are acknowledged and marked duplicate, and only if its stop conditions have not fired.

The revealing case is almost a trap. A sender retransmits segments N and N+1. Only N was lost; N+1 had merely been delayed. When the receiver reports N+1 as a duplicate, the sender has learned something useful: that resend of N+1 was unnecessary. It has not learned that the network lost nothing. Segment N is still a real loss signal, so restoring the congestion state for the whole window would erase evidence that still matters.

That distinction is the point of RFC 3708. Published as an Experimental memo in February 2004, it describes conservative ways to use duplicate notifications from TCP's Duplicate Selective Acknowledgment (DSACK) and SCTP's duplicate Transmission Sequence Number (TSN) reports. The document offers two different uses. A stack may simply count duplicate notices for accounting or monitoring. A sender considering whether to undo congestion-control changes needs the more demanding disambiguation algorithm.

The algorithm asks first whether the reported sequence range or TSN was retransmitted. If it was retransmitted more than once in the window, processing stops; the sender does not restore the previous congestion state. If the sender never retransmitted it, the duplicate can instead indicate that the network replicated a packet. RFC 3708 then stops using this algorithm for the rest of that connection: later duplicate reports would be harder to interpret as evidence of the sender's own unnecessary resends.

Even a report that matches one retransmission is not enough. The sender checks every retransmitted segment or chunk in the previous data window. Only when all have been acknowledged and marked duplicate does RFC 3708 conclude that all those retransmissions were spurious and that the window had no loss. If one retransmission remains unmarked, the algorithm draws no conclusion from that notice. A further guard handles an empty TCP SACK scoreboard and a DSACK beginning at SND.UNA, a pattern consistent with an entire window of ACKs having been lost. In that case, continued rate reduction is the conservative choice.

The algorithm therefore needs memory: beyond ordinary SACK recovery state, an implementation tracks which sequence numbers or TSNs have already been acknowledged as duplicates. That cost buys a carefully bounded inference, not certainty about a receiver's honesty or every path event. RFC 3708's security section warns that a receiver could mislabel out-of-order data as duplicates during genuine loss, causing an unsafe congestion-state change.

RFC 2883 defines how TCP receivers encode duplicate data in D-SACK blocks; it does not tell senders how to respond. RFC 3522's Eifel algorithm follows a different evidentiary path: TCP timestamps can detect a spurious retransmission faster, at the cost of carrying the timestamp option in every packet. RFC 3708 is slower, but its lesson is wider than a single packet: identify the needless resend, then separately ask whether the evidence clears the whole window. It does not prescribe what action to take after detection.

Sources: RFC 3708, RFC 3708 status, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.