Test, QC & Monitoring Global Viewpoint – November 2021

It seems that we can measure an IP packet with either certainty of location or certainty of datarate, but not both simultaneously. The reason I say this is because of the pedantic point of where we measure the IP packet.

In SDI and AES circuits, the transport clock is embedded into the signal itself so that we have an absolute position from which to measure. The rising edge of the clock signal may be our datum point and from this we can derive measurements such as the eye height or jitter. But in asynchronous networks we don’t necessarily have this luxury.

IP is such a powerful protocol as it is transport stream agnostic. It doesn’t care or even know if it is being transferred over ethernet, WiFi, or HDLC. Switchers within the locality of the datacenter may improve their performance if they focus on IP over ethernet for example, but the actual IP packet traverses the worlds networks without any concern of the transport stream it is being carried on.

Each transport mechanism affects the IP streams in a different manner. In essence, the IP datagram is a location in computer memory and only manifests itself when being transported. And the transport mechanism directly influences the timing of the IP packet.

The distortion of timing can be seen in two ethernet circuits, one working at 100BaseT and the other at 1000BaseT. The network working at 1000BaseT is ten times faster than the 100BaseT network leading to the ethernet frame being ten times faster, or ten times shorter, depending on your point of view, which in turn makes the IP packet ten times shorter.

So, if an IP datagram can change in temporal and physical size during its transfer over multiple networks, then where is our point of reference to make absolute measurement? If we use the ethernet preamble then we’re limited to measuring only in the ethernet domain. If we use the IP header to be the point of reference, then we would have to use the first byte as the packet changes in length depending on its transport stream.

To measure the datarate of each datagram then we must measure the length of the whole datagram as well as the amount of data in it. Again, as the datagram varies in temporal length then we cannot be sure we are measuring the correct parameter.

The simple solution is to average the measurement over a number of packets to determine the average datarate. But averaging data takes us into the world of probability and statistics. We soon need to know the standard deviation and median as well as the average for the measurement to make any meaningful sense.

In effect, this is exactly what we do when making our eye height measurements by using the SDI UI filters as we’re removing the noise to give varying term statistics on the state of the signal. But the world of mesh networks operates in the statistical domain where nothing is ever certain and instead, everything is a measure of probability. The good news is, and as can be seen from the SDI UI example, we’ve already been working this way with SDI and AES but may not have realized it.