Shaping vs. Policing ist im Voice-Design eine der wichtigsten Entscheidungen überhaupt, weil beide Mechanismen zwar „Traffic begrenzen“, aber völlig unterschiedliche Auswirkungen auf Echtzeitqualität haben. In der Praxis wird Voice nicht primär durch mehr Bandbreite geschützt, sondern durch kontrollierbare Warteschlangen: minimaler Queueing-Delay, geringer Jitter und möglichst keine Drops in der Media-Klasse. Genau hier trennt sich der Weg. Policing ist hart: Überschüssige Pakete werden verworfen oder ummarkiert, häufig ohne Rücksicht darauf, dass Voice-RTP auf Retransmissions nicht sinnvoll warten kann. Shaping ist weich: Traffic wird geglättet und in eine Queue gelegt, sodass Pakete zeitlich gleichmäßiger abfließen und Congestion idealerweise im eigenen Einflussbereich entsteht. Für Voice ist das meist die bessere Wahl, weil Drops sofort hörbar sind, während ein kontrolliertes, kleines Delay oft tolerierbar bleibt. Gleichzeitig ist Policing im Provider- und Multi-Tenant-Kontext unverzichtbar, um Missbrauch zu verhindern und Serviceprofile durchzusetzen. Der Trick ist deshalb nicht „Shaping oder Policing“, sondern: Wo setze ich was ein, damit Voice geschützt wird, ohne dass Premiumklassen durch Fehlmarking explodieren oder dass der Engpass in eine Black Box wandert? Dieser Artikel erklärt die Mechanik, zeigt typische Failure Patterns und liefert praxiserprobte Regeln, wann welcher Mechanismus Voice wirklich schützt.
Grundprinzip: Voice reagiert auf Drops anders als auf Delay
Um Shaping und Policing sauber zu bewerten, müssen Sie das Verhalten von Voice verstehen. RTP-Streams senden kontinuierlich kleine Pakete. Geht ein Paket verloren, kann es nicht wie bei TCP einfach nachgesendet werden, weil die Wiedergabezeit schon abgelaufen ist. Moderne Codecs nutzen Packet Loss Concealment, eventuell FEC, aber die Toleranz ist begrenzt. Verzögerung ist ebenfalls kritisch, aber anders: Ein bisschen zusätzliches, stabiles Delay lässt sich durch Jitter-Buffer puffern. Unkontrollierte Verzögerungsschwankungen (Jitter) und Drops sind dagegen sofort hörbar. Daraus folgt: Maßnahmen, die Drops erzeugen (Policing), sind für Voice gefährlicher als Maßnahmen, die Traffic glätten (Shaping) – solange Shaping die Queue kurz hält und nicht zu Bufferbloat führt.
- Drops: führen zu hörbaren Aussetzern, Robot Voice, Silbenverschlucken.
- Jitter: führt zu Buffer-Underflows, sporadischen Artefakten, Qualitätsflattern.
- Stabiles Delay: ist oft weniger schlimm als Loss, solange das End-to-End Latenzbudget nicht gerissen wird.
Was Shaping technisch macht – und warum es Voice häufig schützt
Traffic Shaping begrenzt die Ausgangsrate, indem es Pakete puffert und zeitlich verteilt. Der Kernnutzen im WAN- und Provider-Design ist: Sie holen Congestion in Ihr eigenes Gerät. Statt dass ein Provider-Edge oder ein Access-Modem unkontrolliert dropt, entsteht die Warteschlange an Ihrem Shaper, wo Sie sie mit QoS-Klassen (LLQ/CBWFQ), Queue-Limits und AQM kontrollieren können. Für Voice ist das entscheidend, weil Sie Voice-Pakete in einer kleinen Echtzeitqueue priorisieren, während Bulk- und Best-Effort-Traffic geglättet wird. Shaping reduziert außerdem Mikrobursts, die besonders bei Aggregation und bei Tunnel-Encapsulation häufig auftreten.
- Queue im eigenen Einflussbereich: Sie sehen Queue-Delay/Drops und können gezielt optimieren.
- Glättung: Burstiness sinkt, Drop-Bursts werden seltener.
- Kombinierbar mit LLQ: Voice bekommt strikte Priorität innerhalb des Shaper-Budgets.
- Predictability: besseres Sizing und stabilere Perzentile für Latenz/Jitter.
Was Policing technisch macht – und warum es Voice gefährden kann
Policing misst Traffic gegen ein Profil (Rate und Burst) und verwirft oder ummarkiert Pakete, die das Profil überschreiten. Das ist im Provider-Betrieb wichtig, weil es Profile durchsetzt und Missbrauch verhindert. Für Voice ist Policing jedoch heikel, weil es Drops produziert – und zwar oft in Bursts, wenn der Token-Bucket leer ist. Selbst wenn der Durchschnitt „passt“, kann ein zu kleines Burst-Setting oder eine falsche Annahme über Overhead dazu führen, dass Voice-Pakete gedroppt werden. Das ist besonders tückisch bei kleinen Paketen (RTP) und bei Encapsulation (IPsec/VXLAN/GRE), weil der effektive Bandbreitenbedarf höher ist als das „innere“ Modell vermuten lässt.
- Harte Kante: Überschreitungen werden gedroppt – Echtzeit kann das nicht reparieren.
- Burst-Sensitivität: Token-Bucket-Parameter entscheiden, ob kurzzeitige Peaks toleriert werden.
- Overhead-Falle: Tunnel-/Header-Overhead führt dazu, dass Profile „zu eng“ wirken.
- Asymmetrie: Policer in nur eine Richtung erzeugen einseitige Qualitätsprobleme.
Die Carrier-Realität: Warum beides gebraucht wird
Im Provider-Kontext ist die Frage selten „nur Shaping“ oder „nur Policing“. In Multi-Tenant-Umgebungen benötigen Sie Policing oder zumindest Budget-Enforcement, um Premiumklassen (EF/Realtime) vor Fehlmarking zu schützen. Gleichzeitig benötigen Sie Shaping, um Congestion kontrollierbar zu machen und Voice vor Drops in Black-Box-Queues zu schützen. Ein robustes Design setzt daher Policing an Trust Boundaries (Ingress) ein, um Profile und Klassenrechte durchzusetzen, und Shaping an Engpässen (Egress), um die Warteschlange dorthin zu bringen, wo Ihre QoS-Queues wirken.
- Policing an Trust Boundaries: verhindert Missmarking und Premium-Queue-Flutung.
- Shaping an Congestion Points: reduziert Drop-Bursts und stabilisiert Queue-Delay.
- Hybrid: Überschreitungen degradieren (ummarkieren) statt droppen, wenn Voice sonst leidet.
Wann Shaping Voice schützt – typische Szenarien
Shaping ist besonders wirksam, wenn der Engpass außerhalb Ihres Geräts liegt oder wenn Links stark burstig sind. Das ist in der Praxis sehr häufig: Access-Links, Broadband-Uplinks, Metro-Aggregation, Interconnect-Ports oder Tunnel-Overlays. In diesen Szenarien schützt Shaping Voice, weil es Bulk-Traffic glättet und Voice im eigenen Scheduler bevorzugt bedient wird. Wichtig ist dabei die Dimensionierung: Shaping muss knapp unter der realen, nutzbaren Rate liegen (inklusive Overhead), sonst wandert die Congestion wieder zum Provider.
- Access/WAN Upstream: typischer Hauptengpass; Shaping verhindert Bufferbloat im Modem/Provider.
- Interconnects: Fan-in und Mikrobursts; Shaping macht Drops lokal und messbar.
- Tunnel (IPsec/GRE/VXLAN): Overhead und Burstiness; Shaping stabilisiert den Abfluss.
- Failover-Pfade: geringere Kapazität; Shaper-Profile können Worst Case abdecken.
Wann Policing Voice schützt – und wann es unvermeidbar ist
Policing schützt Voice nicht, indem es Voice „besser macht“, sondern indem es das Netz vor Missbrauch schützt. In Provider-Umgebungen kann ein Kunde seinen gesamten Traffic als EF markieren. Ohne Policing/Enforcement wird die Voice-Priority-Queue geflutet, und echte Voice leidet am Ende genauso. Policing ist daher sinnvoll, um EF-Rechte zu begrenzen und um SLA-Profile einzuhalten. Es kann auch an Ingress-Punkten genutzt werden, um Nicht-Voice-Traffic aus der Voice-Klasse herauszuhalten. Entscheidend ist, wie das Policing reagiert: Für Voice-nahe Klassen ist Degradation häufig besser als Drop, weil harte Drops sofort hörbar sind.
- EF/Realtime schützen: Policing/Remarking verhindert Premium-Queue-Flutung durch Missmarking.
- Produktprofile erzwingen: z. B. SIP-Trunk mit definierter Voice-Bandbreite.
- Noisy Neighbor vermeiden: per Subscriber/Service begrenzen (HQoS + Policer).
- Prefer Degrade: Überschreitungen in niedrigere Klasse ummarkieren, statt Voice zu droppen.
Degrade statt Drop: Das praxistaugliche Policing-Muster für Echtzeit
Viele moderne QoS-Designs nutzen Policing nicht als „Schere“, sondern als „Weiche“. Überschreitet eine Klasse ihr Budget, werden Pakete in eine niedrigere Klasse ummarkiert (z. B. EF → AF oder BE), statt sie hart zu verwerfen. Das schützt die Priority Queue vor Überfüllung und reduziert gleichzeitig hörbare Aussetzer. Natürlich ist Degradation kein Freifahrtschein: Wenn die nachrangigen Klassen ebenfalls congested sind, kann auch degradiertes Voice leiden. Aber operativ ist es oft die bessere Option als harte Drops in der Realtime-Klasse.
- Schutz der LLQ: echte Voice bleibt in der Priority Queue stabil.
- QoE besser als Drop: weniger harte Artefakte, weil nicht sofort Pakete verloren gehen müssen.
- Messbarkeit: Remarking-Counter zeigt, wann Budgets überschritten werden.
Token Bucket und Burst-Parameter: Der Policing-Feinschliff, der über QoE entscheidet
Policing wird über Token-Bucket-Mechanismen umgesetzt. Der entscheidende Punkt ist nicht nur die Rate, sondern auch die Burst-Größe: Wie viele Bytes dürfen kurzfristig über dem Durchschnitt liegen, bevor Drops/Degradation greifen? Für Voice ist Burst relevant, weil RTP zwar „gleichmäßig“ wirkt, aber in Aggregation, bei Talkspurts, durch Packetization-Interval oder durch Scheduling auf Endgeräten dennoch kurze Peaks entstehen können. Zu kleine Burst-Werte führen zu „random“ Drops, die in Wahrheit policing-getrieben sind.
- Rate: muss den realen Bedarf inklusive Overhead abdecken.
- Burst: muss typische kurzzeitige Peaks tolerieren, ohne sofort zu droppen.
- Overhead: Encapsulation und L2/MPLS-Header verändern die Byte-Realität.
Shaping richtig dimensionieren: Warum „ein bisschen darunter“ nicht reicht
Shaping ist nur dann wirksam, wenn es den echten Engpass trifft. Dazu muss der Shaper unter der tatsächlich nutzbaren Rate liegen – nicht unter der nominalen Vertragsrate. In Broadband-Links, bei Cable/DSL, in Mobilfunk-Backhauls oder bei geteilten Metro-Übergängen schwankt die effektive Rate. Zudem kann Layer-2/Encapsulation-Overhead die nutzbare Payload-Rate reduzieren. Wird zu hoch geshaped, liegt die Queue beim Provider oder im CPE, und Ihre QoS-Queues greifen nicht mehr. Wird zu niedrig geshaped, verschenken Sie Kapazität und erzeugen unnötige Congestion im eigenen Gerät.
- Realistische Rate: Vertragsrate minus Overhead minus notwendiger Headroom.
- Messung: Utilization-Perzentile und Queue-Delay nutzen, um die Shaper-Rate zu validieren.
- Failover: Backup-Kapazität berücksichtigen, sonst bricht Voice bei Umschaltung ein.
Scheduling-Kombination: Voice braucht LLQ, aber LLQ braucht Limits
Voice wird in der Praxis meist über eine Priority Queue (LLQ) geschützt. Shaping liefert die kontrollierbare Congestion-Umgebung, LLQ liefert minimalen Delay. Policing sorgt dafür, dass die LLQ nicht missbraucht wird. Das stabile Muster lautet daher: Egress Shaping am Engpass, darunter Klassenqueueing (LLQ für Voice mit Limit, gewichtete Klassen für Video/Business, Best Effort mit AQM/ECN, Bulk nachrangig). Starvation wird verhindert, indem die LLQ strikt begrenzt und Marking an Trust Boundaries kontrolliert wird.
- LLQ-Limit: verhindert Starvation und macht das Modell SLA-fähig.
- Weighted Queues: geben Video/Business planbare Mindestanteile.
- AQM/ECN: stabilisiert Best Effort, reduziert Bufferbloat, verbessert Interaktivität.
Monitoring: Woran Sie erkennen, ob Shaping oder Policing Voice wirklich schützt
Die beste Konfiguration ist wertlos, wenn Sie nicht messen, wo Congestion entsteht und welcher Mechanismus wirkt. Für Voice sind queuebezogene KPIs entscheidend: Queue-Delay und Drops in der Realtime-Klasse, Policer-Drops bzw. Remarking-Counts, sowie Perzentile in kurzen Zeitfenstern (p95/p99). Wenn Voice leidet, sollten Sie zuerst prüfen: Gibt es Policer-Drops in der Voice-Klasse? Steigt Queue-Delay im Realtime-Queue? Gibt es hohe Delay-Perzentile in Best Effort (Bufferbloat), die auf fehlendes Shaping hindeuten? Und: Liegt die Queue überhaupt bei Ihnen oder beim Provider?
- Realtime Drops: wenn Drops in Voice auftreten, ist Policing oder Queue-Overflow meist die Ursache.
- Realtime Queue-Delay: hohe p95/p99 Werte deuten auf zu große Queues oder falsches Scheduling.
- Remarking/Policer Counters: zeigen Missmarking und Budgetüberschreitungen.
- Interface Utilization Perzentile: p95/p99 statt Durchschnitt, um Engpässe realistisch zu sehen.
Typische Failure Patterns und schnelle Korrekturen
In der Praxis wiederholen sich Fehler. Wer diese Muster kennt, kann schnell entscheiden, ob Shaping oder Policing angepasst werden muss. Besonders häufig sind zu knappe Policer (ohne Overhead), fehlendes Shaping im Upstream, oder der Versuch, Voice durch harte Drops „zu disziplinieren“.
- Voice bricht bei Upload ein: Shaping fehlt; Congestion liegt beim Provider/CPE → Egress Shaping einführen.
- Policer-Drops in Voice: Budget zu knapp oder Burst zu klein → Rate/Burst inkl. Overhead neu dimensionieren, ggf. degrade statt drop.
- Andere Apps werden langsam: LLQ zu groß oder unlimitiert → LLQ-Limit reduzieren, Trust Boundaries verschärfen.
- Keine Drops, aber schlechte Voice: Bufferbloat → Queue-Limits/AQM prüfen, Shaping-Placement korrigieren.
Blueprint: Wann welcher Mechanismus Voice schützt
Ein praxiserprobtes Entscheidungsmodell lautet: Nutzen Sie Shaping, wenn Sie Congestion kontrollierbar machen müssen – also fast immer am WAN-Edge, an Interconnects und in Tunnel-Umgebungen. Nutzen Sie Policing, wenn Sie Rechte und Profile durchsetzen müssen – also an Trust Boundaries, bei Multi-Tenant-Services und beim Schutz der Realtime-Klasse vor Missmarking. Kombinieren Sie beide, indem Sie am Engpass egress shap(en) und innerhalb des Shapers eine limitierte LLQ für Voice betreiben. Verwenden Sie Policing für Realtime idealerweise mit Degradation statt Drop, außer bei klaren Missbrauchsszenarien oder vertraglich harten Grenzen. Planen Sie Budgets auf Busy Hour und Failover, berücksichtigen Sie Overhead, und betreiben Sie das System messgetrieben über Queue-Delay/Drops und Policer-/Remarking-Zähler. So wird Shaping vs. Policing keine Glaubensfrage, sondern ein reproduzierbarer Mechanismus, der Voice im echten Netzbetrieb zuverlässig schützt.
