Zusammenfassung

  • SQUAD schlägt gemeinsame Multicast-Zustellung vor, während für Authentifizierung und Steuerung eine individuelle QUIC-Beziehung zu jedem Empfänger bleibt.
  • Das IETF-BoF am 16. November ist nicht auf die Gründung einer Arbeitsgruppe ausgelegt: Es sammelt Anforderungen, beschließt keine Charta und wählt kein Protokoll.

Die attraktive Skizze ist schnell gezeichnet: ein Sender, ein Verteilbaum, viele Empfänger. Die Kosten stecken in dem, was die Skizze auslässt. Jeder QUIC-Empfänger braucht weiterhin eine eigene authentifizierte Beziehung. Rückmeldungen müssen zusammengeführt, Verluste erkannt, Pakete repariert und Staus gesteuert werden. Außerdem braucht es eine Antwort auf die Frage, was passiert, wenn ein Pfad oder Empfänger den gemeinsamen Strom nicht mehr nutzen kann.

Genau darum geht es bei SQUAD, Scalable QUIC-Assisted Distribution. Der genehmigte BoF-Antrag schlägt Source-Specific Multicast (SSM) für gemeinsame Eins-zu-viele-Daten vor, während eine herkömmliche QUIC-Verbindung je Empfänger Authentifizierung und Steuerung übernimmt. QUIC definiert bereits einen verschlüsselten, multiplexierten Transport über UDP; TLS gehört zu seinem Sicherheitsdesign. SSM beschreibt ein Modell, bei dem Empfänger Verkehr einer bestimmten Quelle anfordern. Diese Bausteine zusammenzusetzen beseitigt den Abstimmungsbedarf nicht.

Das IETF hat SQUAD für den 16. November auf der IETF 127 angesetzt. Die Bezeichnung zählt: Es handelt sich um ein Birds-of-a-Feather-Treffen, das keine Arbeitsgruppe gründen soll. Der Antrag sagt ausdrücklich, dass dort weder eine Charta beschlossen noch ein Protokoll ausgewählt wird. Gesucht sind gemeinsame Anwendungsfälle und Anforderungen, strittige Annahmen sowie sinnvolle Experimente und Folgeschritte. Ein BoF kann eine Tür öffnen; es macht aus einem Vorschlag nicht stillschweigend einen Internetstandard.

Die offenen Fragen zeigen mehr als das Wort „skalierbar“. Lassen sich Rückmeldungen bündeln, ohne einen beeinträchtigten Pfad zu verdecken? Wie werden Verluste repariert, die nur einige Empfänger treffen? Wie funktioniert Staukontrolle, wenn eine gemeinsame Übertragung Pfade unterschiedlicher Kapazität bedient? Wie verhindert man, dass ein langsamer oder böswilliger Empfänger den Dienst für alle stört? Und wann fällt ein Empfänger auf seinen eigenen Unicast-Strom zurück, wenn Multicast nicht verfügbar ist?

Diese Fragen verlagern Arbeit zwischen Sender und Netz. Bei Unicast muss der Sender dieselben Daten wiederholen, erhält aber einen Blick auf jede Verbindung. Ein gemeinsamer Multicast-Zweig könnte auf passenden Verbindungen Duplikate verringern; dafür muss das System Zustellung und Ausnahmen für viele Empfänger koordinieren. Die individuellen QUIC-Beziehungen sollen Identität und Steuerung pro Empfänger erhalten, während die Nutzdaten gemeinsam laufen. Ob diese Aufteilung trägt, hängt von Verkehr und Netz ab.

Bestehende Standards liefern Teile, keine fertige Maschine. RFC 9000 beschreibt QUIC, RFC 9001 dessen TLS-Nutzung und RFC 9221 QUIC DATAGRAM. Das SSM-Modell steht in RFC 4607. RFC 7450 beschreibt AMT, mit dem Multicast Netzabschnitte ohne native Multicast-Unterstützung überqueren kann. Keines dieser Dokumente misst SQUAD-Leistung oder belegt einen Einsatz durch Betreiber.

Das nützliche Ergebnis im November muss keine Protokollankündigung sein. Vielleicht wird das Problem enger gefasst, es entstehen prüfbare Anforderungen oder die offenen Punkte erweisen sich als zu breit für eine neue Arbeitsgruppe. Auch das wäre Fortschritt. Ein Standardisierungsgremium sollte die fehlende Arbeit sichtbar machen, bevor jemand die Skizze als Einsparung verkauft.

Die erfassten Primärquellen enthalten keine vergleichenden Messwerte zu Einsatz oder Leistung. Wiederholbare Tests in verwalteten Netzen gegen Unicast würden die Einschätzung möglicher Einsparungen verändern.

Quellen: genehmigter SQUAD-BoF-Antrag; neue Themen der IETF 127; RFC 9000, RFC 9001, RFC 9221, RFC 4607, RFC 7450.