Microbursts behandeln: Buffering, Shaping und AQM als Toolbox

Microbursts behandeln ist eine der wichtigsten Fähigkeiten im modernen Netzwerkbetrieb, weil sie genau in dem Zeitbereich auftreten, den klassische Monitoring-Ansätze oft übersehen: Millisekunden bis wenige Sekunden. In dieser kurzen Zeit können Warteschlangen (Queues) schlagartig volllaufen, Pakete gedroppt werden oder die Latenz massiv ansteigen – obwohl die durchschnittliche Auslastung eines Links über Minuten betrachtet völlig unkritisch wirkt. Das ist besonders problematisch für Echtzeitdienste wie Voice und Video, aber auch für interaktive Anwendungen, Transaktionen, VDI und Cloud-Workloads, bei denen nicht nur Durchsatz zählt, sondern stabile RTT-Perzentile. Microbursts entstehen typischerweise durch Fan-in (viele Eingänge auf einen Ausgang), durch Traffic-Bündelung in Servern, Hypervisors und NICs, durch TCP-Verhalten (z. B. Slow Start und Windowing), durch Encapsulation in Tunneln, durch Scheduler in Shared-Media-Access (PON/DOCSIS) oder durch Routing- und Failover-Ereignisse, die Flows plötzlich neu verteilen. Die gute Nachricht: Es gibt eine praxiserprobte Toolbox, mit der sich Microbursts kontrollieren lassen. Diese Toolbox besteht aus Buffering (bewusst gewählte Puffer und Queue-Limits), Shaping (Bursts glätten und Congestion in den eigenen Einflussbereich holen) und AQM (Active Queue Management) inklusive ECN, um Queue-Längen stabil zu halten und Drops kontrollierter zu machen. Entscheidend ist, die Werkzeuge nicht isoliert zu betrachten, sondern als System: Buffering ohne AQM führt schnell zu Bufferbloat; AQM ohne Shaping kann Drops an der falschen Stelle erzeugen; Shaping ohne passende Queue-Profile kann zwar Bursts glätten, aber Echtzeit dennoch nicht schützen.

Was Microbursts sind und warum sie so tückisch sind

Ein Microburst ist ein kurzfristiger, hoher Datenstoß, der die momentane Servicekapazität eines Ausgangsports übersteigt. „Kurzfristig“ kann dabei wirklich kurz sein: wenige Millisekunden reichen, um eine Hardware-Queue zu füllen. In dieser Zeit entstehen entweder Drops (Tail Drops oder AQM-Drops) oder eine deutliche Erhöhung des Queueing-Delay. Die Tücke besteht darin, dass viele Monitoring-Systeme in Minuten- oder Sekundenintervallen mitteln. Ein Link kann über 5 Minuten bei 30–40% Durchschnittsauslastung liegen und dennoch regelmäßig Microbursts produzieren, die Echtzeitqualität zerstören. Für QoS bedeutet das: Wer nur Bandbreite betrachtet, diagnostiziert falsch; wer Queue-Delay und Drops in kurzen Zeitfenstern betrachtet, sieht die Wahrheit.

• Kurze Zeitfenster: Microbursts spielen sich oft in Millisekunden ab.
• Hohe Impact-Dichte: wenige Drops oder wenige Millisekunden zusätzlicher Delay können Voice/Video merklich verschlechtern.
• Unsichtbar im Durchschnitt: Mittelwerte verstecken Peaks.
• Multi-Hop-Effekt: kleine Delay-Spitzen können sich über mehrere Hops addieren.

Typische Ursachen von Microbursts in Provider-, Campus- und DC-Netzen

Microbursts sind kein „Fehler“, sondern häufig eine natürliche Folge moderner Traffic-Muster. In Data-Center-Fabrics ist Fan-in der Klassiker: Viele Serverports speisen über einen Leaf in einen Uplink, der kurzfristig überrannt wird. Im WAN entstehen Microbursts durch Aggregation von vielen Flows, durch Encapsulation (IPsec/GRE/VXLAN) oder durch Traffic Engineering, das Flows auf weniger Pfade bündelt. In Access- und Metro-Domänen verstärken Shared-Media-Scheduler Bursts, wenn Timeslots in Wellen vergeben werden. Zusätzlich gibt es „softwaregetriebene“ Bursts: TCP kann nach einer ruhigen Phase schnell wieder senden, Hypervisor-Queues können Pakete bündeln, und moderne NICs sowie Offloads erzeugen paketweise „Bündelung“.

• Fan-in: viele Ingress-Links auf einen Egress-Link (Leaf→Spine, Metro-Aggregation, Interconnect).
• TCP-Dynamik: Windowing, Slow Start und ACK-Clocking erzeugen Peaks.
• Host/NIC-Bündelung: Interrupt-Coalescing, Offloads und VM-Scheduling führen zu Sende-Salven.
• Encapsulation: Tunnel erhöhen Overhead und können Burstiness verschärfen.
• Failover: Pfadwechsel konzentrieren Traffic, Hotspots entstehen abrupt.

Warum „einfach mehr Buffer“ keine zuverlässige Lösung ist

Buffering ist verführerisch: Größere Puffer verhindern Drops. Das stimmt – kurzfristig. Aber in gemischten Traffic-Szenarien erzeugen große Buffers häufig Bufferbloat: hohe, schwankende Latenz, die interaktive Anwendungen und Echtzeitdienste beschädigt, obwohl Drops gering sind. Für Microbursts ist Buffering daher nur ein Teil der Lösung. Sie brauchen genug Buffer, um sehr kurze Peaks abzufangen, aber nicht so viel, dass sich Warteschlangen minutenlang aufbauen. Die Kunst ist die bewusste Pufferstrategie: kurze, kontrollierte Queues für Echtzeitklassen, moderate Queues für Video/Business und AQM/ECN für Best Effort, damit Warteschlangen nicht unbounded wachsen.

• Zu wenig Buffer: Microbursts führen zu Drop-Bursts, besonders sichtbar bei Voice/Video.
• Zu viel Buffer: Latenzspitzen ohne Drops, „zähe“ Applikationen, QoE bricht ein.
• Richtiger Buffer: kurze Peaks abfangen, aber Queue-Länge aktiv stabilisieren.

Die Toolbox im Überblick: Buffering, Shaping, AQM

Microbursts lassen sich am zuverlässigsten mit einem kombinierten Ansatz behandeln. Buffering sorgt dafür, dass sehr kurze Peaks nicht sofort droppen. Shaping glättet Bursts und verlagert Congestion in einen kontrollierbaren Punkt. AQM (Active Queue Management) hält Queues kurz, indem es frühzeitig markiert (ECN) oder droppt, bevor Tail Drops in großen Wellen auftreten. Im Provider-Kontext kommt noch ein vierter Begleiter hinzu: saubere Klassifizierung und Budgetierung (HQoS), damit Echtzeit nicht durch Missmarking oder Noisy Neighbors überflutet wird.

• Buffering: kontrollierte Puffer, passende Queue-Limits pro Klasse.
• Shaping: Abfluss begrenzen, Bursts glätten, Queue-Lage kontrollieren.
• AQM: Queue-Länge aktiv steuern (RED/WRED, CoDel, PIE), idealerweise mit ECN.
• HQoS/Budgets: Fairness pro Service/Subscriber, Schutz vor Noisy Neighbors.

Buffering richtig einsetzen: Queue-Limits pro Klasse statt „one size fits all“

Wenn Microbursts auftreten, ist es entscheidend, welche Klasse betroffen ist. Echtzeit (Voice) braucht minimale Verzögerung und toleriert nur sehr wenig Jitter; deshalb sollten Voice-Queues kurz sein. Video und interaktive Anwendungen vertragen etwas mehr Buffer, aber nicht unendlich. Best Effort profitiert oft am meisten von AQM, weil TCP auf Congestion reagieren kann. Eine saubere Bufferstrategie setzt daher nicht „maximale Buffer überall“, sondern differenzierte Queue-Limits und Drop-Mechanismen pro Klasse. Das reduziert Latenzspitzen und macht das Verhalten in Busy Hour reproduzierbar.

• Echtzeitqueues: kurz halten, damit Jitter niedrig bleibt.
• Video/Business: moderat puffern, um kurze Peaks zu absorbieren, aber Delay begrenzen.
• Best Effort: AQM/ECN nutzen, statt große Tail-Drop-Puffer aufzubauen.
• Bulk/Scavenger: nachrangig, ggf. größere Buffer, aber bewusst „nicht zeitkritisch“.

Shaping als Microburst-Filter: Congestion kontrollierbar machen

Shaping ist eines der effektivsten Mittel gegen Microbursts, weil es Bursts zeitlich verteilt. Besonders am Rand (WAN-Edge, Interconnect-Port, Metro-Uplink, Tunnel-Interface) verhindert Shaping, dass kurze Sende-Salven in einen engeren Link „hineinschießen“. Praktisch bedeutet das: Sie setzen die Shaper-Rate knapp unter die effektive, nutzbare Linkrate, damit die Warteschlange im eigenen Gerät entsteht. Dann können Ihre Service Queues (LLQ/CBWFQ) wirken, und Microbursts werden zu kontrollierten, kleinen Queueing-Ereignissen statt zu Drop-Bursts beim Provider oder im Modem.

• Egress Shaping: reduziert Fan-in-Peaks und macht das Verhalten reproduzierbar.
• Shaping-Rate: muss Overhead (L2/Tunnel/MPLS) und Headroom berücksichtigen.
• HQoS: Parent-Shaper pro Service/Subscriber, darunter Klassenqueues gegen Noisy Neighbors.
• Risiko: zu hoch geshaped → Queue wandert wieder „nach außen“; zu niedrig → unnötige eigene Congestion.

AQM als Gegenmittel: Latenz senken, ohne Throughput zu zerstören

AQM (Active Queue Management) steuert die Queue-Länge aktiv. Statt erst zu droppen, wenn der Buffer voll ist (Tail Drop), beginnt AQM früher zu markieren oder zu droppen, um die Queue kurz zu halten. Das senkt Latenz und reduziert die typischen „Drop-Wellen“, die TCP und Echtzeit gleichermaßen schaden. In Best Effort Klassen ist AQM besonders wirkungsvoll, weil TCP auf Congestion reagieren kann. Mit ECN (Explicit Congestion Notification) kann AQM sogar markieren statt droppen, wodurch Throughput erhalten bleibt, während die Queue-Länge trotzdem sinkt. Für Microbursts bedeutet das: AQM fängt die „Queue-Aufblähung“ ab, die Bursts sonst in Bufferbloat übersetzen würden.

• RED/WRED: probabilistisches frühes Droppen/Markieren, oft mit Drop-Prioritäten nutzbar.
• CoDel: delay-basiert, zielt auf stabile niedrige Queueing-Delay.
• PIE: steuert Queue-Latenz über einen Regelkreis, häufig in Access/WAN-Umgebungen.
• ECN: Markieren statt Droppen, wenn Endpunkte und Pfad es unterstützen.

Shaping und AQM zusammen: Warum die Kombination oft am besten wirkt

Shaping glättet Bursts und kontrolliert die Lage der Warteschlange. AQM hält die Warteschlange kurz und verhindert Bufferbloat. Zusammen liefern sie ein robustes Microburst-Handling: Der Shaper sorgt dafür, dass Microbursts nicht an unkontrollierten Stellen droppen, und AQM sorgt dafür, dass die lokale Queue nicht „aufbläht“. Für Provider-Designs ist das besonders relevant an Interconnects und Metro-Uplinks, wo viele Ingress-Ströme auf wenige Egress-Ports laufen. Ohne Shaping droppen Microbursts „irgendwo“, ohne AQM werden Queues lang und Latenzspitzen ruinieren QoE.

• Shaping: Bursts in kontrollierbare Queue-Ereignisse verwandeln.
• AQM: Queue-Länge stabil halten, Delay-Perzentile senken.
• Ergebnis: weniger Drop-Bursts, niedrigere p95/p99 Latenz, stabilere Echtzeitqualität.

Microbursts und QoS-Klassen: Echtzeit schützen, ohne Starvation zu erzeugen

Microbursts treffen nicht nur Best Effort. Wenn die Echtzeitklasse falsch dimensioniert ist oder wenn Missmarking Traffic in die Priority Queue zieht, können Microbursts in der Priority Queue zu Starvation anderer Klassen führen. Deshalb ist Microburst-Handling immer auch Klassen- und Budget-Handling: Priority Queues (LLQ) strikt begrenzen, Video in gewichtete Klassen statt in die LLQ, und Trust Boundaries durchsetzen, damit nur legitimer Echtzeittraffic in Echtzeitqueues gelangt. AQM gehört in der Regel nicht in eine strikte Voice-LLQ, sondern in Best Effort und ggf. in datenlastige Klassen; Echtzeitqueues profitieren eher von kurzen Queue-Limits und sauberen Budgets.

• LLQ limitieren: verhindert Starvation und macht das System stabil bei Peaks.
• Video getrennt: Video ist burstig und bandbreitenintensiv; besser in gewichtetem Service.
• Trust Boundary: Missmarking ist ein häufiger Microburst-Verstärker in Premiumklassen.
• Queue-Design pro Linkrolle: Access, Metro, Core und Interconnect brauchen unterschiedliche Profile.

Praktische Designmuster: Wo Sie welche Toolbox einsetzen

Microbursts sind domänenspezifisch. Im Data Center dominieren Fan-in, NIC-Bündelung und East-West Flows; im WAN dominieren Engpässe und Upstream-Bufferbloat; im Metro dominieren Ring-Umlenkungen und Aggregation. Deshalb lohnt es sich, Muster pro Domäne zu nutzen: Im DC häufig AQM und saubere Underlay-Queues, im WAN konsequentes Shaping und HQoS, an Interconnects Shaping plus AQM plus Telemetrie. Entscheidend ist, die Engpässe als Congestion Domains zu definieren und die Queueing-Mechanik genau dort zu instrumentieren.

• Data Center Fabric: kurze Telemetrieintervalle, AQM/ECN in Best Effort, saubere Queue-Profile auf Uplinks.
• WAN/Access: Egress Shaping am Upstream, HQoS pro Site/Subscriber, AQM gegen Bufferbloat.
• Metro/Interconnect: Shaping an Ports, die Fan-in bündeln, AQM zur Latenzstabilisierung, klare Klassenbudgets.
• Tunnel/Overlay: Overhead und MTU berücksichtigen, Outer Marking korrekt setzen, dann Shaping/AQM am Underlay-Engpass.

MTU und Overhead: Warum Microbursts manchmal wie „Packet Loss“ aussehen

Encapsulation und MTU-Probleme können Microburst-Symptome imitieren: Drops treten scheinbar „random“ auf, oft in kurzen Clustern. In Wahrheit sind es Fragmentierung, PMTUD-Probleme oder Overhead-bedingte Engpässe, die Bursts schneller an Grenzen bringen. Deshalb gehört zur Microburst-Toolbox auch Disziplin bei MTU/MSS und Overhead-Budgets: Wenn Overhead nicht eingerechnet ist, wird Shaping zu hoch gesetzt und Policers greifen zu früh. Gerade bei kleinen Echtzeitpaketen ist der relative Overhead groß, wodurch Microbursts schneller „hart“ werden.

• MTU-Standards: Underlay muss Encapsulation-Overhead tragen, sonst entstehen Drops/Fragmentierung.
• MSS-Clamping: verhindert TCP-Fragmentierung in Tunnelpfaden.
• Budget-Anpassung: Shaper- und Policer-Raten inklusive Overhead dimensionieren.

Messbarkeit: Microbursts sichtbar machen, bevor Nutzer es spüren

Microbursts sind nur dann beherrschbar, wenn Sie sie sehen. Dafür brauchen Sie Telemetrie, die näher an der Realität ist als 5-Minuten-Mittelwerte. Besonders wertvoll sind Queue-Delay (p95/p99), Queue-Drops pro Klasse, ECN-Mark-Raten (bei AQM/ECN), sowie kurzgranulare Utilization-Perzentile auf Engpassports. In vielen Umgebungen ist auch eine „Burst-Detektion“ über Interface-Buffer-Statistiken oder High-Frequency Sampling sinnvoll. Der wichtigste operative Schritt ist die Korrelation: Treten Drops/Delay-Spikes zeitgleich mit bestimmten Events auf (Backup-Start, Failover, Deployment, Link-Flap), dann haben Sie einen konkreten Ansatzpunkt, um Shaping, AQM oder Queue-Limits gezielt zu verbessern.

• Queue-Delay p95/p99: zeigt Bufferbloat und Microburst-Queueing deutlich früher als Drops.
• Class Drops: Drop-Bursts in Echtzeit-/Video-Klassen sind kritische Qualitätsindikatoren.
• ECN/AQM Marks: Mark-Raten zeigen Congestion, ohne dass Throughput sofort kollabiert.
• Short-interval KPIs: 1–5 Minuten oder feiner, um Peaks nicht zu verschleifen.

Typische Failure Patterns und was die Toolbox jeweils löst

Microburst-Probleme zeigen oft ähnliche Muster. Wenn Sie diese Muster erkennen, können Sie die richtige Maßnahme aus der Toolbox wählen, statt „mehr Buffer“ oder „mehr Bandbreite“ reflexartig einzusetzen. Ein häufiges Muster ist: Drops in kurzen Clustern bei niedriger Durchschnittslast (Microburst-Drops). Ein anderes Muster ist: starke Latenzspitzen ohne viele Drops (Bufferbloat). Ein drittes ist: Echtzeit leidet bei Upload, während Download „okay“ wirkt (Upstream-Queue außerhalb der Kontrolle).

• Drop-Bursts bei niedriger Durchschnittslast: Shaping am Fan-in/Egress + passende Buffer + ggf. AQM zur Stabilisierung.
• Hohe Latenz ohne Drops: AQM/ECN und Queue-Limits gegen Bufferbloat, Shaping korrekt platzieren.
• Echtzeitprobleme bei Upload: Egress Shaping am Upstream, kurze Voice-Queue, Bulk nachrangig.
• Probleme nur nach Failover: Headroom fehlt; Shaper-Profile und Congestion Domains für Backup-Pfade anpassen.

Blueprint: Microbursts systematisch behandeln

Ein robustes Vorgehen beginnt mit der Lokalisierung der Congestion Domain: Wo entsteht der Stau wirklich (Access, Metro, Core-to-Edge, Interconnect, Fabric-Uplink)? Dann wählen Sie die Toolbox gezielt. Erstens definieren Sie eine Bufferstrategie pro Klasse: Echtzeitqueues kurz, Datenklassen moderat, Best Effort mit AQM/ECN. Zweitens setzen Sie Shaping an den echten Engpässen ein, um Congestion in den eigenen Einflussbereich zu holen und Bursts zu glätten; bei Multi-Service-Links nutzen Sie HQoS, um pro Service/Subscriber zu budgetieren. Drittens aktivieren oder optimieren Sie AQM, um Queue-Längen stabil zu halten und Bufferbloat zu reduzieren, idealerweise mit ECN, wenn Endpunkte es unterstützen. Parallel stellen Sie MTU/MSS und Overhead-Budgets sicher, damit Drops nicht durch Fragmentierung oder zu knappe Profile entstehen. Abschließend bauen Sie Telemetrie auf, die Queue-Delay/Drops und AQM-Marks in kurzen Zeitfenstern sichtbar macht und mit Events korreliert. So wird Microburst-Handling nicht zu einer Serie von Zufallsänderungen, sondern zu einem reproduzierbaren Engineering-Prozess, der Buffering, Shaping und AQM als abgestimmte Toolbox nutzt.