Zusammenfassung

  • RFC 9971 beschreibt MLRsearch, eine Labormethodik, die für ein deklariertes System und Verkehrsprofil eine oder mehrere Verlustquoten-Suchziele und jeweils zugehörige Grenzen ausweist.
  • Der bedingte Durchsatz ist Beleg für die dokumentierte Versuchsanordnung, nicht für eine zugesagte Produktionskapazität, ein Anwendungsergebnis, eine Lieferantenpflicht oder einen SLA-Nachweis.
  • Wer die Zahl für Betrieb, Beschaffung oder Freigabe nutzen will, braucht zusätzlich Produktionsbelege und eine lokal verantwortete Entscheidung mit klarer Rücknahme.

Eine Zahl beantwortet nur die Frage, die ihr gestellt wurde

RFC 9971 nennt die Methode Multiple Loss Ratio Search. Sie soll bei Datenebenen-Benchmarks Wiederholbarkeit und Vergleichbarkeit verbessern und die Suchdauer verkürzen. Besonders relevant ist dies für softwarebasierte Netzfunktionen auf allgemeiner Hardware. Der RFC sucht jedoch keine kontextfreie Wesenseigenschaft eines Produkts. Er beschreibt Trials mit gewählten Lasten und Dauern, aus denen Ergebnisse für ausdrücklich definierte Search Goals hervorgehen.

Damit ein anderer Teststandort das Resultat einordnen kann, muss der Bericht sein SUT, Verkehrsprofil, Rahmengrößen, Richtung, angebotene Last, Trial-Dauer, Verlustziel und die akzeptierte Breite zwischen Grenzen nennen. Ohne diese Angaben ist ein Durchsatzwert keine vergleichbare Kapazitätsmessung. Er ist eine Behauptung ohne wiederholbaren Weg.

RFC 9971 ist Informational. Die BCP-14-Sprache verlangt Präzision von Verfahren, die MLRsearch-Konformität beanspruchen; sie verpflichtet niemanden zur Einführung und bestätigt keine Implementierung. Der RFC ist unabhängig von RFC 2544, ändert oder ersetzt ihn nicht. Ein einzelnes Ziel kann unter besonderen Einstellungen RFC-2544-Bedingungen erfüllen. Diese Aussage gehört aber in den Testbericht und folgt nicht aus dem Namen der Methode.

Das getestete System reicht über die Funktion hinaus

Der Unterschied zwischen DUT und SUT ist entscheidend. Das DUT ist die untersuchte Weiterleitungsfunktion. Das SUT ist die Gesamtheit, der Stimulus angeboten und deren Antwort beobachtet wird. Bei Software gehören dazu womöglich Host, Firmware, Betriebssystem, Hypervisor, Treiber, Netzkarte, Ein-/Ausgabe und konkurrierende Lasten. Derselbe Programmstand kann deshalb mit einem anderen Umweltsystem ein anderes Trial-Ergebnis erzeugen.

RFC 9971 fasst Störungen des SUT und schwer trennbare Schwankungen innerhalb der Funktion als noise zusammen. CPU-Planung, Speicher- oder I/O-Druck, Nebenlast oder internes Verhalten können sich als Verlust zeigen. Eine endliche Testreihe weist nicht jeder verlorenen Frame eine endgültige Ursache zu. Sie erzeugt eine nachvollziehbare Beschreibung der beobachteten Bedingungen und Grenzen.

Ein Benchmark darf daher über das erklärte SUT sprechen. Er beweist keine zeitlose Leistungseigenschaft außerhalb dieses Systems und erst recht keine Kapazität eines Produktionsdienstes mit wechselnden Pfaden, Wiederholungen, Kundenregeln, Abhängigkeiten und Ausfallzuständen.

Verlustziele machen die Wertentscheidung sichtbar

RFC 1242 definiert Throughput als höchste Rate ohne Verlust angebotener Frames. Diese Definition bleibt wichtig. Nahe einer Softwaregrenze können Trials jedoch inkonsistent sein: Ein höheres Load kann eine niedrigere Loss Ratio zeigen als ein früheres niedrigeres Load. Eine einzelne Zahl verdeckt dann, wer Dauer, Präzision und den Umgang mit dieser Inkonsistenz gewählt hat.

MLRsearch legt die Rollen offen. Der Manager konfiguriert und erstellt den Test Report; der Controller wählt Lasten und Dauern; der Measurer führt Trials aus. Das sind abstrakte Funktionen, keine Pflicht zu drei Produkten. Jedes Search Goal hat eigene Bedingungen. Für ein regelmäßiges Ergebnis nähern sich relevante Unter- und Obergrenze nach der deklarierten Goal Width an.

Mehrere Verlustziele sind möglich. Daraus folgt nicht, dass geringe, aber nicht null Verlust überall akzeptabel sind. Der RFC hält fest, dass kein Konsens über ein universell bestes Verlustziel besteht und dass der Zusammenhang zwischen Trial-Verlust und höherer Schicht nicht einfach ist. Dieselbe Quote kann für TCP, Echtzeitverkehr, Replikation oder Sicherheitssteuerung etwas anderes bedeuten. Die Toleranz ist eine lokale Entscheidung derjenigen, die die Folge tragen, und muss als solche dokumentiert werden.

Wiederholbar ist nicht gleich repräsentativ

Ein wiederholbarer Test erkennt kleine Regressionen in einer festen Laborumgebung. Er kann aber auch einen unrepräsentativen Verkehr sehr präzise wiederholen. RFC 9971 lässt interne Lastwahl-Heuristiken des Controller absichtlich implementierungsspezifisch und schreibt keine universelle Zielkonfiguration vor. Diese Lücke ist nicht für Werbeaussagen bestimmt. Sie markiert eine Entscheidung, die der lokale Betreiber erklären muss.

Heng Lus Running-Code Primacy führt zur gleichen Praxis: maßgeblich sind ausgeführter Code, aktive Konfiguration, tatsächlich angebotener Verkehr und Rohbeobachtung, nicht das Prestige des Wortes Benchmark. Eine gemeinsame Spezifikation erleichtert Vergleich, aber sie überträgt nicht die Befugnis, die verkaufte Kapazität, das zulässige Risiko oder eine fremde Betriebsentscheidung festzulegen.

Die Brücke zur Entscheidung muss separat gebaut werden

Bewahren Sie vier getrennte Akten auf. Die Benchmark-Akte enthält Build, Hardware- und Virtualisierungsgrenze, Profil, Ziele, Dauer, Werkzeuge und Rohresultate. Die Interpretationsakte formuliert nur die enge technische Aussage, etwa keine Regression gegenüber einer Laborbasis. Die Produktionsakte enthält reale Queue-, CPU-, I/O-, Retry-, Transaktions- und Service-Canary-Belege. Die Entscheidungsakte nennt Verantwortliche, Schwellen, Ausnahmen, Ablauf und Rollback für Release, Kauf oder Kapazitätsreservierung.

Ein Benchmark kann Beschaffung informieren, ersetzt aber weder Abnahmelast noch Vertrag. Er kann Kapazitätsplanung informieren, ersetzt aber keine Spitzenverteilung, Fehlermarge oder konkurrierende Last. Er kann einen Release-Gate speisen, ersetzt aber keine Kompatibilitäts-, Sicherheits-, Rollout- und Rücknahmeprüfung. Ein SLA ist eine Zusage für einen definierten Dienst und Zeitraum, nicht die Erinnerung an einen gelungenen Frame-Test.

Auch eine vorsichtige Untergrenze reserviert keine Zukunft. Ein schwaches Ergebnis beweist umgekehrt weder Lieferantenverstoß noch Produktionsursache. Beides sind Anlässe für überprüfbare Hypothesen, nicht fertige Urteile.

Quellen