One way Latency


One way Measurement Mechanism

The trafMon tool administrator can configure matching criteria for some uni-directional flows (define flow class) whose successive packets pass in front of two or more probing points in their network travel from source to destination. Those probing points are named “hops“.

Every corresponding flow packet is hashed (using MD5) in such a way as to produce a unique signature, which differentiates successive packets, but produces the same value for a given packet in the successive probes. The probe systems must be kept synchronised as closely as possible, e.g. through distributed GNSS-based NTP servers (accuracy around the millisecond despite the geographical distance).

For every matched packet, the probe at each hop produces both the signature and the capture timestamp. Those partial observations are centralised by the concerned probes in the data collector run-time process. This central component reconciles the chunks of observations received about a same observed packet from the several probes over the network path. The collector is therefore able to deduce either:

  • the timestamp at successive network hop, or the latency delay between a given pair of hop,
  • or the fact that a packet has been lost between two hops, due to lack of observations received about the remaining hop(s), after a timeout longer than the reasonably expected network travel duration,
  • or, more surprisingly, that a packet observation is available for the last hop(s), but has not been received for previous hop(s) in the expected network travel path: partly missed packet – this can be due to a stopped probe, to saturation at a packet capture point, to a broken path between a probe and the collector (although the underlying protocol is made resilient) or to the match of packets that are not routed via the expected path,
  • and/or, that a missing partial packet observation is received later than the end of the time window within which all chunks of observations for a given packet are expected to be centrally collected: dropped packet observation.

 The evolution of the counters for these last three types of anomalies is presented in the One way Counters Report.

One way Latency Distribution

The latency measurements are partitioned into configurable slices. A 3-dimensional bubble chart is used to depict, in a single figure, the distribution histogram of latency buckets as well as its evolution over the requested time span (see Two way Delays Report for explanation).

In the below example, the typical nominal latency for the flow instance is near to zero and stable. But a sudden traffic peak saturation or network slow down arises which increases the travel time of the packets, and in a hectic way. Due to increased size of the bubbles, it is more probably an increase of traffic volume that is the root cause. Progressively the increased latency tends to converge around 1.5 millisecond, while the traffic remains sustained, until 22:53, where the peak disappears the nominal flow behaviour is restored.


One way Latency Average

Although grouping all useful information in a single figure, bubble charts are often difficult to read and interpret. Worse, in many cases, bubbles are so small that they are not even drawn: some bucket aren’t visible or, even, the entire chart body appears empty!

To enhance and complement the distribution view, the average latency evolution can be plotted as a single line.

And, to complement this picture with precise information, a tabular list of successive values can also be added.