how/network

TCP retransmission and fast retransmit

What does TCP do when a packet is lost? It does not wait long. Three "duplicate ACKs" in a row, and it resends right away without waiting for the timer.

The network is not perfect: packets sometimes get lost (a full queue on a router, a Wi-Fi glitch, a broken link). And TCP promises "reliable delivery," so it has to recover losses somehow. How exactly?

TCP has two mechanisms for resending:

RTO retransmit, a timer. If the ACK for a packet does not arrive within a certain time (RTO = retransmission timeout, usually ~200ms +), the packet is considered lost and gets resent
Fast retransmit, a fast reaction through dup ACKs. If you receive 3 ACKs in a row with the same number, it is a signal "I have a gap, please resend," and the client resends immediately, without waiting for RTO

Press ▶ to see how fast retransmit kicks in when a single packet is lost in the middle of the stream.

step 1/8·00 · connection established, sending data

§ steps

The client and server have gone through the three-way handshake (see tcp-handshake) and are both in ESTABLISHED. They are ready to transfer data.

TCP does not wait for an ACK on each packet. It pipelines them. The send window cwnd defines how many packets can be "in flight" at once without an acknowledgment.

recap

What to remember:

TCP pipelines packets: the client sends several in a row without waiting for an ACK on each. This keeps the link from sitting idle for an RTT
When the server receives a packet out of order (for example 1400 when it expected 1200), it does not discard it. It buffers it and sends the sender a dup ACK with the gap's number. "I am waiting for 1200, send 1200"
3 dup ACKs are the standard trigger for fast retransmit (RFC 5681). Why 3? An empirical constant. It gives a good balance between "do not react to plain packet reordering" and "do not wait out RTO for nothing"
Modern Linux supports SACK (Selective ACK): the server can say "I got 1400, 1600, 1800, but not 1200." Then the client resends only 1200, not everything from 1200 onward
With mass loss, RTO fires first (there are no 3 dup ACKs, because the packets themselves are not getting through). RTO grows exponentially on repeated timeouts, a protection against congestion collapse
TCP statistics (netstat -s / /proc/net/snmp) show how many retransmits occurred. A high percentage means network problems

If you want to go deeper, there is the [[tcp-handshake|TCP lifecycle]] and the intermediate-02-tcp-handshake lesson where you can sniff packets by hand.

§ dig into the knowledge base

§ steps

The client and server have gone through the three-way handshake (see tcp-handshake) and are both in ESTABLISHED. They are ready to transfer data.

TCP does not wait for an ACK on each packet. It pipelines them. The send window cwnd defines how many packets can be "in flight" at once without an acknowledgment.