Site icon BintoroSoft PDF Tools

Congestion Domains designen: Wo Bandbreite knapp wird, dort QoS

Red Snapper

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

Praktischer Ablauf: Congestion Domains in bestehende Netze einführen

Exit mobile version