Scheduler-Algorithmen wie WFQ, CBWFQ und PQ sind im Telco-Kontext das „Herz“ von QoS: Sie entscheiden bei Engpässen, welche Traffic-Klasse wann und wie viel Bandbreite bekommt. Viele QoS-Designs scheitern nicht an DSCP-Markierungen oder an einem fehlenden Klassenmodell, sondern an einer falschen Scheduling-Strategie: Voice wird zwar markiert, aber nicht wirklich mit niedriger Warteschlangenzeit bedient; Video bekommt zu viel Priorität und verdrängt andere Dienste; oder Best Effort leidet unter Bufferbloat, obwohl im Backbone ausreichend Kapazität vorhanden wäre. In Telekommunikationsnetzen kommt hinzu, dass Scheduling skalieren und überall konsistent sein muss – von Access- und Metro-Aggregation über Mobile Backhaul bis in den IP/MPLS- oder Segment-Routing-Core. Genau dort treffen unterschiedliche Lastprofile aufeinander: konstante Sprachpakete, burstige Videokonferenzen, TCP-lastiges Streaming, Signalisierung und Massentraffic. Dieser Artikel erklärt WFQ, CBWFQ und PQ verständlich, zeigt, wie sich die Algorithmen unterscheiden, wann sie sinnvoll sind und welche Gefahren im Providerbetrieb drohen – inklusive praktischer Designregeln, wie Sie Scheduler so kombinieren, dass Voice & Video stabil bleiben, ohne Best Effort und Betriebsstabilität zu opfern.
Warum Scheduling in Telco-Netzen wichtiger ist als „QoS-Markierung“
DSCP, CoS oder MPLS-TC sind nur Kennzeichnungen. Sie beschreiben, welche Behandlung ein Paket bekommen soll. Ob diese Behandlung wirklich stattfindet, entscheidet das Scheduling am Egress eines Engpasses. Sobald ein Interface mehr Daten sendewillig hat, als physisch übertragen werden kann, entsteht eine Warteschlange – und der Scheduler bestimmt, aus welcher Queue als Nächstes gesendet wird. Im Telco-Kontext ist das besonders relevant, weil Engpässe an vielen Stellen auftreten können:
- Access-Uplinks: oft asymmetrisch und rate-limitiert, besonders upstream.
- Metro-Aggregation: viele Quellen, Microbursts, Oversubscription.
- Mobile Backhaul: variable Kapazität (z. B. Microwave), Lastsprünge durch Funktraffic.
- Interconnect/Peering: häufige Hotspots, die QoE dominieren.
- Core-Failover: Traffic-Shifts können selbst im Backbone kurzfristige Congestion erzeugen.
Ein gutes Scheduler-Design macht das Verhalten unter Last vorhersehbar: Voice bleibt verständlich, Video bleibt stabil, Best Effort bleibt fair.
Grundbegriffe: Queueing, Scheduling und Klassen
Bevor wir WFQ, CBWFQ und PQ vergleichen, lohnt sich ein klarer Sprachrahmen:
- Queue (Warteschlange): Puffer, in dem Pakete auf die Übertragung warten.
- Scheduling: Regelwerk, nach dem Pakete aus den Queues ausgewählt werden.
- Class-Based QoS: Pakete werden in Klassen eingeteilt (z. B. Voice, Video, Best Effort) und pro Klasse behandelt.
- Engpass: Interface/Link, an dem Contention entsteht; dort ist QoS wirksam.
Wichtig: Scheduling ist immer eine Egress-Funktion. Ingress kann klassifizieren, markieren, policen – aber der tatsächliche „Vorrang“ entsteht beim Senden.
PQ: Priority Queueing – maximal schnell, maximal riskant
PQ (Priority Queueing) ist das klassische Prioritäts-Queueing. Es existieren mehrere Queues mit unterschiedlichen Prioritäten. Der Scheduler bedient zuerst die höchste Queue; erst wenn sie leer ist, wird die nächste Queue bedient. Das ist extrem wirksam für zeitkritische Pakete, aber gefährlich, wenn die höchste Queue zu groß wird.
Wann PQ im Telco-Kontext sinnvoll ist
- Echte Echtzeitströme mit kleinem Volumen: typischerweise Voice Media (RTP) oder sehr schmale, klar definierte Steuerpfade.
- Links mit realer Contention: WAN-Edges, Backhaul-Engpässe, Aggregation-Uplinks.
Warum PQ gefährlich werden kann
- Starvation: Wenn die höchste Queue dauerhaft gefüllt ist, bekommen andere Queues kaum Sendezeit.
- Missmarkierung/Missbrauch: Wenn zu viele Pakete als „Priority“ klassifiziert werden, verliert QoS seine Steuerwirkung.
- Netzinstabilität: Best Effort und sogar wichtige Nebenklassen können unter Last kollabieren.
Im Providerbetrieb gilt deshalb: Reines PQ ohne Limit ist selten akzeptabel. In modernen Designs wird PQ durch LLQ-Ansätze ersetzt, die Priorität begrenzen.
LLQ als „modernes PQ“: Priorität, aber begrenzt
Viele Plattformen sprechen bei einer Prioritätsklasse von LLQ (Low Latency Queue). Konzeptuell ist es PQ, aber mit einer entscheidenden Ergänzung: Die Priority-Queue erhält ein Bandbreitenlimit. Dadurch wird Starvation verhindert, während Echtzeit trotzdem minimal wartet.
- Telco-Best Practice: Voice Media in LLQ (strict priority) mit Limit, Video nicht in LLQ.
- Warum: Voice ist klein und sensibel; Video ist groß und variabel und würde eine Priority-Queue aufblähen.
Wenn Sie PQ einsetzen wollen, ist LLQ fast immer die sichere Variante: gleiche Echtzeitwirkung, aber kontrollierbar.
WFQ: Weighted Fair Queueing – Fairness als Default
WFQ (Weighted Fair Queueing) ist ein fairnessorientierter Scheduler. Er versucht, Flows (oder Klassen, abhängig von Implementierung) so zu bedienen, dass kein einzelner Flow alles dominiert. Die Idee ist, jedem Flow/Traffic-Anteil eine faire Bedienung zu geben, oft mit Gewichtung basierend auf Paketmerkmalen oder DSCP.
Warum WFQ im Telco-Kontext attraktiv ist
- Automatische Fairness: Einzelne „Top Talker“ dominieren weniger.
- Gute Default-Eigenschaft: Besonders auf kleineren Links kann WFQ ohne großes Klassenmodell bereits spürbar helfen.
- TCP-freundlich: Fairness reduziert Kollaps-Effekte, wenn viele TCP-Flows konkurrieren.
Grenzen von WFQ
- Begrenzte Steuerbarkeit: Für klare Telco-SLAs ist „automatische“ Fairness oft zu unscharf.
- Echtzeit braucht mehr als Fairness: Voice profitiert von Low-Latency-Priorität; WFQ allein garantiert das nicht zuverlässig.
- Skalierung/Hardware: In High-Speed-Core-Plattformen wird WFQ oft in vereinfachten, hardwarefreundlichen Varianten umgesetzt.
WFQ ist daher oft ein gutes Baseline-Verfahren, ersetzt aber in Telco-Netzen nicht das klare Klassenmodell mit LLQ/CBWFQ.
CBWFQ: Class-Based Weighted Fair Queueing – der Telco-Standard für Mehrklassen-QoS
CBWFQ (Class-Based WFQ) ist eine Erweiterung: Statt „automatisch“ pro Flow zu entscheiden, definieren Sie explizite Klassen (z. B. Voice, Video, Business, Best Effort) und weisen ihnen Bandbreitenanteile/Gewichte zu. Das passt hervorragend zu DiffServ-Klassenmodellen im Provider-Netz.
Warum CBWFQ in Telco-Netzen so verbreitet ist
- Planbarkeit: Jede Klasse hat definierte Mindestanteile – gut für SLAs.
- Kontrollierte Priorisierung: Video kann bevorzugt werden, ohne strict priority zu sein.
- Skalierbarkeit: Klassenbasierte Behandlung funktioniert über viele Hops.
CBWFQ typischerweise kombiniert mit LLQ
In der Praxis ist das häufigste Muster:
- Voice Media: LLQ (Priority mit Limit).
- Video: CBWFQ-Klasse mit garantierten Anteilen.
- Signaling/Control: CBWFQ-Klasse mit hohem Anteil, aber nicht strict.
- Best Effort: Rest, fair verteilt, Puffer kontrollieren.
- Background: niedrige Gewichtung.
Dieses Muster ist im Telco-Kontext so beliebt, weil es die typische Anforderung exakt abbildet: Voice maximal schützen, Video stabilisieren, Restverkehr fair halten.
WFQ vs. CBWFQ vs. PQ: Direkter Vergleich im Providerbetrieb
- PQ: maximale Verzögerungsreduktion für eine Klasse, aber hohes Starvation-Risiko. Nur sicher mit Limit (LLQ).
- WFQ: gute Fairness, weniger Konfigurationsaufwand, aber begrenzte SLA-Steuerbarkeit für differenzierte Services.
- CBWFQ: explizite Klassensteuerung, SLA-fähig, ideal in Kombination mit LLQ für Voice.
Wenn Sie nur einen Telco-Satz merken wollen: LLQ für Voice + CBWFQ für Video/Business + fairer Best Effort ist in vielen Netzen die robusteste Standardkombination.
Video im Scheduler: Warum gewichtet fast immer besser ist als Priority
Video ist für Scheduler-Design besonders tückisch: Es ist bandbreitenstark, variabel und bursty. Interaktives Video (Meetings) reagiert empfindlich auf Jitter und Verlust, aber es verträgt eher eine leicht höhere Warteschlangenzeit als Voice. Deshalb ist die typische Telco-Regel:
- Audio: Priority/LLQ mit Limit.
- Video: CBWFQ (gewichtet), mit garantierten Anteilen und kontrollierten Queue-Limits.
Priority für Video wird gefährlich, weil Video die Priority-Queue schnell „dauerhaft nicht leer“ macht. Dann verhungern andere Klassen, und die Gesamtqualität sinkt.
Scheduler und Bufferbloat: Queue-Limits sind Teil des Designs
Scheduler allein löst nicht jedes QoS-Problem. Wenn Queues zu groß sind, können Latenz und Jitter steigen, selbst wenn Drops niedrig sind. Besonders in Metro- und Access-Umgebungen ist das ein häufiger Grund für „Ruckler ohne Verlust“.
- Zu große Queues: mehr Latenz/Jitter, Plattformen reagieren mit Quality-Downshift.
- Zu kleine Queues: mehr Drops, besonders bei Microbursts.
- Balance: Echtzeitqueues klein und schnell, Video moderat, Best Effort kontrolliert.
Ein praxistauglicher Ansatz ist, zusätzlich Shaping an rate-limitierten Links zu nutzen, um Microbursts zu glätten und Drop-Cluster zu vermeiden.
Telco-spezifische Stolperfallen: Wo Scheduler-Design oft scheitert
- Inkonsistentes Klassenmapping: DSCP/CoS/MPLS-TC wird nicht überall gleich gequeued; Scheduler wirkt nur „stellenweise“.
- Priority ohne Limit: führt zu Starvation; im Providerbetrieb ein Stabilitätsrisiko.
- Zu viele Klassen: Hardware-Queues reichen nicht, Templates driften, Betrieb verliert Überblick.
- Policing statt Shaping: harte Drops auf Video/Voice erzeugen sichtbare/hörbare Störungen.
- Monitoring nur auf Linkauslastung: Microbursts bleiben unsichtbar; Queue-Drops und Queue-Depth sind wichtiger.
Monitoring: So erkennen Sie, ob WFQ/CBWFQ/PQ richtig funktionieren
Im Betrieb sollten Sie nicht nur Traffic-Mengen, sondern Scheduler-Effekte sichtbar machen. Sinnvolle KPIs sind:
- Queue-Drops pro Klasse: Drops in Voice sind kritisch; Drops in Video deuten auf fehlende Garantien oder Bursts.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
- Scheduler-Auslastung/Weights: ob Klassen ihre Anteile bekommen oder verdrängt werden.
- Policer-Hits und Remarking: zeigt Profilverletzungen oder Missmarkierung.
- Service-KPIs: MOS/R-Faktor für Voice, QoE-Indikatoren für Video (Freeze-Events) korrelieren mit Queue-Events.
Ein bewährter Telco-Standard ist: Drops in der Voice-Klasse sind ein Incident. So bleibt die wichtigste Echtzeitklasse operational geschützt.
Praxisleitfaden: Welcher Scheduler passt zu welchem Ziel?
- Sie brauchen schnelle Ergebnisse auf einem Engpass-Link: LLQ für Voice, CBWFQ für den Rest, Shaping wenn rate-limitiert.
- Sie wollen „faire“ Best Effort-Verteilung ohne komplexe Policies: WFQ als Baseline, aber Voice separat schützen.
- Sie betreiben SLAs für mehrere Dienste: CBWFQ ist Pflicht, ergänzt um LLQ für Voice und klare Queue-Limits.
- Sie sind im Providerbetrieb mit vielen Kunden: Priority nur begrenzt, Trust Boundary und Profilierung sind essenziell.
Der Kern ist immer derselbe: Priorität dort, wo es sein muss (Voice), Gewichtung dort, wo Volumen groß ist (Video), Fairness dort, wo Vielfalt herrscht (Best Effort).
Häufige Fragen zu Scheduler-Algorithmen
Kann ich nur mit WFQ gute Voice-Qualität erreichen?
Manchmal, aber nicht zuverlässig in Engpasssituationen. Voice profitiert am stärksten von einer Low-Latency-Queue (Priority mit Limit). WFQ ist gut für Fairness, ersetzt aber die harte Echtzeitbehandlung nicht.
Ist PQ im Telco-Netz grundsätzlich falsch?
Nicht grundsätzlich, aber ohne Limit riskant. Im Providerbetrieb wird PQ praktisch immer als LLQ umgesetzt, also strict priority mit Bandbreitenlimit. So bleibt Echtzeit schnell, ohne dass andere Klassen verhungern.
Warum ruckelt Video trotz CBWFQ?
Häufig wegen Microbursts, zu kleinen Video-Queues, fehlendem Shaping an Rate-Limits oder falschem Mapping (Video landet nicht in der vorgesehenen Klasse). Prüfen Sie Queue-Drops, Queue-Depth und Shaping/Policer-Hits – nicht nur die durchschnittliche Linkauslastung.