Congestion Domains designen: Wo Bandbreite knapp wird, dort QoS

Congestion Domains designen ist eine der wirkungsvollsten Methoden, um QoS nicht überall „ein bisschen“ zu konfigurieren, sondern genau dort scharf zu machen, wo es wirklich zählt: an den Stellen, an denen Bandbreite knapp wird und Warteschlangen (Queues) entstehen. In vielen Netzen wird QoS flächendeckend ausgerollt, aber ohne klares Engpassmodell. Das führt zu zwei Problemen: Erstens wird Betrieb unnötig komplex (viele Policies, viele Mappings, viele Varianten). Zweitens werden die echten Echtzeitprobleme trotzdem nicht verhindert, weil der entscheidende Engpass an einer Stelle liegt, an der gar keine kontrollierte Queue existiert – zum Beispiel im Provider-Access, im Modem/CPE, in einer Firewall mit DPI, in einem WLAN-Funkmedium oder in einem virtuellen vSwitch. Ein Congestion Domain Ansatz dreht die Perspektive um: Sie identifizieren die wenigen Segmente, in denen Congestion realistisch auftreten kann, schaffen dort kontrolliertes Queueing (inklusive Shaping), und messen diese Stellen so, dass Sie Degradation früh erkennen und beweisen können. Dieser Artikel erklärt, was Congestion Domains sind, wie Sie sie in Enterprise- und Telco-Umgebungen modellieren, wie Sie QoS gezielt platzieren und welche Mess- und Designregeln dafür sorgen, dass Echtzeitdienste (Voice, Video, WebRTC, IPTV, 5G-User-Plane) stabil bleiben.

Was ist eine Congestion Domain?

Eine Congestion Domain ist ein Netzwerkbereich, in dem mehrere Trafficströme um dieselbe begrenzte Ressource konkurrieren und dadurch Warteschlangen entstehen können. Die Ressource kann ein physischer Link sein (z. B. WAN-Uplink), ein logischer Link (Tunnel, VRF), ein Funkmedium (WLAN/5G), eine Software-Pipeline (Firewall/DPI) oder eine Compute-Ressource (vSwitch/CPU). Innerhalb einer Congestion Domain ist QoS sinnvoll, weil es dort überhaupt etwas zu „priorisieren“ gibt. Außerhalb – wo Links massiv überdimensioniert sind und keine Queues entstehen – ist QoS oft nur administrativer Ballast.

• Engpass-Ressource: Linkrate, Airtime, CPU, Buffer-Pool oder Provider-Limit.
• Konkurrierende Flows: mehrere Anwendungen teilen sich dieselbe Ressource.
• Queueing-Entstehung: mehr Angebot als Abtransportkapazität im relevanten Zeitfenster.
• Messbarkeit: Queue Depth/Delay und Per-Class Drops sind dort aussagekräftig.

Warum QoS ohne Congestion Domain Modell oft ins Leere läuft

QoS setzt an Queueing an. Wenn Congestion an einer Stelle entsteht, die nicht in Ihrer Kontrolle liegt, greift Ihre Policy nur eingeschränkt oder gar nicht. Ein typischer Fall: Ein Router hat perfekte Klassen und LLQ, aber der Upstream ist ein Internetanschluss, dessen Modem oder Provider-Access puffert und droppt. Dann sehen Sie im Router kaum Queueing, trotzdem leiden Voice/Video. Genau deshalb ist Congestion Domain Design auch ein „Ownership“-Thema: Wo endet Ihre Kontrolle, wo beginnt die des Providers, und wie holen Sie Congestion durch Shaping zurück in Ihren kontrollierten Bereich?

• Unkontrollierte Buffers: CPE/Modem/Provider puffert, nicht Ihr QoS-Scheduler.
• Fehlende Shaper: ohne Shaping entstehen Queues dort, wo Sie sie nicht sehen und nicht steuern können.
• Falsche Prioritäten: QoS wird im Core optimiert, obwohl der Engpass am Edge liegt.
• Zu viel Komplexität: QoS überall erhöht Fehlkonfigurationsrisiko und Drift.

Schritt 1: Engpässe finden – wo Bandbreite knapp wird

Der erste Schritt ist nicht „Klassen definieren“, sondern Engpässe identifizieren. Engpässe sind selten überall. In den meisten Netzen sind es wenige Hotspots: Standort-Uplinks, Internet-Breakouts, VPN-Gateways, WLAN-Funkzellen, Aggregationslinks mit Oversubscription, Interconnects zu Cloud/Partnern oder Service-Chains über Security. Sie können Engpässe aus Topologie, Kapazitätsplanung und Telemetry ableiten. Besonders hilfreich sind Zeitreihen von Queue Depth/Delay, Per-Class Drops und Shaper-Headroom, weil sie Congestion sichtbar machen, auch wenn die durchschnittliche Auslastung moderat ist.

• WAN/Internet-Uplinks: typischer Engpass Nummer 1, oft asymmetrisch (Upload knapper).
• Aggregation/Access-Uplinks: Oversubscription, viele Clients/Ports auf weniger Uplink-Kapazität.
• WLAN Airtime: geteiltes Medium; Congestion ist Airtime, nicht Mbit/s.
• Security/Service Chaining: DPI/Decryption/IPS kann zum Processing-Engpass werden.
• Virtualisierte Datenpfade: vSwitch/CPU Scheduling erzeugt Queueing ohne Linküberlast.
• Interconnects: Peering/Transit und regionale Cloud-Edges mit variabler Performance.

Schritt 2: Congestion Domains abgrenzen – klein genug, um kontrollierbar zu sein

Eine Congestion Domain sollte so geschnitten sein, dass Sie sie operativ kontrollieren und messen können. In der Praxis heißt das: Eine Domain endet dort, wo Sie die Ressource nicht mehr steuern können oder wo ein anderer Scheduler übernimmt. Typischerweise schneiden Sie Domains um Engpässe herum: „Standort-Uplink egress“, „Firewall-DPI Pipeline“, „WLAN-AP/SSID“, „SD-WAN-Tunnel-Underlay“, „DC-Edge Link“. Je klarer die Domain, desto leichter können Sie Ursachen zuordnen und Policies standardisieren.

• Domain pro Engpass: ein Uplink oder ein klarer Bottleneck, nicht ein ganzer Campus.
• Egress-Fokus: Congestion entsteht meist beim Senden; Domain-Definition orientiert sich an Egress-Interfaces.
• Ownership-Kante: Übergabe an Provider/Cloud/Partner ist oft Domain-Grenze.
• Messpunkt-Fähigkeit: Domain ohne Telemetry/Queue-Stats ist schwer zu betreiben.

Schritt 3: QoS gezielt platzieren – dort, wo Queueing kontrolliert werden kann

QoS ist am wirksamsten dort, wo Sie die Warteschlangen kontrollieren: an Routern/Switches mit klaren Queues, an WAN-Edges mit Shaping, an Fabric-Edges, an WLAN-Controllers/SSIDs oder an vSwitch-/Host-Policies, wenn Compute-Queueing relevant ist. Das Ziel ist nicht, überall Prioritäten einzubauen, sondern an jeder Congestion Domain ein konsistentes „QoS-Kit“ bereitzustellen: Klassifizierung, Queue-Mapping, Scheduling und Messbarkeit.

• WAN-Edge: Shaping + Klassen (Voice/Media/Control/BE/Bulk) als Standard.
• Aggregation: Queue-Profile auf Uplinks, um Echtzeit vor lokalen Peaks zu schützen.
• WLAN: WMM und Airtime-fokussierte Policies als Funk-QoS.
• Security: wenn im Pfad, dann QoS-aware oder selektiv, damit Echtzeit nicht in Slow Paths staut.
• Virtualisierung: CPU/Queue-Guardrails, wenn VNFs/CNFs Echtzeit tragen.

Der wichtigste Hebel in Congestion Domains: Shaping holt Congestion „zurück“

Shaping ist das Werkzeug, mit dem Sie Congestion an eine Stelle bringen, an der Ihr Scheduler sie kontrollieren kann. Ohne Shaping findet Congestion oft hinter Ihrem Gerät statt (Provider-Access, Modem), und QoS wird zur Theorie. Mit Shaping knapp unter Realrate stellen Sie sicher, dass Queueing in Ihren Queues stattfindet und Sie per Klasse priorisieren können. Für Echtzeit ist das essenziell, weil kontrolliertes Queueing Delay und Loss reduziert und vor allem kalkulierbar macht.

• Realrate statt Vertragsrate: Shaper muss die tatsächlich nutzbare Rate abbilden.
• Overhead berücksichtigen: VLAN/PPPoE/Tunnel reduzieren Nutzrate; Shaper muss darunter liegen.
• Hierarchisches QoS: Gesamtshaper + Klassenlimits für Isolation und Fairness.
• Bulk in Grenzen: Bulk/Updates dürfen Congestion erzeugen, aber nicht in Echtzeitklassen.

Klassenmodell pro Domain: Nicht jedes Segment braucht die gleiche Granularität

Ein Congestion Domain Ansatz bedeutet auch: Klassenmodell pragmatisch anpassen. Am WAN-Edge brauchen Sie meist mehr Granularität (Voice vs. Media vs. Bulk), weil dort echte Konkurrenz herrscht. Im Core kann ein einfacher Transit-Satz reichen, wenn dort keine Engpässe entstehen. Im WLAN ist die Abbildung über WMM-Kategorien oft ausreichend, während in Telco-Transportnetzen ein DSCP/MPLS-TC-Modell mit wenigen Klassen dominierend ist. Wichtig ist Konsistenz der Semantik, nicht zwingend identische Queue-Anzahlen.

• Edge-Granularität: mehr Klassen dort, wo Konkurrenz am stärksten ist.
• Transit-Simplifizierung: im überdimensionierten Core eher Mapping-Konsistenz als komplexe Policies.
• Funk-/Compute-Domänen: eigene Mechaniken (Airtime, CPU Scheduling) erfordern spezifische Metriken und Guardrails.

Messung in Congestion Domains: Queue Delay/Depth und Per-Class Drops als Primärsignale

Congestion Domains sind nur dann nützlich, wenn Sie sie messen können. Für QoS sind Queue Delay und Queue Depth die besten Frühindikatoren: Sie zeigen Stau, bevor Drops auftreten. Per-Class Drops liefern den harten Beweis, ob Echtzeitpakete betroffen sind. Drop Reasons erklären das „Warum“: Tail Drop (Queue voll), Policer Drop (Rate-Limit), Buffer Exhaustion (Microbursts/Plattform), Policy Drop (Filter). Diese Metriken sollten pro Domain standardisiert erhoben werden, damit NOC-Teams schnell von einem Symptom zu einer konkreten Engpassstelle kommen.

• Queue Delay 95p/99p: zeigt Peaks, die Echtzeit zerstören, auch wenn Mittelwerte gut sind.
• Peak Queue Depth: macht Microbursts sichtbar.
• Per-Class Drops: Voice/Media Drops sind Incident-Signal; BE/Bulk Drops sind Kontext.
• Drop Reasons: beschleunigen Root Cause (Congestion vs. Policer vs. Ressourcenlimit).
• Shaper Headroom: zeigt, ob eine Domain dauerhaft am Limit läuft.

Typische Congestion Domains in Enterprise-Netzen

In Enterprise-Topologien lassen sich häufig wiederkehrende Congestion Domains identifizieren, die den Großteil der Echtzeitprobleme erklären. Wenn Sie diese Domains als Standard in Design und Monitoring aufnehmen, wird QoS deutlich wirksamer und Betrieb planbarer.

• Site WAN Egress: Internet/MPLS/SD-WAN Uplinks, oft mit asymmetrischem Upstream.
• VPN/Remote Access Gateway: viele Nutzer teilen Crypto- und Linkressourcen; CPU und Queueing relevant.
• WLAN Zellen/SSIDs: Airtime und Retries als Congestion-Indikatoren, nicht nur Mbit/s.
• Campus Aggregation Uplinks: viele Access-Switches auf wenige Uplinks; Peak-Spikes bei Meeting-Starts.
• Internet Edge + Security Stack: DPI/Decryption kann als Processing-Engpass wirken.

Typische Congestion Domains in Telco- und Service-Provider-Netzen

Im Telco-Umfeld verschieben sich die Engpässe, aber das Prinzip bleibt: QoS dort, wo konkurrierende Flows eine begrenzte Ressource teilen. Besonders relevant sind Access-Aggregationen, User-Plane-Edges, Interconnects und virtualisierte Core-Funktionen.

• RAN Backhaul/Midhaul: viele Sites teilen Metro-Kapazität; Microbursts sind häufig.
• UPF/Edge Cloud: PPS- und CPU-Limits, vSwitch Queues und Service Chains.
• Interconnect/Peering: regionale Engpässe und Policy-Unterschiede; DSCP-Realität beachten.
• IMS/Voice-Edges: SBCs und Media-Anker als kritische Engpasspunkte, oft PPS-limitierend.

Designregeln: So bauen Sie Congestion Domains „qos-fähig“

• Engpass zuerst, Policy danach: QoS ohne Engpassmodell ist Zufall; zuerst Domains identifizieren.
• Shaping als Standard an Uplinks: Congestion in kontrollierte Queues holen, Realrate berücksichtigen.
• Klassen begrenzen: Premium-/Echtzeitklassen klein und geschützt, aber nicht unendlich (Starvation vermeiden).
• Bulk bewusst isolieren: Updates/Backups in BULK-Klasse mit Limits, um Peaks zu entschärfen.
• Trust Boundary klar: Markierungen nur von vertrauenswürdigen Quellen übernehmen; Rest normalisieren.
• Beobachtbarkeit verpflichtend: pro Domain Queue Delay/Depth, Per-Class Drops, Drop Reasons und Headroom erfassen.
• Regression und Canary: Änderungen erst in kleinen Domains testen und progressiv ausrollen, bevor Kundenimpact entsteht.

Praktischer Ablauf: Congestion Domains in bestehende Netze einführen

• Inventarisieren: Topologie und potenzielle Engpässe markieren (Uplinks, Aggregation, Security, WLAN, VPN).
• Messen: erste Telemetry auf Queue Delay/Depth und Drops aktivieren, um Hotspots zu bestätigen.
• Domänen schneiden: pro Engpass eine Domain definieren, inklusive Ownership und Messpunkten.
• QoS-Kit ausrollen: Shaping + Klassen + Mapping + Guardrails an Domain-Grenzen implementieren.
• Dashboards/Alerts: High-Signal Panels pro Domain (Delay 99p, Voice Drops, Drop Reasons).
• Rezertifizieren: regelmäßige Regression Tests, besonders nach Provider-, Security- oder SD-WAN-Changes.