QoS für Videokonferenzen ist in der Praxis weniger eine Frage von „mehr Priorität“, sondern von Burst-Verhalten und realistischen Bandbreitenprofilen. Genau hier scheitern viele Designs: Teams, Zoom, WebRTC oder andere Videokonferenzlösungen laufen im Leerlauf scheinbar stabil, kippen aber bei Peak-Last – etwa beim Screen Sharing, beim Wechsel von Sprecheransicht zu Galerie, beim Ein- und Aussteigen mehrerer Teilnehmer oder wenn ein Standort gleichzeitig Upload-Last erzeugt. Die Nutzer sehen dann typische Symptome: Video wird pixelig, friert kurz ein, Audio klingt verzerrt, die Qualität pendelt ständig oder der Client schaltet aggressiv auf eine niedrigere Auflösung. Ursache ist selten „zu wenig Durchschnittsbandbreite“, sondern fast immer instabile Durchsatzfenster durch Microbursts, Bufferbloat und Drop-Cluster – oft kombiniert mit zu harten Policern oder fehlendem Shaping an rate-limitierten Links. Ein professionelles QoS-Design für Videokonferenzen trennt Audio und Video, priorisiert korrekt ohne Premium-Inflation, glättet Bursts durch Shaping, dimensioniert Profile pro Standort und pro Klasse (Audio, Video, Content) und überwacht Klassenmetriken (Queue-Drops, Queueing Delay, Policer-Hits) statt nur Linkauslastung. Dieser Artikel erklärt praxisnah, wie Burst-Verhalten entsteht, wie Sie Bandbreitenprofile für Videokonferenzen planen und welche QoS-Mechanismen in Access, Metro und Core wirklich helfen.
Warum Videokonferenzen so „burstig“ sind
Videokonferenzen wirken wie kontinuierlicher Traffic, sind aber technisch stark variabel. Selbst wenn ein Call „konstant“ erscheint, entstehen kurzzeitig sehr hohe Sendespitzen. Typische Ursachen:
- Variable Bitrate: Encoder passen Bitrate an Szenenkomplexität an (Bewegung, Detail, Lichtwechsel).
- Keyframes/I-Frames: regelmäßig oder bei Szenenwechseln werden größere Frames gesendet, die Bursts erzeugen.
- Layout-Wechsel: Galerieansicht, Sprecherwechsel oder neue Teilnehmer verändern die Anzahl/Qualität der Streams.
- Screen Sharing: Content-Streams sind bursty, weil Text/Bewegung anders kodiert wird als Kamera-Video.
- Adaptation und Recovery: nach kurzer Congestion versucht der Client wieder hochzuskalieren – das erzeugt neue Peaks.
Diese Burstigkeit ist der Kern, warum harte Policer und unkontrollierte Puffer besonders schädlich sind: Sie erzeugen Drop-Cluster und Jitterwellen genau in den Momenten, in denen der Client ohnehin am Limit arbeitet.
Audio, Video und Content: Drei unterschiedliche QoS-Anforderungen
Videokonferenzen bestehen fast immer aus mehreren Medienkomponenten, die unterschiedliche QoS-Behandlung benötigen:
- Audio (RTP/SRTP): sehr jitter- und loss-sensibel, geringe Bandbreite. Hier wirkt LLQ/EF am stärksten.
- Kamera-Video: bandbreitenstark, variabel, sensibel gegenüber Drop-Clustern, aber nicht geeignet für strict priority.
- Content/Screen Share: häufig burstiger als Kamera-Video, für Meetings oft geschäftskritisch (Lesbarkeit), aber QoS-Ziel ist eher Stabilität als minimalste Latenz.
Ein häufiges Problem ist, alles „in eine Videoklasse“ zu legen. Besser ist eine saubere Trennung: Audio strikt, Video gewichtet, Content entweder in einer eigenen Klasse oder gemeinsam mit Video, aber mit klaren Budgets.
Die typischen QoE-Symptome und was sie im Netz bedeuten
Wenn Nutzer von „schlechter Videokonferenzqualität“ sprechen, lässt sich das meist auf wenige Netzmechanismen zurückführen:
- Pixelig / niedrige Auflösung: Durchsatz wird als instabil eingeschätzt, Client downshiftet Bitrate.
- Freeze / Standbild: Drop-Cluster oder starke Jitter-Spikes, Buffer läuft leer.
- Audio robotisch / knackt: Drops oder Jitter in Audio-Streams; oft durch Bufferbloat oder Policer-Drops.
- Qualität pendelt: ABR-Regelung reagiert auf wechselnde Bedingungen (Microbursts, Tail Drop, Retransmits bei TCP/QUIC-Anteilen).
Die entscheidende Erkenntnis: Viele dieser Effekte entstehen bei kurzen Congestion-Events. Deshalb helfen Durchschnittsmetriken wenig; Sie brauchen Burst- und Queue-Sicht.
Warum „mehr Priorität“ für Video schnell gefährlich wird
Video ist groß. Wenn Sie Video zu hoch priorisieren (z. B. in EF/LLQ oder in einer zu dominanten Queue), passiert Premium-Inflation: Die bevorzugte Klasse wird dauerhaft gefüllt und verdrängt andere Klassen. Das kann sogar Audio verschlechtern, wenn Ressourcen und Puffer falsch verteilt sind.
- Strict priority nur für Audio: Audio ist klein genug, um eine LLQ sicher zu betreiben – mit Limit.
- Video gewichtet: Video braucht garantierte Anteile, aber keine absolute Vorrangschaltung.
- Content separat bewerten: Screen Sharing kann wichtiger sein als Kamera-Video, aber bleibt bursty – daher ebenfalls gewichtet.
Das Ziel ist nicht „Video immer zuerst“, sondern „Video stabil genug, damit der Client nicht ständig downshiftet“.
Bandbreitenprofile: Was Sie wirklich dimensionieren müssen
Viele QoS-Profile scheitern, weil sie nur die durchschnittliche Video-Bitrate berücksichtigen. Für Videokonferenzen müssen Sie drei Ebenen betrachten:
- Baseline: typische Bitrate pro Teilnehmer/Stream im Normalbetrieb (abhängig von Auflösung, Framerate, Codec).
- Peak: kurzzeitige Spitzen durch Keyframes, Layoutwechsel, Recovery nach Congestion.
- Gleichzeitigkeit: wie viele parallele Calls/Streams pro Standort sind realistisch, besonders in Meetingräumen.
Ein robustes Profil hat daher nicht nur eine Rate, sondern auch Burst-Toleranz und einen Plan, wie Überschuss behandelt wird (Shaping/Remarking statt Drop-Cluster).
Der wichtigste Engpass in der Praxis: Access-Upstream
Für Videokonferenzen ist der Upstream oft kritischer als der Downstream, besonders bei Homeoffice, Filialen, kleinen Standorten und asymmetrischen Zugängen. Upload-Last erzeugt Bufferbloat, und Videokonferenz-Uploads konkurrieren mit Backups, Cloud-Sync, Updates.
- Bufferbloat: große CPE-Puffer lassen Latenz explodieren, Audio leidet sofort.
- Bursts treffen Rate-Limits: ohne Shaping werden Bursts hart gedroppt (Policer/Provider-Profile).
- Konferenz-Uploads sind variabel: Screen Share kann den Upstream plötzlich stark erhöhen.
Wenn Sie nur im Core QoS bauen, aber den Access-Upstream nicht shapen und nicht sauber klassifizieren, bleibt die Nutzererfahrung instabil.
Shaping ist das zentrale Burst-Werkzeug für Videokonferenzen
Shaping glättet Verkehr am Egress und verhindert, dass Microbursts in Drop-Cluster umschlagen. Für Videokonferenzen ist Shaping häufig der wichtigste QoS-Baustein – insbesondere an rate-limitierten Links und vor Downstream-Policern.
- Egress-Shaping am Standort: stabilisiert Upstream, reduziert Bufferbloat und Drop-Spitzen.
- Shaping pro Klasse: Audio bleibt in LLQ, Video/Content werden gepaced, Best Effort wird fair verteilt.
- Shaping statt harter Policer: Policer-Drops sind für Video sichtbar; Shaping ist QoE-freundlicher.
Wichtig: Shaping darf Audio nicht in große Puffer ziehen. Audio muss über LLQ/Low Latency aus dem Shaper schnell herauskommen.
Policing und Remarking: Überschuss kontrollieren, ohne Meetings zu „zerstören“
Policing ist im Provider- und Multi-Tenant-Umfeld notwendig, um Fairness zu sichern. Für Videokonferenzen gilt aber: Harte Drops sind oft schlimmer als eine kontrollierte Herabstufung.
- Audio nicht droppen: Audio-Budgets so dimensionieren, dass Policing praktisch nie greift.
- Video/Content remarken: Überschuss von einer bevorzugten Video-Klasse in Best Effort oder in höhere Drop-Precedence, statt sofort zu droppen.
- Burst-Toleranz einplanen: Profile müssen kurze Peaks zulassen, sonst entstehen Drop-Cluster bei Keyframes.
Ein gutes Profil ist nicht „hart“, sondern „vorhersehbar“: Kernqualität bleibt stabil, Überschuss degradiert kontrolliert.
Queueing und Scheduling: Gewichte, Limits und Buffer richtig setzen
Für Videokonferenzen hat sich ein Muster bewährt:
- Audio: LLQ/strict priority mit Limit, kleine Queue-Limits.
- Video: gewichtete Queue (CBWFQ/WFQ) mit garantierten Anteilen, moderaten Pufferlimits.
- Content: entweder eigene gewichtete Klasse oder zusammen mit Video, aber mit klarer Gewichtung.
- Best Effort: fair, kontrollierte Puffer gegen Bufferbloat.
Zu große Video-Queues erzeugen Jitterwellen und Latenzspitzen, die der Client als „instabil“ interpretiert. Zu kleine Video-Queues erzeugen Drops bei Bursts. Die Balance ist entscheidend.
DSCP, CoS und MPLS-TC: End-to-End Mapping ohne QoS-Löcher
Videokonferenzen laufen oft über mehrere Domänen: Ethernet-Access (802.1p CoS), IP/MPLS-Core (MPLS-TC/EXP), VPN/Tunnel (Outer-DSCP), IPv6 Dual-Stack. Wenn Markierungen nicht konsistent gemappt werden, wirkt QoS nur „teilweise“.
- DSCP-to-CoS: Video/Content müssen in Metro/Access in die richtige PCP-Klasse gemappt werden.
- DSCP-to-TC: im MPLS/SR-Core muss Video in eine Video-TC, Audio in eine Voice-TC.
- Tunnel-Propagation: bei VPN/Overlays muss inneres DSCP in den äußeren Header kopiert oder gemappt werden.
- Trust Boundary: Markierungen nicht blind übernehmen; normalisieren und profilieren.
Wenn Video nur auf bestimmten Pfaden ruckelt, ist ein Mapping-Loch an einem Übergangspunkt häufig der Grund.
Interconnect und Cloud-UC: Wo QoS an Grenzen stößt
Teams/Zoom-Verkehr geht häufig in Cloud-Rechenzentren. Über das öffentliche Internet werden DSCP-Markierungen oft neutralisiert. In solchen Fällen sind andere Hebel wichtiger:
- Kapazität und Peak-Management: ausreichend Interconnect-/Internet-Uplink, keine dauerhafte Congestion.
- Private Interconnects: wo möglich, direkte Anbindungen oder optimierte Cloud-Edges.
- Pfaddiversität: mehrere Upstreams/Peers reduzieren Hotspots.
- Lokales QoS bleibt wichtig: Access-Upstream, CPE, Firewall und Campus-LAN müssen stabil sein, auch wenn DSCP im Internet nicht wirkt.
Ein realistisches QoS-Design für Videokonferenzen definiert daher die SLA-Grenze: innerhalb der kontrollierten Domäne wird priorisiert, außerhalb werden Pfad- und Kapazitätsstrategien genutzt.
Monitoring: Was Sie messen müssen, um Burst-Probleme zu sehen
Für Videokonferenzen reicht Linkauslastung nicht. Sie benötigen Sicht auf Klassen und auf kurze Zeitfenster:
- Queue-Drops pro Klasse: Drops in Audio sind kritisch; Drops in Video/Content erklären Freezes und Downshifts.
- Queue-Depth/Queueing Delay: Jitterwellen und Bufferbloat erkennen; Perzentile sind entscheidend.
- Policer-Hits/Remarking: zeigt Profilverletzungen, zu enge Budgets oder Fehlmarkierung.
- QoE-KPIs: Freeze-Events, Bitrate-Switches, Framerate-Einbrüche, Audio-Interruptions (falls UC-Analytics verfügbar).
Ein praxistauglicher Betriebssatz: Drops in der Audio-Klasse sind ein Incident. Bei Video sind Drop-Cluster und starke Queueing-Delay-Spitzen die wichtigsten Frühindikatoren.
Praxis-Blueprint: QoS für Videokonferenzen mit Burst-Verhalten und Bandbreitenprofilen
- Medien trennen: Audio (EF/LLQ), Video (AF/gewichtet), Content (eigene Klasse oder mit Video, aber budgetiert).
- LLQ nur für Audio: strict priority mit Limit, damit Premium klein bleibt.
- Profile realistisch dimensionieren: Baseline + Peak + Gleichzeitigkeit; Burst-Toleranz einplanen.
- Shaping an Engpässen: besonders am Access-Upstream und vor Rate-Limits; Bursts glätten statt droppen.
- Policing vorsichtig: Audio nicht droppen; Video/Content bevorzugt remarken statt harte Drops.
- End-to-End Mapping sichern: DSCP->CoS, DSCP->MPLS-TC, Tunnel-Outer-DSCP konsistent.
- Trust Boundary definieren: Markierungen nur kontrolliert akzeptieren; sonst normalisieren.
- Monitoring operationalisieren: Queue-Drops, Queueing Delay, Policer-Hits und QoE-Korrelation in Dashboards.
Häufige Fragen zu QoS für Videokonferenzen
Warum reicht „Video in AF“ manchmal nicht?
Weil der Engpass oft im Upstream oder an Rate-Limits liegt und Bursts dann in Drop-Cluster umschlagen. Ohne Shaping und passende Queue-Limits kann selbst eine bevorzugte Klasse instabil werden. Zusätzlich können Mapping-Löcher (CoS/TC/Tunnel) die AF-Klasse unterwegs verlieren.
Sollte Screen Sharing höher priorisiert werden als Kamera-Video?
Das hängt vom Use Case ab. In vielen Business-Szenarien ist Content kritisch, aber sehr bursty. Sinnvoll ist häufig eine eigene Content-Klasse mit garantierten Anteilen oder eine Video-Klasse mit interner Priorisierung, ohne strict priority zu nutzen.
Was ist der wichtigste Hebel gegen „Qualität pendelt“?
Stabilität am Engpass: Shaping gegen Bursts, kontrollierte Puffer gegen Bufferbloat und Congestion-Avoidance gegen Drop-Cluster. Wenn der Durchsatz nicht in Wellen schwankt und Drops nicht in Clustern auftreten, wird die ABR-Regelung deutlich ruhiger – und die Nutzer erleben weniger Ruckler und weniger Downshifts.
