QoS und TCP wirken auf den ersten Blick wie getrennte Welten: QoS steuert Priorisierung und Warteschlangen im Netz, TCP steuert zuverlässigeren Transport mit Congestion Control und Retransmits. In der Praxis treffen beide jedoch ständig aufeinander – und genau deshalb reagieren Video-Apps manchmal völlig anders als VoIP. VoIP (typisch RTP/SRTP über UDP) ist zeitkritisch: Ein Paket, das zu spät kommt, ist praktisch wertlos. Video-Apps hingegen laufen häufig über TCP oder QUIC (z. B. HLS/DASH-Streaming, viele Cloud-Video-Workflows, Updates von Segmenten) und können durch Retransmits „heilen“, solange genug Puffer vorhanden ist. Das führt zu einem entscheidenden Unterschied im Nutzererlebnis: Bei VoIP ist schon ein kurzer Drop-Cluster hörbar (Knacken, Aussetzer), während TCP-basierte Video-Apps oft zunächst „nur“ langsamer werden, dann Qualität herunterregeln oder erst später buffern. Umgekehrt kann QoS, das für VoIP optimal ist (kleine Low-Latency-Queues, harte Priorisierung), für TCP-Video unerwartete Effekte haben: Wenn TCP in einer bevorzugten Klasse zu stark gedroppt wird oder wenn Bufferbloat in Best Effort entsteht, reagiert Congestion Control mit Durchsatzwellen, ABR-Algorithmen (Adaptive Bitrate) pendeln, und Video wirkt instabil. Dieser Artikel erklärt verständlich, warum QoS und TCP zusammen so unterschiedliche Reaktionen erzeugen, wie Sie VoIP und TCP-Video sinnvoll gleichzeitig betreiben und welche Designregeln verhindern, dass „QoS aktiviert“ zwar Voice rettet, Video aber ruckeliger macht.
UDP vs. TCP: Der grundlegende Unterschied für QoS und Nutzererlebnis
Der wichtigste Ausgangspunkt ist nicht „Voice vs. Video“, sondern „UDP vs. TCP“ – denn das Transportprotokoll entscheidet, wie Anwendungen auf Verlust und Verzögerung reagieren.
- UDP (z. B. RTP/SRTP): keine Retransmits, keine eingebaute Congestion Control. Verlust ist sofort spürbar, Verzögerungsschwankungen (Jitter) sind kritisch.
- TCP: zuverlässiger Transport durch Retransmits, Reihenfolgegarantie, Congestion Control. Verlust führt nicht sofort zu sichtbaren Artefakten, sondern zu Durchsatzreduktion und ggf. Pufferproblemen.
- QUIC: läuft über UDP, hat aber TCP-ähnliche Zuverlässigkeit und Congestion Control auf Anwendungsebene, oft mit anderen Tuning-Eigenschaften.
QoS wirkt auf Pakete im Netz. Die Anwendung reagiert auf das, was am Ende beim Empfänger ankommt. Genau diese Reaktionslogik ist bei UDP-Voice fundamental anders als bei TCP/QUIC-Video.
Warum VoIP so empfindlich ist: „Zu spät“ ist wie „verloren“
VoIP-Streams sind auf eine kontinuierliche, zeitlich gleichmäßige Zustellung angewiesen. Der Jitter-Buffer im Endgerät kann nur begrenzt schwankende Laufzeiten ausgleichen. Wenn Pakete zu spät eintreffen, werden sie verworfen – selbst wenn sie technisch „ankommen“.
- Jitter: führt zu Buffer-Unterläufen; Audio knackt oder wird robotisch.
- Paketverlust: ist sofort hörbar; Drop-Cluster sind besonders schlimm.
- Keine Retransmits: UDP repariert nicht; der Codec kann nur kaschieren (PLC/FEC, falls vorhanden).
Darum ist QoS für VoIP meist sehr klar: Audio bekommt eine echte Low-Latency-Behandlung (LLQ/EF), wird nicht hinter großen Paketen gequeued und sollte praktisch nicht gedroppt werden.
Warum TCP-Video anders wirkt: Verluste werden „versteckt“, bis der Buffer leer ist
Viele Video-Apps – besonders Streaming (HLS/DASH) – nutzen TCP oder QUIC und arbeiten mit Puffern. Der Player lädt Segmente vor, misst Durchsatz und passt die Bitrate an (ABR). Dadurch entsteht ein völlig anderes Fehlerbild:
- Verlust → Retransmit: Der Player bekommt die Daten trotzdem, aber später; kurzfristig sinkt der Durchsatz.
- Durchsatzwellen: Congestion Control reduziert die Sendeleistung nach Loss, steigt dann wieder an.
- Buffer maskiert Probleme: Solange genug Puffer vorhanden ist, merkt der Nutzer wenig; erst bei anhaltender Instabilität kommt Buffering.
- ABR reagiert: Videoqualität wird herabgesetzt, um stabil zu bleiben – was als „pixelig“ oder „nur 720p“ wahrgenommen wird.
Deshalb kann ein Netz, das VoIP sauber priorisiert, bei TCP-Video trotzdem „unruhig“ wirken: TCP wird nicht sofort kaputt, aber es pendelt sichtbar in Qualität und Latenz.
QoS und Congestion: Was der Scheduler wirklich beeinflusst
QoS-Mechanismen (Queues, Scheduler, Shaping, Policing) wirken an Engpässen. Dort entscheiden sie, wer wartet, wer zuerst rausgeht und wer gedroppt wird. Das hat für UDP und TCP unterschiedliche Konsequenzen:
- UDP-Voice: profitiert stark von kurzen Queues und Priorität, weil Jitter sinkt.
- TCP-Video: profitiert weniger von absoluter Priorität, sondern von stabilen Throughput-Fenstern und kontrollierter RTT-Variabilität.
- Drop-Verhalten: TCP interpretiert Drops als Congestion-Signal und reduziert aggressiv die Rate; UDP reagiert nicht und bleibt konstant.
Praktisch heißt das: Ein Drop, der VoIP sofort hörbar schädigt, führt bei TCP eher zu Durchsatzreduktion und späterem Buffering. Und genau diese zeitversetzte Wirkung macht Troubleshooting so verwirrend.
Bufferbloat: Warum große Queues TCP „verlangsamen“ und VoIP „zerstören“ können
Bufferbloat ist ein Klassiker: Zu große Best-Effort-Puffer am Access oder Router lassen die Warteschlangen stark anwachsen. Das erhöht RTT und Jitter. Für TCP kann das bedeuten, dass Verbindungen „zäh“ werden, ohne dass viele Drops auftreten. Für VoIP ist es oft fatal, weil Jitter steigt.
- TCP: arbeitet weiter, aber RTT steigt, Durchsatzschätzung wird ungenauer, ABR wird konservativer.
- VoIP: Jitter-Buffer muss wachsen oder läuft leer; MOS fällt schnell.
Deshalb ist Shaping am Upstream häufig der wichtigste QoS-Baustein für beide Welten: Es verlagert die Queue an einen kontrollierbaren Punkt und verhindert, dass unkontrollierte Puffer (Modem/CPE) das Timing ruinieren.
Warum Video-Apps „trotz QoS“ ruckeln können
Ein typisches Missverständnis lautet: „Wenn wir Video höher priorisieren, ruckelt es weniger.“ In vielen Fällen stimmt das nicht – oder es verschlechtert sogar andere Dienste. Häufige Ursachen:
- Video ist zu groß für Premium: Wenn Video in zu hohe Klassen rutscht, bläht es Queues auf und verdrängt andere Klassen (Premium-Inflation).
- TCP reagiert auf Drops: Wenn Ihre Video-Klasse Drops erzeugt, sinkt TCP-Rate; ABR downshiftet.
- Unstabile Throughput-Fenster: Microbursts, Policer-Drops und wechselnde Pfade erzeugen „Wellen“, die ABR als schlechtes Netz interpretiert.
- Interconnect/Internet neutralisiert DSCP: außerhalb der eigenen Domäne wirkt Markierung nicht zuverlässig; Kapazität und Pfadstrategie zählen mehr.
Für viele Video-Workloads ist „stabiler Best Effort“ mit guter Congestion Avoidance und Shaping oft besser als „zu aggressive Priorisierung“.
Policing vs. Shaping: Warum TCP und UDP unterschiedlich leiden
Policing droppt Pakete, wenn ein Profil überschritten wird. Shaping verzögert Pakete, um ein Profil einzuhalten. Für Echtzeit und TCP hat das unterschiedliche Effekte:
- UDP-Voice: Drops durch Policing sind sofort hörbar; Shaping kann Jitter erhöhen, wenn Voice nicht in einer LLQ priorisiert wird.
- TCP-Video: Policing-Drops triggern Congestion Control und reduzieren Durchsatz; Shaping glättet Bursts und kann stabilere Throughput-Fenster liefern.
Best Practice: Shaping an rate-limitierten Links, Voice in LLQ (mit Limit) aus dem Shaper heraus, Video gewichtet – und harte Policer auf Echtzeit vermeiden.
Congestion Avoidance: WRED und warum es TCP-Video oft hilft
Bei TCP-lastigem Traffic kann Congestion Avoidance (z. B. WRED) helfen, Tail Drop und Drop-Cluster zu reduzieren. Tail Drop erzeugt oft synchrone Retransmit-Wellen und dadurch Throughput-Pendeln. WRED dropt früher und verteilt, sodass Flows weniger synchron reagieren.
- Für TCP/QUIC: weniger Drop-Cluster, stabilere RTT, weniger globale Synchronisation.
- Für UDP-Voice: Voice sollte idealerweise gar nicht gedroppt werden; daher gehört Voice in eine separate, geschützte Klasse.
WRED ist kein „Voice-Tool“, sondern ein Tool, um TCP-Verhalten in Best Effort oder Streaming-Klassen zu stabilisieren.
Interaktiv vs. nicht interaktiv: Video-Apps sind nicht alle TCP
Ein wichtiger Zusatz: Nicht jedes Video läuft über TCP. Videokonferenzen nutzen häufig RTP/SRTP (UDP) oder QUIC-basierte Medienpfade. Dann ähneln sie in einigen Aspekten VoIP, bleiben aber bandbreitenstärker und burstiger.
- Videokonferenz-Video (interaktiv): reagiert empfindlich auf Loss/Jitter, aber toleriert meist etwas mehr Delay als Audio.
- VoD (TCP/QUIC): toleriert mehr Delay, ist throughput-sensibel, nutzt Buffer und ABR.
Das erklärt, warum „Video-App“ als Begriff zu grob ist. Für QoS müssen Sie unterscheiden: interaktives Real-Time-Video vs. segmentiertes Streaming.
Praktisches Klassenmodell: VoIP schützen, Video stabilisieren, Best Effort fair halten
Ein bewährtes, operativ stabiles QoS-Modell in Telco- und Enterprise-Netzen sieht so aus:
- Voice Audio (RTP/SRTP): EF/LLQ mit Limit, kleine Queue-Limits, praktisch keine Drops.
- Signaling/Control: hoch priorisiert, gewichtet (SIP, ICE, DNS, relevante Control-Flows).
- Interaktives Video: AF-Klasse, gewichtete Queue mit garantierten Anteilen, keine strict priority.
- Streaming/Best Effort: fair, kontrollierte Puffer, ggf. Congestion Avoidance.
- Background: niedrig priorisiert.
Dieses Modell verhindert Premium-Inflation und berücksichtigt das unterschiedliche Reaktionsverhalten: UDP-Voice braucht Low Latency, TCP-Video braucht stabile Throughput-Fenster.
Warum „QoS im Core“ nicht reicht: Engpässe liegen oft am Access
Die größten Effekte für VoIP und Video entstehen meist dort, wo Links knapp und Puffer groß sind: am Access-Upstream, in CPEs, an Firewalls oder an VPN-Gateways. Dort entscheidet sich, ob TCP-Video pendelt und ob VoIP knackt.
- Upstream-Shaping: reduziert Bufferbloat, stabilisiert RTT und Jitter.
- Trust Boundary: verhindert, dass Video als Voice markiert wird.
- Tunnel-QoS: Outer-DSCP muss stimmen, sonst ist QoS im Underlay unsichtbar.
Das erklärt auch, warum Video-Apps „manchmal“ anders reagieren: Sie laufen über andere Pfade (IPv4/IPv6, VPN/Direct), treffen andere Engpässe und werden anders gequeued.
Monitoring: Welche Metriken erklären die unterschiedlichen Reaktionen?
Um VoIP und Video richtig zu bewerten, müssen Sie die Metriken passend interpretieren:
- Für VoIP: Jitter, Loss, MOS/R-Faktor, Queueing Delay und Drops in der Voice-Klasse.
- Für TCP-Video: Throughput-Perzentile, RTT/RTT-Variabilität, Retransmits, Queue-Depth/Bufferbloat, ABR-Events (Downshift/Freeze).
- Für beide: Policer-Hits, Queue-Drops pro Klasse, Perzentile statt Mittelwerte.
Ein häufiges Missverständnis ist, dass „keine Drops“ automatisch „gute Qualität“ heißt. Bei TCP kann Bufferbloat ohne Drops zu schlechter QoE führen. Bei VoIP kann ein kleiner Drop-Anteil sofort hörbar sein.
Typische Fehler bei QoS-Designs für Voice und Video
- Video in EF/LLQ: Premium-Inflation, Voice wird nicht besser, Best Effort leidet massiv.
- Kein Shaping am Upstream: Bufferbloat, VoIP knackt, TCP-Video pendelt.
- Harte Policer auf Streaming: Drop-Cluster, TCP-Rate bricht ein, ABR downshiftet.
- Keine Congestion Avoidance: Tail Drop erzeugt synchrone Throughput-Wellen.
- Markierungslücken: DSCP geht an Firewalls/VPNs verloren, Underlay queued falsch.
Praxis-Blueprint: So betreiben Sie VoIP und TCP-Video stabil nebeneinander
- Traffic sauber trennen: Voice-Audio strikt, Signaling separat, Video gewichtet, Best Effort fair.
- LLQ nur für Audio: strict priority mit Limit, kleine Queue-Limits.
- Upstream-Shaping einsetzen: knapp unter Linkrate, um Bufferbloat zu vermeiden und Throughput-Fenster zu stabilisieren.
- Congestion Avoidance für BE/Streaming: Tail Drop reduzieren, Throughput-Wellen glätten.
- Policing vorsichtig: Drops für Echtzeit vermeiden; Streaming lieber shapend stabilisieren oder in kontrollierten Klassen behandeln.
- Trust Boundary definieren: verhindern, dass Video als Voice markiert wird.
- Monitoring differenziert: VoIP über Jitter/Loss/MOS, Video über Throughput/RTT/ABR-Events.
Häufige Fragen zu QoS und TCP im Video-Kontext
Warum wird Video manchmal „nur schlechter“, während VoIP sofort knackt?
Weil TCP/QUIC Verluste durch Retransmits ausgleicht und der Player puffern kann. Der Nutzer sieht zuerst Qualitätseinbußen (Downshift) oder später Buffering. VoIP über UDP kann nicht retransmittieren; verspätete oder verlorene Pakete sind sofort hörbar.
Hilft es, Video genauso hoch zu priorisieren wie Voice?
In der Regel nicht. Video ist zu groß und zu variabel. Es gehört in eine gewichtete Klasse mit garantierten Anteilen und stabilen Puffer-/Drop-Mechanismen, während Voice-Audio in eine kleine, limitierte LLQ gehört.
Was ist der wichtigste gemeinsame Hebel für Voice und TCP-Video?
Upstream-Shaping gegen Bufferbloat und saubere Queue-/Klassen-Trennung. Shaping stabilisiert RTT und verhindert Drop-Cluster an rate-limitierten Links, wodurch VoIP weniger Jitter sieht und TCP-Video weniger Throughput-Wellen und ABR-Pendeln zeigt.
