Zusammenfassung

  • RFC 1242 definierte Durchsatz als die höchste angebotene Framerate, bei der das Gerät keinen angebotenen Frame verwirft – nicht als Gesamtnote für Leistung oder Dienstqualität.
  • Latenz, Frameverlust, Back-to-back-Bursts, Überlast, Neustart und Einzel-Frame-Verhalten bildeten getrennte Beweisflächen mit jeweils eigenen Bedingungen und Einheiten.
  • Spätere BMWG-Dokumente ergänzten Verfahren und Geltungsgrenzen; ein Messwert muss deshalb Framegröße, Last, Richtung, Prüfobjekt und Laborumgebung behalten.

Eine Sprache gegen die bequeme Höchstzahl

Im Juli 1991 veröffentlichte die Benchmarking Methodology Working Group der IETF RFC 1242. Das Dokument führte weder ein Routingprotokoll noch ein Paketformat ein. Es ordnete die Begriffe, mit denen Tests von Routern, Bridges und verwandten Kopplungsgeräten beschrieben wurden.

Am Anfang stand ein Marktproblem. Anbieter konnten durch „specsmanship“ einen günstigen Wert herausstellen und die Vergleichbarkeit des Rests dem Leser überlassen. RFC 1242 zertifizierte kein Gerät und erstellte keine Rangliste. Stattdessen erhielt jeder Begriff eine feste Form: Definition, Erläuterung, Maßeinheit, offene Fragen und Verweise.

Diese Form zwang die Bedingungen in die Aussage hinein. Framegröße, Richtung, angebotene Last und Pfad waren keine nachträgliche Dekoration. Wer sie entfernte, kürzte nicht bloß den Bericht, sondern löschte die Identität der Messung.

Null Verlust markierte nur eine Grenze

Durchsatz war die maximale Rate angebotener Frames, bei der das Gerät keinen dieser Frames verwarf. Die Null war absichtlich streng. Schon ein fehlender Frame konnte ein höheres Protokoll in eine Erholungsschleife zwingen; gesucht wurde daher die höchste Rate unterhalb dieses Ereignisses.

Der Wert durfte jedoch nicht frei schweben. RFC 1242 verlangte Messungen mit unterschiedlichen Framegrößen. Bei Geräten, die routeten und bridgten, waren beide Funktionen getrennt zu messen. Die aufgeführten Fragen reichten vom einzelnen zum aggregierten Pfad, von uni- zu bidirektionalem Verkehr und bis zur Prüfsummenverarbeitung.

Ein Nullverlustwert verband somit einen bestimmten Reiz mit einer bestimmten beobachteten Antwort. Er sagte nicht, dass das Gerät bei einer anderen Framegröße, in beiden Richtungen, über mehrere Ports, mit aktivierten Filtern oder während zusätzlicher Kontrollarbeit ebenfalls verlustfrei blieb. Noch weniger sagte er etwas über das Ergebnis eines Endkundendienstes.

Nach der Null begann die Verlustkurve

Die Frameverlustquote war nicht einfach ein misslungener Durchsatztest. RFC 1242 definierte sie unter konstanter Last als den Anteil jener Frames, die wegen mangelnder Ressourcen nicht weitergeleitet wurden, obwohl sie hätten weitergeleitet werden sollen. Ausgegeben wurde die Beziehung zwischen angebotener Last und Verlustquote.

Damit beschrieb die Kurve das Verhalten jenseits der verlustfreien Grenze. Zwei Geräte konnten dieselbe letzte Nullverluststufe erreichen und sich danach völlig unterschiedlich verschlechtern. Das eine verlor schrittweise mehr, das andere kippte abrupt. Wer nur die letzte erfolgreiche Zelle behielt, verlor genau diese Information.

Überlast bildete wiederum eine eigene Lage. Wenn die Nachfrage die Ressourcen überstieg, fragte der Text nach Erreichbarkeit des Managements, nach dem Umgang mit Routinginformationen und nach der Rückkehr in den Normalbetrieb. Keine dieser Antworten steckt automatisch im Durchsatzmaximum.

Latenz hing am gewählten Uhrpunkt

Für ein Store-and-forward-Gerät begann die Latenz, wenn das letzte Eingangsbit den Port erreichte, und endete, wenn das erste Ausgangsbit erschien. Bei einem bitweise weiterleitenden Gerät lag der Startpunkt beim ersten Eingangsbit. Gemessen werden sollte über mehrere Framegrößen, ohne zwischen den Versuchen den Aufbau zu verändern.

Unter dieser Konvention konnte bei einem Gerät, das früh mit dem Senden begann, aber nach seinem Fehlerverhalten noch als Store-and-forward galt, sogar ein negativer Wert entstehen. Das war kein Zeitreiseeffekt. Es zeigte, dass eine Konvention Beobachtungspunkte festlegt, ohne daraus die interne Architektur abzuleiten.

Null Verlust und geringe Verzögerung konnten gemeinsam auftreten, doch das eine bewies das andere nicht. Auch die Streuung blieb sichtbar: Ein niedriger Mittelwert ersetzte keine Aussage über zeitkritische Ausreißer.

Ein Burst war kein Dauerstrom

Back-to-back bezeichnete gleich lange Frames mit dem kleinsten legalen Abstand des Mediums, gesendet aus einem Ruhezustand. Das Ergebnis war die Anzahl der Frames einer bestimmten Länge, die ein Gerät in einem Burst aufnehmen konnte. Der Begriff zielte auf die Pufferung.

Diese Zahl war kein dauerhafter Durchsatz. Ein Gerät konnte seinen Puffer bereits leeren, während der Burst noch eintraf; ein anderes konnte einen kurzen Stoß aufnehmen, ohne dieselbe Rate dauerhaft zu tragen. RFC 9004 präzisierte die Methode später mit Wiederholungen, Verteilungsstatistiken, Suchgrenzen und einer korrigierten Pufferzeit, die den gemessenen Durchsatz derselben Framegröße und Verkehrskonfiguration verwendete.

Die Aktualisierung machte den alten Begriff nicht falsch. Sie zeigte, welche kausalen Verknüpfungen fehlen, wenn nur eine beeindruckende Framezahl stehen bleibt.

Seltene Zustände blieben außerhalb der Durchsatzzelle

RFC 1242 benannte Overhead als Arbeit jenseits normaler Weiterleitung: Routinginformationen, Managementanfragen, ICMP, Optionen, Fragmentierung, Fehlerbehandlung, Protokollierung und ARP. Seine Wirkung sollte in Veränderungen anderer Messgrößen sichtbar werden. Auch administrative Filter bildeten eine eigene Entscheidungs- und Lastfläche.

Das Neustartverhalten umfasste Unterbrechungen nach Einschalten, Software-Neuladen, Pufferleeren oder anderen Reinitialisierungen. RFC 6201 aktualisierte den Begriff später: Reset Time bezeichnet die gesamte Zeit außer Betrieb, einschließlich Reset und vollständiger Wiederkehr der Weiterleitung. Verlustzählung und Zeitstempel waren mögliche Verfahren, jeweils mit eigenen Anforderungen an Tester und Bericht.

Selbst ein isolierter Frame verdiente einen Test. Routenberechnung, ARP, Berechtigungsprüfung oder Cache-Aufbau konnten ihn langsamer machen als einen Frame in einem bereits laufenden Strom. Ein Gerät konnte im eingeschwungenen Zustand glänzen und beim ersten Ereignis eine ganz andere Kostenstruktur zeigen.

Verfahren ersetzte nicht den Geltungsbereich

RFC 2544 machte aus dem Vokabular später konkrete Prüfungen und Berichtsformate. Es verlangte die anwendbaren Tests und verwies auf Wiederholbarkeit, Streuung und statistische Bewertung. RFC 2285 trennte ein einzelnes Device under Test von einem System under Test sowie die beabsichtigte von der tatsächlich am Prüfobjekt angebotenen Last. RFC 2889 erweiterte den Ansatz für LAN-Switching, bei dem Richtung, Verteilung, Überlast, Adresslernen und Filterung verschiedene Fragen erzeugen.

Die schärfste Grenze zog RFC 6815. RFC-2544-Methoden waren für Geräte in einer isolierten Testumgebung entworfen, nicht für Produktionspfade mit Nutzverkehr. Ihre Überlastlasten konnten andere Nutzer schädigen; unkontrollierter physischer oder Linkverlust zerstörte zudem eine Suche, deren Endpunkt gerade null Verlust war.

Diese Grenze schützt beide Arten von Evidenz. Ein Labor charakterisiert ein kontrolliertes Gerät, ohne einen lebenden Dienst zu behaupten. Eine Produktionsmessung beobachtet einen realen Pfad, ohne die Präzision eines nicht reproduzierbaren Aufbaus auszuleihen.

Quellen und Grenzen

Grundlage ist RFC 1242, ergänzt durch den RFC-Editor-Eintrag und den IETF-Datatracker-Eintrag. Späteren offiziellen Kontext liefern RFC 2544, RFC 2285, RFC 2889, RFC 6201, RFC 6815 und RFC 9004.

Diese Quellen belegen Terminologie, Verfahren, Aktualisierungen und Einsatzgrenzen. Sie belegen kein Ergebnis eines benannten Produkts, keine konkrete Einführung von 1991, keine Verbreitungsquote, keine Messung eines Produktionspfads und kein Dienstergebnis. Eine spätere Präzisierung macht nicht pauschal alle frühen Werte falsch; sie macht den vollständigen Prüfdatensatz für ihre Deutung notwendig.