What is RTT?

Round-Trip Time (RTT) is the time it takes for a packet to travel from a source to a destination and for an acknowledgment to travel back, measured in milliseconds. It is a core network-performance metric – alongside packet loss and jitter – used to gauge path quality and drive automated traffic-steering decisions.

Key takeaways

• RTT measures a full round trip, not one-way network latency.
• Lower RTT generally means a more responsive path for real-time traffic.
• RTT combines propagation, transmission, queuing, and processing delay.
• Versa’s SASE client measures RTT via TWAMP to score circuit quality.
• SLA profiles use RTT thresholds to trigger automatic path switching.

On this page: Why it matters · How it works · Types · RTT & Versa · FAQ

Why is RTT important?

Round-trip time is one of the first numbers engineers check when a connection feels slow, because it is a direct proxy for user-perceived responsiveness. Voice calls, video conferencing, and other real-time applications tolerate very little added delay, and RTT – latency in both directions plus far-end processing time – best captures what a user actually experiences on a round trip.

RTT also matters operationally. Modern SD-WAN and SASE architectures use RTT, alongside packet loss and jitter, to continuously score every available path between an endpoint and a destination. Instead of relying on a link’s advertised bandwidth or a static routing table, path-selection logic reacts in near real time: when RTT on the active path degrades past a threshold, traffic steers automatically to a better path – turning a troubleshooting metric into a live input for automated routing decisions.

What is RTT?

RTT is measured by timestamping a packet when sent and again when its response arrives, then taking the difference. No clock synchronization between endpoints is required, which makes it far easier to measure than true one-way latency. The total is the sum of propagation delay in both directions, transmission delay, queuing delay at intermediate hops, and any processing time the destination needs before replying.

Because RTT bundles the forward and return paths together, it can mask asymmetry – a fast forward leg and a slow return leg produce the same RTT as a path that is evenly slow both ways. Engineers typically probe it with ICMP echo (ping), TCP SYN/SYN-ACK handshakes, or synthetic-traffic protocols, then track the minimum and median over a window rather than trust a single sample skewed by transient congestion.

Types of RTT measurement

RTT measurement falls into two broad approaches. Active (synthetic) measurement injects dedicated probe traffic – ICMP echo requests, or a purpose-built protocol such as the Two-Way Active Measurement Protocol (TWAMP) – onto a path at a regular interval and times the response, giving a controlled, repeatable sample at the cost of a little added traffic.

Passive measurement derives RTT from traffic that would exist anyway, typically by timing a TCP three-way handshake or matching request and response packets in a live flow – no overhead, but no sample until qualifying traffic appears. A further distinction is network-layer RTT (ICMP, TCP handshake) versus application-layer RTT, which adds server processing time on top.

RTT & Versa

Versa’s SASE client uses RTT as a core input to automatic path selection. When you configure the Versa Secure Access Service, an SLA profile sets a relative threshold (a multiple of the minimum RTT since connecting) and an absolute millisecond ceiling; exceeding either over a rolling window is an SLA breach, measured via TWAMP on the gateway. The client periodically probes RTT – along with packet loss, duplicate, and reordered packets – against every WAN IP the gateway advertises, switches its IPsec connection when another address scores better, and reports the results to Versa Analytics. The same pattern applies to the Secure SD-WAN and NGFW variants.

Frequently asked questions

What is a good RTT value?

There is no universal threshold – it depends on the application. Voice and video need well under 150 ms round trip; interactive apps tolerate more; bulk transfers are largely insensitive to RTT. SLA profiles let administrators set thresholds per deployment rather than assume one number.

What is the difference between RTT and latency?

Latency, or one-way delay, is the time a packet takes to travel in one direction; RTT is that packet plus its reply completing the round trip. RTT is often approximated as double the one-way latency, though asymmetric paths can make that estimate inaccurate.

What is the difference between RTT and jitter?

RTT is a single measurement of round-trip delay at one point in time; jitter is the variation in that delay across measurements. A path can have moderate RTT but high jitter – inconsistent timing – which degrades real-time voice and video even when average delay looks fine.

How does Versa measure RTT?

The Versa SASE client uses TWAMP-based synthetic probes to measure round-trip circuit time to each of a gateway’s WAN IP addresses periodically, then compares the results against the relative and absolute thresholds in an SLA profile to detect a breach.

Can RTT be reduced?

Some causes are fixable – moving closer to a point of presence, adding a better circuit, or removing congested hops – but propagation delay set by physical distance is a hard floor. SD-WAN mainly reduces effective RTT by steering traffic to the best path, not by beating physics.

More on RTT

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about RTT, these are worth looking at next.