Per-Packet Provenance Part 0: Introduction
Not at all like the Law Of Thermodynamics, but inevitably calling it to mind, when I considered that I had a lot to write up, and then I decided that the preceding Part 1 would be part of a series, and named it “Per-Packet Provenance” on the spot. The “series” wasn’t very well planned then, but now I’ve had time to think about it, hence this “Part 0” which expands on exactly what “Per-Packet Provenance” refers to.
“Per-Packet Provenance” describes the nature of an exercise where there is no “packet loss”, but an accounting for where each and every packet went, and why it went there. This goal, resides immediately on the other side of an asymptote, but the examination of simplified cases might reveal somethings that help sort out a more complicated case.
For example, upcoming Part 2 describes a scenario where 2 test machines run 4,308 nuttcp tests across a simple network, while watching a collection of packet counters, and shows that in that scenario, the packets that are not delivered to the receiving nuttcp app are dropped in Ethernet driver queue overflows on the receiving machine. This effect, when left unobserved, is left to be considered as “loss” from an unknown effect, occurring in some unknown, perhaps observable place.
So the P-PP Series is about the question “what can be observed about packet ultimate packet outcomes in the simple test network that informs our testing of the real network?” or perhaps “Where, oh where has my little packet gone?”
Per-Packet Provenance, Part 1: Managing Burst Size To Sidestep Queue Drops Per-Packet Provenance Part 2: Non-delivered Packets In nuttcp/iperf3 UDP Tests
Comments are currently closed.