Round-trip time 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 by users. Round-trip time can be impacted by a range of design decisions, especially concerning network topology. However, there is some confusion around what exactly round-trip time is, how it affects your service, and how you can improve it.
What is Round-trip Time?
One of our most viewed dashboard metrics in our testRTC products, round-trip time (RTT) 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. In addition, 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 is aligned with geographical distances and sometimes it isn’t. 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 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 negligible. The more hops, the higher the delay, since each such network node needs to receive, process and route the data towards the next hop, adding its own milliseconds of delay to the total RTT calculation.
In real-time communications, we must consider the impact of network topology on RTT. Any infrastructure-based topology introduces incremental delay as compared to a peer-to-peer connection. When media is anchored by a 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 2: Infrastructure Topology
Hairpinning occurs when media is anchored in a location that is geographically remote from an endpoint, adding significant propagation delay, as 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 away the media server is from the sending and receiving endpoints, the higher the RTT value and the lower the service quality.
Figure 3: The media server is located further away than necessary from the sending and receiving endpoints, resulting in a high round-trip time.
Figure 4: The media server is located between the sending and receiving endpoints, resulting in a lower round-trip time.
Clearing Up a Few Misconceptions
Round-trip time and ping time are often considered synonymous. While ping time may provide a good RTT estimate, it differs in that most ping tests are executed within the transport protocol using 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 SRTP packets themselves, providing 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 may affect the latency of a service. Latency is not explicitly equal to half of RTT, because delay may be asymmetrical between any two given endpoints. 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 in delivering live, highly interactive services and conversations. Doing that requires low delay from the time a user speaks until the intended recipients hear the words spoken.
At testRTC, we’ve made RTT a first class citizen in all of our services, making sure it is available to you in aggregate form in highlight dashboards as well as in drill down analysis charts where RTT can be analyzed over time.
New to Spearline?
Spearline provides quality assurance tools for business communication services, allowing you to proactively manage your inbound and outbound voice, SMS and fax services. Our latest WebRTC products offer testing, monitoring and support for web-based communications.
We work globally across business sectors, supporting contact centers, conferencing services, and more to successfully connect with their customers and employees. For further information, or if you have any further questions please get in touch.
