Zusammenfassung

  • RFC 2354 ordnete vier Reparaturfamilien nach Verzögerung, Kapazität, Codec-Wissen und Genauigkeit; eine universelle Zuverlässigkeitsschicht gab es nicht.
  • Ein Sequenzloch belegte Verlust, aber keine freie Kapazität. Zusätzliche Reparatur konnte Überlastung erhöhen, weitere Pakete verdrängen und die nächste Reparaturrunde auslösen.

Colin Perkins und Orion Hodson veröffentlichten das Dokument im Juni 1998 als Informational RFC. Es war weder Internetstandard noch vollständige Bestandsaufnahme. Untersucht wurden Verfahren mit Beteiligung des Senders; reine Empfängerkorrektur blieb außen vor.

Die erste Grenze verlief zwischen Medieneinheit und Paket. Eine Einheit war ein zeitlicher Abschnitt aus dem Codec, ein Paket konnte mehrere Einheiten tragen. Exakte Byte-Wiederherstellung, eine angenäherte Ersatzdarstellung, die Verteilung eines langen Ausfalls auf kleine Lücken und eine perfekte, aber verspätete Kopie waren deshalb verschiedene Ergebnisse.

RTP lieferte zwei Belege. Sequenznummern beschrieben die Sendereihenfolge und machten Lücken sichtbar. Zeitstempel legten die Wiedergabereihenfolge fest. Da Reparatur Einheiten bewusst außerhalb der Reihenfolge senden konnte, musste der Empfänger nach Medienzeit planen. Die Sequenz erklärte, was fehlte; die Playout-Uhr entschied, ob Warten noch sinnvoll war.

Die Verlustform bestimmte den Schutz

RFC 2354 zitierte Mbone-Messungen, bei denen viele Empfänger einer großen Sitzung etwa zwei bis fünf Prozent Verlust sahen, einige deutlich mehr. Einzelverluste dominierten, kurze Bursts waren seltener und lange Bursts selten. Das war ein historischer Befund, keine ewige Internetstatistik.

Er begründete jedoch eine Priorität: Häufige Einzelverluste effizient behandeln, dann den Preis für Bursts abwägen. Dauerhaft starke Codes gegen seltene lange Ausfälle konnten im Normalbetrieb mehr Verzögerung und Last erzeugen, als ihr Nutzen rechtfertigte.

Wiederholung reagierte nach dem Verlust. Der Empfänger fragte, der Sender sendete erneut. Das konnte exakt sein, kostete aber Rückmeldung, einen weiteren Weg und Zeit bis zur Wiedergabe. Im Multicast konnte fast jedes Paket bei mindestens einem Teilnehmer fehlen. Ohne Unterdrückung machten viele lokale Schäden gemeinsamen Verkehr. Das RFC sah Wiederholung vor allem bei lockeren Zeitgrenzen und kombinierte sie gedanklich mit FEC für häufige Einzelverluste.

Medienunabhängige FEC zahlte vorher. Paritäts- oder Codedaten ermöglichten Wiederherstellung ohne neue Anfrage. Einfaches XOR war leicht; stärkere Codes schützten Bursts mit mehr Berechnung und Latenz. Auch in verlustfreien Phasen belegte die Versicherung Bandbreite.

Medienspezifische Redundanz nutzte Wissen des Codecs. Eine niedriger codierte Audiokopie, doppelte Schlüsselteile eines Videos oder Schutz nur empfindlicher Bits konnte Kontinuität mit kleinerem Aufwand sichern. Dafür bedeutete „repariert“ nicht zwingend „identisch“.

Interleaving änderte die Reihenfolge kleiner Einheiten. Ein verlorenes Paket erzeugte nach dem Zurücksortieren mehrere kurze Lücken statt eines langen Ausfalls. Es verbrauchte keine zusätzliche Bandbreite, verlangte aber Pufferzeit. Für verzögerbare Sendung war das günstig, für Dialoge problematisch.

Die Anwendung setzte die Frist

Bei einseitiger, nicht interaktiver Übertragung durfte Qualität wichtiger als Verzögerung sein. Interleaving, Wiederholung und FEC waren mögliche Antworten. In einer interaktiven Sitzung schadeten Rundreise und tiefer Puffer dem Gespräch; nur FEC mit kleiner Verzögerung blieb naheliegend. Selbst dann hing die Wahl zwischen generischer und codec-spezifischer FEC vom Format ab.

Die gefährliche Schleife begann, wenn Verlust Überlastung anzeigte. Mehr Reparatur füllte dieselbe Warteschlange, verursachte neue Verluste und legitimierte scheinbar noch mehr Reparatur. Das RFC warnte, übermäßiger Reparaturverkehr könne bis zum Denial of Service reichen.

Mangels standardisierter Streaming-Staukontrolle nutzte das Dokument einen näherungsweisen TCP-Vergleich als Obergrenze vernünftigen Verhaltens. Es erklärte zugleich, warum dieser Beleg schwach blieb: Eine Mittelwertformel bildete TCP-Dynamik nicht ab, und ein Multicast-RTT war nur eine grobe Durchschnittsschätzung.

Spätere RFCs hielten die Mechanismen getrennt: RFC 4588 definierte RTP-Wiederholung, RFC 5109 generische FEC, RFC 8085 die Pflicht von UDP-Anwendungen zur Kontrolle ihres gesamten Verkehrs. Die Entwicklung bestätigte keine Einheitsreparatur, sondern getrennte Verantwortungen.

Der bleibende Beitrag von RFC 2354 ist die Belegkette: Verlust erkannt, Reparaturlast zugelassen, Einheit rekonstruiert, Wiedergabefrist erreicht, Wahrnehmung erhalten. Ein einziges Feld „Recovery aktiv“ kann diese Wahrheit nicht tragen.