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.

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.