What is Round Trip Time (RTT) and how can it be measured?

What is Round Trip Time (RTT)?

Introduction

When measuring latency, tools such as ping, traceroute and mtr are often used. These tools report various metrics, including latency, which is (more often than not) measured in “ms” (milliseconds), along with the Round Trip Time. The RTT is a measure of latency between a client and host, including the time taken for said host to respond.

How is it measured?

Round Trip Time can be measured using any of the (nonexhaustive) tools above. We’ll stick to using ping; an example can be seen when you run ping test.b-cdn.net:

ping test.b-cdn.net -c 4
PING test.b-cdn.net (138.199.57.151): 56 data bytes
64 bytes from 138.199.57.151: icmp_seq=0 ttl=57 time=14.524 ms
64 bytes from 138.199.57.151: icmp_seq=1 ttl=57 time=15.309 ms
64 bytes from 138.199.57.151: icmp_seq=2 ttl=57 time=15.215 ms
64 bytes from 138.199.57.151: icmp_seq=3 ttl=57 time=15.992 ms

--- test.b-cdn.net ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.524/15.260/15.992/0.520 ms

A quick refresher on how TCP connections work: when a connection is established, a client needs to send a SYNchronize packet, which is succeeded by the intermediate SYN-ACK state and finally, if everything goes well, the client will receive an ACKnowledge response from the host.

Having said that, we’re taking a look at the last line (this can vary with different versions of the ping binary): the information shown refers to the “round-trip,” or RTT. The time (in milliseconds here) is the total amount of time taken for a “request.” This includes the time taken for SYNchronization, followed by the time for said packet to be sent (in this case, an ICMP echo) and the time taken for a reply to be ACKnowledged and received. When you see suboptimal latency, this can be caused by a variety of issues:

• ICMP deprioritization
  • Routers are occasionally configured to not reply after X number of ICMP requests; i.e. rate-limiting
• Geographical distance
  • This means that your ICMP packet might need to hop over, say, 10 networks before reaching the destination
• Poor network conditions
  • Attempting to test network performance to a host on a slow 3G connection; or a network that is heavily congested
• Server issues
  • Servers can occasionally experience periods of extremely high load; this means that there aren’t many CPU cycles left to send an ACKnowledgement for your ping requests (this consequently affects both latency and round trip time)

Conclusion

Round Trip Time (RTT) is an important measure of web performance. For the most part, when measured under “standard” conditions (i.e. uncongested network, acceptable server load), it can provide valuable insight into the performance of existing routes. With deprioritization, ICMP responses can occasionally be lost or be delayed significantly; however, in most cases, routers will either block or accept requests (deprioritization is less popular than outright blocking ICMP requests; they make it more difficult to diagnose issues pertaining to routing and latency).

In essence, RTT is a performance metric returned by ping, traceroute, and many other latency monitors. It is important to understand this metric as it bundles both the time taken to reach the host (using your ISP’s routes) and back (using a host’s routes). The routes taken to reach a host and back are not necessarily the same, which is why this metric is so useful for both end-users and network administrators alike.