L4S – ein Booster für ECN?

L4S steht für “Low Latency, Low Loss, Scalable Throughput”. Der “L4S Internet Service” basiert auf dem Verfahren der Explicit Congestion Notification (ECN). Mit letzterem quäle ich regelmäßig die Teilnehmer meines Seminars „Fehlersuche in lokalen Netzen“. ECN funktioniert im Prinzip wie folgt:

• Sobald ein Router in einer seiner Warteschlangen eine hohe Auslastung feststellt, markiert er die entsprechenden IP-Pakete mit „Congestion Experience“.
• Der Empfänger erkennt diese Markierung und markiert seinerseits die Quittung an den Absender mit „ECN Echo“.
• Daraufhin wird der Absender seine Paketrate vermindern.

Das Verfahren erfordert nicht nur die Unterstützung durch Endgeräte und Server. Vielmehr müssen auch alle Netzkomponenten mitspielen. Wahrscheinlich ist das die Ursache dafür, dass ECN bisher kaum zum Einsatz kommt. Die deutschsprachige Wikipedia [1] schreibt:

„Wer ECN einsetzt, sollte sich bewusst sein, dass manche Administratoren die geänderte Semantik des TOS-Bytes durch den RFC 3168 im September 2001 noch nicht realisiert haben. Auch gehen Router und Firewalls selbst namhafter Unternehmen teilweise unvorhersehbar mit den ECN-Bits um. Es besteht daher die Gefahr, dass eine Verbindung mit eingeschaltetem ECN nicht zustande kommt.“

Ich selbst habe ECN an meinem Client aktiviert und beobachte keinerlei Einschränkungen. Protokollanalyse zeigt, dass es im Internet zahlreiche Sites gibt, bei denen ECN ebenfalls aktiviert ist. Einen Nutzen konnte ich bislang jedoch nicht nachweisen. Wahrscheinlich liegt das auch daran, dass die bisherige Art der Auslastungs-Regelung bei TCP, die im Wesentlichen auf Paketverlusten basiert, ganz gut funktioniert, und das wie folgt:

Aus Sicht der meisten TCP-Varianten besteht das Optimum darin, dass die Zahl unbestätigt gesendeter Pakete (das Congestion Window, CWND) dem Produkt aus Bandbreite und Antwortzeit (Round Trip Time, RTT) entspricht. An diesem Punkt ist das Medium vollständig ausgelastet, und es gehen noch keine Pakete verloren.

Um das Optimum zu erreichen, erhöht der Sender die Paketrate so lange, bis erste Pakete verloren gehen. Daraufhin vermindert er seine Sendetätigkeit schlagartig, um sich nachfolgend wieder an das vermeintliche Optimum heranzutasten, an dem Paketverluste einsetzen, und so fort.

Für die meisten Anwendungen ist das mehr als ausreichend. Stellt man jedoch erhöhte Anforderungen an die Übertragungsqualität, erkennt man die folgenden Nachteile:

• Die tatsächlich erzielte Bitrate folgt einer Art Sägezahn-Funktion, ist also nicht konstant.
• Verlorene Pakete müssen wiederholt werden („Retransmissions“), wodurch sich die Antwortzeit verlängert.
• Im Bereich des Optimums sind die Warteschlangen an den „Engstellen“ der Netze gefüllt, was ebenfalls die Antwortzeit erhöht.

Besser wäre es, frühzeitig die Paketrate zu begrenzen. Dann erreichte man dauerhaft geringe Antwortzeiten bei gleichmäßiger Bitrate. Dieses Ziel hat L4S im Auge. Scalable Congestion Control bedeutet, dass der Sender frühzeitig die Paketrate begrenzt, sodass keine Paketverluste auftreten. Dafür benötigt er die Informationen aus den Netzkomponenten, die Pakete proportional zur Auslastung mit „Congestion Experience“ markieren.

Neben Scalable Congestion Control ist eine weitere Voraussetzung dafür zu schaffen, dass sich eine gleichmäßige Paketrate mit geringer Latenz ergibt: Die Warteschlangen sind von „unregelmäßigem“ Verkehr weitgehend freizuhalten. Mit anderen Worten, L4S-Datenverkehr ist in separaten und priorisierten Warteschlangen zu übertragen. Man muss also Quality of Service (QoS) implementieren. Die Klassifizierung der Pakete erhält man dabei zum Nulltarif: L4S-Datenverkehr lässt sich an der ECN-Markierung im Type-of-Service-(ToS-)Feld des IP-Headers erkennen.

Nun, werden Sie einwenden, wieso sollte L4S erfolgreicher sein als ECN? Auch hierbei müssen doch Endgeräte, Server und Netzkomponenten zusammenarbeiten. Richtig! Im LAN wird L4S wohl kaum Relevanz erlangen. Jedoch wird es als große Chance für den Mobilfunk angesehen.

Mit der Einführung des 5G-Mobilfunks sind bekanntlich hohe Erwartungen an Verlässlichkeit und geringe Latenz verknüpft. „Ultra-reliable and Low Latency Communications“ (URLLC) wird mit den kommenden 5G Releases dafür die Voraussetzungen auf der Luftschnittstelle schaffen.

L4S ist das noch fehlende Puzzle-Teil, welches diese hohen Erwartungen auch Ende-zu-Ende zu erfüllen hilft. Im Rahmen der Weiterentwicklung der 5G-Standards soll L4S Berücksichtigung finden, so hört man in [2]. L4S selbst wurde im Januar in den RFCs 9330 [3] bis 9332 veröffentlicht.

Die eingangs gestellte Frage beantworte ich wie folgt: Mit L4S und 5G wird der Explicit Congestion Notification endlich die verdiente Wertschätzung zuteil. Auf der Seite der Clients und Server sind dafür die Voraussetzungen bereits seit Langem geschaffen. Fehlt nur noch der Mobilfunk…

Verweise

[1] https://de.wikipedia.org/wiki/Explicit_Congestion_Notification

[2] https://www.ericsson.com/en/reports-and-papers/white-papers/enabling-time-critical-applications-over-5g-with-rate-adaptation

[3] RFC 9330, Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture, IETF Informational, Januar 2023, https://www.rfc-editor.org/rfc/rfc9330.html