First time I saw on "TCP Spurious Retransmissions" on Wireshark, I had to look up the definition of Spurious on Google as I've never heard that word before :). It reads "not being what it purports to be; false or fake". Fake retransmissions? hmmm ... interesting ... started to wonder what this really means. After some investigation, I found out what these mysterious Spurious retransmissions really are. In Wireshark, TCP retransmissions are classified as one of three categories.
RTO - Retransmission Timeout. Every TCP segment as it is sent to the IP layer has a timer associated with it and an ACK should be received before this timer expires. This timer is dynamically adjusted according to RTT and other factors. Here is a good write-up RFC 6298 if you want to get more information on how RTO is calculated.
TCP Retransmissions - These are the normal (althought not so normal if it happens quite often) everyday retransmissions in which the Packets sent are not acknowledged by receiver within a certain amount time (derived from SRTT .. smoothed round trip time). This is also sometimes referred to as TCP retransmission due to RTO (Retransmit Timeout). TCP retransmissions due to RTO is worse than other causes of TCP retransmissions because depending on your TCP implementation, the flow can go to slowstart, congestion window (cwnd) can be cut in half and the performance is hit with major penalties.
TCP Fast Retransmissions - These retransmissions are used by TCP to react to PacketLoss quicker and retransmit the missing packets before the RTO. This type of retransmission is less harsh on the TCP performance because the sender realizes that the Packets are making it to the receiver, and that it's just occasional packet drops and path is generally not congested.
TCP Spurious Retransmissions - These are the retransmissions in which the receiver acknowledged the packet but not before the Sender retransmits the packet due to an RTO. These type of retransmissions will hinder TCP performance much like TCP retransmissions due to RTO. Wireshark catches these because it sees an ACK for the Packet sent but the sender retransmits the packets anyways so wireshark sees the packet twice. For example, SEQ 2 is seen twice by Wireshark even though ACK 2 was sent.
Many more articles to come so ....
Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.
"You only live once, but if you do it right, once is all you need" ...