Zusammenfassung

  • FQ-PIE hasht sichtbare Fünf-Tupel in endlich viele Queues, führt PIE-Zustand je Queue und bedient sie mit einem von DRR abgeleiteten Scheduler.
  • Ein Queue-Besuch und übertragene Bytes belegen lokalen Dienst, aber keine Gleichheit zwischen Kunden, Anwendungen, Tunneln oder Fertigstellungszeiten.
  • Klassifikation, Messung, Überlastentscheidung, Scheduler-Dienst, Transportreaktion und Ergebnis brauchen getrennte, verknüpfbare Belege.

Ordnungsgemäß bedient, ungleich beendet

Zwei Anwendungen starten gleichzeitig. Der Scheduler besucht ihre aktiven Buckets, verbucht Defizit und überträgt aus beiden. Seine lokale Buchführung ist sauber. Trotzdem endet eine Übertragung deutlich früher. Paketgrößen, RTT, Transportalgorithmus, Nachfrage und ein weiterer Engpass unterscheiden sich.

Aus dem Bucketprotokoll lässt sich kein Fehler des Schedulers ableiten. Ebenso wenig lässt sich daraus Ergebnisgleichheit ableiten. Dienst ist ein Ereignis an einer bestimmten Kontrollstelle; Fertigstellung ist das Produkt einer ganzen Kette. Wer beides in einer Kennzahl „fair“ zusammenzieht, entfernt genau die Grenze, die eine spätere Untersuchung braucht.

Revision 02 des TSVWG-Internet-Drafts Flow Queue PIE vom 6. Juli 2026 beschreibt die Kombination von Flow Queuing und PIE. Sie läuft am 7. Januar 2027 ab. Datatracker führt sie als aktives Working-Group-Dokument mit IESG-Status I-D Exists; der Text nennt Experimental als beabsichtigten Status. Sie ist kein RFC.

Ein Bucket ist kein Vertragspartner

FQ-PIE verwendet Protokollnummer, Quell- und Zieladresse sowie Quell- und Zielport als sichtbares Fünf-Tupel. Ein Hash ordnet es einer endlichen Queue-Tabelle zu. Das ist eine praktische Implementierung, aber kein Identitätsregister.

Verschiedene Tupel können im selben Bucket kollidieren. Dann teilen unabhängige Flows PIE-Zustand und Schedulerbehandlung. Umgekehrt kann ein Kunde oder eine Anwendung viele Verbindungen öffnen und in vielen Buckets erscheinen. Gleichmäßiger Dienst für Buckets kann daher mit ungleicher aggregierter Zuteilung an Kunden einhergehen.

Ein belastbarer Klassifikationsbeleg enthält Tupel, Hash- und Perturbationsepoche, Tabellengröße, ausgewählten Bucket und Kollisionshinweise. Ohne diese Herkunft wirkt eine Queuenummer wie ein dauerhaftes Subjekt, obwohl sie nur eine veränderliche Implementierungsadresse ist.

Verschlüsselung verändert die sichtbare Einheit

Ein undurchsichtiger Tunnel kann viele innere Sitzungen als einen äußeren Flow erscheinen lassen. Daneben kann eine ungekapselte Anwendung mehrere Fünf-Tupel erzeugen. An einer Grenze mag der Tunnel die richtige Einheit sein; an einer anderen gilt die Zusage pro Anschluss oder Anwendung.

Innere Identität allein für die Queuebehandlung offenzulegen, kann neue Datenschutz- und Sicherheitsrisiken schaffen. Governance verlangt deshalb keine grenzenlose Sichtbarkeit. Sie verlangt die Benennung der beobachtbaren Einheit, der geschützten Einheit und der Qualität ihrer Zuordnung. Eine fehlende Zuordnung begrenzt die Aussage, nicht zwingend den Betrieb.

PIE steuert gemessenen Zustand

PIE verändert eine Drop-Wahrscheinlichkeit anhand der Abweichung zwischen gemessener Queueverzögerung und Ziel sowie der Bewegungsrichtung. RFC 8033 verwendet beispielhaft 15 Millisekunden als Ziel und als Standard-Aktualisierungsintervall. Ein Zielwert ist eine Controllergröße, keine Garantie pro Paket.

Die Burst Allowance lässt kurze Spitzen zeitweise die zufällige Dropentscheidung umgehen. Eine Verzögerung oberhalb des Ziels bei verbleibendem Guthaben ist deshalb nicht automatisch ein Defekt. Umgekehrt beweist das Ziel keinen erfüllten SLO. Ziel, Guthaben, Wahrscheinlichkeit, Probenzeit und Erholung müssen gemeinsam gelesen werden.

PIE kann Verzögerung über Queuelänge und Abflussrate nach Little abschätzen oder direkt Zeitstempel nutzen. Der FQ-PIE-Entwurf empfiehlt direkte Zeitstempel, weil eine verlässliche Abflussrate je Queue schwer zu erhalten ist. Der Übergang von einer Hostqueue in einen Treiberring ist nicht zwingend die Übertragung auf der Leitung.

Auch ein direkter Wert kann echt und dennoch nicht mehr repräsentativ sein. Für die Aktualisierung darf die Verzögerung des zuletzt entnommenen Pakets dienen. Nach einer Geschwindigkeits- oder Laständerung ist diese Probe gealtert. Messpunkt, Probenzeit, Alter, vorheriger Wert, Updatezeit und Offloadzustand gehören in denselben Beleg.

Markierung und Drop bleiben lokal

Bei ECN-fähigen Paketen kann FQ-PIE markieren statt verwerfen. Die Markierung beweist eine lokale Feldänderung unter einer bestimmten Schwelle, Wahrscheinlichkeit und Konfiguration. Sie beweist nicht, dass der Empfänger sie zurückmeldete, der Sender seine Rate senkte, ein späterer Engpass verschwand oder eine Anwendung profitierte.

Ist die gesamte Paketkapazität erschöpft, wird ein neues Paket ohne weitere Verarbeitung verworfen. Das ist ein Beleg für Nichtaufnahme, nicht für die Schuld eines „dicken Flows“. Anders als das gesättigte Limitverfahren von FQ-CoDel sucht FQ-PIE nicht die größte Bytequeue und verwirft daraus massenhaft. Der Entwurf warnt, dies könne bei bereits am Eingang arbeitendem PIE zur Unterauslastung führen. Berichte dürfen die bewusst fehlende Zuschreibung nicht nachträglich erfinden.

DRR-Dienst hat einen engen Beweisumfang

Der Scheduler verwendet Quantum und Defizit, um aktive Queues zu besuchen. Besuch, positives Defizit und entnommene Bytes sind starke Belege dafür, dass der Bucket Dienst erhielt. Sie sagen nichts Endgültiges über Flow Completion Time, Anwendungsnutzen oder Kundenanteil.

Auch hohe Linkauslastung löst die Verteilungsfrage nicht. Ein beschäftigter Ausgang kann gleichzeitig einen kollidierenden kleinen Flow, einen Tunnel mit vielen inneren Sitzungen und eine Anwendung mit acht Buckets tragen. Mittelwert, Auslastung, aktive Queuezahl und Kundenerlebnis besitzen verschiedene Nenner.

Der Entwurf nennt Implementierungen in Linux, FreeBSD und ns-3. Das belegt verfügbaren Code, nicht die Disziplin einer konkreten Produktionsschnittstelle, ihre Parameter, ihren Messpunkt oder das Nutzerergebnis. Wechselwirkungen mit BBR, Mark/Drop-Schwellen, kurze Flows, PIE-Erweiterungen und alternative Hashes bleiben ausdrücklich Gegenstand weiterer Experimente.

Quellen