Measuring TCP Retransmissions in Flowmon

Network Performance Monitoring was extended with monitoring of TCP retransmissions and out of order packets. Using these metrics we are able to identify data transfer issues. This article explains TCP retransmissions and shows how to easily measure them and how it helps network administrators to identify network issues and troubleshoot the network.

Flowmon solution allows measuring various network metrics, which can help administrator to identify and troubleshoot network related issues. Today we take a look at TCP retransmissions, a new metric added to improve Network Performance Monitoring.

Let me firstly explain principle of TCP retransmissions. In TCP connection sender waits for an ACK for the byte-range sent to the receiver.  When an ACK is not received, sender resends the packets after particular interval. In the case of resending packets, we are talking about TCP retransmission. Retransmissions are essentially identical with Automatic Repeat Request (ARQ) and ensure reliability of TCP connection by resending damaged or lost packets.

So how is TCP retransmission identified? There are two parameters we need to focus on to determine whether TCP retransmission occurred. First is Sequence Number from TCP header (layer 4) and second is Identification from IP header (layer 3). When Sequence Number in two packets is the same, but Identification is different, we are talking about TCP retransmission. Move your mouse cursor on picture below to see the difference. 

Traffic was captured by Flowmon Packet Investigator and analyzed in Wireshark using filter for TCP retransmissions. Process of capturing the traffic and follow up analysis took me several minutes, but using Flowmon Monitoring Center I was able to see the results within few clicks. After specifying time interval and typing specific filter I was able to see all TCP retransmissions in connection between specified IP addresses and other measured NPM metrics like Server Response Time, Jitter and Delay. For filtered communication we can see maximum of 16 retransmissions, low Server Response Time, delay and thus we can state that the communication proceeded without any major issues.

In following communication lasting 85 second with 97.4MB of transferred data we can see high amount of retransmissions. Although average delay and server response time is low, number of retransmissions is almost 17 thousands. That means, that almost 17 thousands of packets had to be retransmitted because they were damaged or lost. Moreover, this issue is happening between IPs in the local network which may indicate issues on physical layer. Without having TCP Retransmission measurement available, network administrator wouldn’t know about this issue. Using this information available in matter of seconds, network administrator is able to identify possible network issues and thus it helps to troubleshoot the network.

Follow this link to learn more about Network Performance Monitoring.

Get the visibility with Flowmon! Visit Flowmon Online Demo and stay in touch for further information on our products!