Introduction to TCP Retransmission
TCP is one of the reliable protocols working in the transport layer, in terms of Open System Interconnect (OSI) model. The protocol offers packet delivery guarantees, even if some of the packets have been lost during the transmission. The lost packets are recovered by retransmissions and acknowledgments while sequence numbers are used to determine correct packet reordering in the receiving side.
Whenever a sender transmits a packet, it saves a copy of the packet int its buffer and it stays there until receiving side acknowledges that it has received the packet. After that, the copy gets deleted and resources are released for future use.
Packet loss may happen due to two main reasons which can fall into many sub categories. Packet loss is mostly caused by hardware issues, software bugs, network congestion, and some other factors. Before diving into retransmissions and examining the types of retransmissions, we need to explain two concepts.
How to get TCP Round-Trip Time (RTT)?
For sake of simplicity, lets first go with pinging. I am using Windows OS and when I ping 1.1.1.1 address, it displays an output that shows me how much time it takes to send an ICMP packet from my computer to the server and gets back an answer from the server to my computer. The total time is called RTT for ping.
My ping command displays the RTT for each packet sent and returned below.
# ping 1.1.1.1 Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=12ms TTL=56 Reply from 1.1.1.1: bytes=32 time=12ms TTL=56 Reply from 1.1.1.1: bytes=32 time=11ms TTL=56 Reply from 1.1.1.1: bytes=32 time=37ms TTL=56 Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum = 37ms, Average = 18ms
The similar concept can be applied to TCP as well. RTT is how long it takes to receive an ACK for data that has been sent. Wireshark is capable of calculating and displaying TCP RTT in the header. Let’s get our hands dirty and capture a TCP flow. We will measure RTT for the first packet (SYN) in the flow.
- Go to the TCP header and expand [SEQ/ACK Analysis] tree.
- You should see something like below.
As you see in the screenshot above, after SYN/ACK packet arrived, the RTT for the SYN packet has calculated as 0.229751 second.
Analysing TCP Retransmission Timeout (RTO)
When a packet is sent over a network, the sender starts a timer and expects the packet to be acknowledged before the timer expire. If the packet gets lost or the sender does not receive the acknowledgment in the time, the timer expires and the sender retransmits the packet again. This timer is called RTO which is doubled after each retransmission. When RTO is calculated, RTT parameter is taken into account. The number of retransmissions depends on what type of operating system (OS) you use or what kind of configuration they have. I will create 3 scenarios in which we will observe RTOs and retransmissions.
Scenario 1
In this scenario, we will use a Windows 10 client and try to reach 8.8.8.8 (dns.google) through port 125, which we know it is filtered by a firewall. All our packets will be dropped. The screenshot is below.
As you see, 4 times retransmission happened before it gave up. Each time RTO doubled in the “Delta” column. RTO timer can be customized in Windows 10.
Scenario 2
We will repeat the same test with Kali. It has turned out that Kali is more stubborn compared to Windows 10 in terms of retransmissions. It tried 13 times before it gave up. You can see how RTO increased in the figure below.
Scenario 3
In this scenario, we will create the topology below in which two Cisco routers are connected to each other. The client will try to telnet to the server but it will fail due to our configuration.
We will configure the server so that it will drop all the telnet traffic coming from the client. I prepared a configuration that did the filtering. The configuration is below from my Cisco router.
! ip access-list extended TELNET_TRAFFIC permit tcp any host 192.168.1.1 eq telnet ! class-map match-all SELECT_TELNET match access-group name TELNET_TRAFFIC ! policy-map DROP_TELNET_TRAFFIC class SELECT_TELNET police cir 8000 conform-action drop exceed-action drop violate-action drop policy-map test ! interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 speed auto duplex auto service-policy input DROP_TELNET_TRAFFIC !
Now, it is time to telnetting to the server from the client while we are capturing the packets between two parties.
client# telnet 192.168.1.1
Trying 192.168.1.1 ...
% Connection timed out; remote host not responding
It appears that our filtering is working and we will verify that with packet capture as well. The pcaps are below.
The Cisco router does not seem to try much. It retransmitted only once and then gave it up. All 3 scenarios have proved that different OS uses different implementation for retransmission. This information can be used in OS fingerprinting.
Analysing TCP Retransmission
TCP Retransmission happens when RTO timer expires. For better understanding, we will continue with more scenarios.
Scenario 1
In this scenario, we will imitate packet loss with filtering only http responses coming from a site and examine the captures. Filtering will be made in a node between the client and the server. The captures are below.
Since only http packets coming from the server has been dropped, TCP 3-way handshaking is looking successful. Then the client creates a http GET request and RTO timer starts for that packet (in the row 4).
The packet arrives the server and the server responses back. When the packet reaches our filtering node between the client and the server, the node immediately drops the packet. The client is still waiting for the packet. A soon as the RTO expires, the client retransmits the packet number 5 but still gets no response from the server. It keeps retransmitting the packet until it gives up in the packet number 22 by which it resets the connection.
The RTO increase can be seen in the “Time” column.
Scenario 2
We will imitate a low bandwidth, creating an artificial congestion then we will try to download a nice wallpaper and observer what happens in the packet level. I will create a Quality of Service (QoS) rule on node between the client and server, which limits the bandwidth at rate of 8kbps (kilo bit per second). The size of wallpaper is 888KB (Kilo Byte).
Since TCP 3-way handshaking consumes very low bandwidth, the artificial congestion does not seem to affect the first 7 packets. After that you can see the latency in the packet number 8. The latency increases dramatically. Although there are pretty much latency, we do not see any RTO in the first 23 packets. The reason is high RTT. Remember that RTT is taken into consideration when calculating RTO. Then RTOs and retransmissions happen so much that the connection gets terminated later without completing the download.
When I opened the wallpaper, I saw the picture below:
It reminded me the time when we used dial up connection for the internet 😊
What is Fast Retransmission
When a TCP sender receives three duplicate acknowledgements with the same acknowledge number, the sender concludes that the packet has been sent is lost and it retransmits the packet without waiting the RTO for the packet. This method is used to avoid congestion and detect lost packet in the network faster than normal TCP retransmit.
How to filter TCP Retransmissions with Wireshark
Wireshark provides a useful feature called “Expert Info”. When Wireshark see some anomalies, it adds some description to packet header, especially for TCP. It analyses TCP flags and inserts a relevant description to the header for informing experts (administrators). We can create a filter and make a “display filter button” for it. Steps are below.
Go to display filter and type analysis.flags && !tcp.analysis.window_update. My output before filtering is below.
Now I am applying the filter below.
After applying the display filter, go to top right and click on the “plus” button.
Fill all the relevant areas and click “OK” to save.
Now you have a button that points to your filter. You should see something like below.
Final Thoughts
TCP retransmissions happen when there is packet loss or congestion, which causes high latency and low speed. TCP implements many methods to recover connections when packet loss occurs. Retransmission and Fast Retransmission are both used for this purpose.
Very useful information, thanks a lot…
Very Good. Thank you
Thank you, particularly for the Wireshark filters.