Summary

  • RFC 3522 uses TCP timestamps and the first acceptable ACK during loss recovery to decide retrospectively whether the sender entered recovery unnecessarily. The classification can arrive quickly, but it does not itself restore the congestion window, slow-start threshold, retransmission timer or application performance.
  • A defensible receipt preserves the original transmission, recovery trigger, immutable retransmission timestamp, ACK evidence, ambiguity exits, saved pre-recovery state, response action, later network evidence and application outcome. “Spurious” is a diagnosis, not a rollback transaction.

TCP had already acted. A timeout or duplicate-ACK threshold had caused a retransmission. Congestion control had reduced the sender’s operating range. Only then did the acknowledgment arrive with evidence that the original data had not been lost at all.

RFC 3522, published in April 2003 as Experimental, gives that evidence a disciplined interpretation. The Eifel detection algorithm uses the TCP Timestamps option to eliminate retransmission ambiguity: after a retransmit, an ordinary acknowledgment number cannot say whether it responds to the original transmission or the copy. An echoed timestamp can.

The document’s title matters. This is a detection algorithm. Its response step is literally a placeholder that does nothing. The difference between detecting a false premise and reversing an action taken under that premise is the operational heart of the specification.

The first acceptable ACK is a retrospective witness

At the start of a loss-recovery episode, the sender clears SpuriousRecovery and stores RetransmitTS, the Timestamp Value carried by the timeout-based or fast retransmit that initiated recovery. That stored value must not be overwritten by later retransmissions as recovery proceeds.

The sender then waits for the first acceptable ACK—one that acknowledges previously unacknowledged data. If its Timestamp Echo Reply is smaller than RetransmitTS, the ACK must correspond to an original transmission that preceded the retransmit. Subject to the algorithm’s later ambiguity checks, the sender can conclude that it entered loss recovery unnecessarily.

This is stronger than a guess based on elapsed time. It is a correlation between a returned marker and a particular transmission history. It also arrives soon enough to avoid the chain of go-back-N retransmissions that can follow a spurious timeout.

But it remains retrospective. The loss trigger fired, the copy left and control state changed before the witness arrived.

False loss has more than one cause

A sudden increase in delay can let the retransmission timer expire before an acceptable ACK arrives. Packet reordering can produce enough duplicate ACKs to trigger fast retransmit even though no data disappeared. Duplication of packets or acknowledgments can create the same visible pattern.

Those mechanisms share a consequence but not a cause. A spurious fast retransmit commonly sends one useless copy and halves the congestion window. A spurious timeout can force slow start, then provoke additional needless retransmissions as delayed acknowledgments for originals arrive.

Eifel classifies whether recovery was unnecessary; it does not uniquely attribute the underlying path event. An older echoed timestamp does not prove “reordering,” identify a radio handover, measure congestion or assign fault to a network domain.

Even the word timeout needs care. RFC 3522 distinguishes a “fast timeout” that merely beats the duplicate-ACK path. If a segment really was lost, recovery was justified and the event is not spurious simply because waiting longer would have produced a fast retransmit.

Equality is not affirmative evidence

The base algorithm asks whether the echoed timestamp is smaller than RetransmitTS, not smaller than or equal. A coarse timestamp clock or a fast path can give an original and retransmit the same timestamp value. In that case, the conservative result is not to declare spurious recovery.

That detail is useful beyond TCP. A comparison rule defines the evidentiary burden. Treating equality as a positive match would increase the number of reversals made on ambiguous evidence.

The receipt should therefore keep both raw timestamp values, the clock granularity, the comparison operator and the branch taken. A dashboard label such as “Eifel checked” cannot show whether evidence was positive, negative or merely inconclusive.

Losing every ACK creates a dangerous resemblance

Suppose the oldest outstanding segment reached the receiver, but the entire flight of ACKs was lost. The sender must eventually time out and retransmit. That retransmit is unnecessary in a narrow byte-delivery sense, yet the timeout is unavoidable and reducing the window may be an appropriate response to congestion on the ACK path.

A receiver following the historical timestamp rules can echo the timestamp of the last in-sequence original when the duplicate arrives. The value can be smaller than the retransmission timestamp, superficially resembling spurious recovery.

RFC 3522’s step 5 uses DSACK evidence and the question of whether the acceptable ACK covers all outstanding data to terminate rather than reverse in this corner case. The algorithm is not simply echo < retransmit; its conservative exits are part of the result.

An implementation receipt that logs only the final SpuriousRecovery value discards why the classification was permitted or withheld.

A receiver can manufacture persuasive evidence

An uncooperative receiver could forge echoed timestamps and make a genuine retransmission appear unnecessary. RFC 3522 therefore describes a safe variant. Instead of storing only the retransmit timestamp, the sender stores timestamps for outstanding original transmissions and accepts evidence only when the returned value equals the corresponding original timestamp.

The safer proof costs state. It is more sensitive to ACK loss and reordering because it relies on the particular acknowledgment for the original. Coarse timestamp granularity can also help a receiver guess a missing value.

Security is therefore not a label attached to “timestamps enabled.” It is a trade among stored secrets, granularity, receiver behavior and evidence availability. The safe variant narrows what can be believed while increasing what the sender must retain.

Detection cannot reconstruct unsaved state

The (RESP) step in RFC 3522 says to do nothing. The document notes possible goals—restore congestion-control state, avoid needless go-back-N retransmissions, adapt the duplicate-ACK threshold or adjust RTT estimators—but leaves them outside scope.

RFC 4015 later specifies the Eifel response algorithm. Response is separate because it needs different evidence and preparation. If the sender may restore a prior congestion window or slow-start threshold, it needs their earlier values. Once overwritten without a receipt, those values cannot be derived from the fact that recovery was spurious.

Rollback also needs a safety boundary. A retransmission can be unnecessary while another segment in the same flight was genuinely lost. RFC 3708’s DSACK discussion makes the mixed case explicit: evidence that one copy was needless does not prove that all congestion response was mistaken.

A detector is entitled to classify the event it observed. It is not automatically entitled to restore every variable affected by the wider episode.

Later success does not erase the intervention

After detection and response, the sender may transmit new data, adapt an RTO estimator or return toward a saved window. Each action needs a receipt: variables before recovery, variables after the trigger, detector output, response rule, restored values and later adjustments.

Then the network still has to deliver the byte stream. A restored congestion window does not prove that reordering stopped, capacity remained constant or the application completed. Later standards such as the TCP roadmap, RACK-TLP and CUBIC retain the distinction between detecting a spurious loss signal and responding safely in a changing network.

The final measure belongs to the promise. If the promise is byte delivery, record acknowledged ranges. If it is latency, measure the relevant interval. If it is an application transaction, keep an authenticated application receipt. A timestamp echo cannot inherit those meanings.

Build a reversible-loss receipt

Record whether timestamps were negotiated and how their clock advances. Preserve the original byte range and timestamp, the loss trigger, duplicate-ACK count or timer state, and every congestion-control value before the trigger.

Hash or otherwise bind the first retransmit and its immutable RetransmitTS. Keep the first acceptable ACK, its acknowledged range, Timestamp Echo Reply, DSACK blocks and the exact step-5 decision. Mark whether the base or safe variant was used.

For response, record the algorithm and version, which variables were saved, which were restored, which were deliberately retained and why. Correlate subsequent real loss, reordering, retransmission and timer changes. Finish with observed delivery and application outcome.

The chain should survive implementation restart and telemetry sampling. A summary counter for “spurious retransmissions” is useful for trend analysis but cannot reconstruct a disputed restoration without the per-event state.

Evidence boundary

This Article identifies no TCP implementation, operating system, vendor, operator, access network, path, receiver, user, flow, incident or deployment. It makes no claim about adoption, timestamp use, reordering, loss, performance, battery use, security or business outcome in a current system.

RFC 3522 is treated as an April 2003 Experimental document, not an Internet Standard. RFC 4015, RFC 5681, RFC 5682, RFC 6298 and RFC 7323 retain their own status and scope. RFC 9438, RFC 8985 and RFC 9002 are later comparison evidence, not proof of RFC 3522 implementation.

Heng Lu’s authority and running-code notes are disclosed editorial lenses. They support separating a formal signal from operational state and observed outcome; they are not sources of IETF intent.

The narrow conclusion is enough: the ACK can change the diagnosis without changing the state, and no system should report a restored outcome until a separate response has acted and its effect has been observed.

Sources