TCP Fast Retransmit
- Fast Retransmit: the sender retransmits a lost segment before the RTO expires
- Fast Retransmission is opposed to Timer-based Retransmission. Timer-based Retransmission is when the sender waits for RTO to expire before retransmitting the requested segment.
- Fast Retransmit is part of both TCP Tahoe and TCP Reno
- when a TCP receiver receives out-of-order segments, it immediately sends a duplicate ACK. This is to signal to the sender that it receives out-of-order segments. When the TCP sender receives the duplicate ACK, it assumes there is packet loss. The role of the TCP sender is to fill in the holes of the TCP receiver as soon as possible.
- Once the first duplicate ACK received, TCP sender waits for a period of dupthresh and then sends the missing segment without waiting for RTO to expire (RTO stands for Retransmission TimeOut). Note that I said the “missing segment” and not “missing segments” because I am assuming that normal ACKs -and not Selective ACKs- is used. This is the purpose of Fast Retransmit.
- Fast Retransmit occurs in one RTT, after receiving the three dup ACKs. In this same RTT, the ACK for the retransmitted segment is received.
- Receiving one or more duplicate ACK is an indication of one of two things: there is packet loss, and/or there is packet reordering in the network. Since there is no way for the TCP sender to know what exactly is going on, it assumes there is packet loss.
- dupthresh: Duplicate ACK Threshold: is the number of duplicate ACKs that the TCP sender waits for before firing TCP Fast Retransmit. Usually, dupthresh=3, but some Unix implementations have dupthresh >3.