Zusammenfassung

  • Bei gleicher Priorität sollte nach RFC 1458 die höchste Anwendungsqualität zuerst fallen, wenn eine niedrigere Basisschicht ohne die Erweiterung weiter brauchbar blieb.
  • Ob die Politik wirkte, ließ sich nicht am Bit erkennen: Abhängigkeitsmodell, Kundenwunsch, MGA-Zähler, Interfacezustand, tatsächlicher Verlust, Reparatur und Anwendungsergebnis waren getrennte Belege.

In einem einzigen IPv4-Feld trafen 1993 zwei Ordnungen aufeinander. Die eine wollte dem Netz sagen, welchen Pfad es bevorzugen sollte. Die andere wollte beschreiben, welche Teile eines Bildes voneinander abhingen. RFC 1458 räumte die Unvereinbarkeit ein — und baute dennoch eine ganze Verlustpolitik auf die zweite Lesart.

Gerade dadurch wird die Schrift interessant. Sie zeigt, dass ein Zahlenrang nicht automatisch eine Wertordnung ist. Ein Paket mit mehr Details kann weniger eigenständigen Nutzen besitzen als ein grobes Fundament.

Der Bilddienst verlangte eine zuverlässige Untergrenze

RFC 1458 erschien im Mai 1993. Der RFC-Editor-Eintrag führt ihn als Informational, nicht als Internet Standard. Ausgangspunkt waren riesige digitale Fernerkundungsbilder, Tausende Terabyte pro Tag, Hunderte verteilte Betrachter, Fristen von Sekunden bis Minuten und Bandbreitenunterschiede von bis zu sechs Größenordnungen.

Eine einheitliche Zuverlässigkeit passte nicht. Eine verlorene Mausbewegung in einer Bildkonferenz konnte belanglos sein. Ein Archivbild verlangte vollständige Wiederherstellung. Hierarchische Kompression eröffnete eine Zwischenstufe: Die räumliche Basisauflösung musste zuverlässig ankommen, zusätzliche Details durften teilweise fehlen.

Der Nutzer konnte also die volle Qualität wünschen und zugleich nur für eine niedrigere Stufe verlässliche Übertragung verlangen. Wunsch, Garantiegrenze und tatsächliche Brauchbarkeit waren drei verschiedene Größen.

Verteilter Zustand statt eines einzelnen Protokolls

Der Entwurf bestand aus der Multicast Group Authority (MGA), dem Reliable Adaptive Multicast Protocol (RAMP) und verändertem Routing. Die MGA sollte Adressen und Dienste verwalten sowie Empfänger nach Qualität und Zuverlässigkeit zählen. RAMP sollte Reihenfolge, Fehlerbehebung und Rate steuern. Router sollten pro Ausgangsinterface Gruppe und angeforderte Qualitätsmenge speichern.

Eine Dienstregistrierung löste noch keine Übertragung aus. Der Server wartete auf eine Anweisung der MGA. Ein Client konnte einen noch nicht registrierten Dienst anfordern. Der erste Hörer einer Qualität konnte deren Erzeugung starten, der letzte Austritt sie beenden. Keine dieser Handlungen belegte eine zugestellte Bildschicht.

Auch ein Qualitätswechsel war eine verteilte Zustandsänderung: alten Zähler senken, neuen erhöhen, die Änderung durch die Hierarchie tragen, den Server informieren und nötigenfalls Router anpassen. Die Annahme des Wunsches war nur der Anfang dieser Kette.

TOS war kein freies Etikettenfeld

RAMP sollte Pakete für eine oder mehrere Anwendungsqualitäten markieren. Der Empfänger prüfte sowohl die Multicastgruppe als auch die verlangte Qualität. Für ältere IPv4-Umgebungen schlug RFC 1458 vor, das Type-of-Service-Feld als Bitmenge zu benutzen.

Das Dokument bezeichnete diesen Gebrauch ausdrücklich als inkompatibel mit RFC 1349. Dort war TOS ein einzelner Aufzählungswert für Netzpfad-Abwägungen: Verzögerung minimieren, Durchsatz oder Zuverlässigkeit maximieren, Kosten minimieren oder normalen Dienst wählen. Eine logische ODER-Verknüpfung mehrerer Werte sei nicht mehr sinnvoll. RFC 791 hatte Type of Service bereits als Netzbehandlung in den IP-Header gelegt.

Der Konflikt betraf Zuständigkeit. Die Internet-Schicht und die Bildanwendung beanspruchten dieselben Bits für verschiedene Aussagen. Ein Mitschnitt beweist das Muster, aber nicht die Grammatik. Dafür braucht man Protokollversion, Experimentkontext und die Konfiguration jedes interpretierenden Knotens.

Die feinste Schicht war die abhängigste

Ein Router sollte nur auf Interfaces weiterleiten, bei denen Gruppe und Qualität übereinstimmten. Bei Überlastung blieben als prioritär markierte Pakete länger erhalten. Innerhalb gleicher Priorität sollten jedoch die Pakete höchster Qualität zuerst verworfen werden.

Die Basisschicht war ohne Erweiterung nutzbar; die Erweiterung war ohne Basis womöglich wertlos. Wer die Basis behielt, erhielt die Möglichkeit eines schlechteren Bildes. Wer nur Details behielt, konnte korrekt übertragene Daten und dennoch kein Bild besitzen.

Das Beispiel unterscheidet unabhängige Q1- und Q2-Ströme von abhängigen Schichten. Unabhängige Daten laufen nur zu ihren Bestellern. Wenn Q2 für Q1 nötig ist, tragen Q2-Pakete beide Markierungen und werden an der Verzweigung in beide Richtungen kopiert. Markierung und Interfacezustand materialisieren eine Abhängigkeitsannahme und eine Nachfrageannahme.

Sie verifizieren sie nicht. Der Server kann die Beziehung falsch beschreiben. MGA-Zähler können alt sein. Routingänderungen können nur teilweise greifen. Ein Gerät kann TOS nach RFC 1349 lesen. Eine Basis kann nach der Nutzfrist ankommen. RAMP kann sie annehmen, während der Clientprozess scheitert.

Reparatur folgte der räumlichen Verteilung des Fehlers

RAMP-Empfänger sollten fehlende Sequenzbereiche per NAK melden. Der Sender sammelte Anfragen während eines Timers. Überschritt ihre Zahl einen Schwellenwert, wurde die Reparatur multicast gesendet; bei wenigen Betroffenen unicast. Bereits freigegebene Daten konnten nicht mehr verfügbar sein.

So ließ sich vermeiden, wegen eines lokalen Fehlers gesunde Zweige zu fluten oder bei einem gemeinsamen Fehler viele Einzelkopien zu erzeugen. Ein NAK-Zähler erklärte aber keine Ursache. Das Überschreiten des Schwellenwerts bewies nicht, dass jeder Empfänger die Reparatur brauchte. Senden bewies kein Empfangen.

Wiederholungsanfragen und Router-Rückmeldungen senkten die Rate; eine Strecke ohne solche Anfragen erlaubte eine vorsichtige Erhöhung. Schweigen war ein begrenztes Regelsignal, kein Gesundheitsnachweis für die Gruppe.

Entwurfsgeschichte ohne erfundene Einführung

RFC 1458 prüfte das Multicast Transport Protocol aus RFC 1301, würdigte Master, Sendetoken und selektive NAK-Reparatur, hielt aber den nahezu vollständig masterzentrierten Kontrollverkehr für die Bildlast für ungeeignet. Der IP-Multicast-Hintergrund kam aus RFC 1112.

Diese Beziehungen belegen eine damalige Entwurfsdebatte, keinen Produktivbetrieb. RFC 1458 nennt keine RAMP-Installation und erklärt, Sicherheitsfragen nicht zu behandeln. Gruppenmitgliedschaft authentifizierte keine Person, Registrierung autorisierte keinen Zugriff und eine Qualitätsmarke garantierte weder Herkunft noch Integrität.

Der belastbare historische Befund ist enger: Eine Verlustordnung kann ein Anwendungsergebnis nur bewahren, wenn die Abhängigkeit korrekt beschrieben, überall gleich interpretiert und am Ende tatsächlich beobachtet wird.