fast retransmit
Suppose you are reading a letter aloud to a friend over the phone, one numbered page at a time, and they must say 'got page 5' after each. If a page goes missing in the post, the slow way to notice is to wait for a stopwatch to run out. The fast way: your friend keeps saying 'still waiting for page 5' every time a LATER page arrives out of order — and after the third such complaint you do not wait for the clock, you just resend page 5 immediately. Fast retransmit is exactly that shortcut for TCP.
Here is the mechanism. A TCP receiver always acknowledges the highest in-order byte it has — so if segment 5 is lost but 6, 7, and 8 arrive, the receiver keeps re-acknowledging 'I still need 5' for each of them. The sender sees these duplicate acknowledgments (dup ACKs). One or two might just be reordering, but three duplicate ACKs for the same point (a triple dup ACK, meaning the sender has seen the same ACK number four times) is a strong sign that one specific segment was dropped while later ones got through. So the sender retransmits that one missing segment at once, without waiting for the retransmission timeout to expire.
Why it matters: the retransmission timeout is deliberately conservative — often a fair fraction of a second or more — to avoid resending packets that are merely slow. Waiting that long for every loss would make TCP feel sluggish. Fast retransmit lets the sender recover from an isolated loss in about one round-trip time instead, which is a huge speedup on interactive and bulk transfers alike. It works hand in hand with fast recovery, which decides what to do with the congestion window after the quick retransmit.
The sender sends segments 5, 6, 7, 8, 9. Segment 5 is lost. The receiver gets 6, 7, 8, 9 and sends back four ACKs all saying 'expecting 5'. The first is the original; the second, third, and fourth are duplicates. On the third duplicate, the sender retransmits segment 5 instantly — perhaps 300 ms before its retransmission timer would have fired.
Three duplicate ACKs trigger an immediate resend, recovering in one RTT instead of waiting for the timeout.
Three duplicate ACKs is a heuristic, not proof of loss — a packet may simply have been badly reordered by the network. The threshold of three is a deliberate trade-off: low enough to react fast, high enough that mild reordering does not trigger needless retransmissions. Selective acknowledgment (SACK) makes this far more precise by naming exactly which segments arrived.