Why does losing the last segment of a TCP response often stall it for a whole RTO, while a mid-stream loss recovers in about one round trip?

## Fast retransmit depends on what comes after the loss A TCP receiver acknowledges **cumulatively**: its ACK names the next byte it expects. When one segment goes missing and later ones arrive, every later arrival makes the receiver repeat the same ACK, a **duplicate ACK**. Under RFC 5681, the sender treats the **third** duplicate ACK as evidence of loss and retransmits at once: **fast retransmit**. The repair therefore costs roughly one round trip. The key word is *later*. Duplicate ACKs are manufactured by segments that follow the hole. No followers, no duplicates. ## The tail case, traced Consider a response sent as ten segments: 1. **Segment 5 lost.** Segments 6 to 10 arrive, producing five duplicate ACKs. The third triggers fast retransmit; the loss is repaired about one round trip later. 2. **Segment 8 lost.** Only 9 and 10 follow it, so just two duplicate ACKs arrive. The threshold of three is never met. 3. **Segment 10 lost.** Nothing follows it. The receiver has nothing new to acknowledge, so the sender hears silence. In cases 2 and 3 the sender falls back to the **retransmission timer**. RFC 6298 computes the RTO from measured round-trip times and says it SHOULD be at least **1 second**, often many times the actual RTT. After the timeout the sender also resets its congestion window to one segment under RFC 5681. RFC 5681 recommends Limited Transmit (RFC 3042), sending new data on the first two duplicate ACKs to generate more of them, but at the end of a response there is usually no new data to send. ## What the stall costs RFC 8985 §3.2 gives a worked example: a sender transmits 100 segments and only the last three are lost. Without a probe, the RTO expires, the sender retransmits the first missing segment and slow-starts from a window of one. The whole transfer takes **three RTTs plus one RTO**. Had the same losses happened three segments earlier, fast recovery would have repaired them within one round trip and the window would not have been reset. The pattern bites hardest on: - **short request-response exchanges**, where the entire response is a tail; - **small windows**, where fewer than four segments are ever in flight; - **application-limited senders** that pause after each burst of data. ## The tail loss probe **RACK-TLP** (RFC 8985, Standards Track) adds a timer that fires well before the RTO. It **requires SACK** (RFC 2018), because it reads the receiver's selective acknowledgments to find holes. The probe timeout (PTO) is chosen as follows: - with an RTT estimate, `PTO = 2 * SRTT`, since an ACK normally arrives within one SRTT and exactly one would risk spurious probes; - when only one segment is in flight, the sender MAY add an allowance for a delayed ACK; - with no RTT estimate yet, `PTO = 1 second`, matching RFC 6298's initial RTO; - if the RTO would fire sooner than the PTO, the probe is sent at the RTO time instead. When the PTO fires, the sender SHOULD send **previously unsent data** if it has any and the receive window allows; otherwise it retransmits the **highest-sequenced segment** sent so far. At most one probe may be outstanding, and after sending one the sender re-arms the RTO timer, so the timeout remains the last resort. ## Why the probe works The probe gives the receiver something to acknowledge. Its SACK shows the receiver holds the end of the flight, which exposes every earlier hole. In the 100-segment example, the probe retransmits segment 100; the SACK for it lets RACK detect that 98 and 99 were lost and trigger fast recovery. Total time: **four RTTs**, with the congestion window only partly reduced rather than reset. If the probe is lost too, RTO recovery happens as before. | Situation | What repairs it | Typical cost | |---|---|---| | Loss with at least three segments behind it | Fast retransmit on duplicate ACKs | About one RTT | | Tail loss, no probe | Retransmission timer | One RTO, normally at least 1 s, plus slow start from one segment | | Tail loss with RACK-TLP | Tail loss probe, then fast recovery | About 2 x SRTT before the probe, then about one RTT | ## Misconceptions - Fast retransmit cannot repair every single loss in one round trip; it needs followers. - The probe does not wait for the RTO; it fires after about two smoothed RTTs. - RACK-TLP defines no new TCP option; it is sender-side logic that relies on SACK.