L4S-Internetdienste für niedrige Latenz, geringe Verluste und skalierbaren Durchsatz: RFC 9330
(datatracker.ietf.org)- RFC 9330 definiert die L4S-Architektur, um Queueing-Latenz und stauungsbedingte Verluste in Internetanwendungen zu verringern, und sieht die eigentliche Ursache der Latenz nicht in der Queue selbst, sondern in der kapazitätssondierenden Staukontrolle des Senders
- L4S kombiniert skalierbare Staukontrolle auf dem sendenden Host, AQM am Flaschenhals und ECN-basierte Protokolle; zur Kennzeichnung von L4S-Paketen wird der Codepoint ECT(1) im IP-ECN-Feld verwendet
- Die Ziel-Queueing-Latenz liegt im Mittel unter 1 ms und beim 99. Perzentil bei ungefähr unter 2 ms; in Beispielen mit DCTCP und Dual-Queue Coupled AQM liegt die Queueing-Latenz im 99. Perzentil selbst unter Überlast grob bei 1–2 ms
- Um mit bestehender Classic-Staukontrolle der Reno-/CUBIC-Familie koexistieren zu können, trennt L4S die Latenz von Classic- und L4S-Traffic, teilt die Bandbreite aber nicht fest auf, sondern lässt sie langfristig gemeinsam nutzen
- L4S ergänzt Diffserv, FQ-CoDel, PIE und BBR statt sie zu ersetzen; TCP benötigt präziseres Feedback wie AccECN, während QUIC und DCCP das für L4S nötige ECN-Feedback bereits bereitstellen
Das Latenzproblem, das L4S lösen will
- Situationen, in denen Traffic mit Präferenz für geringe Latenz wie Web, Sprache, Videokonferenzen, Gaming, Remote Desktop, Cloud-Anwendungen, AR/VR und Fernsteuerung Engpass-Links auslastet, nehmen zu
- Caches und Server wurden näher an Nutzer platziert und haben die Ausbreitungslatenz reduziert, doch Queueing bleibt weiterhin ein wesentlicher und intermittierender Bestandteil der Latenz
- Selbst mit modernem AQM sind Latenzspitzen von mehreren hundert Millisekunden nicht selten
- Classic-AQM wird oft so eingestellt, dass es die sägezahnförmigen Queue-Schwankungen eines einzelnen langlebigen Flows puffert; dadurch können die gesamten Netzwerklatenzspitzen während langlebiger Flows ungefähr doppelt so hoch wie die Basis-Pfadlatenz werden
- Ziel von L4S sind sehr geringe Queueing-Latenz, sehr geringe Verluste und skalierbarer Durchsatz
- Sehr geringe Queueing-Latenz bedeutet im Mittel unter 1 ms und beim 99. Perzentil ungefähr unter 2 ms
- Anspruchsvollere interaktive Anwendungen wirken unnatürlich, sobald die End-to-End-Latenz 50 ms oder 20 ms überschreitet
- Da Verluste bei interaktiven Anwendungen zu Verzögerungen durch Wiederübertragungen führen, ist geringer Verlust ebenfalls ein zentrales Ziel
Ursache der Latenz: Classic-Staukontrolle statt Queue
- L4S sieht die eigentliche Ursache von Queueing-Latenz nicht in der Queue selbst, sondern in der kapazitätssondierenden Staukontrolle des Senders
- Classic-Staukontrollen wie Reno und CUBIC verändern die Queue-Belegung in großen sägezahnförmigen Mustern
- Wird die Queue durch AQM zu flach gehalten, kann Classic-Staukontrolle den Link an jedem Tiefpunkt des Sägezahns nicht vollständig auslasten
- Mit steigender Flow-Rate verlängert sich die Erholungszeit der Classic-Staukontrolle, wodurch die Steuerung von Queue und Auslastung ungenauer wird
- Skalierbare Staukontrolle hält die durchschnittliche Zeit zwischen Stau-Signalen, also die Erholungszeit, auch bei steigender Flow-Rate konstant
- DCTCP ist ein weit verbreitetes Beispiel in kontrollierten Umgebungen
- Es ist in Windows Server Editions, Linux und FreeBSD implementiert und ausgerollt
- Prague over TCP/QUIC, SCReAM für L4S und der L4S-ECN-Teil von BBRv2 zählen ebenfalls zu den Beispielen für skalierbare Staukontrolle
Die drei Bausteine der L4S-Architektur
- L4S besteht aus drei Komponenten
- Skalierbare Staukontrolle auf dem sendenden Host
- AQM am Netzwerk-Flaschenhals
- ECN-basierte Protokolle für Paketidentifikation und Stau-Signalisierung dazwischen
- Die geringe Latenz wird nicht direkt vom Netzwerk bereitgestellt, sondern entsteht aus dem vorsichtigen Verhalten der skalierbaren Staukontrolle des L4S-Senders
- Die Hauptaufgabe des Netzwerks besteht darin, die geringe Latenz von L4S-Traffic von der höheren Queueing-Latenz zu isolieren, die Classic-Traffic benötigt
- Das Netzwerk nutzt ECN, um der Transportschicht sehr frühe Anzeichen von Queue-Wachstum sofort zu melden
- Es signalisiert also nicht erst nach starker Glättung der Queue-Schwankungen wie bei Classic-AQM
- ECN-Unterstützung ist für L4S zwingend erforderlich
- Der Sender verwendet das ECN-Feld, damit das Netzwerk L4S- und Classic-Pakete unterscheiden kann
ECN und der Codepoint ECT(1)
- L4S benötigt feinere Stau-Signale als Classic-ECN, das der Vorgabe folgt, dass „ECN-Signale wie Drops behandelt werden müssen“
- Signale müssen häufiger auftreten können
- Sie müssen ohne große Verzögerung zur Glättung von Queue-Schwankungen sofort ausgelöst werden können
- RFC8311 lockert einige Anforderungen aus RFC3168, um L4S-Experimente zu ermöglichen
- RFC9331 legt fest, ECT(1) als Kennzeichner für L4S-Pakete zu verwenden
- Der CE-Codepoint wird sowohl bei L4S- als auch bei Classic-Verarbeitung genutzt, um Congestion Experienced anzuzeigen
- Wenn ein vorgelagerter Classic-AQM ECT(0)-Pakete mit CE markiert, besteht das Risiko einer Fehlklassifikation in die L4S-Queue
- Laut Anhang B von RFC9331 müssen dafür fünf seltene Bedingungen gleichzeitig eintreten; selbst dann ist die Wahrscheinlichkeit schädlicher Fehlwiederholungen äußerst gering
- Betreiber könnten nicht-L4S-Traffic, der so niedrig und gleichmäßig ist, dass er keine Queue bildet, in die L4S-Queue aufnehmen wollen
- Beispiele sind VoIP, langsame Datagramme zur Synchronisierung von Online-Spielen, DNS und LDAP
- Dafür ist jedoch eine zusätzliche Markierung wie EF, NQB oder ein betreiberspezifischer Kennzeichner nötig
Dual-Queue Coupled AQM
- L4S zielt darauf ab, geringe Latenz bereitzustellen, ohne dass Netzkomponenten zwingend Flow-spezifische Verarbeitung leisten müssen
- Das typische Design Dual-Queue Coupled AQM verwendet zwei Queues
- Die L4S-Queue hält geringe Latenz aufrecht
- Die Classic-Queue darf die größere Queue besitzen, die Classic-Traffic zur Aufrechterhaltung der Link-Auslastung benötigt
- DualQ ist so konzipiert, dass es wie eine semipermeable Membran wirkt: Es trennt die Latenz, teilt die Bandbreite aber nicht fest auf
- Classic-AQM erzeugt seine eigene auf Queue-Stau basierende Drop-/Markierungswahrscheinlichkeit und koppelt sie an die Signale für Classic- und L4S-Queue
- Das gekoppelte Stau-Signal veranlasst L4S-Flows, ihre Rate zu senken und so die für Classic-Flows nötige Kapazität freizulassen
- Der Scheduler kann der L4S-Queue Priorität geben
- Auf kurzen Zeitskalen werden L4S-Bursts schnell aufgelöst, um geringe Latenz zu schützen
- Auf längeren Zeitskalen oberhalb einer RTT gleicht die Kopplung der Stau-Signale in der Classic-Queue diesen Bandbreitenvorrang aus und erzeugt ungefähre Fairness pro Flow
- Wenn nur L4S-Traffic vorhanden ist, beginnt das AQM der L4S-Queue bereits bei sehr flachen Queues mit der Stau-Markierung und hält so die Queueing-Latenz niedrig
Unterschied zwischen Flow-Queueing und DualQ
- Flow-Queueing wie FQ-CoDel und FQ-PIE kann ebenfalls mit L4S verwendet werden
- Unter Linux wurde es so angepasst, dass flache ECN-Markierungsschwellen nur auf ECT(1)-Pakete angewendet werden können
- Auf Not-ECT- oder ECT(0)-Flows wird Classic-AQM angewendet, auf ECT(1)-Flows typischerweise eine flache Schwelle im Sub-Millisekundenbereich
- Der Flow-basierte Ansatz trennt die Queue je Flow, beseitigt aber nicht das Queueing, das der Flow selbst erzeugt
- Der DualQ-Ansatz benötigt keine tiefere Inspektion als die IP-Schicht, da sich der L4S-Kennzeichner im IP-ECN-Feld befindet
- Er ist daher auch in Umgebungen mit verschlüsselten Transportkennungen nutzbar, etwa bei IPsec oder verschlüsselten VPN-Tunneln
- Beim Flow-basierten Ansatz übernimmt das Netzwerk die Kontrolle der relativen Raten zwischen Anwendungs-Flows
- DualQ trennt die Aufgabe geringer Latenz von der Frage der Flow-Ratenkontrolle; falls nötig, kann separate Flow-Raten-Policing ergänzt werden
Anforderungen auf Host-Seite
- Sender müssen skalierbare Staukontrolle implementieren
- DCTCP ist das verbreitetste Beispiel, benötigt für den Einsatz im öffentlichen Internet aber Verbesserungen bei Sicherheit und Leistung
- Die Teile der Prague-L4S-Anforderungen, die sich auf das Risiko von Schäden für andere beziehen, sind in die normativen Anforderungen von RFC9331 aufgenommen
- TCP Prague ist als Referenzimplementierung unter Linux umgesetzt
- Auch andere Transportprotokolle als TCP müssen zur Nutzung von L4S-Diensten skalierbare Stauantwort implementieren und dies mit dem Codepoint ECT(1) kennzeichnen
- Skalierbare Varianten für QUIC werden geprüft
- Der L4S-ECN-Teil von BBRv2 wird als skalierbare Staukontrolle für TCP, QUIC und andere vorgeschlagen
- Auch eine L4S-Variante von SCReAM für RTP-Medien ist implementiert
- Der Stand des ECN-Feedbacks unterscheidet sich je nach Protokoll
- DCCP und QUIC liefern ausreichend feingranulares ECN-Feedback für L4S
- Das bestehende ECN-Feedback von TCP setzt voraus, dass ECN-Markierungen Drops gleichgestellt sind, und ist daher für skalierbares TCP ungeeignet
- TCP-Empfänger benötigen Unterstützung für das genauere ECN-Feedback AccECN
- SCTP würde zur Unterstützung von L4S eine neue ECN-Architektur samt Implementierung und Rollout benötigen
- Für RTP ist in RFC6679 und RFC8888 ausreichend ECN-Feedback definiert
Warum explizite Stau-Signale nötig sind
- L4S nutzt explizite Stau-Signale statt Verlusten als zentrales Mittel
- Drops sind zugleich Leistungseinbuße und Signal, was die Spannung erzeugt zwischen „je weniger Schaden, desto besser“ und „je mehr Signal, desto besser“
- Explizite ECN-basierte Signale können ohne Schaden mehrfach pro RTT genutzt werden und eignen sich daher besser, Queues kurz zu halten
- L4S verlagert die Glättung vom Netzwerk auf den Host
- Das Netzwerk kennt die RTT jedes Flows nicht und muss bei Classic-Verfahren daher von der schlechtesten RTT ausgehen
- Deshalb können Classic-Stau-Signale um 100–200 ms verzögert sein
- Jeder Host kennt seine eigene RTT und kann deshalb nur so stark glätten wie nötig, meist im Bereich weniger Millisekunden
- Die L4S-Queue nutzt eine neue L4S-ECN-Variante, die nicht Drops gleichgestellt ist, während die Classic-Queue Classic-ECN oder Drops verwendet
Grundlage der Durchsatz-Skalierbarkeit
- Die Classic-Reno-Staukontrolle hat in Umgebungen mit hohem Bandbreite-Latenz-Produkt zunehmend lange Erholungszeiten
- Im Beispiel beträgt die maximale RTT am Sägezahn-Peak 30 ms
- Steigt die Reno-Paketrate um den Faktor 8 von 1.250 packet/s auf 10.000 packet/s, entspricht das bei 1500B-Paketen ungefähr einem Anstieg von 15 Mb/s auf 120 Mb/s, und die Erholungszeit wächst von 422 ms auf 3,38 s
- CUBIC arbeitet bei 120 Mb/s im Reno-friendly-Modus und benötigt zur Erholung etwa 4,3 s
- Bei 960 Mb/s wechselt es in den echten CUBIC-Modus und die Erholungszeit steigt auf 12,2 s
- Bei 7,68 Gb/s wächst die Erholungszeit auf bis zu 24,3 s
- Skalierbare Staukontrolle wie DCTCP oder Prague erzeugt im Mittel 2 Stau-Signale pro RTT, und diese Eigenschaft bleibt unabhängig von der Flow-Rate erhalten
- 2020 lag die weltweite durchschnittliche feste Zugangskapazität bei 103 Mb/s, 2019 die durchschnittliche Basis-RTT zu CDNs bei 25–34 ms
- Ein einzelner CUBIC-Download-Flow kann selbst im besten Fall nach einer Verringerung des Congestion Window ungefähr 200 RTTs, also 5 Sekunden, zur Erholung benötigen
Verhältnis zu bestehenden Technologien
- Diffserv behandelt Bandbreitenzuteilung für wichtigen Traffic und Queueing-Latenz für latenzempfindlichen Traffic, während L4S sich nur mit dem Problem der Queueing-Latenz befasst
- Diffserv ist wirksam, wenn am Flaschenhals nur ein Teil des Traffics geringe Latenz benötigt
- Wenn der gesamte Traffic am Flaschenhals geringe Latenz will, entfällt der Vorteil der Unterscheidung durch Diffserv
- Der L4S-Kennzeichner steht nicht für Qualitätsanforderungen, sondern für das Verhaltensversprechen einer skalierbaren Stauantwort
- Classic-AQM wie PIE und FQ-CoDel reduziert Queueing-Latenz bereits deutlich gegenüber Szenarien ohne AQM
- L4S ergänzt diese Verfahren und ersetzt nicht die Notwendigkeit ihres breiten Einsatzes
- Mit AQM allein lässt sich die Spannung zwischen Latenz und Link-Auslastung wegen der großen Sägezähne der Classic-Staukontrolle nur schwer auflösen
- ABE verändert die Host-Reaktion auf ECN-Markierungen und erhöht dadurch Link-Auslastung und Durchsatz von ECN-Flows, setzt aber weiterhin voraus, dass das Netzwerk ECN und Drops gleich behandelt
- BBR steuert Queueing-Latenz end-to-end ohne spezielle Netzlogik
- BBR hält Queueing-Latenz auf einem vernünftig niedrigen Niveau, aber nicht so niedrig wie L4S
- BBRv2 kann, wenn möglich, L4S-ECN und skalierbares L4S-Staukontrollverhalten verwenden
Geeignete Anwendungen
- L4S kann die Qualität bestehender Anwendungen unter Last deutlich verbessern
- Gaming und Cloud-Gaming
- VoIP
- Videokonferenzen
- Web-Browsing
- Adaptives Video-Streaming
- Instant Messaging
- Noch geringere Queueing-Latenz ermöglicht Funktionen wie cloudbasiertes interaktives Video und cloudbasiertes VR/AR
- In L4S-Demos funktionierten cloudbasiertes interaktives Video und VR gleichzeitig auf einem 40-Mb/s-Breitbandanschluss, während mehrere latenzsensible Anwendungen und Downloads denselben Flaschenhals-Queue teilten
- Bei einer End-to-End-Basislatenz von 7 ms lag die zusätzliche Queueing-Latenz nur bei etwa 1 ms
- Mit alternativem AQM folgte das Video Finger-Gesten und Kopfbewegungen spürbar verzögert
- Das Schwenken eines Videos per Fingerwisch oder Kopfbewegung hat deutlich strengere Latenzanforderungen als VoIP
- Interaktive Remote-Präsenz sowie videogestützte Fernsteuerung von Maschinen und Industrieprozessen sind ohne sehr geringe Queueing-Latenz kaum verlässlich
Rollout-Modell und schrittweise Einführung
- L4S-AQM ist nicht so aufgebaut, dass es nur bei einer flächendeckenden Einführung im gesamten Internet wirksam wäre
- Öffentliche Internetzugangsnetze sind meist so ausgelegt, dass der Flaschenhals an einem einzigen logischen Link pro Standort bekannt ist
- Dazu zählen Haushalte, mobile Geräte sowie kleine und mittlere Campus- und Unternehmensnetze
- Das ist eine Verallgemeinerung, die für verschiedene Zugangstechnologien wie xDSL, Kabel, PON, Mobilfunk, Funk und Satellit gilt
- Im Downstream lassen sich die meisten Vorteile erzielen, wenn L4S-AQM am Eintrittspunkt des Flaschenhals-Links ausgerollt wird; im Upstream gilt Entsprechendes am Eintrittspunkt des Upstream-Links
- Damit ein einzelner L4S-Flow profitiert, sind in der Regel drei Elemente nötig
- Die Staukontrolle des Senders
- Das AQM am Flaschenhals
- Bei älteren Transporten wie TCP ein aufgerüstetes Empfänger-Feedback
- Die Einführungsreihenfolge kann variieren
- Bereits vorhandenes DCTCP kann in kontrollierten Testumgebungen genutzt werden
- Mit TCP Prague und AccECN lässt sich L4S auch im öffentlichen Internet verwenden
- QUIC unterstützt das für L4S nötige ECN-Feedback von Anfang an, was den Rollout der Prague-Staukontrolle auf Senderseite vereinfacht
Einschränkungen je Link-Technologie
- Wi‑Fi, PON und Kabel bündeln mehrere Paketdaten in Bursts und puffern Pakete, die während der Bildung dieser Bursts eintreffen
- Ethernet und DSL führen diese Paketaggregation nicht durch
- Dieses Puffern zur Aggregation kann der Sender nicht reduzieren und sollte daher nicht als vom AQM gesteuerte Queue gezählt werden
- Funklinks wie Mobilfunk, Wi‑Fi und Satellit können ihre Kapazität schnell und stark verändern, weshalb eine stehende Queue als nützlich gilt, um plötzliche Kapazitätserhöhungen auszunutzen
- Mobilfunknetze sind durch Pufferanforderungen für unauffällige Handover zusätzlich komplex
- L4S kann all diese Pufferungsbedarfe nicht beseitigen
- Wenn jedoch die „längste Stange“ – also das Puffern für die großen Sägezähne der Classic-Staukontrolle – entfernt wird, steigt der Anreiz, auch andere Pufferungsfaktoren wie Burst-Größen der Paketaggregation oder MAC-Scheduling-Intervalle weiter zu reduzieren
Nicht-L4S-Flaschenhälse und Verlustbehandlung
- Selbst wenn L4S zwischen zwei Hosts aktiviert ist, muss ein L4S-Sender bei Flaschenhälsen ohne ECN-Unterstützung auf Drops so reagieren, dass sichere Koexistenz mit Reno gewährleistet bleibt
- Diese Regel schützt Classic-Traffic, verschlechtert aber den L4S-Dienst bei Verlusten
- Vorübergehende Flaschenhalsverluste durch Bursts bei flachen Queues
- Übertragungsfehler wie elektrische Störungen
- Raten-Policing
- Drei Ansätze zu deren Behandlung sind derzeit Gegenstand der Forschung
- Ignorieren bestimmter Verluste in der Prague-Staukontrolle, wenn sie wahrscheinlich nicht durch Stau verursacht sind
- Wiederherstellung von Übertragungsfehlern durch die Kombination aus RACK, L4S und erneuter Übertragung auf Links ohne Reordering
- Hybride ECN/Drop-Rate-Policer
- Deployment-Szenarien mit weniger solchen Problemen, etwa in Festnetzen, können parallel zu dieser Forschung vorangetrieben werden
Sicherheit und Traffic-Policing
- Im heutigen Internet wird die Trennung gemeinsamer Link-Kapazität zwischen Standorten meist per Scheduler vorgenommen; die Rate einzelner Anwendungs-Flows wird im Allgemeinen nicht systematisch policiert
- L4S ist so entworfen, dass es diesen Zustand nicht aufbricht
- DualQ ist so ausgelegt, dass unresponsive Flows keinen größeren Ratenvorteil erhalten als bei Single-Queue-AQM
- Falls Flow-basiertes Raten-Policing nötig ist, kann es unabhängig von der L4S/Classic-Unterscheidung ergänzt werden
- L4S soll Latenz reduzieren, ohne die Latenz oder Rate von Classic-Traffic zu verschlechtern; allein zum Schutz von Classic ist daher kein Raten-Policing des Zugangs zu L4S-Diensten nötig
- Manche Betreiber könnten L4S-Dienste nur einer begrenzten Gruppe wie Premium-Kunden anbieten
- In diesem Fall können zusätzlich zum ECN-Feld lokale Kennzeichen wie Quelladressbereiche verwendet werden
- Wenn das lokale Kennzeichen nicht passt, kann selbst Traffic mit ECT(1) in die Classic-Queue geleitet werden
- L4S-Dienste erfordern nicht nur Zurückhaltung bei der Rate, sondern auch bei Burstiness
- Die Schutzfunktion für Low-Latency-Queues in DOCSIS erhält geringe Latenz, indem sie Flows, die Queues bilden, teilweise in die Classic-Queue umleitet
- Solche Schutzfunktionen für Single-Queue sind kein zwingender Bestandteil der L4S-Architektur; ein Teil der L4S-Experimente soll klären, ob sie nötig sind
Tunnel und Privatsphäre
- Da L4S-AQM Stau über das ECN-Feld signalisiert, muss dieses Feld bei Betrieb in Tunneln oder auf unteren Schichten standardkonform zwischen den Schichten propagiert werden
- Die L4S-Architektur schließt Ansätze nicht aus, die Transportkennungen inspizieren
- Ein Beispiel ist um L4S-Unterstützung erweitertes FQ-CoDel
- Die Kerninnovation DualQ AQM erfordert jedoch keine Inspektion tiefer als bis zum äußersten IP-Header
- Selbst wenn Nutzer Anwendungs-Flow-Kennungen mit IPsec oder verschlüsselten VPN-Tunneln verschlüsseln, müssen sie nicht auf geringe Latenz verzichten
- Da L4S einer breiten Menge von Anwendungen geringe Latenz bieten kann, sinkt der Bedarf, einzelne Anwendungen oder feingranulare Klassen während der Übertragung durchs Netz zu unterscheiden
1 Kommentare
Meinungen auf Hacker News
Das ist wirklich cool. Ich habe letzten Monat bei der IETF 118 in Prag eine Live-Demo gesehen, und es sah sehr gut für Videochats aus, weil Bufferbloat vollständig beseitigt wurde.
Offenbar muss man ein zusätzliches Bit in IP-Pakete aufnehmen, um Informationen wie „Buffer voll“ zu transportieren, aber es funktionierte tatsächlich, und ich hatte das Gefühl: „Ich hätte nicht gedacht, dass das möglich ist.“
Für alle, bei denen der Zeitlink nicht funktioniert: Es ist bei 1 Stunde 21 Minuten. Edit: doch nicht, das war die Hackathon-Zusammenfassung, und der Vortrag ist nicht leicht zu finden.
Ich war neugierig, wie der Empfänger dem Sender Überlastung meldet, und habe nachgesehen; es war schwerer zu finden als erwartet. Der Kern ist in https://www.rfc-editor.org/info/rfc3168 dokumentiert.
Vereinfacht gesagt gibt es nicht nur ein Flag, sondern etwa drei. Ein Flag, mit dem der Sender dem Router signalisiert, dass ECN unterstützt werden kann, ein Flag, mit dem der Router dem Empfänger Überlastung signalisiert, und ein Flag, das der Empfänger beim Senden von ACK-Paketen setzt.
Der Sender zeigt ECN-Unterstützung über den ECT-Codepoint an, und ein ECN-fähiger Router setzt statt des Verwerfens des Pakets den CE-Codepoint im IP-Header und leitet es weiter. Der Empfänger setzt im nächsten TCP-ACK ECN-Echo, und der Sender reagiert auf die Überlastung wie auf Paketverlust und setzt anschließend im TCP-Header des nächsten Pakets das CWR-Flag.
Bob Briscoe denkt schon lange in diese Richtung. Als einschlägige Klassiker empfehle ich diese Texte:
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Im Kabelnetz von Comcast wurden einige Tests durchgeführt, und die folgenden Folien erklären das:
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Ich weiß nicht, wohin das führt, aber ich könnte mir vorstellen, dass ISPs anfangen, Maut für eine Überholspur zu verlangen.
Nur meine persönliche Meinung, aber ich arbeite bei Comcast.
Wenn man mehr über L4S erfahren möchte: Auf understandinglatency.com startet heute eine Webinar-Reihe. Dort sprechen einige L4S-Autoren, der Verantwortliche für den L4S-Feldversuch bei Comcast sowie auch kritische Stimmen.
Ich habe eine kurze Demo mit einem praktischen Einsatz für den Video-Feed eines RC-Autos gefunden: https://www.youtube.com/watch?v=RZmS10djDEg
Das ist zwar ein Fortschritt in die richtige Richtung, aber es gibt ein Problem, sobald auch nur ein böswilliger Teilnehmer das Überlastungsfeedback ignoriert und einfach einen größeren Anteil der Bandbreite haben will. Dann weichen die anderen Teilnehmer zurück, und die unfaire Seite bekommt, was sie will.
Gute Teilnehmer können schwer erkennen, ob sich die anderen an die Regeln halten, und müssen wissen, dass Fair Queuing vorhanden ist, um darauf vertrauen zu können, dass L4S sie fair behandelt.
Dieses Problem lässt sich lösen, indem man L4S durch Fair Queuing wie fq_codel ergänzt und die Überlastungssteuerung erkennen lässt, ob Fair Queuing vorhanden ist: https://github.com/muxamilian/fair-queuing-aware-congestion-...
Die Fair-Queuing-Debatte ist Teil einer größeren Debatte. Ohne Fair Queuing wird Fairness unabhängig von L4S bereits von den Endhosts umgesetzt, und Endhosts wie Server können Überlastungsreaktionen ignorieren und mehr als ihren fairen Anteil nehmen. Das ist kein neues Problem, das L4S geschaffen hat, aber manche sehen L4S so, dass es leichter macht, sich einen größeren Anteil zu holen.
Befürworter von Fair Queuing meinen, das Netzwerk müsse faire Teilhabe garantieren, aber nicht alle stimmen dem von ihnen gewählten Fairnessmaß zu. Insbesondere einer der wichtigsten L4S-Befürworter stimmt nicht zu; das sieht man in dem hier verlinkten Paper: https://news.ycombinator.com/item?id=38598023
Ich frage mich, was sich aus Nutzersicht konkret ändert. Werden Videoanrufe zum Beispiel näher an Echtzeit herankommen? Normalerweise gibt es etwa 0,5 bis 1 Sekunde Verzögerung, sodass es beim Sprechen oft zu Unterbrechungen und Hineinreden kommt. Welche anderen Anwendungen würden deutlich besser?
Um unter 3 Mbit/s Bitrate zu bleiben, muss man schwierige Kompromisse zwischen Qualität, Bitrate, CPU-Zeit und Latenz eingehen. Normale Laptops haben entweder langsame CPUs oder halten selbst bei 6-Core-CPUs im Akkubetrieb die Taktfrequenz niedrig. Hardwarebeschleunigte Videocodierung ist ebenfalls nicht überall verfügbar, wodurch Qualität und Latenz leiden.
Auch Wi-Fi fügt Latenz hinzu, besonders wenn ein Laptop im Akkubetrieb läuft. Für NAT-Traversal nutzen viele Videochat-Dienste Cloud-Server als Relay, was zusätzliche Latenz verursacht.
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Auch stark interaktive Funktionen wie Gaming und Videokonferenzen werden ohne Verzögerung deutlich besser. Da heute viele Roundtrips nötig sind, um Webseiten zu rendern, Videos zu streamen oder Interaktionen mit KI-Assistenten wie Alexa zu verarbeiten, kann sich nahezu alles verbessern, womit Nutzer und Geräte interagieren.
Im Kern ist L4S eine Technik, die den Latenz-Feedback-Loop verkürzt. Die zweite Hälfte dieses Videos erklärt das ziemlich gut: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp