Retransmission, Fast Retransmission & Spurious Retransmission

 TCP High-Level Summary

TCP guarantees reliable delivery. So if a segment is not acknowledged within a certain time window, TCP will retransmit it. But not all retransmissions mean a network problem—some are normal behavior, some are optimizations, some are false alarms.

Type	Trigger	Actual Loss?	Wireshark Tag
Retransmission	RTO timeout	Maybe	TCP Retransmission
Fast Retransmission	3 duplicate ACKs	Maybe	TCP Fast Retransmission
Spurious Retransmission	Wrong loss assumption	No	TCP Spurious Retransmission

🔥 When each happens (easy examples) 

Retransmission :  TCP resends a segment because it did not receive an ACK before timeout. Triggered by RTO. Likely packet loss.

• Packet is lost due to congestion.
• Timeout expires.  (Client waits → timeout → resend)

Fast Retransmission : TCP resends early after receiving 3 duplicate ACKs, avoiding waiting for timeout. Triggered by loss or reordering.

• Middle packet is lost
• Later packet arrives
• Receiver sends duplicate ACKs

Spurious Retransmission : Sender retransmits even though the original packet was not lost. Caused by delay, reordering, or path change.

• Packet was just delayed
• TCP guessed wrong 

Real life interpretation

• Retransmission = normal recovery
• Fast Retransmission = recovery but faster
• Spurious Retransmission = false alarm caused by delay 

Which one indicates real network issue?

Most serious

• Regular retransmissions (RTO)
• Caused by actual loss

Sometimes serious

• Fast retransmissions
• Caused by congestion or reordering

Usually not serious

• Spurious retransmissions
• Delay but no loss 

Let’s break them down.

1️⃣ Standard Retransmission (RTO Retransmission) 

This is the basic TCP recovery mechanism. If ACK is not received before the retransmission timeout (RTO) expires, the sender resends the segment.

Why it happens

• Normal packet loss on network
• Congestion
• Receiver load
• Buffer overflow
• Routing issues
• VPN, WAN latency, satellite links 

Trigger : Timeout timer (RTO) expires.

• Frame : 39059, Client  -> Server : Seq#1804834 (no ACK)
• Frame : 39060, Client  → Server : Seq#1804834 (again after timeout) 
• Frame : 39061, Client  → Server : Seq#1804834 (again after timeout)  

How Wireshark shows it : [TCP Retransmission] 

Practical meaning : This is TCP doing its job. 

2️⃣ Fast Retransmission 

Meaning : A performance optimization introduced by TCP Reno/NewReno.

Instead of waiting for timeout expiry, TCP retransmits early when network signals packet loss using duplicate ACKs.

Trigger : Receiver sends 3 duplicate ACKs for the same missing packet:

• Frame : 52318, Client  -> Server : TCP Dup ACK 52200#53
• Frame : 52319, Client  → Server : TCP Dup ACK 52200#54
• Frame : 52320, Client  → Server : TCP Dup ACK 52200#55
• Frame : 52321, Server  → Client : TCP First Retransmission

Reasons

• Out-of-order packets
• Packet loss in middle of stream
• Congestion indication 

 

How Wireshark shows it : [TCP Fast Retransmission]

Practical meaning : Network is unstable OR packets arrived out of order, but TCP handled it quickly.

3️⃣ Spurious Retransmission 

Meaning : A retransmission that happens even though the original packet was NOT lost.

So sender thinks packet is lost → retransmits → but original arrives later anyway.

The cause is generally:

• Delay != loss
• Path change or reordering
• VPN tunneling
• Mobile handover
• Very asymmetric paths
• LTE / 4G / 5G scheduling delays 

 

 

• Frame : 39067, Server-> Client: TCP Spurious Retransmission, Seq : 1291224 
• Frame : 39068, Client  → Server : TCP Dup ACK 39065#1
• Frame : 39069, Server-> Client: TCP Spurious Retransmission, Seq : 1291224
• Frame : 39070, Server  → Client : TCP Dup ACK 39065#2

Common Real Examples

• Satellite internet
• Cloud VPN tunnels
• High-latency TLS handshakes
• Cellular roaming

How Wireshark shows it : [TCP Spurious Retransmission] 

Interpretation : This does NOT mean packet loss. It means TCP believed a loss happened due to delay. 

 Quick Definitions : 

Feature / Behavior	TCP Retransmission	TCP Fast Retransmission (First Retransmission)	TCP Spurious Retransmission
Definition	Resending a packet because sender believes it was lost.	Immediate retransmit triggered by 3 duplicate ACKs (Fast Retransmit).	Retransmission that was not needed (original packet was delivered, just delayed).
Trigger Condition	RTO timeout (Retransmission Timeout) expires OR packet loss detected.	Fast retransmit due to 3 duplicate ACKs indicating likely loss.	Sender misjudges loss due to delay/reordering and retransmits unnecessarily.
Cause	Actual packet loss or severe delay.	Packet lost but detected early using duplicate ACKs.	Packet delay, reordering, delayed ACK, or slow receiver; original packet not lost.
Packet Drop?	Yes, usually indicates a real network drop.	Yes, often real loss but detected faster.	No, original packet arrives later.
Wireshark Label	[TCP Retransmission]	[TCP Fast Retransmission]	[TCP Spurious Retransmission]
Latency Impact	High (RTO can be 200–300 ms or more).	Medium (fast recovery reduces latency impact).	Low–Medium (no real loss, but still adds delay).
Detection Mechanism	Timeout-based (RTO).	Duplicate ACK-based (Fast Retransmit).	DSACK, F-RTO, Eifel algorithm detect that retransmission was unnecessary.
Root Problem	Network drops, congestion, queue overflow.	Slight congestion or isolated packet loss.	Delay, reordering, scheduler stall, NIC buffering—not actual loss.
Severity	🔴 High – real packet loss.	🟠 Medium – actual loss but recovered faster.	🟡 Low/Medium – indicates delay, not loss.
Typical Scenarios	WAN links, overloaded NICs, firewall drops.	High-speed links with occasional packet loss.	Wireless networks, ECMP routing, NIC buffer delay, CPU stall.
ACK Behavior	No ACK received → resend.	3 duplicate ACKs → resend faster.	ACK arrives showing original packet was received → retransmit flagged spurious.