Burst Handling ist einer der häufigsten Gründe, warum Voice manchmal trotz QoS „knackt“, aussetzt oder kurz robotisch klingt – obwohl DSCP EF korrekt gesetzt ist, eine LLQ existiert und die Bandbreite auf dem Papier ausreichen müsste. In der Praxis sind Sprachströme zwar klein und relativ konstant, aber sie treten selten in einer „perfekten Gleichmäßigkeit“ auf. VoIP-Pakete entstehen in festen Intervallen, treffen im Netz jedoch auf Microbursts aus Aggregation, auf Shaper- und Policer-Profile, auf unterschiedliche Paketgrößen anderer Klassen und auf Buffer-Designs, die Bursts mal glätten und mal in Drop-Cluster umwandeln. Genau diese kurzen, sehr intensiven Lastspitzen können ausreichen, um in der Echtzeitkette Jitter-Spitzen oder Paketverlust zu erzeugen – und Voice ist dafür so empfindlich, dass schon wenige fehlende RTP-Pakete als Knacken hörbar werden. Dieser Artikel erklärt, warum Burst Handling in Telco- und Enterprise-Netzen so entscheidend ist, wie Bursts entstehen, an welchen Punkten QoS oft „dabei ist, aber trotzdem verliert“, und welche Designregeln helfen, Voice auch unter Burst-Last stabil zu halten.
Was „Knacken“ bei VoIP technisch bedeutet
Wenn Anwender von Knacken, Klicks oder kurzen Aussetzern sprechen, steckt fast immer eine der folgenden Ursachen dahinter:
- Kurzer Paketverlust: ein oder mehrere RTP-Pakete fehlen; der Decoder kaschiert kurz, dann wird es hörbar.
- Jitter-Spike: Pakete kommen ungleichmäßig an; der Jitter-Buffer läuft leer oder muss abrupt nachregeln.
- Out-of-Order/Reordering: Pakete kommen in falscher Reihenfolge; der Buffer verwirft oder verspätet.
- Transcoding/CPU-Pressure: Medienpfade werden auf SBC/Media-Relays kurzfristig überlastet; das wirkt wie Jitter.
Wichtig ist: Voice kann „im Durchschnitt“ gut aussehen (z. B. 0,1 % Loss), aber kurze Verlust-Cluster von wenigen 100 Millisekunden wirken sehr viel schlimmer als gleichmäßig verteilte Einzelverluste. Bursts erzeugen genau diese Cluster.
Warum Bursts entstehen, obwohl Voice „konstant“ ist
Sprachcodecs erzeugen zwar in festen Abständen Pakete (z. B. alle 20 ms), aber im Netz werden diese Pakete nicht immer einzeln und gleichmäßig weitergeleitet. Bursts entstehen typischerweise durch Aggregation, durch Scheduling und durch Verkehrsmischung.
- Aggregationseffekt: Viele gleichmäßige Voice-Flows addieren sich zu kurzen Peaks, wenn sie zufällig gleichzeitig auf einen Engpass treffen.
- Serialization und Paketgrößen: Große Datenpakete blockieren auf langsamen Links die Leitung; kleine RTP-Pakete warten dahinter.
- Timer-Synchronität: Anwendungen und Stacks senden oft in Taktungen; das kann im Core als Microburst ankommen.
- Shaper-Pacing: Shaping glättet, aber erzeugt auch „Paketgruppen“, wenn mehrere Flows in denselben Sendezeitfenstern landen.
- Virtualisierung: In Telco Clouds/Kubernetes kann CPU-Scheduling Pakete stapeln und dann in Schüben ausgeben.
Das Ergebnis: Auch wenn jeder einzelne Voice-Flow „ruhig“ ist, sieht ein Engpass-Link oft kurze, dichte Paketwolken – und genau dort entscheidet Burst Handling über hörbare Qualität.
Microbursts: Der unsichtbare Gegner in Metro, Backhaul und Fabrics
Microbursts sind extrem kurze Lastspitzen, die in Durchschnittsmetriken kaum sichtbar sind. Sie entstehen besonders dort, wo viele Quellen auf wenige Uplinks treffen: Metro-Aggregation, Mobile Backhaul Aggregation, EVPN/VXLAN-Spines, Border Leafs, Interconnects. Für Voice sind Microbursts gefährlich, weil sie zwei Dinge auslösen:
- Queue-Überlauf: wenn die Echtzeitqueue oder die gemeinsame Pufferstruktur zu klein ist, droppen RTP-Pakete.
- Queueing Delay-Spike: wenn die Queue groß ist, steigt Delay/Jitter – der Jitter-Buffer kommt aus dem Tritt.
Viele QoS-Implementierungen sind gegen „dauerhafte Überlast“ robust, aber nicht automatisch gegen kurze Burst-Spitzen. Deshalb sehen Sie oft: Voice ist 95 % der Zeit perfekt – und knackt dann für wenige Sekunden.
Der Klassiker: EF ist gesetzt, aber der Burst wird am falschen Punkt gedroppt
Ein häufiges Missverständnis ist, dass eine EF-Markierung allein die gesamte Kette schützt. In Wirklichkeit muss EF an jedem Engpass auf eine echte Low-Latency-Queue gemappt sein. Bursts zeigen gnadenlos, wenn irgendwo ein QoS-Loch ist:
- DSCP wird überschrieben: an Übergängen (UNI/NNI, CPE, Provider Edge) wird EF neutralisiert oder falsch gemappt.
- EF landet nicht in der richtigen Queue: Geräte haben das Mapping nicht aktiv oder nutzen andere Traffic-Class-Felder (z. B. MPLS-TC).
- Overlay-Problem: in EVPN/VXLAN ist nur der innere Header markiert, Underlay queuet nach äußerem Header.
- Peering/Interconnect: EF wirkt im eigenen Netz, aber an der Übergabe wird alles Best Effort – Bursts werden dort sichtbar.
Wenn Voice trotz „korrekter“ Konfiguration knackt, ist die erste Frage: Gibt es irgendwo im Pfad einen Hop, der EF nicht konsequent behandelt?
LLQ ohne Burst-Disziplin: Warum Priorität allein nicht reicht
LLQ (Priority Queueing mit Limit) ist die Standardlösung für Voice. Dennoch kann es knacken, wenn Bursts nicht sauber abgefedert werden. Typische Ursachen:
- LLQ-Limit zu eng: Bei Peaks (z. B. viele gleichzeitige Calls) läuft die Voice-Klasse gegen das Limit und verliert Pakete oder wartet.
- Zu kleine Voice-Queue: Kleine LLQ-Puffer droppen bei Microbursts schneller, wenn kein Shaping/Glättung davor liegt.
- Zu große gemeinsame Puffer: Wenn Voice nicht sauber isoliert ist, kann Best Effort Puffer füllen und Voice trotz Priority verzögern.
- Schlechte Reihenfolge der Mechanismen: Policer vor LLQ oder falsches Hierarchie-QoS kann Burst-Drops erzeugen.
LLQ schützt vor großen Best-Effort-Warteschlangen, aber es macht Bursts nicht automatisch „sanft“. Dafür braucht es Shaping, passende Queue-Limits und korrekte Hierarchien.
Policing als Burst-Killer: Wie ein zu harter Policer Knacken erzeugt
Policing ist im Providerbetrieb wichtig, aber für Voice gefährlich, wenn es Drops erzeugt. Bursts treffen Policer besonders hart, weil Policers häufig auf kurzfristige Rate-Überschreitungen reagieren. Selbst wenn die durchschnittliche Voice-Rate im Profil liegt, kann ein kurzer Peak „rot“ werden – und dann dropt der Policer genau die Pakete, die für Sprachqualität kritisch sind.
- Zu kleine Burst-Toleranz: der Policer akzeptiert keine kurzfristigen Peaks; RTP-Pakete werden in Clustern verworfen.
- Policing an der falschen Stelle: Egress-Policing oder Policing hinter Aggregation erzeugt Drop-Spitzen.
- Fehlende Trennung pro Klasse: Policer wirkt auf gemischte Flows; Voice wird „mitbestraft“.
Designregel: Voice sollte so profiliert sein, dass Policing praktisch nie dropt. Wenn Profilierung nötig ist, ist Remarking in seltenen Fällen besser als Drop – und Shaping am Egress ist oft der stabilere Weg.
Shaping: Bursts glätten, ohne Voice zu puffern
Shaping ist das wichtigste Burst-Handling-Werkzeug, weil es Microbursts in einen gleichmäßigeren Fluss verwandelt. Richtig eingesetzt reduziert Shaping Drop-Cluster und stabilisiert Queue-Füllstände. Der kritische Punkt: Shaping darf Voice nicht „in den großen Puffer ziehen“.
- Shaping am Egress von Engpässen: glättet den Gesamtausgang, reduziert Downstream-Drops.
- Voice in LLQ isolieren: Voice wird bevorzugt gesendet, während Best Effort „gepaced“ wird.
- Queue-Limits kontrollieren: Shaper-Buffer nicht unendlich groß, sonst Bufferbloat und zusätzlicher Jitter.
In Metro- und Mobile-Backhaul-Szenarien ist diese Kombination besonders wirksam: LLQ für Voice plus Shaping für Stabilität.
Buffer-Design: Wenn falsche Queue-Größen Bursts verstärken
Queue-Größen sind ein Teil von Burst Handling. Zu kleine Buffers droppen bei Microbursts, zu große Buffers erzeugen Jitterwellen. Besonders häufig ist das Problem, wenn Best Effort riesige Puffer füllt und Voice nicht sauber separiert ist.
- Zu große Best-Effort-Queues: Bufferbloat; interaktive Qualität sinkt, Voice kann trotz Priority spürbar verzögert werden.
- Zu kleine Echtzeit-Queues: Drop-Cluster bei kurzen Peaks.
- Fehlende Per-Class-Buffer: ein gemeinsamer Puffer führt dazu, dass große Datenströme die Echtzeit indirekt beeinflussen.
Ein stabiles Design nutzt kleine, schnelle Echtzeitqueues und kontrollierte Best-Effort-Puffer, ergänzt durch Shaping gegen Microbursts.
Access-Upstream als Sonderfall: Warum es beim Upload knackt
Viele Knack-Probleme treten auf, wenn Nutzer gleichzeitig uploaden: Cloud-Backup, Fotos, Videodaten, große Anhänge. Im Access ist der Upstream häufig der Engpass, und CPEs haben oft große Puffer. Das erzeugt Bufferbloat und Burst-Spitzen.
- Symptom: Voice knackt genau dann, wenn Upload läuft; Ping steigt stark.
- Ursache: Upstream-Queue füllt sich; Voice-Pakete warten oder werden bei Burst gedroppt.
- Gegenmittel: Upstream-Shaping nahe am realen Linklimit, Voice in LLQ, Best Effort-Puffer kontrollieren.
Hier ist Burst Handling oft wichtiger als „mehr Priorität“. Ohne Shaping bleibt das Verhalten unruhig, selbst wenn EF korrekt markiert ist.
Telco Clouds und virtuelle Datenpfade: Bursts durch CPU-Scheduling
In cloud-nativen Telco-Umgebungen (CNFs, Kubernetes) kann Burst Handling auch ein Compute-Thema sein. Wenn CPU-Kerne überlastet sind, werden Pakete nicht gleichmäßig verarbeitet, sondern in Schüben. Das wirkt wie Jitter – ohne dass ein physischer Link überlastet sein muss.
- CPU-Throttling: Echtzeitpods werden kurzfristig ausgebremst; Pakete stauen sich im Host.
- vSwitch/eBPF Overhead: zusätzliche Verarbeitung erzeugt Latenzvariabilität.
- SR-IOV/DPDK: kann Jitter reduzieren, erfordert aber saubere Ressourcenplanung.
Wenn Voice „nur in der Cloud“ knackt, prüfen Sie nicht nur DSCP, sondern auch CPU-Pressure, Runqueue und Drops im Host-Datapath.
Praktische Diagnose: So finden Sie Burst-Probleme schnell
- Queue-Drops in der Voice-Klasse: Drops sind ein direkter Hinweis auf Burst-Überlauf oder falsche Limits.
- Queue-Depth/Queueing Delay: Jitter-Spikes korrelieren häufig mit Queue-Wellen.
- Policer-Hits: besonders in Voice/EF-Klasse sind Policer-Hits ein Warnsignal.
- LLQ-Auslastung: dauerhaft hohe Auslastung deutet auf Premium-Inflation oder falsches Limit hin.
- Pfadprüfung: DSCP/TC Mapping auf jedem Hop; ein QoS-Loch reicht für hörbare Störungen.
- Aktive Messung: Jitter/Loss in kurzen Intervallen messen; Durchschnittswerte verschleiern Bursts.
Wenn Sie nur Linkauslastung betrachten, übersehen Sie Microbursts. Für Burst Handling sind Queue-Statistiken der wichtigste Datensatz.
Best Practices: Burst Handling so designen, dass Voice stabil bleibt
- EF/Voice konsequent mappen: DSCP EF muss auf jedem Hop in eine echte Low-Latency-Queue gehen, auch im MPLS/SR-Core (TC-Mapping).
- LLQ immer limitieren, aber realistisch dimensionieren: Limits zu eng erzeugen Drops; zu weit öffnen gefährdet andere Klassen.
- Shaping an Engpässen: besonders an rate-limitierten Links und Aggregationsuplinks, um Microbursts zu glätten.
- Policing für Voice vermeiden: wenn Profilierung nötig ist, Burst-Toleranz und Remarking statt Drop prüfen.
- Buffer-Design pro Klasse: kleine Echtzeitqueue, kontrollierte Best-Effort-Puffer, keine globalen Riesenschlangen.
- Trust Boundary: verhindern, dass zu viel Traffic in EF landet (Premium-Inflation).
- Monitoring operationalisieren: Drops/Queue-Depth/Policer-Hits als Standard-Dashboards; Drops in Voice als Incident behandeln.
Häufige Fragen zu „Voice knackt trotz QoS“
Warum knackt Voice nur manchmal und nicht dauerhaft?
Weil die Ursache häufig Microbursts oder kurzfristige Congestion ist. Durchschnittswerte sehen gut aus, aber kurze Queue-Überläufe oder Policer-Drops erzeugen genau die wenigen verlorenen Pakete, die als Knacken hörbar sind.
Kann Shaping Voice verschlechtern?
Ja, wenn Voice in große Shaping-Puffer gerät. Richtig eingesetzt glättet Shaping jedoch Best Effort und Bursts, während Voice über LLQ schnell bevorzugt wird. Die Kombination aus LLQ (für Voice) und Shaping (für Stabilität) ist in vielen Telco-Designs der Sweet Spot.
Was ist der wichtigste Indikator für Burst-Probleme?
Queue-Drops und Queue-Depth in kurzen Zeitfenstern. Wenn Drops in der Voice-Klasse oder Policer-Hits auf EF auftreten, ist Burst Handling oder Profilierung fehlerhaft. Wenn Queueing Delay stark schwankt, ist Bufferbloat oder Microburst-Dynamik wahrscheinlich – auch ohne sichtbaren Paketverlust im Durchschnitt.
