Zusammenfassung

  • RFC 2212 setzte den Datenverkehr mit (r,b,p,m,M) in Beziehung zur reservierten Rate R und zur maximalen Abweichung jedes Netzelements vom idealen Fluidserver.
  • Der ratenabhängige Fehler C ging als C/R ein, der ratenunabhängige Fehler D unmittelbar; entlang des Pfades wurden daraus Ctot und Dtot.
  • Die Grenze galt nur bei konformem Verkehr, passender Paketgröße, erfolgreicher Zulassung, ausreichenden Ressourcen und unverändertem Pfad. Sie versprach weder Null-Jitter noch Identität, Zustellung eines bestimmten Pakets oder Anwendungserfolg.

Das nützliche Ideal war gerade kein reales Netz

RFC 2212 begann mit einer Fiktion: Ein Datenstrom erhält kontinuierlich Dienst mit der Rate R, so als verfüge er über eine eigene Leitung. Für einen Token-Bucket-Strom mit Rate r und Burstgröße b ist die Warteschlangenverzögerung in diesem Fluidmodell durch b/R begrenzt, sofern R >= r gilt.

Ein Router bedient jedoch Pakete. Er muss Rahmen serialisieren, Scheduler-Takte abwarten und andere lokale Arbeit erledigen. Der Standard versteckte diese Differenz nicht hinter dem Wort „garantiert“. Er verlangte, sie in zwei maximalen Fehlertermen zu bepreisen.

C steht für ratenabhängigen Rückstand. Seine Zeitwirkung schrumpft, wenn die reservierte Rate steigt, weshalb er als C/R erscheint. Paketisierung ist das anschauliche Beispiel. D steht für eine ratenunabhängige lokale Variation, etwa die Wartezeit bis zu einem zugewiesenen Slot oder eine feste Dienstlücke. Für ein einzelnes Element musste die Warteschlangenverzögerung unter

b/R + C/R + D

bleiben. C und D waren Höchstwerte, keine Mittelwerte und keine Messwerte eines bestimmten Pakets. Ein Element durfte besser sein; schlechter als seine ausgewiesene Grenze durfte es im abgedeckten Fall nicht werden.

Vor der Zusage stand ein fünfteiliger Verkehrsvertrag

Die TSpec bestand nicht aus einem Prioritätsbit. r bezeichnete die nachhaltige Tokenrate, b die Eimertiefe, p die Spitzenrate, m die kleinste kontrollierte Einheit und M die größte konforme Datagrammgröße. Über ein Intervall T durfte konformer Verkehr höchstens

M + min[pT, rT + b - M]

umfassen.

Die beiden Paketgrößen schlossen praktische Schlupflöcher. Ein sehr kleines Datagramm wurde bei der Überwachung mindestens als m gezählt. Überschritt das beantragte M die MTU eines Links, musste die Anfrage abgelehnt werden. Ein zu großes Datagramm erbte die Zusage nicht allein durch die Zugehörigkeit zum gleichen benannten Strom.

Die RSpec ergänzte R und S. Die reservierte Rate R musste mindestens r erreichen. Eine höhere Rate verkürzte gewöhnlich die Warteschlangenzeit. Der Slack S maß dagegen den zusätzlichen Verzögerungsspielraum, den der Empfänger gegenüber dem Ergebnis bei der beantragten Rate zuließ.

Damit war der Dienst ein Vertrag zwischen verschiedenen Kontrollflächen: Der Sender beschrieb den angebotenen Verkehr, der Empfänger verlangte Rate und Spielraum, das Netz entschied über Zulassung und Ressourcen. Keine dieser Angaben war bereits eine Beobachtung erfolgreicher Zustellung.

Die Fehler addierten sich, aber nicht die Bedeutung

Entlang des Pfades wurden die Elementwerte zu Ctot = ΣC und Dtot = ΣD addiert. Bei p > R >= r lautete die maximale Ende-zu-Ende-Grenze der Warteschlangenverzögerung:

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

Für r <= p <= R vereinfachte sie sich zu:

(M+Ctot)/R + Dtot

War die Spitzenrate unbekannt oder wurde sie nicht genutzt, blieb die konservative Form:

b/R + Ctot/R + Dtot

Die Aufteilung war operativ wichtig. Burst und Paketgröße gehörten zur Verkehrsbeschreibung. R war eine reservierte Ressource. Ctot/R bezifferte implementierungsbedingte Arbeit, deren Zeitwert von der Rate abhing. Dtot blieb Zeit. Zwei Pfade konnten daher dieselbe Rate für denselben Strom zulassen und dennoch verschiedene Grenzen besitzen.

Feste Ausbreitungs-, Übertragungs- und unvermeidbare Verarbeitungszeiten lagen außerhalb dieser Warteschlangengrenze. Für eine maximale Ende-zu-Ende-Verzögerung mussten sie separat bestimmt und hinzugefügt werden. RFC 2212 fror auch den Pfad nicht ein: Die berechnete Grenze blieb nur stabil, solange sich der Ende-zu-Ende-Pfad nicht änderte.

Slack war ein Tauschgeschäft mit Buchführung

Ein Element durfte einen Teil des vom Empfänger eingeräumten Slack verwenden, um lokal weniger Rate zu reservieren und mehr Verzögerung zuzulassen. Diese Freiheit hatte eine harte Nebenbedingung. Für eingehende Werte (Rin, Sin) und ausgehende Werte (Rout, Sout) musste gelten:

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

mit r <= Rout <= Rin.

Slack löschte die Zusage also nicht. Er verschob Ressourcen innerhalb eines erhaltenen Budgets. Das Element verbrauchte Sin - Sout, musste den Rest weitergeben und durfte denselben Spielraum nicht noch einmal verkaufen. Wer nur die endgültige Rate speicherte, aber Slackverbrauch und Ungleichung verlor, konnte später nicht mehr erklären, weshalb die Grenze Bestand haben sollte.

Teilsummen beantworteten eine andere Frage

Ctot und Dtot beschrieben den gesamten Pfad. Csum und Dsum summierten dagegen nur seit dem letzten Reshaping-Punkt. Sie dienten dazu, einen Umformpuffer zu dimensionieren. Ohne Optimierung durch die Spitzenrate war b + Csum + Dsum × R eine konservative Anforderung.

Diese Trennung verhindert drei Verwechslungen. Die Totalsumme charakterisiert die Ende-zu-Ende-Grenze. Die Teilsumme beschreibt, wie viel Verzerrung seit einem Reshaper aufgelaufen ist. Eine Paketmessung zeigt, was tatsächlich beobachtet wurde. Keine der drei Aufzeichnungen ersetzt die anderen.

Wenn der Sender seine TSpec verletzte, konnten Datagramme nicht einfach den garantierten Status behalten. Am Rand sollten nicht konforme Pakete normalerweise als Best Effort weiterlaufen. Im Inneren musste die Überwachung die durch Burstbildung verursachte Verzerrung berücksichtigen und häufig mit Reshaping arbeiten.

Eine obere Grenze glättete keinen Takt

Der Standard kontrollierte die maximale Warteschlangenverzögerung. Er minimierte nicht die Differenz zwischen frühester und spätester Ankunft. Viele Pakete konnten lange vor dem schlimmsten zulässigen Zeitpunkt eintreffen; eine Wiedergabeanwendung brauchte deshalb weiterhin einen Empfängerpuffer.

Eine Deadline war somit keine Zusage gleicher Abstände, niedriger Durchschnittslatenz oder Null-Jitter. Ebenso war der Schutz vor Warteschlangenüberlauf bedingt: Der Verkehr musste konform bleiben, die Reservierung zugelassen sein, jedes relevante Element den Dienst unterstützen oder hinreichend nachbilden, Bandbreite und Puffer mussten genügen, die maximale Paketgröße musste eingehalten werden und weder Komponentenausfall noch Routenwechsel durfte die Prämissen aufheben.

Die Zahl gehörte nur zu einer Stufe

RFC 2212 schrieb keinen einzigen Einrichtungsmechanismus vor. RSVP konnte die Parameter transportieren, doch auch manuelle Konfiguration oder ein Managementprotokoll konnte die Reservierung herstellen. RFC 2210 beschrieb separat die RSVP-Objekte und hielt Authentisierung, Abrechnung und Policy von den QoS-Kontrollobjekten getrennt.

Daraus entsteht eine Kette verschiedener Belege: Eine TSpec ist eine Erklärung zulässigen Verkehrs. Eine RSpec ist eine Anforderung. Eine Zulassungsentscheidung weist Ressourcen zu. C und D charakterisieren den Dienst. Die Formel liefert unter ihren Prämissen eine Grenze. Paketbeobachtung belegt Verkehr auf einem konkreten Pfad. Erst die Anwendung bestimmt, ob das Ergebnis nützlich war.

Ein zugelassener FLOWSPEC bewies nicht fortdauernde Konformität. Eine berechnete Grenze bewies nicht die Ankunft eines einzelnen Pakets. Ein angekommenes Paket authentisierte keinen Sender und bewies keine Berechtigung. Selbst die Zustellung garantierte weder Dekodierung noch Anzeige, Speicherung oder richtige Reaktion.

Gerade darin lag die Stärke von RFC 2212: Es machte eine technische Stufe präzise, ohne ihr Autorität über alle späteren Stufen zu geben.

Quellen und Grenzen

Die Quellen tragen die Dienstdefinition und ihre analytischen Grenzen. Sie belegen weder die historische oder heutige Verbreitung noch das Verhalten eines bestimmten Routers, reale Messwerte oder eine direkte Abstammung späterer QoS-Systeme.