RTT (Round Trip Time)

RTT (Round Trip Time) is the time between sending a packet and getting confirmation that it arrived. It covers the trip to the destination, the moment the receiver handles the packet, and the trip back. RTT is given in milliseconds (ms) and is the basic measure of network latency.

How is RTT measured?

RTT is measured either actively or passively. Active measurement sends its own test packets (probes) and times the response:

• ICMP echo (ping) — the simplest measurement: you send an echo request and get back an echo reply. The tool reports the minimum, average, maximum, and spread (e.g. round-trip min/avg/max/stddev = 23.8/26.8/34.9/4.1 ms).
• traceroute/tracert — shows the RTT to each successive point (hop) along the path, so you can see which segment the delay grows on.
• TWAMP (Two-Way Active Measurement Protocol, RFC 5357) and OWAMP — standardized protocols for precise, repeatable measurement of delay and jitter, used to keep an eye on service-level agreements (SLA).

Passive measurement reads RTT from the traffic already flowing through the network — no probes needed. For TCP, you can estimate RTT just from connection setup (the handshake): from sending SYN to receiving SYN-ACK, and then from data-segment/ACK pairs. The TCP stack keeps a smoothed RTT value (SRTT) and its variability, and from those it computes the RTO (Retransmission Timeout) — the time after which it treats a packet as lost and sends it again.

How does RTT differ from one-way latency?

One-way latency is the time for a packet to travel only from point A to point B. RTT is the round trip plus the processing time at the receiver. So RTT is not simply double the one-way latency: the forward and return paths can run differently (asymmetric routing), and the traffic and queues on each can differ too. RTT is measured more often because it is simpler — accurate one-way measurement needs tightly synchronized clocks on both ends, and RTT does not.

What affects RTT?

• Distance and propagation delay — a signal in fiber has a finite speed, so links between continents inherently have higher RTT.
• Number of hops and the path — each router adds something; a suboptimal path lengthens RTT.
• Queuing and congestion — when a device is overloaded, packets wait in its buffers (bufferbloat).
• Type of link — fiber, copper, and radio or satellite links have different delays.
• Receiver-side service time — request processing or an overloaded server adds to the RTT measured at the application level.

How does RTT affect throughput and TCP?

RTT directly limits the real throughput of TCP connections. How much data can be “in flight” without acknowledgment is set by the TCP window, and the theoretical throughput ceiling is described by the Bandwidth-Delay Product (BDP = bandwidth × RTT). With high RTT, even a wide link won’t help: a single TCP session won’t use all the bandwidth if the window is too small (which is why window scaling and congestion control exist). Higher RTT also slows the reaction to lost packets and stretches out how a connection ramps up right after it starts.

Why does RTT matter for monitoring and security?

In network monitoring and NDR (Network Detection and Response) systems, RTT is not only a quality metric but also a diagnostic signal and a piece of security telemetry:

• Pinpointing the problem — splitting RTT into a client-to-network and a network-to-server segment helps tell a link problem apart from an overloaded application.
• Anomaly detection — a sudden change in RTT can mean congestion, a DDoS attack, traffic redirection (e.g. through an unauthorized proxy), or a degraded path.
• Path-change signal — a step change in RTT to a known destination can be a sign of a routing change, sometimes a malicious one (e.g. an unexpected lengthening of the path).
• Passive measurement from the TCP handshake — gives RTT without extra traffic, which makes it easier to watch production networks and analyze trends over time.

What counts as a good RTT?

It depends on the use case and distance, but as a rough guide: below ~100 ms usually feels smooth, 100–200 ms is already noticeable in real-time applications (gaming, VoIP, video conferencing), and above ~200 ms clearly hurts the experience. On a local network (LAN), typical RTT is a few milliseconds or less. These values are best read together with jitter (RTT variability) and packet loss.

Learn more

• Secure Access Service Edge (SASE) — SASE performance depends on RTT, since added security and routing steps can increase latency.
• NPM (Network Performance Monitoring) — NPM uses RTT to measure network delay and spot congestion or path issues.
• ARP spoofing – how to detect a Man-in-the-Middle attack and ARP poisoning in a LAN network — ARP spoofing can change traffic paths and increase RTT between hosts.
• North-South vs East-West Traffic — RTT varies by traffic direction and network path in north-south and east-west flows.
• QUIC — QUIC is sensitive to RTT because it affects handshake time and request latency.
• NOC (Network Operations Center) — NOCs monitor RTT to detect delays, outages, and service degradation.
• Scrubbing Center — Scrubbing centers can raise RTT by adding traffic detours during DDoS mitigation.
• HTTP / HTTPS — HTTP and HTTPS response times are directly affected by RTT on the connection.