Zusammenfassung

  • RFC 3448 ließ den Empfänger Ankunftsrate, Verlustereignisrate und Zeitdaten melden; der Sender maß weiterhin RTT und berechnete eine TCP-nahe Rate.
  • X_recv, begrenzter Anstieg, Pacing und der Timer ohne Rückmeldung blieben eigene Bremsen. Eine glatte Rate bewies weder Kapazität noch genaue Fairness oder Zustellung.

Ruhiger senden hieß weiterhin nachgeben

TCPs Fensterdynamik war für Dateiübertragung brauchbar, für Telefonie und Streaming aber oft zu sprunghaft. RFC 3448 definierte im Januar 2003 TFRC als ratenbasierte Staukontrolle für Unicast-Verkehr, der mit TCP konkurrierte und kurzfristig gleichmäßiger senden sollte.

„Angemessen fair“ war bewusst kein exakter Vertrag. Die Rate sollte unter gleichen Bedingungen im Allgemeinen innerhalb eines Faktors zwei zu einem TCP-Fluss liegen. Das versprach weder momentane Gleichheit noch reservierte Bandbreite oder Medienqualität.

TFRC war auch kein vollständiger Transport. Zuverlässigkeit und ein einziges Paketformat blieben außerhalb des Dokuments. Der Mechanismus konnte in RTP oder einer Anwendung leben. Text, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen, spätere Verweise und Errata-Suche belegen die Spezifikation, nicht einen bestimmten Betrieb.

Aus Paketverlusten wurde ein Ereignis

Der Empfänger sah Reihenfolge, Ankunft, Verlust und ECN-Markierung. Verluste innerhalb ungefähr einer RTT wurden zu einem Ereignis gebündelt. Mehrere Pakete derselben Stauphase sollten nicht so wirken, als hätte TCP für jedes einzeln eine vollständige neue Absenkung vorgenommen.

Gewichtete Abstände zwischen Ereignissen ergaben über ihren Mittelwert die Verlustereignisrate p. Ein ungewöhnlich langer aktueller Abstand konnte ältere Geschichte abwerten. Fünf dicht beieinanderliegende Verluste und fünf über mehrere RTT verteilte Verluste lieferten deshalb andere Signale.

Die Verdichtung war keine Ursachenanalyse. Sie verwarf die Zahl der Pakete innerhalb eines Ereignisses und nannte weder Warteschlange noch Link. RFC 3168 fügte ECN als Stausignal ohne Paketverlust hinzu, doch auch eine Markierung war kein Anwendungsbeleg.

Zusätzlich meldete der Empfänger X_recv und Zeitinformationen. Das war ein Rückblick auf empfangene Daten, keine Zusage künftiger Pfadkapazität.

Der Sender behielt drei unabhängige Grenzen

Aus zurückgespiegelten Zeitwerten schätzte der Sender RTT. Mit dem Gleichungsansatz aus RFC 2915 verband er Paketgröße, RTT, p und einen Timeout-Term zu X_calc, der modellierten TCP-Reno-Rate.

X_calc ging nicht unverändert auf den Draht. In der Stauvermeidung galt zusätzlich höchstens das Doppelte von X_recv, neben einer kleinen Untergrenze aus dem maximalen Rückzugsintervall. Modell und beobachtete Ankunft begrenzten gegenseitig ihren Optimismus.

Auch die Bewegung zwischen Raten war geregelt. Normalerweise sollte die Rate pro RTT höchstens verdoppeln; Pakete wurden getaktet, statt als Schub gesendet. Feedback blieb Eingangsdaten, bis lokale Berechnung, Obergrenze und Zeitregel eine Aktion formten.

Ein fehlerhafter Empfänger konnte Verluste klein- oder Ankunft großreden. Sendergrenzen schränkten diesen Einfluss ein, bestätigten aber nicht die Wahrheit der Meldung.

Ausbleibende Antwort verkleinerte den Spielraum

Ohne Feedback lief ein Timer ab. Der Sender senkte dann die zulässige Rate, oft durch Halbierung seiner gespeicherten X_recv, und berechnete neu. Ohne frühe RTT- oder Feedbackdaten konnte die Rate direkt halbiert werden.

Schweigen war mehrdeutig: Rückwegverlust, Vorwärtsfehler, beendeter Empfänger oder Leerlauf kamen infrage. RFC 3448 erfand keine Gewissheit. Es schrieb eine konservative Reaktion unter Unsicherheit vor.

Damit blieb Verantwortung beim Sender. Der Empfänger lieferte Beobachtungen; sein Berichtskanal wurde nicht zur Befehlsleitung.

Revisionen machten daraus keinen Zustellungsnachweis

RFC 2914 ordnete Staukontrolle der Stabilität des Internets zu. RFC 2581 und RFC 3390 lieferten TCP-Kontext, RFC 3550 den RTP-Rahmen.

RFC 4342 brachte TFRC in DCCP CCID 3. RFC 4828 behandelte kleine Pakete. RFC 5348 ersetzte RFC 3448. Diese Folge zeigt Weiterentwicklung, nicht universelle Einführung.

p war keine Ursache, X_recv keine Kapazität und X_calc keine Erlaubnis. Eine gewählte Rate bewies weder Weiterleitung noch Dekodierung. Gleichmäßigkeit konnte mit veraltetem Feedback oder schlechter Anwendungsqualität zusammenfallen.

Heng Lus Realitätsebenen halten Beobachtung, Verdichtung, Meldung, Berechnung, Handlung und Ergebnis getrennt. Running-Code Primacy erklärt die lokalen Kontrollen statt bloßen Vertrauens in eine Zahl. Minimum Initial Specification macht die Begrenzung sichtbar: Staukontrolle, nicht Zuverlässigkeit oder Anwendungserfolg. Das ist eine spätere redaktionelle Lesart.

RFC 3448 hinterließ somit eine Zuständigkeitsordnung: Der Beobachter berichtet; der Handelnde bleibt für Zurückhaltung verantwortlich.

Quellen