One way Counters
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 (see One way Latency Report),
- 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.
One way Counters Report
The report shows the respective three types of counters, as depicted here above, in three evolution charts.
The user must be aware that database records exist for this group of three metrics only when at least one anomaly has been detected for the corresponding time slot. Hence those charts can only be plotted for a limited set of time windows.
The below data are covering the same traffic peak depicted in the One way Latency Report: this peak induced a significant increase and instability of the latency of packets that succeed to traverse the network path; but it also cause a few packet losses.
