Bufferbloat vermeiden: AQM (CoDel/PIE) in Telco Netzen nutzen

Bufferbloat vermeiden ist in Telco-Netzen heute genauso wichtig wie „genug Bandbreite“ bereitstellen, denn viele Qualitätsprobleme entstehen nicht durch zu wenig Durchsatz, sondern durch zu große, zu träge Warteschlangen. Bufferbloat bedeutet: Pakete werden nicht gedroppt, sondern in großen Puffern gesammelt – die Folge sind hohe und stark schwankende Latenzen. Für Endnutzer äußert sich das als „Internet ist langsam“, obwohl Speedtests gut aussehen: Videokonferenzen ruckeln, Voice klingt instabil, Gaming hat plötzlich hohen Ping, SaaS-Anwendungen reagieren zäh und TCP-Durchsatz schwankt. In Provider-Umgebungen ist Bufferbloat besonders häufig, weil Engpässe oft am Rand liegen (DSL/FTTH/Cable Access, Mobile Backhaul, Interconnects, BNG/BRAS-Uplinks) und weil dort Geräte – absichtlich – viel puffern, um Drops zu vermeiden. Genau hier setzt AQM (Active Queue Management) an: Statt zu warten, bis der Buffer voll ist (Tail Drop), steuert AQM die Queue aktiv und hält sie kurz. Zwei der praxistauglichsten AQM-Verfahren sind CoDel (Controlled Delay) und PIE (Proportional Integral controller Enhanced). Richtig eingesetzt senken sie die Latenz unter Last, ohne den Throughput zu „zerstören“, und sind damit ein ideales Werkzeug, um QoE (Quality of Experience) in Telco-Netzen zu verbessern – vor allem in Best-Effort- und datenlastigen Klassen, flankiert durch Shaping und saubere QoS-Profile.

Was Bufferbloat in Telco-Netzen so gefährlich macht

Bufferbloat ist tückisch, weil es nicht zwingend Paketverlust erzeugt. Klassisches Troubleshooting schaut oft zuerst auf Drops. Bei Bufferbloat sind Drops aber gering, während Queueing-Delay massiv steigt. In Telco-Topologien kumuliert dieser Effekt: Ein großer Puffer im CPE, ein weiterer im Access/BNG, plus ein Puffer im Interconnect – schon sind aus wenigen Millisekunden schnell Hunderte Millisekunden zusätzliche Verzögerung geworden. Für Echtzeitdienste ist das fatal, weil Jitter-Buffer irgendwann überlaufen oder zu groß werden müssen, was Interaktivität zerstört. Für TCP führt Bufferbloat häufig zu „globaler Synchronisation“: Viele Flows stauen sich, dann kommt eine Drop-Welle, alle reduzieren, dann stauen sie sich wieder. Das Ergebnis ist schwankender Durchsatz und schlechte Nutzerwahrnehmung.

• Hohe RTT-Perzentile: p95/p99 Latenz steigt unter Last stark an, obwohl die Durchschnittslatenz moderat wirkt.
• Jitter-Spitzen: Delay-Variation steigt, Voice/Video leidet, selbst ohne sichtbare Drops.
• QoE-Effekt: „Lag“ bei Gaming, träge SaaS, ruckelige Calls, instabile Streams.
• Unsichtbar im Mittelwert: Minuten-Mittelwerte verstecken Bufferbloat, Perzentile zeigen ihn.

Warum Tail Drop Bufferbloat begünstigt

Tail Drop ist das einfachste Queue-Verhalten: Solange Platz ist, werden Pakete gepuffert; ist der Buffer voll, wird gedroppt. In schnellen, hochaggregierten Netzen führt das zu zwei Problemen. Erstens wachsen Queues oft sehr groß, bevor überhaupt gedroppt wird – die Latenz steigt stark. Zweitens sind Drops dann „burstig“: Wenn der Buffer voll ist, werden plötzlich viele Pakete verworfen. TCP reagiert darauf mit Window-Reduktion, was zu Durchsatzschwankungen führt. Für Echtzeitpakete sind Tail-Drop-Wellen besonders schädlich, weil sie plötzlich auftreten und Audio/Video sichtbar beschädigen. AQM setzt früher an: Es markiert oder droppt kontrolliert, bevor der Buffer voll ist, um die Queue kurz zu halten.

• Queue wächst zu lange: Latenz steigt, bevor Congestion sichtbar wird.
• Drop-Wellen: Drops treten gebündelt auf, TCP kollabiert zeitweise.
• Echtzeit leidet indirekt: auch wenn Echtzeit priorisiert ist, kann Bufferbloat in Best Effort die Gesamtinteraktivität drücken.

AQM-Grundidee: Congestion früh signalisieren statt spät bestrafen

AQM verfolgt ein klares Ziel: Die Warteschlange soll nicht „beliebig“ wachsen, sondern in einer kontrollierten Größenordnung bleiben. Dazu werden Pakete bereits vor dem vollen Buffer markiert oder gedroppt. Markieren (ECN) ist besonders elegant, weil es Congestion signalisiert, ohne sofort Verlust zu erzeugen – vorausgesetzt, Endpunkte und Transportpfad unterstützen ECN. Wo ECN nicht zuverlässig verfügbar ist, arbeitet AQM über probabilistische Drops oder delay-basierte Mechanismen. Im Telco-Betrieb ist der größte Gewinn von AQM: Latenz bleibt auch bei hoher Auslastung stabiler, und die Nutzererfahrung verbessert sich, ohne dass man zwangsläufig massiv Kapazität nachrüsten muss.

• Kurze Queues: niedrigere p95/p99 RTT und weniger Jitter.
• Sanftere Congestion: weniger Drop-Wellen, stabilere TCP-Performance.
• Bessere Mischlast: Bulk-Transfers drücken interaktive Flows weniger stark weg.

CoDel: Controlled Delay als delay-basierte AQM

CoDel steuert nicht primär die Queue-Länge in Bytes oder Paketen, sondern das Queueing-Delay. Das ist in Telco-Netzen sehr attraktiv, weil das eigentliche Problem von Bufferbloat eben Verzögerung ist. CoDel beobachtet, wie lange Pakete in der Queue warten, und greift ein, wenn das Delay über eine Zielgröße hinausgeht. Dadurch bleibt die Latenz auch bei Last kontrolliert, selbst wenn die Bandbreite schwankt oder die Paketgrößen variieren. CoDel ist besonders hilfreich in Access-nahen Segmenten, in denen variable Last und Mikrobursts auftreten, und in Best-Effort-Klassen, wo TCP-Verkehr dominiert.

• Delay-Fokus: direkt am Symptom von Bufferbloat orientiert.
• Robust bei Paketgrößen: weniger abhängig davon, ob viele kleine oder wenige große Pakete kommen.
• Gute Interaktivität: senkt Latenzspitzen bei gleichzeitigen Bulk-Transfers.

PIE: Regelkreis-basierte AQM für schwankende Links

PIE arbeitet mit einem Regelkreis, der eine Ziel-Latenz im Buffer anstrebt und die Drop-/Mark-Rate dynamisch anpasst. PIE wurde unter anderem mit Blick auf Access-Szenarien entwickelt, in denen die verfügbare Rate und der Traffic stark schwanken können. Das macht PIE in Telco-Umgebungen interessant, in denen Links variabel sind oder in denen Burstiness stark ausgeprägt ist. PIE versucht, die Queueing-Latenz um ein Ziel herum zu stabilisieren, ohne übermäßig aggressiv zu droppen. Praktisch ist PIE häufig dort attraktiv, wo Sie ein robustes „Set-and-forget“ Verhalten möchten, das sich an wechselnde Bedingungen anpasst.

• Adaptive Steuerung: passt sich an wechselnde Last- und Linkbedingungen an.
• Delay-orientiert: hält Latenzspitzen kontrollierbar.
• Telco-fit: besonders relevant in accessnahen, schwankenden Segmenten.

CoDel vs. PIE: Wie Sie das passende AQM im Telco-Design wählen

In der Praxis ist die Wahl selten ideologisch, sondern abhängig von Plattformunterstützung, Linkcharakteristik und Betriebszielen. CoDel ist sehr attraktiv, wenn Sie konsequent delay-basiert arbeiten und stabile, niedrige Queueing-Delays priorisieren. PIE ist attraktiv, wenn Sie ein adaptives, regelkreisähnliches Verhalten bevorzugen, das in variablen Links gut funktioniert. Entscheidend ist: Egal ob CoDel oder PIE – AQM muss in die richtige Klasse und an den richtigen Ort. AQM in der Voice-LLQ ist meist nicht sinnvoll, weil Voice nicht „durch Congestion lernen“ kann; AQM ist primär für datenlastige Klassen (Best Effort, Bulk) gedacht, um deren Queues kurz zu halten und damit auch interaktive Dienste indirekt zu schützen.

• Best Effort: häufig der beste Ort für AQM/ECN, weil hier die größten Buffers entstehen.
• Bulk/Scavenger: AQM kann Drop-Wellen reduzieren und die Klasse „zahmer“ machen.
• Echtzeitklassen: eher kurze Queue-Limits und Priorisierung statt AQM.

ECN als Verstärker: Latenz senken ohne Drops zu produzieren

Wenn ECN (Explicit Congestion Notification) verfügbar ist, kann AQM markieren statt droppen. Das ist besonders nützlich, weil Throughput erhalten bleibt und TCP dennoch auf Congestion reagiert. In Telco-Netzen ist ECN jedoch eine Frage der End-to-End Unterstützung: Endgeräte, Betriebssysteme, Middleboxes und Tunnel müssen ECN korrekt weitertragen. Wenn ECN unterwegs genullt oder falsch behandelt wird, fällt AQM wieder auf Drops zurück. Ein realistischer Ansatz ist daher: AQM so designen, dass es auch ohne ECN funktioniert, und ECN als Bonus nutzen, wenn die Umgebung es zuverlässig unterstützt.

• Marking statt Drop: reduziert Verlust, stabilisiert Throughput und hält Queues kurz.
• End-to-End Bedingung: ECN muss durch NAT, Firewalls, Tunnels und Provider-Übergänge korrekt bleiben.
• Messbarkeit: ECN-Mark-Raten sind wertvolle Congestion-Indikatoren.

AQM ohne Shaping ist oft nur die halbe Miete

Ein häufiger Praxisfehler ist, AQM einzuschalten, ohne die Queue-Lage zu kontrollieren. Wenn Congestion beim Provider oder in einem CPE-Modem liegt, kann Ihr AQM im Netzgerät nur begrenzt helfen. Deshalb ist Shaping der natürliche Partner von AQM: Egress Shaping verlagert Congestion in Ihr Gerät, AQM hält die lokale Queue kurz. Diese Kombination ist besonders wirksam in Access- und WAN-Szenarien: Sie reduzieren Bufferbloat im Upstream, halten RTT-Perzentile stabil und verbessern Voice/Video indirekt, weil interaktive Anwendungen nicht in riesigen Best-Effort-Queues „ersticken“.

• Shaping: Congestion kontrollierbar machen, Bursts glätten.
• AQM: lokale Queue-Länge stabil halten, Drop-Wellen verhindern.
• Ergebnis: weniger Latenzspitzen, weniger Jitter, stabilerer Throughput.

Wo AQM in Telco-Netzen besonders sinnvoll ist

AQM bringt den größten Nutzen dort, wo Best Effort Queues groß werden und Mischlast dominiert: Access-Edges, BNG/BRAS, Metro-Aggregation, Interconnect-Ports, DC-Edges oder SASE/SD-WAN Egress-Points. Besonders im Upstream von Access-Links (DSL/Cable/FTTH) ist Bufferbloat ein Klassiker: Upload-Backups oder Cloud-Sync füllen die Queue, und Latenz schießt nach oben. AQM in Kombination mit Shaping hilft hier massiv. Im Core ist der Nutzen eher ereignisgetrieben (Failover, Hotspots), aber an Core-to-Edge Übergängen kann AQM ebenfalls wertvoll sein, weil dort Congestion häufiger auftritt als in reinen Transit-Links.

• Access Upstream: häufig der größte Bufferbloat-Hebel, besonders bei Consumer- und SMB-Anschlüssen.
• BNG/PE Uplinks: Aggregation vieler Sessions, Mikrobursts, variable Last.
• Interconnects: Fan-in auf wenige Ports, Drop-Wellen ohne AQM sind typisch.
• Overlay-Tunnel Egress: IPsec/GRE/VXLAN erhöhen Overhead und Burstiness; AQM stabilisiert Queues.

Interaktion mit QoS-Klassen: Voice schützen, ohne Best Effort „unendlich“ zu puffern

In Telco-Designs wird Voice meist über eine limitierte Priority Queue (LLQ) geschützt. Das ist richtig, aber es löst nicht automatisch Bufferbloat in Best Effort. Im Gegenteil: Wenn Best Effort riesige Buffers hat, leiden interaktive Daten, und Nutzer erleben „Lag“, obwohl Voice vielleicht stabil bleibt. Deshalb ist ein gutes Klassenmodell mehr als LLQ: Best Effort bekommt AQM/ECN, Bulk wird nachrangig, Business bekommt gewichtete Mindestanteile. So verhindert man, dass Best Effort durch große Buffers die gesamte Nutzererfahrung verschlechtert, während Echtzeit nur einen Teil des Problems abdeckt.

• LLQ für Voice: strikt limitiert, kurze Queue-Limits gegen Jitter.
• AQM für Best Effort: hält die Daten-Queue kurz, reduziert RTT-Spitzen.
• Bulk separieren: Backups/Updates in Scavenger, damit sie nicht Best Effort „aufblähen“.
• Network Control schützen: Routing/OAM braucht Ressourcen, sonst eskalieren Störungen.

Typische Failure Patterns bei AQM-Einführung

AQM ist kein „Schalter, der immer hilft“, wenn man ihn an der falschen Stelle oder mit falschen Erwartungen einsetzt. Ein häufiger Fehler ist, AQM in einer Umgebung zu aktivieren, in der Congestion nicht am eigenen Gerät entsteht – dann sieht man wenig Effekt. Ein weiterer Fehler ist zu aggressive AQM-Konfiguration, die unnötig Drops erzeugt, obwohl ECN möglich wäre oder Shaping fehlt. Auch Drift ist relevant: Unterschiedliche Plattformen implementieren CoDel/PIE nicht identisch, und ohne Templates/Governance entsteht inkonsistentes Verhalten.

• Keine Wirkung: Congestion liegt beim Provider/CPE; Shaping fehlt.
• Zu viele Drops: AQM zu aggressiv oder ECN nicht nutzbar; Parameter und Klassenplatzierung prüfen.
• Echtzeit leidet: AQM fälschlich in Echtzeitklasse statt in Best Effort; Queue-Design korrigieren.
• Inkonsequenz: Multi-Vendor Drift; Templates und Rezertifizierung fehlen.

Messbarkeit: Wie Sie Bufferbloat und AQM-Wirkung nachweisen

Der Nachweis gelingt über zwei Datenarten: Queue-Delay-Perzentile und Congestion-Signale. Queue-Delay p95/p99 zeigt, ob Bufferbloat tatsächlich sinkt. Drops oder ECN-Marks zeigen, ob AQM aktiv eingreift und Congestion früh signalisiert. Zusätzlich sollten Sie Applikations-KPIs betrachten: RTT-Perzentile für SaaS, Jitter/Loss für Voice/Video, und Nutzerbeschwerden korrelieren mit den Zeiten hoher Queue-Delay. Wichtig ist die Zeitauflösung: Microbursts und Bufferbloat treten in kurzen Fenstern auf; Tagesmittelwerte sind dafür ungeeignet.

• Queue-Delay p95/p99: zentrale Kennzahl gegen Bufferbloat.
• ECN-Mark-Raten: zeigen Congestion, ohne dass Loss steigen muss.
• Drop-Raten: sollten kontrollierter und weniger „wellig“ werden als bei Tail Drop.
• Applikationssicht: SaaS-RTT, UC-KPIs, Gaming-Ping – QoE ist das Ziel.

Blueprint: CoDel/PIE in Telco-Netzen erfolgreich einführen

Ein praxiserprobtes Vorgehen beginnt mit der Lokalisierung der Congestion Domains: Access-Uplink, BNG/PE-Uplink, Interconnect, Metro-Aggregation. Dort definieren Sie ein schlankes Klassenmodell: Voice in limitierte LLQ, Video/Business in gewichtete Klassen, Best Effort mit AQM/ECN, Bulk nachrangig. Anschließend stellen Sie sicher, dass Congestion kontrollierbar ist – typischerweise durch Egress Shaping knapp unter der effektiven Rate, inklusive Overhead und Headroom. Dann aktivieren Sie AQM (CoDel oder PIE) gezielt in Best Effort (und ggf. Bulk), nicht in der Voice-LLQ, und validieren die Wirkung über Queue-Delay p95/p99 sowie ECN-/Drop-Signale. Parallel prüfen Sie ECN-End-to-End, wo möglich, und bauen Governance auf: Templates pro Linkrolle, Rezertifizierung und Monitoring. So wird Bufferbloat vermeiden kein „Tuning-Projekt“, sondern ein reproduzierbares Telco-Pattern, das Latenz unter Last senkt, Throughput stabil hält und die Nutzerqualität nachhaltig verbessert.