Token Bucket Parameter: CIR, PIR, Burst – korrekt dimensionieren

Token Bucket Parameter korrekt dimensionieren ist eine der wichtigsten – und am häufigsten unterschätzten – Aufgaben im QoS-Engineering. Denn CIR, PIR und Burst wirken direkt darauf, ob Traffic sauber geformt (Shaping) oder hart begrenzt (Policing) wird, ob Echtzeitverkehr wie Voice/Video stabil bleibt oder ob es zu scheinbar „zufälligen“ Drops kommt, und ob Throughput bei TCP-lastigen Anwendungen einbricht, obwohl die nominelle Bandbreite eigentlich ausreichen müsste. Gerade in Provider- und Telco-Netzen werden Token-Bucket-Parameter oft als „Default-Werte“ betrachtet, die man einfach übernimmt. Das führt in der Praxis zu zwei typischen Extremen: Entweder sind Burst-Werte zu klein, sodass Mikrobursts und Protokoll-Overhead zu Drop-Bursts führen (Voice hört man sofort), oder Burst-Werte sind zu groß, sodass Bufferbloat entsteht und Latenz/Jitter durch die Decke gehen (Interaktivität leidet, obwohl es kaum Drops gibt). Wer Token Bucket Parameter wie CIR (Committed Information Rate), PIR (Peak Information Rate) und Burst sauber dimensioniert, denkt deshalb nicht nur in Mbit/s, sondern in Zeitfenstern, Paketgrößen, Overhead und Congestion Domains. Ziel ist ein reproduzierbares Verhalten: kurze, kontrollierte Bursts zulassen, echte Profile schützen, Premiumklassen vor Missbrauch bewahren und gleichzeitig die Nutzerqualität (QoE) in Busy Hour und Failover-Szenarien stabil halten.

Token Bucket in der Praxis: Was CIR, PIR und Burst wirklich steuern

Das Token-Bucket-Prinzip ist einfach: Tokens „füllen“ einen Eimer (Bucket) mit einer Rate. Jedes Byte (oder Paket) verbraucht Tokens. Sind ausreichend Tokens vorhanden, darf der Traffic passieren; fehlen Tokens, wird je nach Mechanismus verzögert (Shaping) oder verworfen/umklassifiziert (Policing). CIR ist dabei die Rate, mit der Tokens garantiert nachgefüllt werden. PIR ist ein optionaler Peak, bis zu dem kurzfristig mehr erlaubt ist. Burst beschreibt, wie viel kurzfristige Überschreitung (in Bytes) möglich ist, bevor die „harte“ Behandlung greift. Im Provider-Kontext ist das entscheidend, weil realer Traffic fast nie perfekt gleichmäßig ist: Mikrobursts, TCP-Windowing, Encapsulation und Aggregation erzeugen Peaks, die ohne Burst-Toleranz sofort zu Drops führen würden.

• CIR: langfristig zugesicherte Rate; Basis für SLA-Profile und Fairness.
• PIR: kurzzeitig erlaubter Peak; kann Peaks abfedern, wenn genug Headroom vorhanden ist.
• Burst: Token-Puffer; entscheidet, ob kurze Peaks passieren oder sofort gedroppt/degradiert werden.

Shaping vs. Policing: Gleiche Parameter, völlig anderes Verhalten

Token Buckets stecken sowohl in Shapern als auch in Policern, aber die Wirkung ist grundverschieden. Beim Shaping werden Pakete, denen Tokens fehlen, in eine Warteschlange gelegt und später gesendet. Beim Policing werden sie typischerweise gedroppt oder in eine niedrigere Klasse ummarkiert. Für Echtzeit ist das entscheidend: Shaping kann Delay erhöhen, Policing erzeugt Loss. Deshalb ist Burst-Dimensionierung beim Policing besonders heikel, weil zu kleine Bursts sofort als hörbare Aussetzer sichtbar werden. Beim Shaping ist ein zu großer Burst dagegen häufig der Weg in Bufferbloat, weil zu viele Daten in kurzer Zeit auf einen Engpass treffen und die Queue aufbläht.

• Shaper: Tokens fehlen → Verzögerung (Queue); Ziel: Congestion kontrollierbar machen.
• Policer: Tokens fehlen → Drop/Degrade; Ziel: Profile erzwingen und Missbrauch verhindern.
• Konsequenz: Policer-Burst eher „schützend“ dimensionieren, Shaper-Burst eher „latenzbewusst“.

Warum Burst keine „Nice-to-have“-Zahl ist: Mikrobursts sind normal

In modernen Netzen entstehen Mikrobursts durch Fan-in (viele Eingänge auf einen Ausgang), durch Paketbündelung in NICs/Hypervisors, durch Scheduler in Shared Media (PON/DOCSIS), durch Tunnel-Encapsulation (IPsec/GRE/VXLAN) und durch TCP selbst. Ein Token Bucket ohne ausreichenden Burst „sieht“ diese Peaks als Profilverletzung – und ein Policer reagiert mit Drops. Das wirkt dann wie „mysteriöser Paketverlust“, obwohl die durchschnittliche Rate völlig im Rahmen liegt. Umgekehrt führt ein übergroßer Burst dazu, dass zu viele Bytes „auf einmal“ freigegeben werden, was Downstream-Queues füllt und Latenzspitzen erzeugt.

• Zu kleiner Burst: Drop-Bursts, Voice-Artefakte, TCP-Retransmits, schlechte QoE trotz „genug Bandbreite“.
• Zu großer Burst: Bufferbloat, hohe p95/p99 Latenz, Jitter-Spitzen, träge Apps ohne sichtbare Drops.

Ein einfaches Dimensionierungsmodell: Burst als Zeitfenster denken

Eine praxistaugliche Methode ist, Burst als „erlaubtes Zeitfenster“ zu interpretieren. Wenn CIR in bit/s gegeben ist und Sie ein Burst-Zeitfenster $t$ zulassen wollen, dann ist der Burst in Bits näherungsweise $B=\mathrm{CIR}\cdot t$. In Bytes entspricht das $B/8$. Diese Sicht ist hilfreich, weil QoS-Engineering oft in „Millisekunden“ gedacht wird: Jitter-Budgets, Scheduling-Ticks, Mikroburst-Dauern. Ein Burst von beispielsweise 10 ms bei 100 Mbit/s entspricht grob $100\mathrm{Mbit/s}\cdot 0.01s=1\mathrm{Mbit}$, also etwa 125 kB. Das ist eine Größenordnung, mit der man testen und iterieren kann.

Was dieses Modell gut kann – und wo es ergänzt werden muss

• Gut: liefert eine intuitive Startgröße, die sich an QoS-Zeitbudgets orientiert.
• Ergänzung: Overhead, Paketgrößen, Plattform-Ticks und Downstream-Engpässe müssen berücksichtigt werden.

CIR korrekt wählen: Produktprofil, Busy Hour und Failover zuerst

CIR ist nicht „die maximale Rate“, sondern der zugesicherte Anteil, den ein Service dauerhaft nutzen darf. In Telco- und Provider-Netzen ist CIR direkt mit Produktprofilen, Oversubscription-Modellen und SLA-Definitionen verknüpft. Für Dimensionierung bedeutet das: CIR sollte dem vertraglichen oder internen Ziel entsprechen, aber auch realistisch in Engpass-Szenarien funktionieren – insbesondere in Failover, wenn weniger Kapazität verfügbar ist. Ein typischer Fehler ist, CIR nach Normalbetrieb zu setzen und Failover zu ignorieren. Dann wird bei Umschaltung plötzlich massiv gepolicet oder geshaped, und Echtzeitqualität bricht in Busy Hour ein.

• Normalbetrieb: CIR = zugesicherte Rate gemäß Profil.
• Failover: CIR ggf. so wählen, dass Schutzpfade nicht sofort überfahren werden.
• Multi-Service: Summe der CIRs muss zur Aggregationskapazität und Oversubscription-Policy passen.

PIR sinnvoll einsetzen: Peak darf nicht „Premium-Backdoor“ werden

PIR erlaubt kurzfristig mehr als CIR. Das ist nützlich, wenn die Infrastruktur Headroom hat und Sie Burstiness abfedern wollen, ohne sofort zu queueen oder zu droppen. Gleichzeitig ist PIR im Provider-Kontext eine typische Quelle für Instabilität, wenn er zu hoch ist oder wenn er in Shared Domains als „ständige Zusatzrate“ missbraucht wird. Ein sauberer Einsatz von PIR setzt deshalb voraus, dass Sie (1) Headroom in den relevanten Congestion Domains haben, (2) den Peak-Zweck klar definieren (kurze Spitzen, nicht Dauerlast), und (3) Monitoring haben, das zeigt, ob PIR dauerhaft genutzt wird. Dauerhafte PIR-Nutzung ist praktisch ein Hinweis, dass CIR zu knapp oder die Kapazitätsplanung unrealistisch ist.

• PIR nutzen: um kurzzeitige Spitzen zu absorbieren (z. B. TCP-Slow-Start, Mikrobursts).
• PIR vermeiden: als Ersatz für Kapazitätsausbau oder als „Marketing-Boost“ ohne Headroom.
• Telemetry: messen, wie oft und wie lange PIR tatsächlich erreicht wird.

Burst korrekt dimensionieren: Drei Perspektiven, die zusammenpassen müssen

Eine robuste Burst-Dimensionierung kombiniert drei Perspektiven. Erstens die Zeitfensterperspektive (z. B. 5–20 ms) als Startwert. Zweitens die Paketperspektive: Bursts sollten mindestens mehrere typische Paketgrößen aufnehmen können, sonst wird schon bei wenigen Paketen gedroppt. Drittens die Downstream-Perspektive: Ein Burst, der lokal „harmlos“ ist, kann auf dem nächsten Engpass eine Queue aufblähen und Jitter erzeugen. Im Provider-Kontext ist das besonders wichtig, weil sich Bursts über Aggregation und Multi-Hop addieren können.

• Zeitfenster: Burst als ms-Budget denken (Scheduling- und Jitter-Logik).
• Paketgrößen: Burst muss mehrere MTUs und viele kleine Echtzeitpakete tolerieren.
• Downstream: Burst darf keine Bufferbloat-Lawinen in nachfolgenden Engpässen erzeugen.

Voice-spezifische Dimensionierung: Warum Overhead und PPS zählen

Voice ist ein Sonderfall, weil die Paketfrequenz hoch und die Nutzlast pro Paket klein ist. Das bedeutet: Overhead (L2, IP/UDP/RTP, ggf. Tunnel) macht einen großen Anteil aus, und die effektive Rate ist höher als „Codec-Bitrate“. Außerdem bedeutet es: Policer reagieren nicht nur auf bit/s, sondern implizit auch auf packets per second (PPS), weil viele kleine Pakete den Token-Bucket schneller „zerhacken“ können, wenn Burst zu klein ist. Für Voice-Budgets ist deshalb entscheidend, die tatsächliche On-the-Wire Rate zu modellieren und Bursts so zu dimensionieren, dass Talkspurts und kurze Aggregationspeaks nicht in Drops münden.

• On-the-wire Modell: Codec + RTP/UDP/IP + L2 + ggf. Tunnel-Overhead berücksichtigen.
• Talkspurts: kurze Peak-Phasen sind normal, Burst muss sie tolerieren.
• Degrade statt Drop: bei Überschreitungen in Echtzeitklassen ist Umklassifizierung oft besser als harte Drops.

Praktische Provider-Muster: Two-Rate Three-Color und Profile-Logik

In Provider-Netzen werden Token Buckets häufig in Two-Rate-Modellen umgesetzt: CIR als „Committed“, PIR als „Peak“, und Burst-Puffer für beide. Traffic wird dann in Farben klassifiziert (grün = committed, gelb = excess, rot = exceed) und entsprechend behandelt: grün wird bevorzugt, gelb wird ggf. ummarkiert oder mit höherer Drop-Wahrscheinlichkeit behandelt, rot wird gedroppt. Das ist im Multi-Tenant-Betrieb sehr nützlich, weil Sie Überschreitungen nicht sofort hart droppen müssen, sondern in niedrigere Prioritäten degradieren können. Wichtig ist jedoch: Diese Logik funktioniert nur, wenn Downstream-Queues die Semantik (z. B. Drop-Prioritäten/AQM) auch wirklich abbilden.

• Grün: innerhalb CIR – sollte stabil und SLA-nah behandelt werden.
• Gelb: zwischen CIR und PIR – tolerierbar, aber nicht „Premium“; oft ummarkieren.
• Rot: über PIR – konsequent begrenzen, sonst destabilisiert es die Domain.

Typische Fehler bei CIR/PIR/Burst – und wie sie sich äußern

Viele QoS-Probleme lassen sich auf falsche Token-Bucket-Parameter zurückführen. Diese Fehler sind oft schwer zu erkennen, weil der Durchschnitt gut aussieht, aber die Peaks schlecht sind. Besonders aufschlussreich sind Policer-Counter, Burst-Drops, Queue-Delay-Perzentile und Korrelation mit Busy Hour. Wenn Sie wissen, wie sich Fehler äußern, können Sie die Parameter systematisch statt „trial and error“ anpassen.

• Burst zu klein: sporadische Drops trotz moderater Auslastung; Voice-Artefakte, TCP-Retransmits.
• Burst zu groß: hohe p95/p99 Latenz ohne viele Drops; Bufferbloat, träge Apps.
• CIR zu niedrig: dauerhafte „excess“ Nutzung, häufige Degradation/Drops; SLOs reißen in Busy Hour.
• PIR zu hoch: Peaks überfahren Downstream-Engpässe; kurzzeitige Drop-Bursts bei Partnern/Interconnects.
• Overhead ignoriert: Profile greifen zu früh, besonders in Tunneln; Policers „bestrafen“ Voice.

Messbarkeit: Ohne Telemetrie bleibt Burst-Dimensionierung Glück

Token Buckets lassen sich nicht seriös dimensionieren, ohne Wirkung zu messen. Dazu gehören Policer- und Shaper-Counter (grün/gelb/rot, drops, remarking), Queue-Delay und Drops pro Klasse sowie Utilization-Perzentile in kurzen Zeitfenstern. Für Voice/Video sind p95/p99 wichtiger als Mittelwerte. Zusätzlich sollten Sie Marking-Integrität überwachen: Wenn Überschreitungen degradiert werden, muss sichtbar sein, wie oft das passiert. Nur so erkennen Sie, ob das Profil realistisch ist oder ob es ständig „am Rand“ betrieben wird.

• Policer Counters: exceed/violate, drops, remarking – zeigen direkt, ob Burst und CIR passen.
• Queue-Delay p95/p99: zeigt Bufferbloat-Effekte, besonders bei zu großen Bursts oder fehlendem AQM.
• Short-interval Sicht: 1–5 Minuten oder feiner, um Mikrobursts sichtbar zu machen.
• QoE-KPIs: RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, falls verfügbar.

Blueprint: CIR, PIR und Burst in wiederholbaren Schritten dimensionieren

Ein praxiserprobtes Vorgehen beginnt mit der Serviceabsicht: Welche SLOs und welche Produkte sollen abgedeckt werden? Daraus leiten Sie CIR als zugesicherte Rate ab und entscheiden, ob ein PIR sinnvoll ist oder ob Sie Peaks lieber über Shaping und Queueing abfangen. Danach wählen Sie einen Burst-Startwert als Zeitfenster (z. B. wenige bis einige zehn Millisekunden, abhängig von Domäne und Ziel), und Sie prüfen die Paketperspektive: Burst muss typische MTUs und viele kleine Echtzeitpakete tolerieren. Anschließend berücksichtigen Sie Overhead (L2, MPLS, Tunnel) und Failover-Headroom. In Betrieb validieren Sie die Parameter über Policer-Counter (grün/gelb/rot), Queue-Delay/Drops p95/p99 und QoE-Korrelation. Wenn Drops auftreten, vergrößern Sie nicht reflexartig Burst, sondern lokalisieren Sie zuerst die Congestion Domain: Policer-Drops deuten auf zu enge Profile/Burst; hohe Queue-Delay ohne Drops deutet auf zu große Buffers oder fehlende AQM/ECN; Downstream-Drops deuten auf zu hohen PIR oder auf fehlendes Shaping am richtigen Punkt. So wird Token Bucket Dimensionierung nicht zur Ratespielerei, sondern zu einem systematischen, messbaren Prozess.