The Core of Reliability: Why Retransmission is Essential

Imagine you are building a complex machine by ordering its parts online from a single supplier. The parts are numbered and are meant to be assembled in a specific order. The delivery service that brings these parts is the Internet Protocol (IP), which is fast and efficient but makes no promises about reliability. It operates on a best-effort model.

This means that during shipping, one of the boxes containing a critical part might get lost. Another box might be delayed and arrive after a part that was shipped later. As the recipient, you cannot build the machine if a part is missing or if you do not know the correct order. You need a supervisor who tracks the shipment, notices when a part is missing, and calls the supplier to send a replacement.

In the digital world, TCP is this diligent supervisor. It understands that the underlying IP network is inherently unreliable. TCP-s primary promise is to deliver a complete, ordered stream of data to the destination application. To fulfill this promise, it must have a robust system for detecting when data segments have been lost and a mechanism for triggering their retransmission. TCP retransmission mechanisms are the set of rules and algorithms that detect data loss and ensure that lost segments are sent again, guaranteeing that the final message is complete and correct, no matter how chaotic the journey across the network was.

Detecting Loss: The Two Main Triggers for Retransmission

Before TCP can retransmit a lost segment, it first has to realize that the segment is missing. It does not receive explicit notifications from the network saying a packet was dropped. Instead, it must infer the loss based on the acknowledgments (or lack thereof) it receives from the other end. There are two primary signals that trigger this inference.

1. The Slow Path: Retransmission Timeout (RTO)

This is TCP-s fundamental, last-resort mechanism for detecting a lost segment. The logic is simple:

1. For every data segment it sends, the sender starts a Retransmission Timer.
2. The sender then waits for a corresponding acknowledgment (ACK) from the receiver.
3. If the ACK arrives before the timer expires, the timer is stopped and reset for the next segment. The data is considered delivered.
4. If the timer expires before an ACK arrives, the sender assumes the segment (or its corresponding ACK) was lost in transit.

An RTO event is a strong indicator of a network problem, either significant congestion is causing long delays, or the network path is temporarily broken. The sender reacts by retransmitting the unacknowledged segment and taking drastic measures to reduce network load, as discussed in congestion control. While extremely reliable, waiting for a timer to expire can be very slow, especially on networks with high latency.

2. The Fast Path: Duplicate Acknowledgments

Modern TCP does not have to rely solely on slow timeouts. It has a more intelligent, faster way to infer packet loss, especially in cases of light congestion. This mechanism relies on observing the pattern of incoming ACKs.

TCP uses a cumulative acknowledgment scheme. An ACK with the number $N$ means the receiver has received all bytes up to $N-1$ and is now expecting byte $N$. If segments arrive out of order, the receiver cannot acknowledge the new data yet. Instead, it immediately re-sends an ACK for the last in-order byte it received. This repeated ACK for old data is called a duplicate ACK.

By convention, if the sender receives three duplicate ACKs in a row, it takes this as a very strong signal that the single segment immediately following the acknowledged data has been lost, while subsequent segments have been received successfully. This is a much faster trigger for retransmission because the sender does not need to wait for the full RTO to expire.

Fast Retransmit and Fast Recovery: TCP-s Intelligent Response

The detection of packet loss via three duplicate ACKs enables two powerful, interconnected algorithms that significantly improve TCP-s performance over lossy networks: Fast Retransmit and Fast Recovery. These algorithms were introduced in the TCP Reno implementation and form the basis of modern TCP reliability.

Fast Retransmit

The Fast Retransmit algorithm is straightforward:

Upon receiving the third duplicate ACK, do not wait for the Retransmission Timer to expire. Immediately retransmit the single lost segment that is being requested.

This proactive retransmission can save a full round-trip time (or more) of waiting, dramatically speeding up the recovery process. It is called "fast" because it bypasses the slow timeout mechanism.

Fast Recovery

Fast Recovery addresses the question of what to do immediately after a Fast Retransmit. The arrival of duplicate ACKs provides a valuable piece of information: the network is not dead. Data is still flowing, otherwise the out-of-order segments that triggered the duplicate ACKs would not have arrived.

Therefore, slamming the brakes by resetting the congestion window (cwnd) back to 1 MSS (as would happen after an RTO) would be an unnecessary overreaction that would cripple throughput.

Instead, the Fast Recovery algorithm does the following:

1. Multiplicative Decrease: It cuts the slow start threshold ('ssthresh') in half $(\text{ssthresh} = \text{cwnd} / 2)$. It then sets the 'cwnd' to this new 'ssthresh' value. This is the "multiplicative decrease" part of congestion control.
2. Temporary Inflation: While waiting for the acknowledgment of the retransmitted segment, the sender temporarily inflates its 'cwnd' for each additional duplicate ACK that arrives. This allows it to send new segments and keep data flowing, preventing the network pipe from going empty.
3. Resume Congestion Avoidance: Once the ACK for the retransmitted segment arrives, the 'cwnd' is "deflated" back to the 'ssthresh' value, and the sender resumes its normal, linear growth from this point in the Congestion Avoidance phase.

Together, Fast Retransmit and Fast Recovery allow TCP to efficiently repair a single lost segment within one round-trip time, without stalling transmission or unnecessarily slowing down, leading to much higher and more stable performance.

The Limitation of Cumulative ACKs and The Solution: SACK

While the Fast Retransmit/Recovery mechanism is excellent for single packet losses, it has a significant weakness when multiple packets are lost from a single window of transmitted data.

The Multiple Packet Loss Problem

Consider the part delivery analogy again. The sender ships 10 boxes (segments). The delivery service loses boxes 3 and 6. The receiver gets boxes 1, 2, 4, 5, 7, 8, 9, and 10. Using the cumulative ACK system, all the receiver can report back is: I am still waiting for box 3.

The sender will eventually get three duplicate ACKs for box 3 and perform a Fast Retransmit. It re-sends box 3. This retransmitted box then has to travel across the network. Only after the receiver gets box 3 can it finally acknowledge all the way up to box 5, and report: I am now waiting for box 6. The sender has to wait an entire round-trip time just to learn about the second lost box. To recover two lost packets, it takes two RTTs. This is very inefficient.

Selective Acknowledgment (SACK) to the Rescue

To overcome this limitation, an extension to TCP was developed called Selective Acknowledgment (SACK). SACK is a TCP Option that both sides must agree to use during the initial three-way handshake.

The SACK option allows the receiver to do much more than just report the last in-order byte. Along with its normal cumulative ACK, the receiver can include SACK blocks in the TCP header options. These blocks explicitly list the non-contiguous ranges of data that have been successfully received.

How SACK Works in Practice

Let us revisit our example with SACK enabled. The sender ships segments 1-10. Segments 3 and 6 are lost.

1. The receiver gets segments 1 and 2. It sends a normal ACK with Acknowledgment Number for the start of segment 3.
2. The receiver gets segment 4. It notices a gap. It immediately sends a duplicate ACK for the start of segment 3, but this time it includes a SACK Option saying: By the way, I have received the block of data corresponding to segment 4.
3. The receiver gets segment 5. It sends another duplicate ACK for segment 3, now with a SACK option saying: I have received the block of data corresponding to segments 4-5.
4. The sender receives these duplicate ACKs. The third one triggers a Fast Retransmit of segment 3. But critically, the sender also processes the SACK information. It now knows that segments 4 and 5 have been received safely and do not need to be retransmitted. It marks them as "SACKed" in its data structures.
5. The receiver then gets segment 7. It sends yet another duplicate ACK for segment 3, but the SACK option is updated to report: I have received blocks 4-5 and 7.
6. With this new SACK information, the sender now has a complete picture. It knows it has successfully retransmitted segment 3 and that segments 4, 5, 7, and all subsequent segments have arrived. The only remaining "hole" in the data stream is segment 6. The sender can immediately retransmit segment 6 without waiting for another RTT.

By providing a detailed map of the received data, SACK allows the sender to fill all the "holes" in a single round-trip, dramatically improving TCP's efficiency and throughput on networks that experience more than sporadic packet loss. It is a critical feature for the high performance of the modern internet.