Zusammenfassung

  • RFC 1453 verlagerte die Leistungsfrage vom schnellen Netz zur Anwendung. Erst wenn Daten durch den Host rechtzeitig in Wiedergabe und Sitzung ankamen, wurde Kapazität zu nutzbarem Dienst.
  • Das Dokument warb für XTP als mechanismenreichen, politikoffenen Transport, begrenzte den Anspruch aber selbst: Priorität steuerte nicht allein die Latenz, und Treiber, Betriebssystem oder Anwendungspuffer konnten weiterhin begrenzen.
  • Die angeführten Versuche belegten Möglichkeiten in beschriebenen Umgebungen. Sie belegten weder allgemeine Verbreitung noch Ende-zu-Ende-Garantien; jede Schichtgrenze verlangte neue Beobachtung.

Die Engstelle wanderte in den Rechner

Mit FDDI, ATM und anderen schnellen unteren Schichten schien Anfang der neunziger Jahre ein altes Problem gelöst. RFC 1453 warnte vor der falschen Schlussfolgerung: Wenn die Datenleitung schneller wird, ist nicht automatisch der gesamte Dienst schneller.

William J. Chimiaks Text erschien im April 1993 als Informational. Er war kein Internetstandard und erklärte offen, Xpress Transfer Protocol, XTP, vorstellen zu wollen. Aussagen über dessen Vorzüge sind deshalb als Plädoyer zu lesen. Gerade die Grenzen, die dieses Plädoyer selbst nennt, sind historisch belastbar.

Zwischen Netzwerkkarte und Anwendung lagen Interrupts, Kontextwechsel, Speicherübertragungen, Treiber, Kernelwarteschlangen und Prozessplanung. Ein Transport konnte hohen Durchsatz melden, während der Benutzerprozess zu spät lief. Eine Empfangsstatistik konnte grün sein, während der Audiopuffer leer wurde.

Damit ändern sich die Beweisregeln. Ein Linkzähler belegt Kapazität am Link. Eine Transportmessung belegt Übergabe durch den Transport. Ob ein Bild vor seiner Frist decodiert, ob Ton und Mundbewegung zusammen präsentiert und ob die richtige Person zugelassen wurde, sind andere Tatsachen.

Eine Konferenz bestand aus ungleichen Fristen

Das im RFC beschriebene Szenario umfasste interaktive Sprache und Video, Multicast, Datentransfer, Grafik, gespeicherte Medien und Datenbankabfragen. Diese Arbeit hatte keinen einheitlichen Bedarf.

Eine Datei braucht Vollständigkeit. Bei Sprache kann ein kleiner Verlust besser sein als eine späte Wiederholung. Eine Datenbankabfrage lebt von der Umlaufzeit. Audio und Video benötigen neben ihrer eigenen Taktung eine gemeinsame zeitliche Beziehung. Mehr Durchsatz kann keines dieser Ziele allein definieren.

Auch Sitzungen hatten Zustände: beginnen, einer laufenden Sitzung beitreten, sie verlassen, ohne alle anderen zu trennen, und beenden. RFC 1453 unterschied streng kontrollierte n-zu-n-Sitzungen mit ungefähr zwei bis fünfzehn Beteiligten und locker kontrollierte Eins-zu-viele-Verteilungen.

Wer eine Konferenz finden oder betreten durfte, sollte eine obere Schicht entscheiden. Priorisierte Bytes waren keine authentisierte Identität. Transportvorrang, Sitzungssteuerung und Zugangsrecht blieben getrennte Kontrollflächen.

Dienstgüte begann beim Bedarf

RFC 1453 nannte garantierten Durchsatz, Verbindungszuverlässigkeit, erfolgreiche und abgebrochene Anrufe, tolerierbare Fehler, Kompression, Bewegungsartefakte, Flusssteuerung und Latenz. Diese QoS-Kriterien sollten von der Anwendung beziehungsweise dem Transportnutzer in die Transportschicht eingegeben werden.

Die Anwendung kennt ihre Nutzungsgrenze: wann ein Frame verfällt, welchen Verlust der Codec verdecken kann und welchen Versatz ein Gespräch aushält. Das Netz kennt Ressourcen und Warteschlangen. Dienst entsteht durch Übersetzung zwischen diesen Kenntnissen, nicht dadurch, dass ein Anbieter seine Portgeschwindigkeit „Qualität“ nennt.

RFC 1193 hatte Anforderungen als Verzögerungs-, Jitter-, Durchsatz- und Zuverlässigkeitsgrenzen aus Kundensicht beschrieben. Eine Garantie verstand der Text als bedingte Verpflichtung. Auch ohne juristische Übernahme bleibt die technische Disziplin: Eine Garantie benötigt Messgröße, Grenze, Bedingung und Prüfmethode.

Ein Gigabit sagt nichts über Kopierkosten, Prozessplanung, Pufferunterläufe, Uhren oder Zulassung. Es ist eine verfügbare Ressource, nicht die fertige Erfahrung.

XTP sollte Mechanismus von Politik lösen

RFC 1453 wandte sich gegen einen neuen Protokollstapel für jede Anwendungsklasse. XTP sollte gemeinsame Mechanismen bereitstellen, aus denen die Anwendung eine Politik bildet.

Ein 32-Bit-SORT-Feld trug Priorität. Selektive Bestätigung, schnelle negative Bestätigung und selektive Wiederholung variierten Fehlerbehandlung. Rate, Burst und Fluss waren steuerbar; Multicast und Außbandzustellung kamen hinzu. Partially Error Controlled Connections sollten nur so viel reparieren, dass die Empfangs-FIFO nicht verhungerte.

Die Nützlichkeit einer Reparatur hängt vom Zweck ab. Ein fehlender Dateiblock bleibt später wertvoll. Ein Sprachpaket nach seinem Wiedergabetermin belastet womöglich nur die Warteschlange. Eine anwendungsnahe Politik kann diesen Unterschied ausdrücken.

Wenn Mechanismen stabil und Politik veränderlich sind, kann das System sich an Linkbedingungen anpassen, ohne eine Verbindung zu schließen und einen anderen Stapel aufzubauen. Die Sitzung bleibt bestehen, während sich Fehler- oder Flussbehandlung ändert.

Das RFC zog dennoch eine klare Grenze. Die XTP-Priorität bot für sich keine Latenzkontrolle. Sie ordnete Konkurrenz, schuf aber keine Kapazität, begrenzte nicht jede Warteschlange und plante den Benutzerprozess nicht ein. Außerdem räumte der Text ein, bestehende Protokolle könnten die Anwendungen vermutlich ebenfalls tragen.

Ein vorhandener Mechanismus belegt daher nur eine Handlungsoption. Er belegt weder richtige Einstellung noch Zugriff auf die entscheidende Warteschlange noch das Ergebnis am Bildschirm.

Lokaler Erfolg enthüllte den nächsten Flaschenhals

Wenn teilweise Fehlerkontrolle die Empfangs-FIFO ausreichend füllte, konnten Anwendung, Treiber oder Betriebssystempuffer die neue Grenze werden. Messung musste dem Flaschenhals folgen.

Transportvollständigkeit kann steigen, während nutzbare Frames sinken, weil Reparaturen zu spät kommen. Der Kernelsocket kann voll und der Wiedergabepuffer leer sein. Audio und Video können einzeln ankommen und gemeinsam unsynchron sein.

Die Beweiskette lautet:

verfügbare Linkkapazität → konfigurierter Transportmechanismus → tragfähiger Hostpfad → nutzbare Medien in der Anwendung → erfüllte Sitzungsanforderungen → beobachtete Erfahrung

Jeder Pfeil benötigt neue Daten. Priorität ist keine Verzögerungsgrenze. Ein gefüllter Socket ist keine stabile Wiedergabe. Empfang beider Ströme ist keine Lippensynchronität. Paketursprung ist keine Autorisierung.

Darum nahm das RFC auch Fertigung, VLSI, parallele Zustandsmaschinen, Systemschnittstellen und Interruptkosten in den Entwurf auf. Ein Protokoll kann auf dem Papier effizient sein und an Speicher oder Ausführung verlieren. Implementierung war Teil der Dienstökonomie.

Ein Versuch beweist nur innerhalb seiner Hülle

RFC 1453 berichtete über mehr als hundert simulierte Sprachkanäle auf FDDI an der University of Virginia, eine Videomail-Demonstration mit 30 Bildern pro Sekunde, rund 25 Millisekunden vom Mikrofon zum Lautsprecher bei einem einfachen NRaD-Multicast und ein kommerzielles System mit 1,2 Mbps komprimiertem Video und mindestens zehn gleichzeitigen Strömen.

Diese Angaben waren Gegenbeispiele zur Behauptung, Paketnetze könnten solche Medien grundsätzlich nicht tragen. Sie waren keine Messung der XTP-Verbreitung, keine unabhängige Wiederholung und keine allgemeine Internetgarantie.

Für Vergleichbarkeit wären Topologie, Hardware, Last, Codec, Verlust, Wiederholungspolitik, Uhren und Messpunkte nötig. Dreißig Bilder mit langem Vorpuffer können Videomail ermöglichen und Gespräch zerstören. Hundert simulierte Kanäle sind nicht hundert verständliche Gespräche.

Die Zuschreibung muss bleiben: Das RFC berichtete diese Ergebnisse. Es beschrieb keine universelle Produktion.

Reservierter Strom, beobachteter Strom

ST-II war eine andere Architektur. Ein Ursprung beantragte einen Strom, FlowSpec beschrieb Anforderungen, Zwischenstationen reservierten Ressourcen und Ziele konnten annehmen. Beteiligte ließen sich ändern, beschädigte Äste wieder aufbauen.

Damit wurde ein Anwendungswunsch zu verteiltem Netzzustand, samt Einrichtungs- und Wiederherstellungskosten. XTP setzte auf allgemeine Mechanismen und wandelbare Politik. Beide Ansätze brauchten weiterhin Messung am Anwendungsende.

RFC 3550 definierte später RTP und RTCP für Echtzeitdaten und Überwachung. Es erklärte zugleich, RTP selbst reserviere keine Ressourcen, garantiere weder QoS noch rechtzeitige Zustellung, garantiere keine Zustellung und verhindere keine Umordnung. Sequenznummern und Berichte erzeugen Sichtbarkeit, keine Leistungszusage.

Eine direkte Abstammung von RFC 1453 zu RTP ist nicht belegt. Der Vergleich zeigt lediglich, wie sorgfältig Funktion von Garantie getrennt werden muss.

Quellen und Grenzen

Status und Einordnung stehen im RFC-Editor-Eintrag zu RFC 1453. Problem, XTP-Plädoyer, Einschränkungen und berichtete Versuche stammen aus dem Volltext von RFC 1453. Die Kundenanforderungen beschreibt RFC 1193. Das ressourcenreservierende ST-II steht in RFC 1190. Umfang und Nichtgarantien von RTP nennt RFC 3550.

Diese Quellen belegen Dokumente, Entwürfe und berichtete Ergebnisse. Sie belegen keine heutige Nutzung, Anbieterleistung, Nutzerzufriedenheit, unabhängige Replikation oder kausale Linie von XTP zu RTP.