Zusammenfassung

  • RFC 1363 schlug eine Flussspezifikation für besondere Netzleistungen vor, etwa für Multimedia-Konferenzen. Ein Formular galt jeweils für eine Richtung; die Verzögerungsangabe nannte einen Punkt abnehmenden Nutzens statt einer absoluten Lieferfrist.
  • Die Qualität einer Zusage war ein eigenes Feld. Ein letzter Ethernet-Abschnitt konnte oft gut funktionieren und trotzdem sättigen. Daraus folgte ein anderer Vertrag als bei einer an jedem Hop durchsetzbaren Garantie.

Der verführerischste Eintrag auf einem technischen Bestellformular ist eine runde Zahl. Craig Partridge nahm in RFC 1363 vom September 1992 die 100 Millisekunden auseinander. Für eine Verbindung zwischen den USA und Japan konnte das ein erfreulicher Wert sein; für zwei Menschen in derselben Stadt ein schlechter. Das Dokument schilderte hier eine gedankliche Gegenprobe, keine Messung zweier Leitungen. Wer ein universelles Verzögerungslimit versprach, musste erklären, warum die Karte und die Erwartung der Teilnehmer keine Rolle spielen sollten.

Partridge dachte an Multimedia-Konferenzen, Visualisierung und weitere verteilte Anwendungen, deren Nutzen von Durchsatz, Wartezeit und Verlusten abhängt. Ein Host konnte vor dem Senden, beim Aufbau oder sogar während des Verkehrs mit dem Netz verhandeln. Der Entwurf bestimmte keine einzige Verhandlungsprozedur. Er bestimmte die Daten, mit denen ein Host seine Forderung beschreiben konnte. Die Angabe galt nur für eine Richtung. Ein Gespräch mit Hin- und Rückweg brauchte zwei solche Angaben.

Das Feld Minimum Delay Noticed fragte, ab welcher geringen Verzögerung eine weitere Verbesserung kaum noch bemerkt würde. Es verlangte keine maximale End-to-End-Zeit. Geografische Entfernung war dem Netz nicht immer bekannt, und bewegliche Endpunkte erschwerten einen festen Grenzwert. Auch die Behauptung, nach ungefähr 100 Millisekunden könne niemand mehr sprechen, ließ Partridge nicht gelten: Ein Gespräch mit mehreren Sekunden Pause konnte einer dringenden Angelegenheit immer noch dienen, wenn die Alternative das Abweisen der Verbindung war.

Eine Anwendung musste auch ihre eigene Last offenlegen. Nachhaltige Token-Bucket-Rate, Spitzenrate und ungefähre Burstgröße beschrieben das Angebot des Senders. Erst dann konnte das Netz eine Route beurteilen. Das RFC-Beispiel ist nüchtern: Ein Fluss mit mehr als 10 Megabit pro Sekunde gehört nicht auf eine T1-Leitung mit 1,5 Megabit pro Sekunde. Ein schöner Latenzwert verbreitert die Leitung nicht.

Am Empfänger entstand ein zweiter Preis. Sprachproben gehen in regelmäßigen Abständen auf die Reise und kommen wegen Warteschlangen mit schwankenden Abständen an. Der Empfänger muss puffern, um den Takt wiederherzustellen. Die erlaubte Verzögerungsvariation beschrieb, wie viel Speicher er dafür bereitstellen wollte; der Entwurf verband den gesamten Ankunftsspielraum mit der Datenrate. Bei Verlusten fragte er getrennt nach der Zahl in einem Intervall und nach unmittelbar aufeinanderfolgenden verlorenen Paketen. Wer nur eine Durchschnittszahl nennt, verdeckt die Unterbrechung, die mehrere Verluste am Stück auslösen.

Die größte Macht lag im Feld Quality of Guarantee. Es unterschied einen bloßen Hinweis, eine unvollkommene Garantie, vorhergesagten Dienst und eine feste Garantie. Partridge verwies auf IETF-Konferenzexperimente: Ethernet als letzte Station konnte annehmbare Leistung liefern, aber während eines Flusses in Sättigung geraten. Eine solche Route war vielleicht gut genug; sie bot keine Zusage für jeden Abschnitt. Vorhergesagter Dienst beruhte auf kooperierenden Geräten, die unter Last begrenzt nachgeben konnten. Eine unvollkommene Garantie ließ dagegen eine nicht kooperierende Stelle mit einem anderen Ausfallrisiko zu.

Bei einer festen Anforderung sollte das Netz ja oder nein sagen. Die Anwendung nannte die niedrigste noch brauchbare Leistung, das Netz suchte einen passenden Weg oder lehnte ab. Ein langes Feilschen vom Idealwert durch immer neue Routen hielt Partridge für eine schlechte Eröffnung jedes Gesprächs. Ein geänderter Vorschlag nach der Ablehnung war ein Hinweis, keine bereits eingelöste Zusage.

RFC 1363 war eine Sprache für Anforderungen, kein Bericht über ein überall installiertes Reservierungssystem. Seine scharfe Frage bleibt: Wer kennt das Verkehrsprofil, wer bezahlt den Empfangspuffer, und welcher Abschnitt kann die versprochene Güte tatsächlich halten? Ohne Antworten darauf sind hundert Millisekunden nur eine präzise klingende Überschrift.

Quellen: RFC 1363; offizieller Eintrag zu RFC 1363.