Priority Queues richtig einsetzen ist im Provider- und Enterprise-Kontext eine der wichtigsten QoS-Disziplinen, weil Priority Queues (oft als LLQ, Strict Priority oder Expedited Queue umgesetzt) gleichzeitig das beste Mittel gegen Jitter und das größte Risiko für Instabilität sind. Sie sind ideal für echtzeitkritischen Verkehr wie Voice (RTP), manchmal auch für bestimmte Control- oder Timing-Flows – aber sie können andere Klassen verhungern lassen, wenn sie falsch dimensioniert, falsch befüllt oder unzureichend kontrolliert werden. Genau dieses Problem nennt man Starvation: Eine strikt priorisierte Warteschlange wird so oft bedient, dass für Best Effort, Business-Daten oder sogar Network Control zu wenig Sendezeit übrig bleibt. Das Ergebnis ist paradox: Voice ist „okay“, aber alles andere wird langsam, TCP bricht ein, Routing/OAM wird instabil, und unter Last eskaliert das Netzverhalten. Professionelle QoS-Designs behandeln Priority Queues deshalb nicht als „Turbo-Knopf“, sondern als kontrolliertes Budget mit klarer Trust Boundary, strikter Obergrenze, geeigneten Queue-Limits und begleitendem Shaping/AQM. Dieser Artikel zeigt, warum Starvation entsteht, wie Sie Priority Queues robust dimensionieren und welche operativen Muster verhindern, dass Ihr Netz bei Peaks oder Fehlmarking kollabiert.
Was eine Priority Queue technisch ist und warum sie so wirksam ist
Eine Priority Queue ist eine Warteschlange, die gegenüber anderen Queues bevorzugt bedient wird. Bei strikter Priorität gilt: Solange Pakete in der Priority Queue liegen, werden sie zuerst gesendet. Das reduziert Queueing-Delay und Jitter massiv – genau das, was Voice und interaktives Echtzeitvideo brauchen. In vielen Implementierungen wird diese Priorität mit einer LLQ kombiniert: Der Scheduler bedient die Priority Queue zwar bevorzugt, aber mit einer definierten Obergrenze (Rate/Prozent), damit andere Klassen nicht vollständig verdrängt werden. Der Unterschied zwischen „strict priority ohne Limit“ und „priority mit Limit“ ist im Provider-Kontext der Unterschied zwischen stabiler QoS und Starvation-Risiko.
- Strict Priority: Prioritätsqueue wird zuerst geleert, andere Queues warten.
- LLQ (Priority mit Limit): Priorität ja, aber nur bis zu einem Budget; danach bekommen andere Klassen Sendezeit.
- Nutzen: minimale Verzögerung für Realtime, weniger Jitter, weniger Playout-Probleme.
- Risiko: ohne Limits oder bei Missmarking kann die Priority Queue das System dominieren.
Wie Starvation entsteht: Drei typische Ursachen
Starvation entsteht nicht „zufällig“, sondern fast immer durch ein Zusammenspiel aus falscher Klassifizierung, fehlender Limitierung und falscher Lage der Congestion. Besonders gefährlich ist, dass Starvation häufig erst unter Last sichtbar wird: Im Normalbetrieb wirkt alles stabil, in Busy Hour oder nach Failover kippt das System. In Provider-Topologien verstärkt sich das durch Aggregation und Shared Links: Eine falsche Markierung an einer Stelle kann Premium-Queues über viele Hops fluten.
- Unlimitierte Priority: Strict Priority ohne Obergrenze verdrängt andere Queues, sobald die Priority Queue dauerhaft gefüllt ist.
- Missmarking/Fehlklassifizierung: zu viel Traffic landet in der Priority Queue (absichtlich oder durch Fehler).
- Engpass am falschen Ort: Congestion liegt außerhalb Ihrer Kontrolle (Provider/Access/Black Box), Ihre Limits greifen nicht wie erwartet.
Trust Boundary ist Pflicht: Wer darf überhaupt in die Priority Queue?
Das wirksamste Mittel gegen Starvation ist nicht „noch besser schedulen“, sondern die Prioritätsklasse vor Missbrauch zu schützen. In Multi-Tenant- und gemischten Umgebungen dürfen Endgeräte, Kunden-CPEs oder Anwendungen nicht beliebig EF/Realtime markieren. Deshalb gehört zu jedem Priority-Queue-Design eine Trust Boundary: eine Stelle, an der Markierungen geprüft, normalisiert und auf ein internes Klassenmodell gemappt werden. Im Provider-Kontext sitzt diese Trust Boundary typischerweise am PE/BNG/Service Edge, im Enterprise häufig am Access-Switch/WLAN-Controller oder am WAN-Edge.
- Allowlist: nur definierte DSCP-Werte (z. B. EF für Voice) werden als Realtime akzeptiert.
- Normalization: unbekannte Markings werden auf Best Effort gesetzt.
- Profile pro Kunde/Service: Realtime ist nur für bestimmte Services erlaubt, nicht für „alles“.
- Audit: Remarking- und Policer-Zähler zeigen, ob Missmarking stattfindet.
LLQ-Limitierung: Das wichtigste Anti-Starvation-Tool
Eine Priority Queue muss limitiert werden – fast immer. Die Obergrenze kann als Prozent der Linkrate oder als absolute Rate umgesetzt werden. Der Zweck ist immer gleich: Die Priority Queue bekommt bevorzugte Bedienung, aber nur bis zu einem Budget, das Ihre Realtime-Dienste tatsächlich benötigen. Alles darüber wird entweder gedroppt (hart) oder – in manchen Designs – degradiert (umklassifiziert), damit andere Klassen weiterhin Sendezeit bekommen. Das entscheidende Engineering-Element ist die Dimensionierung dieses Limits: zu klein verursacht Realtime-Drops und hörbare Aussetzer, zu groß erhöht das Starvation-Risiko.
- Budget statt „unendlich“: Priority Queue als reserviertes Kontingent verstehen.
- Dimensionierung nach Busy Hour: Limits nicht nach Durchschnitt, sondern nach Spitzenlast planen.
- Overhead berücksichtigen: Tunnel-/Encapsulation-Overhead erhöht effektive Rate, besonders bei kleinen Paketen.
- Failover-Headroom: Schutzpfade sind oft enger; LLQ-Budget muss Worst Case überstehen.
Praktische Faustregeln für Limits
- Voice strikt klein halten: Voice/Realtime sollte im Gesamtsystem ein klar begrenzter Anteil bleiben.
- Keine „Sicherheitsaufschläge“ ohne Messung: zu große LLQ wirkt wie eine Einladung zur Starvation.
- Peak-Messung nutzen: reale LLQ-Auslastung in p95/p99 betrachten und Limits daran orientieren.
Queue-Limits und Bufferbloat: Starvation ist nicht nur „keine Bandbreite“
Starvation wird oft nur als „andere Klassen bekommen keine Bandbreite“ verstanden. In der Praxis gibt es aber eine zweite Dimension: Latenz. Wenn Ihre nicht-priorisierten Queues große Puffer haben und selten bedient werden, steigt die Warteschlangenverzögerung massiv – selbst wenn noch „etwas“ Bandbreite durchkommt. Das äußert sich als träge Anwendungen, schlechte SaaS-Performance und instabile TCP-Flows. Deshalb müssen Queue-Limits und AQM/ECN (in Best Effort) Teil des Anti-Starvation-Designs sein: Sie halten die Queues kurz und verhindern, dass sich Delay-Spitzen aufbauen.
- Realtime-Queue kurz: damit Jitter klein bleibt; große Realtime-Puffer sind kontraproduktiv.
- Best Effort mit AQM/ECN: reduziert Bufferbloat, stabilisiert RTT-Perzentile.
- Delay-Metriken: Queue-Delay p95/p99 zeigt Starvation-Effekte oft früher als Drops.
Scheduling-Kombinationen: Priority Queue neben CBWFQ/WRR sauber einbetten
In realen Netzen existiert die Priority Queue nicht allein. Sie wird meist mit gewichteten Klassen (CBWFQ/WRR) kombiniert. Das Ziel ist ein Gesamtmodell: Realtime bekommt Priorität mit Limit, Video/Business bekommen Mindestanteile, Best Effort nutzt den Rest und bleibt durch AQM/ECN latenzstabil, Bulk ist nachrangig. Starvation vermeiden Sie dabei nicht nur durch das LLQ-Limit, sondern auch durch sinnvolle Mindestanteile für wichtige Nicht-Realtime-Klassen – insbesondere Network Control und OAM, damit das Netz auch unter Last steuerbar bleibt.
- Network Control schützen: Routing/OAM braucht garantierte Ressourcen, sonst eskaliert jede Störung.
- Video nicht in die LLQ: Video ist „Realtime-nah“, aber bandbreitenintensiv; meist besser in gewichtete Klasse.
- Business Critical: bevorzugt, aber fair; verhindert, dass Best Effort alles dominiert.
- Bulk/Scavenger: bewusst niedrig, damit Updates/Backups nicht die QoS-Domäne aufblasen.
Shaping als Starvation-Schutz: Die Queue an den richtigen Ort holen
Starvation wird besonders schwer zu kontrollieren, wenn Congestion außerhalb Ihres Einflussbereichs liegt. Wenn ein Provider-Edge oder ein Access-Gerät die echte Warteschlange hält, können Ihre LLQ-Limits zwar lokal „gut aussehen“, aber die Drops passieren woanders. Egress Shaping verlagert Congestion in Ihr Gerät und macht Queueing reproduzierbar. In Hub-and-Spoke- oder Metro-Aggregation-Szenarien hilft zusätzlich HQoS: Sie begrenzen pro Kunde/Service und priorisieren innerhalb dieser Budgets, sodass eine einzelne Quelle die Priority Queue nicht dauerhaft füllen kann.
- Egress Shaping: Congestion lokal halten, Mikrobursts glätten, Starvation diagnostizierbar machen.
- HQoS: per Service/Customer budgetieren, dann Priority nur innerhalb des Budgets zulassen.
- Failover-Profile: Shaper- und LLQ-Budgets müssen auf Backup-Pfaden ebenfalls gelten.
Policer und Priority Queue: Warum harte Drops oft die falsche Stelle treffen
Policer werden häufig eingesetzt, um Realtime zu begrenzen. Das ist grundsätzlich sinnvoll, aber die Nebenwirkung ist kritisch: Policer-Drops in der Priority Queue sind für Nutzer sofort hörbar. Wenn Sie Policers als Starvation-Schutz einsetzen, sollten Sie sorgfältig entscheiden, wo sie sitzen und wie sie reagieren. Für viele Designs ist „degrade statt drop“ besser: Überschreitungen werden in eine niedrigere Klasse ummarkiert, sodass sie nicht die Priority Queue füllen, aber auch nicht als harte Drops in der Realtime-Klasse auftreten. Wo harte Drops notwendig sind (Missbrauch, klare SLA-Grenzen), müssen die Budgets realistisch und mit Overhead kalkuliert sein.
- Degradation: Überschreitungen ummarkieren, damit die Priority Queue geschützt ist.
- Drop nur mit Bedacht: harte Drops verursachen sofort QoE-Probleme bei Voice/Video.
- Overhead einrechnen: Tunnel-/Header-Overhead kann Policers „zu eng“ wirken lassen.
Messbarkeit: Starvation früh erkennen, bevor Nutzer es melden
Starvation ist ein Betriebsproblem, das Sie messen müssen. Durchschnittsauslastung reicht nicht – wichtig sind queuebezogene KPIs: Queue-Delay, Queue-Depth, Drops pro Klasse und bei AQM/ECN die Mark-Raten. Für die Priority Queue sind zwei Dinge besonders relevant: Wie hoch ist die Auslastung (p95/p99) und treten Drops oder Policer-Events auf? Für die anderen Klassen ist Queue-Delay der Frühindikator: Wenn Best Effort und Business plötzlich hohe Delay-Perzentile sehen, ist die Wahrscheinlichkeit hoch, dass die Priority Queue zu groß ist oder dass Congestion außerhalb Ihrer Kontrolle liegt.
- Priority Utilization p95/p99: zeigt, ob die LLQ am Limit läuft oder dauerhaft gefüllt ist.
- Class Drops: Drops in Nicht-Realtime-Klassen plus hohe Priority-Auslastung sind ein Starvation-Signal.
- Queue-Delay p95/p99: Bufferbloat und Starvation werden hier sichtbar, bevor TCP kollabiert.
- Marking Distribution: plötzlicher Anstieg von EF/Realtime deutet auf Missmarking hin.
Typische Failure Patterns und schnelle Gegenmaßnahmen
In der Praxis wiederholen sich Starvation-Probleme. Das macht sie gut beherrschbar, wenn Sie strukturiert vorgehen: zuerst Marking-Quelle kontrollieren, dann LLQ-Limit prüfen, dann Queue-Limits/AQM und Shaping-Placement, und erst danach an Gewichten „herumdrehen“. Viele Teams verlieren Zeit, weil sie nur an Gewichten arbeiten, während die echte Ursache Missmarking oder fehlendes Shaping ist.
- „Alles ist EF“: Trust Boundary fehlt; sofort Allowlist/Remarking einführen.
- Priority dauerhaft am Limit: LLQ zu groß oder Realtime-Budget zu knapp; Limits anhand realer Peaks neu dimensionieren.
- Andere Klassen haben hohe RTT/Jitter: Bufferbloat; Queue-Limits reduzieren, AQM/ECN aktivieren.
- Probleme nur bei Upload/Peak: Shaping fehlt; Congestion liegt beim Provider/CPE.
- Failover bricht alles: Backup-Pfad ohne Headroom oder ohne QoS-Templates; Failover-Tests unter Mischlast.
Blueprint: Priority Queues im Carrier- und Enterprise-Betrieb sicher einsetzen
Ein robustes Vorgehen beginnt mit einem schlanken Klassenmodell: Realtime (Voice), Video/Interactive, Business, Best Effort, Bulk plus Network Control. Danach legen Sie Trust Boundaries fest: Welche Quellen dürfen Realtime markieren, welche DSCP-Werte sind erlaubt, und wie werden Missmarkings normalisiert? Anschließend konfigurieren Sie die Priority Queue als LLQ mit strikter Obergrenze, dimensioniert nach Busy Hour plus Overhead und Failover-Headroom. Video bleibt in einer gewichteten Echtzeitklasse, nicht in der LLQ. Best Effort erhält AQM/ECN und passende Queue-Limits gegen Bufferbloat. Shaping wird an den echten Engpässen platziert, damit Congestion kontrollierbar und messbar ist, und HQoS wird genutzt, um Noisy Neighbors zu verhindern. Abschließend etablieren Sie Telemetrie: Priority-Auslastung p95/p99, Queue-Delay/Drops pro Klasse, Marking-Verteilungen und Policer-/Remarking-Zähler. So setzen Sie Priority Queues richtig ein – und verhindern Starvation nicht durch Glück, sondern durch kontrollierte Budgets, klare Grenzen und messbare Betriebssicherheit.
