Zusammenfassung
- RFC 3738 verlegte WEBRCs Stau-Messungen und Ratenentscheidungen auf die einzelnen Empfänger. Diese traten Multicast-Kanälen bei oder verließen sie, statt individuelle Berichte an den Sender zu schicken.
- Die über mehrere Kanäle verteilten Wellen machten aus diesen Mitgliedschaftsentscheidungen unterschiedliche Empfangsraten. Dafür stieg die Komplexität auf der Empfängerseite; Zuverlässigkeit oder ein Zustellnachweis waren nicht enthalten.
Der stille Sender war nicht das ganze System
Multicast bot eine verlockende Rechnung: Ein Sender konnte eine Sitzung an eine Gruppe übertragen, statt für jeden Empfänger einen eigenen Datenstrom zu eröffnen. Staus verteilen sich jedoch nicht gleichmäßig. Ein Empfänger hinter einer schmalen oder ausgelasteten Verbindung kann Verluste erleben, während ein anderer in derselben Sitzung noch freie Kapazität hat. Müsste der Sender vor jeder Anpassung einen Bericht von allen Empfängern einsammeln und verarbeiten, könnte bereits der Rückkanal zum Skalierungsproblem werden.
RFC 3738, im April 2004 als Experimental RFC veröffentlicht, untersuchte eine andere Arbeitsteilung. Wave and Equation Based Rate Control (WEBRC) war ein Baustein für Multicast-Protokolle zur Staukontrolle. Empfänger mussten keine Stauberichte an den Sender übermitteln. Jeder maß die Bedingungen seines eigenen Pfads, berechnete eine Ziel-Empfangsrate und änderte die Multicast-Kanäle, denen er beigetreten war. „Keine Rückmeldung an den Sender“ bedeutete daher nicht „kein Signal“. Das Signal war eine gewöhnliche Netzaktion: einem Kanal beitreten oder ihn verlassen.
Diese Unterscheidung ist fein, aber architektonisch wichtig. Der Sender bekam keinen individuellen Bericht über Verluste, verfügbare Bandbreite oder Abschluss. Der Empfänger musste ebenso wenig auf einen vom Sender ausgehandelten persönlichen Strom warten. Der Sender sendete eine gemeinsame Gruppe von Kanälen; jeder Empfänger wählte daraus entsprechend seiner eigenen Stauschätzung einen Teil.
Ratenkontrolle durch Kanalmitgliedschaft
WEBRC teilte eine Sitzung in einen langsam sendenden Basiskanal und mehrere Wellenkanäle. Der Basiskanal half dem Empfänger, sich im Zeitfensterzyklus der Sitzung zu orientieren, und blieb während seiner Teilnahme aktiv. Die Raten der Wellenkanäle änderten sich im Zeitverlauf: Nach einem schnellen Anfang sank die Paketrate einer Welle über aufeinanderfolgende Zeitfenster und erreichte schließlich eine Ruhephase, bevor sich der Zyklus wiederholte.
Diese zeitliche Form erlaubte dem Empfänger, seine Rate zu wählen, ohne beim Sender einen eigenen Strom anzufordern. Für eine höhere Zielrate trat er früher im abfallenden Verlauf einer Welle einer weiteren aktiven Schicht bei. Für eine niedrigere Rate trat er keinen zusätzlichen Schichten bei und verließ einen Kanal, wenn dessen Welle ruhte. Da sich die Zuordnung aktiver Wellen zu Schichten mit dem Zyklus änderte, musste der Empfänger den Zeitfensterindex und seine bereits beigetretenen Kanäle verfolgen.
Die Zielrate war keine bloße Präferenz. WEBRC schätzte die mittlere Paketverlustwahrscheinlichkeit und die mittlere Multicast-Rundlaufzeit und setzte diese Messwerte in eine TCP-ähnliche, von TFRC inspirierte Gleichung ein. Das Ergebnis half bei der Entscheidung, ob eine weitere Schicht den Empfänger noch innerhalb seiner Zielrate halten würde. Die RFC formulierte zwei Entwurfsziele: eine angemessene Fairness im Wettbewerb mit TCP und einen gleichmäßigeren Durchsatz im Zeitverlauf. Der Preis war eine langsamere Reaktion als bei TCP, wenn sich die verfügbare Bandbreite änderte.
Das sind Ziele der Spezifikation, keine Feldmessungen, die ihr Erreichen in einer bestimmten Installation belegen.
Ein Tausch zwischen Komplexität und Wissen
Die Arbeit des Senders war absichtlich einfacher gehalten. Er benötigte eine Obergrenze für die aggregierte Sitzungsrate, Kanalzuweisungen, Zeitparameter und Paketköpfe mit Kanal- und Zeitfensterkennung. Die aufwendigere Arbeit lag beim Empfänger: Verluste messen, Multicast-Rundlaufzeit schätzen, Mittelwerte aktualisieren, eine wechselnde Schichtreihenfolge verfolgen und über Beitritt oder Austritt entscheiden. Verschiedene Empfänger konnten unterschiedliche Raten erhalten, ohne dass der langsamste alle anderen begrenzte.
Dieser Tausch beschränkte auch das Wissen des Senders. Der Beitritt oder Austritt eines Empfängers änderte den Verteilpfad des Netzes zu diesem Empfänger. Daraus wurde aber kein Bericht, der dem Sender mitteilte, wer welche Daten erhalten hatte. RFC 3738 war eine Komponente zur Staukontrolle, kein Abschlussprotokoll. Sie lieferte weder Wiederübertragung noch Verlustbehebung. Sitzungsbeschreibung und Zuordnung von Paketen zu einer Sitzung überließ sie ebenfalls anderen Bausteinen oder einer Verteilung außerhalb des Bandes. Zuverlässigkeit, Empfangsabschluss und Annahme durch die Anwendung blieben getrennte Fragen.
RFC 3738 gehörte zu einer umfassenderen RMT-Entwurfsarbeit. RFC 3269 beschrieb einen modularen Ansatz für zuverlässigen Multicast-Transport, RFC 3048 einen Rahmen zum Zusammensetzen von Bausteinen. WEBRC konnte daher mit Zuverlässigkeits- oder Objektzustellungsmechanismen kombiniert werden. Die Kombination hob die getrennten Zuständigkeiten jedoch nicht auf. Eine Staukontrolle kann den Empfang regeln, ohne die Rekonstruktion eines Objekts zu garantieren; eine Reparaturschicht kann die Rekonstruktion ermöglichen, ohne dem Sender mitzuteilen, welcher Empfänger fertig war.
Auch der Status von RFC 3738 gehört zur Geschichte. Die Autoren kennzeichneten die Spezifikation ausdrücklich als Experimental und wollten zunächst eine anfängliche Bereitstellung und Betriebserfahrung abwarten, um Wirksamkeit und Skalierbarkeit zu beurteilen. Die Arbeitsgruppe bekundete die Absicht, sie bei ausreichender Eignung später erneut als Proposed Standard einzureichen. Diese Absicht beweist weder eine Bereitstellung noch eine spätere Standardisierungsentscheidung oder betriebliche Übernahme.
Das Dokument hält einen Entwurf samt Annahmen fest; eine aktive Implementierung, Messungen ihres Verhaltens und ein späterer Normungsbeschluss benötigten jeweils eigene Belege.
Quellen
- RFC 3738: WEBRC-Baustein; RFC-Editor-Eintrag; IETF-Datatracker-Eintrag
- RFC 3448: TCP-freundliche Ratenkontrolle (TFRC); RFC 3450: ALC-Protokollinstanziierung
- RFC 3048: Bausteine für zuverlässigen Multicast-Transport; RFC 3269: Leitlinien für zuverlässigen Multicast-Transport
- RFC 8085: UDP-Nutzungsrichtlinien
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
