Summary

  • RFC 3393 defined IP packet delay variation as the difference between the one-way delays of a selected packet pair, then separated that singleton from the sample and statistics built from it.
  • RFC 4148 tried to register IPPM metrics, but RFC 6248 later said its structure could not uniquely identify metrics amid Type-P, metric and stream choices; RFC 8911 responded with tighter entries and fixed versus runtime parameters.

In 2002, the Internet Performance Metrics working group did not try to make every path variation mean one number. RFC 3393 defined a singleton: take two selected packets travelling from one measurement point to another, then subtract the first packet's one-way delay from the second's. The selection function matters. The pair could be consecutive, indexed, or selected by another stated rule. A singleton was not yet a distribution, a percentile or a verdict on service quality. RFC 3393 separately defined a Poisson-stream sample and statistics, and said reports had to include the associated parameters so readers could tell what a result meant. RFC 3393

That flexibility was intentional. Different applications and experiments might need different packet types, pair-selection functions or summaries. The same document notes that a differential measurement can cancel a fixed clock offset between endpoints, but spends separate sections on skew, drift, timing intervals and other errors. The metric's value therefore depended not only on its label, but on the choices that made a particular observation. Even “jitter” was unsettled: RFC 3393 preferred “delay variation” because the other word carried different meanings in signal engineering and computing.

Three years later, RFC 4148 tried to give IPPM measurements a registry. It assigned OBJECT-IDENTITIES to metrics and listed RFC 3393's delay-variation work alongside delay, loss and other measurements. The appeal was clear: a stable identifier could help people refer to a metric across specifications. But the registry inherited variability in Type-P packet properties, metric parameters and streams. A short registry label could not, by itself, settle every choice that materially shaped the observation. RFC 4148

In 2011, RFC 6248 made that gap explicit. It declared RFC 4148 and its IANA registry obsolete because the registry was not detailed enough to uniquely identify IPPM metrics. It said registering every combination of packet type, metric parameter and stream parameter was not feasible or useful; it also reported that the old registry had “very few users, if any,” and that no one responded to a call for interest during the second half of 2010. Those are claims about the registry, not evidence that the underlying delay-variation measurement had no users. The old registry's contents remained available; they simply stopped receiving new registrations. RFC 6248

The lesson was not to remove parameters from measurement. It was to decide which parameters belong inside the definition and which can vary when a measurement runs. RFC 8911's later Performance Metrics Registry distinguishes fixed parameters—whose changed values define a different registered metric—from runtime parameters that an agent can receive at execution. It also asks whether a proposed entry is interpretable, implementable, deployable, operationally useful and tightly specified enough to support equivalent results. RFC 8912 populated that registry with initial entries. The sequence marks a change in design: a catalogue needed to describe enough of a method that another party could choose or run it, not just recognize its name. RFC 8911 RFC 8912

RFC 3393 did not become obsolete with RFC 4148, and the later registry is not proof that every IPDV result is comparable. The durable distinction is between a metric as a concept and a measurement method as an executable set of choices. Registries can coordinate those choices only when they say which ones are fixed, which remain variable, and how the result should be interpreted.

Sources

RFC 3393 information record · RFC 3393 text · RFC 4148 · RFC 6248 · RFC 8911 · RFC 8912 · RFC 5481 · RFC 2330 · RFC 2679 · RFC 7679 · RFC 3357 · RFC 5148 · Verified editorial Erratum 6981 · Verified editorial Erratum 8282