RTT, Jitter, and Packet Loss: A Unified Timing Perspective

Overview

This guide treats round‑trip time (RTT), jitter, and packet loss as three manifestations of a single timing process. By understanding the what, how, and why of each concept, readers can reason about network performance and TCP decision‑making.

What Is RTT?

RTT (Round Trip Time) is the elapsed time from sending a packet to receiving its acknowledgment.

• Measured in milliseconds (ms).
• Varies per packet because of queuing, congestion, and routing decisions.
• Typical tools: ping, traceroute, TCP timestamps.

Why Baseline RTT Matters

Baseline RTT is the minimum RTT observed over a period and represents the path’s “calm” state.

• Provides a reference point for all subsequent measurements.
• Helps distinguish normal propagation delay from temporary queuing delay.
• Enables detection of abnormal latency spikes.

What Is Jitter?

Jitter is the extra delay added to the baseline RTT. It quantifies how much observed RTT deviates from the baseline.

• Always non‑negative: a packet cannot arrive faster than the baseline.
• Calculated as Jitter = Observed RTT – Baseline RTT.
• Reflects bursty, irregular network conditions.

Where Jitter Comes From

Jitter originates when packets are delayed in the network.

• Queueing in routers or switches.
• Temporary congestion on links.
• Retransmissions after drops.
• Scheduling variations in network hardware.

How TCP Learns RTT and Jitter

TCP has no a priori knowledge of path latency. It builds expectations from ACK timing.

• SRTT (Smoothed RTT): weighted average that favours recent samples.
• RTTVAR (RTT Variance): measures the variability of RTT samples.

Both values are updated on each ACK using the RFC 6298 algorithm.

What Is RTTVAR?

RTTVAR quantifies jitter from TCP’s perspective.

• Low RTTVAR → stable network, high confidence in SRTT.
• High RTTVAR → volatile network, larger safety margin needed.

How TCP Decides Packet Loss

TCP decides a packet is lost when an acknowledgment does not arrive before the Retransmission Timeout (RTO) expires.

Retransmission Timeout (RTO)

RTO is computed from SRTT and RTTVAR:

• RTO = SRTT + max(G, 4 × RTTVAR) where G is the clock granularity.
• The term 4 × RTTVAR provides a margin that accounts for jitter.

Example: SRTT = 50 ms, RTTVAR = 5 ms → RTO = 70 ms.

Delay vs. Packet Loss

TCP treats a packet as:

• Delayed if ACK arrives before RTO.
• Lost if ACK arrives after RTO (or not at all).

Thus loss is a timing decision, not a guarantee that the packet vanished.

How Jitter Turns Into Packet Loss

When jitter stays within the RTO margin, packets are merely delayed. When jitter exceeds the margin, the RTO expires and TCP interprets the delay as loss.

• Small jitter → stable RTO, few unnecessary retransmissions.
• Large or bursty jitter → frequent RTO expirations, perceived loss.

Summary

Understanding RTT, baseline RTT, jitter, and TCP’s timing mechanisms (SRTT, RTTVAR, RTO) reveals that packet loss is often a consequence of timing uncertainty rather than physical disappearance. By monitoring these metrics, engineers can tune networks, select appropriate congestion‑control algorithms, and improve overall application performance.