Round-trip time (RTT) is an important metric that can indicate the quality of communications available between two end-points. It’s a metric that our team often discusses with customers because it directly relates to the service quality experienced. RTT can be impacted by a range of design decisions, especially concerning network topology. However, there is some confusion around what exactly RTT is, how it relates to latency, how it can impact your service, and how you can improve it.
What is Round-trip Time?
One of our most viewed dashboard metrics in our Cyara testRTC product suite is RTT. This is the time it takes for a packet to go from the sending endpoint to the receiving endpoint and back. There are many factors that affect RTT, including propagation delay, processing delay, queuing delay, and encoding delay. These factors are generally constant for a given pair of communicating endpoints. Additionally, network congestion can add a dynamic component to RTT.
Propagation delay is the network distance between the two endpoints. It is the route taken by the data across the various networks, through different network switches and routers to get from the sending endpoint to the receiving endpoint. Sometimes, this may be aligned with geographical distances and sometimes it may not. Propagation delay is usually the dominant component in RTT. It ranges from a few milliseconds to hundreds of milliseconds, depending on whether the endpoints are separated by just a few kilometers or by an entire ocean.
The remaining components (processing, queuing, and encoding delays) can vary by the number of nodes in the network connecting endpoints. When only a few router hops separate the endpoints, these factors are insignificant. However, the more hops, the higher the delay, since each network node needs to receive, process and route all the data towards the next hop, adding its own milliseconds of delay to the total RTT calculation.
Impact of Network Topology
In real-time communications, we must consider the impact of network topology on RTT. Any infrastructure-based topology introduces incremental delays when compared with a peer-to-peer connection. When media is anchored by a multipoint control unit MCU, SFU, or TURN server, additional processing, queuing and encoding delays occur. But, more importantly, an infrastructure topology can add significant propagation delay depending on where the server is located relative to the endpoints.
Figure 1: Infrastructure Topology
Hairpinning occurs when media is anchored in a location that is geographically remote from an endpoint, this adds significant propagation delay, when compared to a peer connection. This is why the placement of infrastructure can be critical to delivering low RTT and a high-quality user experience. The further the media server is from the sending and receiving endpoints, the higher the RTT value and the lower the service quality.
Figure 2: The media server is located further away than necessary from the sending and receiving endpoints, resulting in a high round-trip time.
Figure 3: The media server is located between the sending and receiving endpoints, resulting in a lower round-trip time.
Clearing Up a Few Misconceptions
RTT and ping time are often considered synonymous. But while ping time may provide a good estimate of RTT, it is different. This is because most ping tests are executed within the transport protocol using internet control messaging protocol (ICMP) packets. In contrast, RTT is measured at the application layer and includes the additional processing delay produced by higher level protocols and applications (e.g. HTTPS). In WebRTC, RTT on the media streams is calculated by looking at the secure real-time transport protocol (SRTP) packets themselves. This provides the closest measure to what the actual media in a session feels like in terms of RTT.
Network latency is closely related, but different from RTT. Latency is the time it takes for a packet to go from the sending endpoint to the receiving endpoint. Many factors affect the latency of a service, including:
- Network congestion
- Packet loss and jitter
- Traffic prioritization
- Server load
- Codecs and encryption
Therefore, latency is not explicitly equal to half of RTT, because delays may be asymmetrical between any two given endpoints. For example, RTT includes processing delay at the echoing endpoint.
How Does RTT Affect Your Real-time Communications Service?
As a rule of thumb, the lower the RTT, the higher the media quality for that session is. Our focus is on ensuring the delivery of live, highly interactive services and conversations. Doing that requires a low delay from the time a user speaks until the intended recipients hear the spoken words.
At Cyara, we’ve made RTT a central focus in all of our WebRTC services. We ensure it is available to you in both aggregate form (in highlight dashboards) as well as in drill down analysis charts where you can analyze RTT over time.
