TCP Retransmission vs. TCP Fast Retransmission

Solution 1:

When a packet is sent using TCP, it has a sequence number transmitted with it. When the receiver receives the packet, they send an acknowledgement to the sender with the sequence number showing that packet was received. Based on the way you asked your question, I'm assuming you know this. I wanted to put it in for other readers.

TCP Retransmission is just a packet that doesn't acknowledge within the timeout.

TCP Fast Retransmission is when the source gets confirmation that the packet wasn't received...quoting from Fast retransmit - Wikipedia, the free encyclopedia

if a TCP sender receives three duplicate acknowledgements with the same acknowledge number (that is, a total of four acknowledgements with the same acknowledgement number), the sender can be reasonably confident that the segment with the next higher sequence number was dropped

Solution 2:

I have digested this from Microsoft:

TCP starts a retransmission timer when each outbound segment is handed down to the Internet Protocol (IP) layer. If TCP does not receive an acknowledgment for the data in a given segment before the timer expires, the segment is retransmitted.

The retransmission time-out is adjusted on the fly to match the characteristics of the connection, using Smoothed Round Trip Time (SRTT) calculations as described in Van Jacobson and Mike Karels' paper "Congestion Avoidance and Control" in Proceedings of the ACM SIGCOMM Conference on Data Communication, November 1988. This paper can be found in the ACM Digital Library at the Association for Computing Machinery. For more information on SRTT calculations, see RFC 793: Transmission Control Protocol DARPA Internet Program Protocol Specification. The retransmission time-out for a given segment is doubled after each retransmission of that segment.

Using this algorithm, TCP tunes itself to the usual delay of a connection. TCP connections over high-delay links take much longer to time out than those over low-delay links, in order to avoid incorrectly timing out when a connection is merely slow rather than not present.

Under some circumstances, TCP retransmits data before a particular segment's retransmission timer expires. The most common such circumstance occurs because of a feature known as fast retransmit.

When a receiver that supports fast retransmit receives a packet with a sequence number higher than the current expected one, it proceeds as if some data was dropped. To help make the sender aware of the apparently dropped data as quickly as possible, the receiver immediately sends an acknowledgment (ACK), with the ACK number set to the sequence number that seems to be missing. The receiver sends another ACK for that sequence number for each additional TCP segment in the incoming stream that arrives with a sequence number higher than the missing one.

When the sender receives a stream of duplicate ACKs that acknowledge the same sequence number and the indicated sequence number is earlier than the sequence number of the current segment being sent out, the sender can infer that one or more segments it previously sent were dropped. After receiving a certain number of duplicate ACKs, senders that support the fast retransmit algorithm resend the segment or segments that the receiver is requesting to fill the gap in the data, without waiting for the retransmission timer to expire for the missing segments. This optimization greatly improves performance in a busy network environment.

With fast retransmit, the sender retransmits the missing TCP segments before their retransmission timers expire. Because the retransmission timers did not expire for the missing TCP segments, missing segments are received at the destination and acknowledged by the receiver more quickly than they would have been without fast retransmit and the sender can more quickly send later segments to the receiver. This process is known as fast recovery. Fast retransmit and fast recovery are described in RFC 2581: TCP Congestion Control.