A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
obsoletes
- rfc-3517 — A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
Extracted elements (24)
NextSeg() rule (3) was changed from MAY (in RFC 3517) to SHOULD, reflecting the authors' and working group's view that uncertain retransmissions to sustain the ACK clock should be performed by default unless an implementor has a compelling reason to omit them.
The duplicate acknowledgment definition was broadened to include any ACK carrying new SACK data covering the range HighACK to HighData. This allows SACK information (rather than just cumulative ACK stagnation) to trigger loss recovery entry, enabling more accurate distinction between loss and reordering.
The pipe algorithm (using a Pipe variable to estimate in-flight bytes) is used instead of RFC 5681's congestion window algorithm during recovery, allowing TCP to use fundamentally different congestion control that better handles multiple losses from a single flight.
The RescueRxt variable was added to allow one extra optimistic retransmission per loss recovery entry, limited to at most one segment of no more than 1 SMSS. This prevents ACK clock stalling when loss occurs at the end of the window and no new data is available.
Implementers may optionally re-arm the RTO timer on each retransmission sent during recovery (rather than on each cumulative ACK advance per RFC 6298). This more conservative variant can prevent needless retransmissions when a loss event lasts longer than the RTO, but may not always be desirable.
The SACK-based algorithm is a conservative replacement for fast recovery (RFC 5681) and can be safely used alongside standard TCP congestion control. Alternate SACK-based loss recovery methods may be used as long as they follow RFC 5681 guidelines.
After an RTO, a SACK TCP sender SHOULD expunge SACK information (per RFC 2018) and MUST ignore prior SACK information when determining which data to retransmit. However, the sender SHOULD utilize all new SACK information made available during post-RTO loss recovery.
An incoming cumulative ACK for a sequence number greater than RecoveryPoint signals end of loss recovery and the recovery phase MUST be terminated. Scoreboard information for sequence numbers greater than the new HighACK SHOULD NOT be cleared when leaving recovery.
During loss recovery, if cwnd - pipe >= 1 SMSS, the sender SHOULD transmit one or more segments as directed by NextSeg(). HighRxt MUST be updated to the highest retransmitted sequence number when retransmitting below HighData (unless NextSeg() rule 4 was used).
If an RTO occurs during loss recovery, RecoveryPoint MUST be set to HighData, the new RecoveryPoint MUST be preserved, and the loss recovery algorithm MUST be terminated. A new recovery phase MUST NOT be initiated until HighACK >= the new RecoveryPoint.
NextSeg() MUST return a lost segment (rule 1: smallest unSACKed S2 > HighRxt, below highest SACK coverage, where IsLost returns true) if one exists; otherwise MUST return new unsent data if available (rule 2); otherwise SHOULD return an unconfirmed-lost segment (rule 3); otherwise SHOULD return a single rescue retransmission of the highest outstanding unSACKed segment (rule 4).
SACKed data MUST NOT be removed from TCP's retransmission buffer until the data is cumulatively acknowledged, because SACK information is advisory and the receiver may renege.
SetPipe() MUST set the 'pipe' variable to an estimate of octets currently in transit between sender and receiver, by traversing sequence space from HighACK to HighData. Pipe is incremented for each non-SACKed octet where IsLost returns false, and again for each octet at or below HighRxt (retransmitted octets are counted twice).
Upon receipt of any ACK containing SACK information, the scoreboard MUST be updated via Update(). If the ACK is cumulative, DupAcks MUST be reset to zero.
When entering fast retransmit and loss recovery: ssthresh = cwnd = FlightSize / 2, per RFC 5681. Segments sent via Limited Transmit MUST NOT be counted in FlightSize for this calculation.
A 'duplicate acknowledgment' is defined as a segment arriving with a SACK block identifying previously unacknowledged and un-SACKed octets between HighACK and HighData. Unlike RFC 5681, an ACK carrying new SACK data counts as a duplicate ACK even if it advances the cumulative acknowledgment point or carries new data.
DupThresh is set to 3 duplicate acknowledgments as the threshold for triggering retransmission, per RFC 5681. Implementers should consult updates to RFC 5681 for the current value or method of determining DupThresh.
IsLost(SeqNum) returns true when either DupThresh discontiguous SACKed sequences have arrived above SeqNum, or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than SeqNum have been SACKed. This improvement over RFC 3517 handles segments smaller than SMSS.
RescueRxt enables a single 'rescue' retransmission per loss recovery entry when all other NextSeg() rules fail but outstanding unSACKed data exists. This retransmits the highest outstanding unSACKed sequence number to sustain the ACK clock when loss occurs at the end of the window. HighRxt MUST NOT be updated for this retransmission.
The SACK-based algorithm maintains six sender variables: HighACK (highest cumulatively ACKed byte), HighData (highest transmitted sequence number), HighRxt (highest retransmitted sequence number during current recovery), RescueRxt (highest optimistically retransmitted sequence number), Pipe (estimated bytes outstanding in network), and DupAcks (duplicate acknowledgments since last cumulative ACK).
The scoreboard is a per-connection data structure used to store incoming SACK information. It tracks which octets have been cumulatively ACKed or SACKed, and must support Update(), IsLost(), SetPipe(), and NextSeg() operations. Implementations typically manage this as sequence number ranges rather than individual octets.
SACK-based loss recovery is more robust than standard TCP against attackers forging duplicate ACKs to force cwnd reduction, because SACK provides an additional check on ACK legitimacy. While not fool-proof, SACK offers meaningful protection against this attack vector.
SACK-based loss recovery mitigates a blind in-window attack variant (per RFC 5961 and CPNI309) where spoofed out-of-window data causes duplicate cumulative ACKs. Requiring SACK information to trigger loss recovery means attacker-induced duplicate ACKs without corresponding in-window SACK data will not trigger a recovery phase.
Loss recovery is entered when DupAcks >= DupThresh (step 1) or IsLost(HighACK+1) returns true (step 2). Entry sets RecoveryPoint = HighData, reduces ssthresh and cwnd to FlightSize/2, retransmits first presumed-dropped segment, and runs SetPipe(). Recovery ends when a cumulative ACK exceeds RecoveryPoint.