Zusammenfassung

  • NQB ist kein Gutschein für die Überholspur. RFC 9956 gibt gleichmäßigen, datenarmen Mikroflüssen eine kurze Best-Effort-Queue, weil ihr Paketmuster beobachtbar und prüfbar ist.
  • Queue-Schutz kann Verkehr zurückstufen oder verwerfen, der die geschützte Queue füllt; L4S verlangt separat skalierbare Staukontrolle, ECT(1) und kompatible Markierung.
  • Das sinnvolle Produktmaß ist die End-to-End-Latenz unter Last über Sender, Zugang, Gateway und WLAN, einschließlich Markierungs-, Fallback- und Reklassifizierungsbeleg.

Man nehme einen Anschluss mit 1 Gbit/s. Ein Notebook startet ein Backup. Die interaktive Anwendung braucht kaum Bandbreite, doch ihre kleinen Pakete warten hinter einem Burst an der engsten Queue. Der Leerlauftest bleibt tadellos. Der Nutzer erlebt Verzögerung.

Genau diese Differenz adressiert die neue Non-Queue-Building-Behandlung der IETF. RFC 9956, seit Mai 2026 Proposed Standard, definiert einen Best-Effort-Dienst mit kleinem Puffer für gleichmäßige, datenarme und anwendungsbegrenzte Mikroflüsse. Sprache, Spiel-Synchronisierung, DNS und manche Maschine-zu-Maschine-Nachrichten können passen; eine kapazitätssuchende Übertragung nicht.

NQB bedeutet nicht „wichtige Anwendung“. Der Strom behauptet, selbst keine wesentliche Queue aufzubauen, und diese Behauptung ist beobachtbar. Ein Sender oberhalb der Verhaltensgrenze darf den NQB-DSCP nicht setzen. Ein unterstützender Knoten muss NQB und Default trennen und sollte die kurze Queue gegen Flüsse schützen, die ihr Versprechen brechen.

Das ist Best Effort mit Beweislast, keine bezahlte Priorität. Die Queue bleibt kurz, weil sie nicht zur zweiten tiefen Queue werden darf.

Verhalten kann die Markierung widerrufen

RFC 9956 empfiehlt, inkompatible Ankunftsmuster zu erkennen und den beanstandeten Verkehr in die normale Queue zurückzulegen oder zu verwerfen. Maßstab sind Pakete, nicht Anwendungsname, Port oder Adresse. Der Engpass ist der richtige Beobachter, denn dort wird Wachstum sichtbar.

RFC 9957, ebenfalls vom Mai 2026, erläutert einen DOCSIS-Queue-Protection-Algorithmus. Er ist informativ und kein Standards-Track-Dokument. Der Algorithmus misst die Verzögerung der Low-Latency-Queue, führt einen Warteschlangen-Score je Fluss und greift ein, wenn Verzögerung und Beitrag ihre Schwellen überschreiten. Üblich ist die Reklassifizierung in die Classic-Queue.

Die kommerzielle Grenze ist klar. Die Anwendung wählt die Markierung, das Zugangsgerät entscheidet, ob das beobachtete Verhalten die Behandlung weiter verdient. Software, Schwellen, Zähler und Update-Support werden Teil des Dienstes. Zwei Angebote mit gleicher Leitungsrate können dasselbe markierte Paket unterschiedlich behandeln.

L4S ist ein paralleler Vertrag, kein Synonym

NQB kann eine Low-Latency-Queue mit L4S teilen, doch die Pflichten unterscheiden sich. Die L4S-Architektur verbindet skalierbare Staukontrolle beim Sender, feine Markierung am Engpass und das Protokoll dazwischen. RFC 9331 verwendet ECT(1) im ECN-Feld für Verkehr, der diese Reaktion beansprucht. RFC 9332 beschreibt Dual-Queue Coupled AQM: Wartezeit wird isoliert, Stausignale werden gekoppelt, damit Classic und L4S dieselbe Kapazität nutzen.

Strikte Priorität würde jede Anwendung an die Spitze locken. DualQ soll Verzögerung trennen, ohne unbegrenzten Bandbreitenvorrang zu gewähren. NQB hängt am anwendungsbegrenzten Muster, L4S an häufiger, proportionaler Reaktion auf Markierungen. Bleibt nur das Etikett, scheitern beide.

RFC 9331 verlangt daher einen Rückweg. Der Sender muss das Zusammenwirken mit Classic ECN überwachen und bei einem ungelösten Koexistenzproblem auf Classic-Staukontrolle zurückfallen. „L4S aktiviert“ ist kein dauerhaftes Recht auf jedem Pfad.

Der Pfad endet nicht am Modem

Eine korrekte Zugangs-Queue kann ihre Wirkung im Haushalt verlieren. CableLabs bezeichnet WLAN häufig als End-to-End-Engpass. Medienzugriffszeit, Entfernung, Konkurrenz, AP-Implementierung und Client-Mix kommen zum Puffern hinzu. CableLabs veröffentlichte ein experimentelles NS-3-Modell und beschreibt Simulationen sowie Tests mit einem Nokia-AP. Das sind reproduzierbare, begrenzte Versuche, kein globaler Leistungswert.

Auch der IP-Header kann seine Bedeutung verlieren. Apple warnt davor, beim Löschen von DSCP versehentlich ECN zu entfernen, da beide dasselbe Traffic-Class-Byte nutzen. Apple nennt L4S-Unterstützung für einige Nutzer seit iOS 17 und iPadOS 17 in QUIC und TCP. Das belegt Plattformfähigkeit, nicht Erhaltung über Zugang, Gateway und WLAN.

Comcast erklärte im Januar 2025, Low Latency DOCSIS/L4S mit Anwendungspartnern auszurollen; die Markierung sei freiwillig, ohne Sonderkosten und ohne proprietäre API. Das belegt Entwurf und Angebot eines Betreibers, nicht allgemeine Abdeckung oder einen festen Gewinn je Haushalt.

Wie die These widerlegt wird

Getestet wird unter Last. p50, p95 und p99 der RTT sowie Verluste mit und ohne Behandlung vergleichen, einen absichtlich falsch markierten Großfluss hinzufügen und über Kabel und WLAN, mit erhaltener oder gelöschter ECN sowie mehreren Gateway-Versionen wiederholen.

Die These wird schwächer, wenn getrennte Queues die Lastlatenz nicht ändern, falsch markierter Großverkehr selbst ohne Schutz nicht schadet, WLAN und Header-Erhaltung nichts ändern und Implementierungswahl weder Reklassifizierung noch Fallback beeinflusst. Die Quellen liefern weder weltweiten Anteil, übliche Sanktionsrate noch universellen Gewinn. Sie liefern einen falsifizierbaren Mechanismus.