Within the context of network architectures there are two primary known approaches to packet delay measurement between points A and B in the network.
The first utilizes a measurement of the complete round-trip time for a packet travelling from point A to point B followed by another packet that subsequently travels from point B to point A. The round trip time is determined by subtracting the time that the first packet departed point A from the time that the second packet arrived at point A. Since both time stamps come from the same time source, clock synchronization is not required. To achieve this measurement, packets can either be injected (e.g. with a responder service that sends a reply back to the sender), or else timestamps can be transmitted for existing application packets by appending a header or sending the timestamps out of band. It is possible to compensate for the additional delay between the first packet being received and the second packet being sent at location B, by measuring the time difference at point B and subtracting it from the original round-trip time. While this known methodology provides an indication of the round trip measurement it suffers in that there is no indication of how the packet delays are distributed between the two directions. The assumption that traffic delay is symmetrical between two locations is not a valid assumption as the time taken by the packet in one direction is often quite different from the time taken in the other direction.
Another known technique is to measure one-way delays using synchronized clocks, such as GPS or radio based time sources. A timestamp is recorded when a packet leaves or passes point A, and a second timestamp is recorded when the packet subsequently arrives at or passes point B. Since the clocks are synchronized, the difference between these timestamps is the one-way delay. In this technique, the timestamps from point B need to be transmitted back to point A (or vice versa) for subtraction. This can be performed as a response packet, a timestamp header or some out-of-band timestamp communication.
While this method does provide an estimation of the one-way packet delays, synchronized clocks of sufficient precision are difficult and expensive to deploy in practice. For example, GPS receiver antennas require an unobstructed view of the sky, so considerable antenna cabling or clock signal distribution infrastructure is typically required.
It has also been found that network-based time synchronization available today (e.g. Network Time Protocol (NTP), an internet protocol that is based on the UDP protocol) is unable to provide sufficiently accurate synchronization for most network delay measurements. In particular, when attempting to measure network delays while using the same network for NTP synchronization, the time synchronization errors are typically larger than many measured packet delays. This results in anomalies such as measuring some one-way packet delays as negative.
Some approaches attempt to compensate for unsynchronized clocks by subtracting the most negative time difference from all the others. This does not take into account the variation over time of the clock offset between unsynchronized clocks, and therefore cannot be considered as providing an accurate estimation of the delay. Within this context it will be appreciated that the variation between clocks can be characterized as having a number of components—offset, skew and drift. Within the present specification these terms will be understood as follows—offset is the time difference between clocks, skew is the rate at which the offset changes with time, and drift is variation of the skew with time.
Other known approaches include “best fit” statistical modeling of delay estimates and clock parameters. For example the statistics of round-trip delay estimates from different paths through the network can be combined to provide a better statistical model of the one-way delays experienced by a single path through the network. Best fit modeling can also be used to compensate for clock skew when comparing recorded traces of packet timestamps from hosts with unsynchronized clocks. These approaches may improve the accuracy of simplistic one-way delay estimates, but they cannot provide reliable information about one-way delays, especially for individual packets.
There is therefore still a need to provide a method that can provide information for individual packets. There is a further need to provide a method to measure accurately the variable component of one-way point to point packet delays without the need for synchronized time sources.