Networking · Network Performance
One-Way Delay and the Clock Offset Problem
Why a one-way delay measurement needs synchronised clocks, how a constant offset biases the result, and how two-way exchanges bound the error.
A round-trip measurement is the sum of two one-way delays, and splitting it requires knowing how the total divides. The division is not a constant of the path: forward and reverse directions can differ by a large factor, because routing policy, queueing, and link rates are chosen independently per direction. Measuring one direction directly requires a timestamp taken at each end, and that requires the two clocks to agree. The agreement is the hard part, and the error it leaves behind is the dominant uncertainty in most one-way figures. The terms that make up the total, and the way each direction contributes them, are set out in decomposing path latency.
The IPPM framework defines one-way delay precisely as the difference between the time a packet’s first bit arrives at one observation point and the time it arrives at another, with the timestamps taken by the clocks at those points. Everything else in a practical measurement is an attempt to make that definition usable given that clocks are imperfect.
The bias a constant offset produces
Suppose the sender’s clock is ahead of the receiver’s by an offset $\theta$. A packet transmitted at sender time $t_1$ arrives at receiver time $t_1 + d + \theta$, where $d$ is the true one-way delay. The receiver computes $t_2 - t_1 = d + \theta$ and reports that as the delay. The error is the offset, added in full to the measurement, and it is indistinguishable from real delay in a single observation.
The magnitude matters. A clock synchronised by a typical network time protocol client on a well-behaved path is usually within a few milliseconds of true time, and often within one. A clock that has lost synchronisation and is free-running can drift by seconds per day, so its offset after a week without a source is large enough to make any delay measurement meaningless. An offset of 10 ms on a path whose true one-way delay is 15 ms produces a reported 25 ms, an error larger than the quantity being measured.
A varying offset is worse than a constant one, because it cannot be calibrated out. If the two clocks drift at different rates, the offset changes over the course of a measurement run, and the change appears as apparent delay variation. A pair of clocks drifting apart at 50 parts per million, which is within the tolerance of an uncompensated crystal, accumulates 50 microseconds of offset per second, or 3 milliseconds per minute. Over an hour-long measurement that is 180 milliseconds of apparent delay drift, which swamps any real variation in the path.
How a two-way exchange bounds the offset
The classical technique for estimating an offset uses a two-way message exchange, and it produces both an estimate and a bound on its error.
The client sends a request and records time $t_1$ by its own clock. The server records the arrival time $t_2$ by its clock and the departure time $t_3$ of its reply. The client records the arrival time $t_4$. Assuming the forward and reverse network delays are $d_1$ and $d_2$, the observable quantities satisfy
$$t_2 - t_1 = \theta + d_1, \qquad t_4 - t_3 = d_2 - \theta$$
The offset can be solved for only if $d_1$ and $d_2$ are known, and they are not. The standard estimator assumes they are equal, which gives
$$\theta \approx \frac{(t_2 - t_1) + (t_3 - t_4)}{2}$$
and a round-trip delay of $(t_4 - t_1) - (t_3 - t_2)$. The assumption of equal delays is where the error enters: if the forward path is slower than the reverse by an asymmetry $\delta$, the estimate is wrong by $\delta/2$. The round trip bounds the error, because the total $d_1 + d_2$ is known, so the offset estimate’s error cannot exceed half the round-trip time. That bound is loose when the round trip is large but it is a genuine bound, and it is why synchronisation accuracy is usually quoted as a fraction of the round trip to the time source.
Repeated exchanges improve the estimate by filtering, not by changing the bound. Each sample has an error bounded by half its own round trip, and a filter that selects the samples with the smallest round trips reduces the bound, on the reasoning that a short round trip is less likely to contain a large asymmetry. This is the basis of the clock selection and filtering algorithms in the network time protocol, which combines samples from multiple servers and prefers those whose measured round trip is small and whose offset estimates agree.
Hardware timestamping and the parts that remain
The largest avoidable error in a software-timestamped measurement is the path between the wire and the timestamp. A packet arriving at a network interface is copied to memory, queued, and eventually handled by the kernel, which reads the clock at that point. The interval between the wire event and the clock read includes interrupt latency and queueing in the receive path, and it can vary by microseconds to milliseconds depending on load.
Hardware timestamping moves the clock read to the network adapter, which records the time at which the packet’s start-of-frame delimiter crossed the interface. The adapter’s clock is disciplined from the same source as the system clock, and the timestamp is delivered with the packet. This removes the receive-path latency from the measurement, leaving the adapter’s own clock accuracy as the residual.
Even with perfect timestamping at both ends, three things remain. The clocks still have to be synchronised to each other, which returns to the offset problem. The timestamp is taken at a point on the interface, not at the application, so any queueing between the interface and the application is excluded from the measurement even though it is real delay from the application’s perspective. And the two observation points are not the two endpoints of interest: a measurement between two hosts includes the hosts’ own network stacks, while a measurement between two switches on the path excludes them.
Precision time protocol and its assumptions
The precision time protocol defined in IEEE 1588 was designed for local networks where sub-microsecond agreement is needed. It uses the same two-way exchange as network time protocol but relies on hardware timestamping at every device on the path, and on transparent clocks that measure and compensate for the time a synchronisation message spends queued inside a switch. A boundary clock terminates the protocol and re-serves it, so each segment’s delay is measured separately rather than accumulated.
The assumptions are what limit it. It assumes the path between master and slave is symmetric, or that the asymmetry has been measured and corrected. It assumes every device in the chain participates; a non-participating switch in the middle introduces queueing delay that the protocol cannot see. And it assumes the master’s clock is accurate, which in practice means a source traceable to a national time standard.
These assumptions are reasonable inside a data centre where the operator controls every device. They are not reasonable across the public Internet, where the path crosses equipment belonging to other parties, and where the asymmetry between directions is unmeasured and can be milliseconds. A one-way delay measurement across the public Internet therefore inherits an uncertainty of the same order as the quantity it is trying to report, which is the reason most wide-area latency figures are quoted as round trips.
Reporting what the measurement can support
The practical consequence is a discipline about what a one-way figure means. A one-way delay reported without a statement of clock uncertainty is not interpretable, because the reader cannot tell whether the number reflects the path or the clocks. A figure quoted to the microsecond from software timestamps on unsynchronised hosts is almost certainly reporting the offset.
The useful practice is to report the round trip alongside the one-way split, to state the synchronisation method and its bound, and to report the asymmetry assumption explicitly. Where the split cannot be justified, the round-trip figure is the honest one, and it supports the conclusions that matter for most engineering: whether a path is faster or slower than its predecessor, and whether the change is larger than the measurement’s uncertainty. The complementary problem of what a round-trip probe can and cannot establish about the same path is treated in what ICMP echo and TTL probing actually measure.
References
- RFC 7679: A One-way Delay Metric for IPPM — IETF
- RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification — IETF
- IEEE 1588: Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems — IEEE