troubleshoot tcp retransmission wireshark

Any source of electronic noise could potentially cause bit errors, which result in packet errors. A bad NIC, perhaps containing a memory chip that has a stuck bit in its internal buffer, could be another source of packet errors. Packet errors can be caused by bad cabling or cables run near sources of EMI/RFI, such as high-voltage power lines or fluorescent lighting ballasts. Most people think of packet errors as a common reason for TCP to retransmit a segment and that’s correct. Several things can cause a retransmitted packet (technically, a TCP segment). See descriptions of TCP such as at Wikipedia for more information about how TCP works. Features like Selective ACK (SACK) and fast retransmit speed up the process. If TCP doesn’t receive an ACK within 2*RTT (twice the smoothed Round Trip Time), it will retransmit the first previously sent and unacknowledged segment. TCP guarantees data delivery by using an ACK mechanism to make sure that the data is received (note that a failure internal to the receiving system may corrupt the data after TCP hands it off to the kernel, but we’re not going to go there in this article). The few things I did find typically contained inaccuracies of some sort. But I haven’t seen anything much about the sources of TCP retransmissions. There is a fair amount of information on the web about TCP retransmissions and how TCP works. I look at servers and user workstations as well as looking for retransmisisons using packet capture tools. I’ve been doing a number of network assessments recently and one of the factors that I use to determine network health is the number of TCP retransmissions that occur.

Troubleshoot tcp retransmission wireshark