At one point or another, anyone who captures packets will see a TCP Retransmission. Even in the best of network environments, packet loss will happen from time to time – hey, TCP is built to handle it so don’t worry that the sky is falling! Of course, if you see a bunch of them, that’s a problem.
In Wireshark, there are several ways that a retransmission can be categorized, depending on the behavior. In order to make the best next-step decision, it is important to understand each type of retransmission and what it indicates.
TCP Retransmission – This is a plain-Jane retransmission. Wireshark observed a packet in a TCP conversation with a sequence number and data, and later observed another packet with the same sequence number and data. These are typically sent after a retransmission timer expires in the sender. There are some gotchas, but this is the general definition.
TCP Fast Retransmission – The station sending data kicks off a retransmission immediately after detecting that the original packet was lost, instead of waiting the full retransmission timer. Typically, this is triggered by the sender receiving three duplicate acknowledgments from the receiver for the same sequence number. You may also see these if Wireshark receives duplicate packets from poor SPAN configuration.
TCP Spurious Retransmission – Since version 1.12 of Wireshark, TCP Spurious Retransmission events have been identified. These indicate that the sender sent a retransmission for data that was already acknowledged by the receiver. For some reason, the sender interpreted that a packet was lost, so it sends it again.
These are the big three that you will likely see in any given environment. Remember that TCP is built to handle some packet loss, so these are normal events, but hopefully not common! If these start to impact application or service performance, comb the path between network and server and look for discards, Ethernet errors, high utilization or cabling issues that may be the real underlying culprit.
