WRED und Congestion Avoidance sind im Telco- und Provider-Netz oft der fehlende Baustein, wenn Video-Traffic zwar „priorisiert“ ist, aber trotzdem bei Lastspitzen ruckelt, Freezes zeigt oder in der Qualität pendelt. Der Grund ist simpel: Viele QoS-Designs kümmern sich vor allem um Klassifizierung und Scheduling (EF/AF, LLQ, CBWFQ), aber nicht darum, wie Queues bei Annäherung an Congestion reagieren. Ohne Congestion Avoidance droppen Warteschlangen häufig „Tail Drop“: Die Queue läuft voll, und dann werden Pakete am Ende abrupt verworfen. Für Video ist das besonders schädlich, weil Tail Drop zu Drop-Clustern führt – also mehreren verlorenen Paketen hintereinander. Interaktives Video (UC/WebRTC) reagiert darauf mit sichtbaren Aussetzern und aggressivem Bitrate-Downshift. Streaming (TCP) reagiert mit Retransmits, Buffering und instabilen Throughput-Fenstern. WRED (Weighted Random Early Detection) setzt genau hier an: Es beginnt frühzeitig und gewichtet Pakete zu verwerfen, bevor die Queue komplett voll ist, und steuert so die Stauentwicklung intelligenter. Dieser Artikel erklärt WRED und Congestion Avoidance verständlich, zeigt, wie Sie Video-Traffic in AF-Klassen sinnvoll behandeln, welche Parameter wirklich zählen und welche typischen Fehler in Metro, IP/MPLS-Core, EVPN/VXLAN-Fabrics und Telco Clouds vermieden werden sollten.
Warum Tail Drop Video so stark schadet
Tail Drop ist das Standardverhalten vieler Queues: Solange Platz im Puffer ist, werden Pakete aufgenommen. Ist die Queue voll, werden neue Pakete verworfen. Das klingt logisch, ist aber aus QoE-Sicht problematisch – insbesondere für Video.
- Drop-Cluster: Bei Tail Drop entstehen oft kurze Phasen mit vielen Verlusten, weil die Queue am Limit „klebt“.
- Synchronisierte Retransmits: Bei TCP-Video (Streaming) führen Drops zu gleichzeitigen Retransmits vieler Flows – das erzeugt neue Bursts und verstärkt Congestion.
- Qualitäts-Pendeln: Bei interaktiven Plattformen werden Bitrate/Framerate schnell reduziert, dann wieder erhöht – das wirkt „unruhig“.
- Mehr Jitter: Eine Queue, die bis zum Anschlag gefüllt ist, erzeugt große und stark schwankende Queueing Delays.
Das Ergebnis ist paradox: Ein Netz kann „viel Bandbreite“ haben und trotzdem eine schlechte Videoerfahrung liefern, weil Tail Drop Bursts in sichtbare Störungen übersetzt.
Congestion Avoidance: Was dahinter steckt
Congestion Avoidance bezeichnet Mechanismen, die Congestion früher und sanfter adressieren, bevor eine Queue vollständig überläuft. Statt abrupt am Ende zu droppen, werden Pakete mit einer steigenden Wahrscheinlichkeit verworfen, sobald die Queue eine definierte Füllhöhe erreicht. Ziel ist:
- Queues kürzer halten: weniger Bufferbloat, geringere Latenz und weniger Jitter.
- Verluste „entclustern“: lieber wenige, verteilte Drops als viele Drops am Stück.
- TCP zu früher Anpassung bewegen: Flows reduzieren ihre Sendrate rechtzeitig, bevor es zum Kollaps kommt.
WRED ist die bekannteste Congestion-Avoidance-Variante in Provider-Netzen, weil sie gewichtet pro Klasse und pro Drop Precedence arbeiten kann.
RED vs. WRED: Der Unterschied in einem Satz
- RED (Random Early Detection): frühes, zufälliges Droppen basierend auf der Queue-Füllung – ohne Differenzierung nach Klassen/Markierungen.
- WRED (Weighted RED): wie RED, aber mit Gewichtung nach Klassen, DSCP oder AF Drop Precedence (x1/x2/x3) – und damit für DiffServ-Designs geeignet.
Im Telco-Kontext ist WRED meist die relevante Variante, weil Provider ohnehin mit Klassenmodellen (EF/AF/BE) arbeiten und innerhalb von AF oft Drop Precedences nutzen.
Wie WRED funktioniert: intuitiv erklärt
WRED betrachtet typischerweise einen geglätteten Queue-Füllstand (Average Queue Size) statt nur den aktuellen Momentwert. Dann werden zwei Schwellen definiert:
- Min Threshold: ab dieser Füllhöhe beginnt WRED, Pakete mit geringer Wahrscheinlichkeit zu droppen.
- Max Threshold: ab dieser Füllhöhe steigt die Drop-Wahrscheinlichkeit bis zum Maximalwert an.
- Max Drop Probability: maximale Drop-Wahrscheinlichkeit, wenn die Queue sehr voll ist (aber noch nicht voll).
Zwischen Min und Max Threshold steigt die Drop-Wahrscheinlichkeit graduell an. Damit „signalisiert“ die Queue Stau frühzeitig und verhindert, dass sie dauerhaft am Limit klebt.
Warum WRED besonders gut zu AF-Klassen passt
Assured Forwarding (AF) ist für Verkehr gedacht, der bevorzugt, aber nicht strikt priorisiert wird – typisch für Video. AF hat zusätzlich die Idee der Drop Precedence: innerhalb einer AF-Klasse kann Überschussverkehr höher droppable markiert werden. Genau hier spielt WRED seine Stärke aus:
- In-Profile Video (z. B. AFx1) wird bei Congestion später und weniger stark gedroppt.
- Out-of-Profile Video (z. B. AFx2/AFx3) wird früher und stärker gedroppt.
- Ergebnis: Die Kernqualität bleibt stabil, Überschuss wird kontrolliert abgeschnitten.
So können Sie Bursts tolerieren, ohne dass sie die gesamte Videoklasse zerstören.
WRED und Video-Typen: Interaktiv, IPTV, Streaming
Ob WRED sinnvoll ist, hängt stark vom Videotyp und dem Transportprotokoll ab.
Interaktives Video (UC/WebRTC)
- Pro: WRED kann Drop-Cluster reduzieren und Jitterwellen vermeiden, wenn die Video-Queue sonst in Tail Drop läuft.
- Contra: Zu aggressives WRED kann unnötige Drops erzeugen, die bei interaktivem Video sofort sichtbar werden.
Für interaktives Video ist WRED meist dann sinnvoll, wenn die Alternative Tail Drop bei Peaks ist – und wenn Sie WRED „mild“ konfigurieren, mit klarer Priorisierung von In-Profile gegenüber Out-of-Profile.
IPTV/Managed Video (UDP, oft Multicast)
- Pro: WRED kann Überschuss oder weniger wichtige Streams früher droppen, um Kernstreams zu schützen.
- Contra: IPTV reagiert extrem empfindlich auf Verlust; jede zusätzliche Drop-Wahrscheinlichkeit muss sehr vorsichtig dimensioniert werden.
Für IPTV ist häufig eine sehr verlustarme Behandlung entscheidend. Wenn WRED genutzt wird, dann vor allem, um klar markierten Überschuss (höhere Drop Precedence) abzuschneiden – nicht, um „normale“ IPTV-Pakete früh zu droppen.
Streaming über TCP (HLS/DASH)
- Pro: WRED ist besonders effektiv, weil TCP auf Drops reagiert und seine Rate senkt; dadurch kann Congestion stabiler werden.
- Contra: Zu aggressive Drops führen zu Retransmits und Buffering; WRED muss so eingestellt sein, dass es Congestion vermeidet, ohne die QoE zu ruinieren.
Für TCP-Streaming ist WRED oft ein sehr guter Congestion-Avoidance-Mechanismus, weil es den „global synchronization“-Effekt vieler gleichzeitiger TCP-Flows reduziert.
WRED im Telco-Design: Wo es am meisten bringt
WRED entfaltet seinen Nutzen an Engpässen, an denen viele Flows zusammenlaufen und Tail Drop typischerweise Drop-Cluster erzeugt. Typische Orte im Provider-Netz:
- Metro-Aggregation Uplinks: Microbursts und Oversubscription; WRED kann Tail-Drop-Spitzen entschärfen.
- Interconnects/Peering: rate-limitierte Übergänge; WRED hilft, Congestion dynamischer abzufangen.
- Provider Edge bei Business-Video: wenn Video in AF-Klassen profiliert ist und Überschuss getrennt markiert wird.
- EVPN/VXLAN Border Leafs: viele East-West-Quellen treffen auf wenige Uplinks; WRED kann Drop-Cluster reduzieren, wenn Hardware es unterstützt.
Wichtig: WRED ersetzt kein Shaping und kein sauberes Scheduling. Es ist ein Ergänzungsmechanismus, der das Drop-Verhalten intelligenter macht.
WRED und Scheduler: Warum die Kombination zählt
WRED arbeitet in einer Queue – aber wie diese Queue bedient wird, bestimmt der Scheduler. Für Video gilt fast immer: gewichtete Bedienung statt strict priority. Ein typisches Telco-Muster ist:
- Voice (EF): LLQ/Low Latency Queue, strict priority mit Limit, meist ohne WRED (Echtzeit soll nicht „früh gedroppt“ werden).
- Video (AF): CBWFQ/WFQ-Queue mit garantierten Anteilen, WRED zur Congestion Avoidance, Drop Precedence zur Differenzierung.
- Best Effort: fair, oft ebenfalls mit Early Drop, um Bufferbloat zu reduzieren.
So bleibt Voice maximal geschützt, Video wird stabilisiert, und Best Effort wird vor Queue-Kollaps bewahrt.
WRED-Parameter praxisnah interpretieren
In der Praxis sind die exakten Parameter plattformspezifisch. Entscheidend ist die Logik:
- Min Threshold zu niedrig: WRED dropt zu früh, Videoqualität sinkt unnötig.
- Min Threshold zu hoch: WRED greift erst, wenn die Queue bereits sehr voll ist – Tail-Drop-Cluster bleiben.
- Max Threshold zu hoch: Queue wird sehr groß, Bufferbloat und Jitter steigen.
- Drop Probability zu aggressiv: QoE leidet durch übermäßige Drops.
- Drop Probability zu niedrig: Congestion wird nicht effektiv vermieden, Tail Drop bleibt dominant.
Ein bewährtes Vorgehen ist, WRED für Video „mild“ zu starten und die Wirkung anhand von Queue-Depth, Drops pro Klasse und Video-QoE (Freeze-Events, Bitrate-Switches) zu tunen.
AF Drop Precedence und WRED: Video-Überschuss sauber schneiden
Wenn Sie Video in AF-Klassen fahren, ist Drop Precedence Ihr wichtigster Hebel, um WRED gezielt arbeiten zu lassen. Ein praxistaugliches Muster:
- AFx1: In-Profile Video, am besten geschützt, WRED beginnt später und droppt weniger.
- AFx2: moderater Überschuss, WRED beginnt früher.
- AFx3: klarer Überschuss/out-of-profile, wird zuerst gedroppt.
So bleibt die Basiserfahrung stabil, während Bursts oder Übernutzung kontrolliert zurückgeschnitten werden. Das ist besonders wertvoll in Aggregationsnetzen, in denen Video-Bitratenschwankungen normal sind.
Shaping vs. WRED: Was macht was?
WRED wird oft als „Alternative“ zu Shaping missverstanden. In Wirklichkeit adressieren beide unterschiedliche Aspekte:
- Shaping: glättet den Verkehr am Egress, reduziert Microbursts, verhindert Downstream-Policer-Drops.
- WRED: steuert das Drop-Verhalten in der Queue, vermeidet Tail Drop und globale TCP-Synchronisation.
Für Video ist die Kombination häufig am stärksten: Shaping reduziert Burst-Spitzen, WRED verhindert, dass Rest-Congestion in Drop-Cluster umschlägt.
WRED richtig einsetzen: typische Designregeln für Video
- Voice nicht mit WRED „optimieren“: Echtzeit-Audio soll nicht früh gedroppt werden; Voice in LLQ mit Limit.
- Video in AF-Klasse mit Gewichten: garantierte Ressourcen statt strict priority.
- Drop Precedence aktiv nutzen: In-Profile (x1) schützen, Überschuss (x2/x3) früher droppen.
- WRED mild starten: zu aggressives Early Drop verschlechtert QoE schneller als Tail Drop in leichten Lastsituationen.
- Queue-Limits kontrollieren: Bufferbloat vermeiden; WRED ersetzt keine sinnvollen Queue-Limits.
- Shaping an Engpässen ergänzen: besonders an rate-limitierten Links und Interconnects.
So erreichen Sie das typische Ziel: weniger ruckelnde Video-Phasen bei Lastspitzen, ohne das Netz durch übergroße Puffer oder unkontrollierte Prioritäten zu destabilisieren.
Häufige Fehler bei WRED im Provider-Netz
- WRED in der falschen Klasse: z. B. auf Voice/EF – führt zu unnötigen Drops und hörbaren Aussetzern.
- Keine Drop Precedence: WRED kann nicht differenzieren, In-Profile und Out-of-Profile werden gleich behandelt.
- Zu aggressive Schwellen: Video wird „kaputtoptimiert“, weil Early Drop zu früh greift.
- Zu große Queues trotz WRED: Bufferbloat bleibt, Jitter steigt, QoE sinkt.
- Nur Linkauslastung überwachen: Microbursts, Queue-Depth und Drops pro Klasse bleiben unsichtbar.
Monitoring: Wie Sie WRED-Erfolg bei Video nachweisen
WRED ist kein „Checkbox-Feature“. Sie sollten messen, ob es Drop-Cluster reduziert und Queueing Delay stabilisiert. Sinnvolle KPIs sind:
- Queue-Depth/Queueing Delay: sinkt die durchschnittliche und die Spitzen-Queue-Tiefe?
- Drops pro Klasse: werden Drops gleichmäßiger verteilt, statt in Clustern zu kommen?
- WRED-Drop-Zähler: wie viele Drops stammen aus Early Drop vs. Tail Drop?
- Policer-Hits/Remarking: läuft Video regelmäßig out-of-profile und wird korrekt auf x2/x3 gesetzt?
- Video-QoE: weniger Freeze-Events, weniger harte Bitrate-Pendler, stabilere Framerate (bei UC/Analytics).
Wenn Video trotz WRED ruckelt, ist die Ursache oft nicht WRED selbst, sondern fehlendes Shaping an einem Rate-Limit oder falsches Scheduling (zu wenig Gewicht für Video).
Häufige Fragen zu WRED und Video-Traffic
Ist WRED immer gut für Video?
Nein. WRED ist ein Werkzeug gegen Tail-Drop-Cluster und TCP-Synchronisation. Es hilft besonders bei aggregiertem, burstigem Verkehr. Wenn Ihre Video-Queue ohnehin selten in Congestion läuft, kann WRED unnötige Drops erzeugen, wenn es zu aggressiv eingestellt ist. Daher: mild starten, messen, dann tunen.
Sollte ich WRED für interaktives Video und Streaming gleich konfigurieren?
In der Regel nicht. Interaktives Video reagiert sensibel auf zusätzliche Drops; Streaming reagiert stärker auf Throughput-Schwankungen und TCP-Effekte. Häufig braucht interaktives Video eine sanftere Early-Drop-Charakteristik und ausreichende garantierte Anteile, während Streaming stärker von stabiler Congestion Avoidance profitieren kann.
Was ist der wichtigste Erfolgsfaktor für „intelligenteres“ Video unter Last?
Eine saubere AF-Klasse mit gewichteter Bedienung, klare Drop Precedences für In-Profile vs. Überschuss und eine Congestion-Avoidance-Strategie (WRED), die Drop-Cluster reduziert. Ergänzt durch Shaping an echten Engpässen entsteht so ein Video-Verhalten, das unter Last stabil bleibt, statt abrupt zu kippen.
