Understanding RTT Impact on TCP Retransmissions

Ever get asked to explain or elaborate on something that you should definitely know, only to realize that you don’t fully understand it yourself? You’re certainly not alone.

Even though the basics of Transmission Control Protocol (TCP) connections are one of the very first topics covered when learning about computer network fundamentals, many of us are perplexed by retransmission logic and still have no idea what Smoothed Round Trip Time (SRTT) means. But fear not; we’re here to shed some light on them for all levels of speed gurus.

First, we start with Round Trip Time, or RTT. For Ping and Traceroute, this measures the round trip time between sending the Ping packet and getting the ICMP packet back. For TCP connections it is quite similar; it measures the time sending a packet to getting the acknowledgment packet from the target host.

Let’s say you have host A and host B. The TCP Three-Way Handshake is as follows:

1. Computer A sends a TCP SYN packet to computer B (This is where RTT timer begins)
2. Computer B sends a TCP SYN-ACK packet to computer A (This is where RTT timer ends)
3. Computer A then sends a TCP ACK packet to computer B (The TCP connection is now established!)

If you are relying on Wireshark to capture and analyze packets, the tool will calculate and display the RTT on the packet containing the ACK. See the last line in the figure below:

Easy to understand, right? But what happens when a packet is lost? TCP protocol has built-in logic for ensuring that packets are received. Thus, to ensure the packet is received, the sender will retransmit the packet to the other party.

The majority of us are well aware of the primary retransmission logic. On the initial packet sequence, there is a timer called Retransmission Timeout (RTO) that has an initial value of three seconds. After each retransmission the value of the RTO is doubled and the computer will retry up to three times. This means that if the sender does not receive the acknowledgement after three seconds (or RTT > 3 seconds), it will resend the packet. At this point the sender will wait for six seconds to get the acknowledgement. If the sender still does not get the acknowledgement, it will retransmit the packet for a third time and wait for 12 seconds, at which point it will give up.

While this is the most well-known fact of RTO, it is not the only logic in TCP. The TCP protocol was designed to take in consideration that the connection between two computers is not the same – hence the retransmission logic should be quicker for cases where the two computers are close. This where RTT starts impacting RTO.

When the TCP connection is established, there is one RTT value, and the RTO will be adjusted based on the Smoothed RTT (SRTT) calculation. The calculation applies a smoothing factor to the RTT which creates a predicted round-trip time that is beneficial to the assurance of packet delivery. SRTT formula is:

SRTT(ALPHA * SRTT) + ((1-ALPHA) * RTT)

ALPHA = smoothing factor between .8 and .9
RTT = Round Trip Time

Once the SRTT is calculated, it is used as a determining factor of how long the host will wait before retransmitting the segment, which is calculated as RTO below:

RTO = min[UBOUND, max[LBOUND(BETA * SRTT)]]

UBOUND = upper bound on the timeout (e.g. 1 minute)
LBOUND = lower bound on the timeout (e.g. 1 second)
BETA = delay variance factor (e.g. 1.3-2.0)

If no response packet is received after sending the segment, then the RTO is doubled after each re-transmission and the previous re-transmission is ignored in the RTT calculation. This strategy is known as Karn’s Algorithm and is considered to be highly effective, especially in areas with high packet latency.

Take, for example, the packet capture seen here from a Windows client, and the retransmission highlighted:

In the packet capture above, you can see that in Frame 4 there was a packet sent with length of 1502, and there is a retransmission in Frame 5 due to the lack of acknowledgement from the receiving host. If you dive into the individual frame details, you can find out how long the RTO was set for this particular retransmission:

Remember, the new RTO is calculated based on the SRTT, which is based on RTT, which results in an adjustment that is highly effective when experiencing latency on your network. The lowest RTO will vary by operating system (or TCP implementation); in Windows it is 300ms, and in Linux it is 200ms.

In the case of web browsers, the computer opens multiple connections to the same host. For Windows each connection has its own SRTT calculations, so one connection does not impact the other. We have not received confirmation of this for Linux, but probably it is the same.

The Smoothed RTT retransmission logic exists to ensure that the Retransmission Timeout is based on the connectivity between the two machines in communication, and to ensure that users do not experience long latency when there is congestion in a low latency connection. So for example, connections from New York Fiber and London 3G to a server in Los Angeles are going to vary significantly based on distance, peering, and type of connection – thus deserving separate RTO calculations. After all, why would you apply the same RTO to all cases when it could be adaptively changed to the behavior of your network?

If it wasn’t for the application of these accurate predictions then you would experience even more latency on your network due to unnecessary retransmissions.