Zusammenfassung

  • RFC 3393 definiert IPDV als Differenz der Einweg-Laufzeiten eines ausgewählten Pakets Paars und trennt diesen Einzelwert von Stichprobe und daraus berechneten Statistiken.
  • RFC 4148 versuchte, IPPM-Metriken zu registrieren. RFC 6248 befand später, Type-P-, Metrik- und Stromparameter verhinderten eine eindeutige Identifikation; RFC 8911 reagierte mit präziseren Einträgen und festen beziehungsweise Laufzeitparametern.

Die Arbeitsgruppe IP Performance Metrics wollte 2002 nicht jede Laufzeitänderung auf einem Pfad in eine einzige Zahl pressen. RFC 3393 definiert zunächst einen Einzelwert: Man wählt zwei Pakete zwischen einem Messpunkt und einem anderen und zieht die Einweg-Laufzeit des ersten Pakets von der des zweiten ab. Die Auswahlregel zählt. Die Pakete können aufeinanderfolgen, festgelegte Indizes tragen oder nach einer anderen offengelegten Regel ausgewählt werden. Dieser Einzelwert ist weder eine Verteilung noch ein Perzentil oder ein Urteil über Dienstqualität. RFC 3393 definiert getrennt davon eine Stichprobe aus einem Poisson-Strom und dazugehörige Statistiken. Berichte müssen die Parameter nennen, damit sich die Aussage der Messung bestimmen lässt. RFC 3393

Die Flexibilität war beabsichtigt. Verschiedene Anwendungen und Versuche können andere Pakettypen, Paar-Auswahlen oder statistische Zusammenfassungen brauchen. RFC 3393 hält zudem fest, dass eine Differenzmessung einen festen relativen Uhrenversatz an den Endpunkten aufheben kann. Uhrenabweichung, Drift, Paketabstände und sonstige Messfehler behandelt der Text gesondert. Die Bedeutung eines Messwerts ergibt sich also auch aus den Entscheidungen, die ihn erzeugen. Selbst „Jitter“ war mehrdeutig: RFC 3393 bevorzugt „delay variation“, weil Signaltechnik und Informatik denselben Ausdruck verschieden verwendeten.

Drei Jahre später sollte RFC 4148 IPPM-Metriken in einem Register zusammenführen. Das Dokument vergab OBJECT-IDENTITIES an definierte Metriken und führte die Paketlaufzeitvariation aus RFC 3393 neben Verzögerungs-, Verlust- und weiteren Metriken. Der Zweck lag auf der Hand: Ein beständiger Bezeichner erleichtert Verweise über mehrere Spezifikationen hinweg. Doch das Register übernahm die Variabilität von Type-P-Paketen, Metrikparametern und Stromparametern. Ein knapper Registername konnte nicht von allein alle Entscheidungen festlegen, die die Beobachtung wesentlich beeinflussen. RFC 4148

2011 benannte RFC 6248 diese Lücke ausdrücklich. Weil sich IPPM-Metriken mit der Registerstruktur nicht eindeutig bestimmen ließen, erklärte das Dokument RFC 4148 und das zugehörige IANA-Register für obsolet. Jede Kombination aus Pakettyp, Metrik- und Stromparametern einzutragen sei weder machbar noch sinnvoll. Das alte Register habe „sehr wenige Nutzer, wenn überhaupt“ gehabt; auf einen Interessensaufruf im zweiten Halbjahr 2010 habe sich niemand gemeldet. Diese Aussagen betreffen das Register, nicht die Nutzung von Messungen zur Laufzeitvariation. Die bisherigen Einträge blieben erhalten, neue kamen nicht mehr hinzu. RFC 6248

Die Lehre bestand nicht darin, Parameter abzuschaffen. Entscheidend war, welche Parameter zur Definition gehören und welche erst bei der Messung gewählt werden dürfen. Das spätere Performance Metrics Registry aus RFC 8911 unterscheidet feste Parameter, deren Änderung eine andere registrierte Metrik bedeutet, von Laufzeitparametern, die ein Messagent bei der Ausführung erhält. Außerdem muss ein Vorschlag verständlich, implementierbar, einsetzbar, nützlich und so eng definiert sein, dass gleichwertige Ergebnisse möglich sind. RFC 8912 füllte die ersten Einträge ein. Der Entwurfswechsel ist klar: Ein Katalog musste genug Methode beschreiben, damit eine andere Partei eine Messung auswählen oder ausführen konnte – nicht nur ihren Namen erkennen. RFC 8911 RFC 8912

RFC 3393 wurde nicht mit RFC 4148 obsolet, und das spätere Register garantiert nicht, dass alle IPDV-Ergebnisse vergleichbar sind. Dauerhaft wichtig bleibt der Unterschied zwischen einer Metrik als Konzept und einem Messverfahren als ausführbarem Satz von Entscheidungen. Ein Register kann diese Entscheidungen nur koordinieren, wenn es offenlegt, was feststeht, was variabel bleibt und wie das Ergebnis zu lesen ist.

Quellen

RFC-3393-Informationen · RFC 3393 Text · RFC 4148 · RFC 6248 · RFC 8911 · RFC 8912 · RFC 5481 · RFC 2330 · RFC 2679 · RFC 7679 · RFC 3357 · RFC 5148 · Verifiziertes redaktionelles Erratum 6981 · Verifiziertes redaktionelles Erratum 8282