Why and How do I want to turn off IPv6 in my Win 7&8 machines? (by The Oldcommguy)
LMTV | Network Capacity Planning (by Zack Belcher and Chris Greer)

The TCP Retransmission Flavors of Wireshark (by Chris Greer)

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.

Spurious Retransmisssion

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.

 

Chris Greer Packet Pioneer Logo

Author Profile - Chris Greer is a Network Analyst for Packet Pioneer. Chris has many years of experience in analyzing and troubleshooting problems at the packet level. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. Chris also delivers training and develops technical content for several analysis vendors, and is a training partner for Wireshark University. 

Chris can be contacted at chris (at) packetpioneer (dot) com.

Comments