QoS-Profile pro Service sind der Unterschied zwischen „QoS ist irgendwo aktiviert“ und einer End-to-End-Qualität, die auch unter Last stabil bleibt. In vielen Netzen wird QoS zu grob umgesetzt: Alles, was nach Echtzeit klingt, landet in einer einzigen Premium-Klasse – oder schlimmer noch: Voice, Video und Signaling werden gemeinsam als „High Priority“ behandelt. Das funktioniert im Leerlauf oft, führt aber bei Busy Hour, Microbursts, rate-limitierten Access-Links oder in Security-Ketten (Firewall, NAT, VPN) zu Nebenwirkungen: Premium-Inflation, Drops in der Voice-Klasse, ruckelndes Video, lange Call-Setup-Zeiten oder ein Best-Effort, der komplett verhungert. Ein professionelles QoS-Design definiert deshalb QoS-Profile pro Service: Voice (Audio) wird in einer kleinen, strikt priorisierten Low-Latency-Klasse behandelt, Signaling bekommt eine eigene Control-Klasse mit hoher, aber gewichteter Priorität, Video bekommt eine gewichtete Klasse mit stabilen Durchsatzfenstern statt strict priority, und Best Effort bleibt fair und kontrolliert, damit das Netz nicht durch Bufferbloat und Throughput-Wellen instabil wird. Dieser Artikel zeigt, wie Sie diese Serviceprofile sauber definieren, wie Sie Markierung, Trust Boundary, Shaping/Policing und Scheduler-Parameter pro Klasse festlegen und wie Sie das Ganze so operationalisieren, dass es nicht nur auf dem Papier stimmt, sondern im Betrieb messbar wirkt.
Was ist ein QoS-Profil und warum „Klassen“ allein nicht reichen
Viele setzen QoS gleich mit „DSCP markieren“ oder „Queues konfigurieren“. Ein QoS-Profil ist mehr: Es ist die vollständige Servicebeschreibung, wie ein Verkehrstyp im Netz behandelt werden soll – inklusive Markierung, erlaubter Quellen, Bandbreitenbudget, Burst-Toleranz, Queue-Strategie und Drop-Verhalten. Nur so entsteht reproduzierbare Qualität.
- Markierung: DSCP/CoS/MPLS-TC, die den Service identifiziert.
- Trust Boundary: wer darf markieren, wer wird normalisiert/remarkt?
- Budget: welche Bandbreite ist garantiert, wie viel ist maximal erlaubt?
- Scheduler: LLQ, CBWFQ/WFQ, PQ, Prioritäten und Gewichte.
- Congestion-Verhalten: Shaping, Policing, WRED/Drop-Strategien, Queue-Limits.
- Monitoring-Kriterien: welche KPIs zeigen Erfolg oder Incident (Drops, Delay, MOS, Freeze-Events)?
Ohne diese Profilidee ist QoS oft inkonsistent: unterschiedliche Teams konfigurieren Klassen unterschiedlich, und End-to-End entsteht ein „QoS-Loch“ an Übergängen.
Die vier Kernservices im Praxisbetrieb: Voice, Video, Signaling, Best Effort
Für die meisten Telco- und Enterprise-Netze lässt sich ein robustes QoS-Basismodell auf vier Kernservices reduzieren. Das ist bewusst „nicht zu viele Klassen“, aber ausreichend, um Echtzeit korrekt zu schützen:
- Voice (Audio Media): RTP/SRTP, extrem jitter- und loss-sensibel, geringe Bandbreite, benötigt Low Latency.
- Video (Interaktiv/Real-Time Video): WebRTC/UC-Video, bandbreitenstärker und burstig, benötigt stabile Throughput-Fenster, aber keine strict priority.
- Signaling (Control): SIP/IMS, ICE/STUN/TURN, DNS/Control-Flows; volumenarm, aber für Setup und Stabilität kritisch.
- Best Effort: Standarddatenverkehr, sollte fair bleiben und darf nicht durch Premium-Inflation verhungern.
Optional ergänzen viele Netze noch eine Background-Klasse (Updates/Backups), aber die Kernlogik bleibt: Audio strikt, Video gewichtet, Signaling robust, Best Effort fair.
Serviceprofil Voice: Audio stabil halten – ohne Premium-Inflation
Voice ist der empfindlichste Dienst. Schon kurze Drops oder Jitterspitzen sind hörbar. Deshalb ist das Voice-Profil in der Regel das strengste Profil – aber es muss klein bleiben.
Qualitätsziele (praxisnah)
- Minimales Queueing Delay: Audio soll nicht warten.
- Sehr geringe Drop-Rate: Drops in der Voice-Klasse sind ein Incident.
- Niedriger Jitter: stabile Ankunftszeiten, Jitter-Buffer bleibt klein.
Mechanik
- Markierung: typischerweise DSCP EF für Audio Media.
- Scheduler: LLQ/Strict Priority, aber immer mit Bandbreitenlimit.
- Queue-Limit: klein halten (Voice soll nicht gepuffert werden).
- Shaping: Voice aus dem Shaper priorisieren; Shaping verhindert Burst-Drops am Upstream.
- Policing: auf Voice möglichst keine harten Drops; Profile so dimensionieren, dass Voice praktisch nie out-of-profile ist.
Designregeln gegen Nebenwirkungen
- LLQ limitieren: schützt Best Effort und verhindert Starvation.
- Trust Boundary: EF nur aus kontrollierten Quellen akzeptieren (SBC, Managed CPE, UC-Server).
- Keine „Voice für alles“: Video, Content oder Bulk darf niemals in EF landen.
Serviceprofil Signaling: Zuverlässig und schnell – aber nicht „Priority um jeden Preis“
Signaling ist in der Regel volumenarm, aber für den Dienstzustand entscheidend: Call Setup, Re-INVITE, UPDATE, REGISTER, BYE oder ICE-Kandidaten müssen stabil funktionieren. Gleichzeitig ist Signaling nicht so jitterkritisch wie Audio.
Qualitätsziele
- Geringe Verzögerung: Setup- und Reaktionszeiten stabil.
- Hohe Zustellzuverlässigkeit: Control-Pakete dürfen nicht im Best Effort untergehen.
- Stabilität bei Bursts: Failover-Events können Signaling-Spitzen erzeugen.
Mechanik
- Markierung: separate Control/Signaling-Klasse (DSCP-Wert nach Ihrem Standardmodell).
- Scheduler: hoch priorisierte, aber gewichtete Queue (keine strict priority).
- Queue-Limit: moderat; Control darf nicht in großen Puffern versinken.
- Policing: möglich, aber mit Burst-Toleranz; Drops können Setup-Probleme verursachen.
Typische Fehler vermeiden
- Signaling in EF: bläht die Voice-Klasse, ohne dass Audio besser wird.
- Signaling in Best Effort: führt zu langen Setup-Zeiten bei Congestion.
Serviceprofil Video: Stabilität über Durchsatzfenster, nicht über strict priority
Interaktives Video (z. B. UC/WebRTC) ist bandbreitenstark und burstig. Es reagiert empfindlich auf Drop-Cluster und auf instabile Throughput-Fenster. Gleichzeitig wäre strict priority gefährlich, weil Video Premium-Queues dauerhaft füllen kann.
Qualitätsziele
- Stabile Throughput-Fenster: weniger Qualitäts-Pendeln, weniger Downshifts/Freezes.
- Begrenzte Drops: Drops sind tolerierbarer als bei Voice, aber Drop-Cluster sind sichtbar.
- Kontrollierte Latenz: Video toleriert mehr Delay als Audio, aber Bufferbloat macht es instabil.
Mechanik
- Markierung: AF-basierte Video-Klasse (nach Ihrem DiffServ-Modell).
- Scheduler: CBWFQ/WFQ mit garantierten Anteilen; keine LLQ.
- Queue-Limit: moderat; zu groß erzeugt Bufferbloat, zu klein dropt bei Keyframes.
- Shaping: sehr hilfreich an rate-limitierten Links, weil es Video-Bursts glättet.
- Remarking: Überschuss kann in Best Effort herabgestuft werden, statt harte Drops zu erzeugen.
Designregeln
- Video nie in EF: sonst Premium-Inflation und Starvation.
- Content separat prüfen: Screen Sharing kann burstiger sein als Kamera; ggf. eigenes Budget.
Serviceprofil Best Effort: Fairness, Kontrolle und weniger Bufferbloat
Best Effort ist nicht „egal“. Wenn Best Effort kollabiert, entstehen Nebenwirkungen: DNS wird langsam, Web-Apps hängen, Updates stauen sich, und indirekt kann auch Echtzeit leiden (z. B. weil Control-Pfade oder Telemetrie betroffen sind). Ziel ist daher ein fairer, kontrollierter Best-Effort-Betrieb.
Qualitätsziele
- Fairness: einzelne Heavy-Flows sollen nicht alles dominieren.
- Kontrollierte Latenz: Bufferbloat vermeiden, damit RTT nicht explodiert.
- Planbares Congestion-Verhalten: weniger Drop-Cluster, stabilere Throughput-Fenster.
Mechanik
- Scheduler: WFQ/CBWFQ, faire Verteilung.
- Queue-Limits: kontrolliert, nicht überdimensioniert.
- Congestion Avoidance: wo sinnvoll, WRED/ähnliche Mechanik zur Glättung von Tail Drop-Effekten.
- Shaping am Upstream: verhindert, dass unkontrollierte Modem-/CPE-Puffer das gesamte Netz „klebrig“ machen.
Mapping über Domänen: DSCP, 802.1p CoS und MPLS-TC konsistent halten
QoS-Profile funktionieren nur Ende-zu-Ende. In Telco- und Metro-Umgebungen wechseln die Queuing-Domänen: Ethernet (802.1p), IP (DSCP), MPLS (TC/EXP), Tunnel (Outer-DSCP). Ein sauberes Profil braucht ein konsistentes Mapping:
- DSCP->CoS: am Access/Metro müssen Voice/Video/Control in passende PCP-Werte gemappt werden.
- DSCP->MPLS-TC: im MPLS/SR-Core muss Voice in eine Voice-TC, Video in eine Video-TC, Control in eine Control-TC.
- Tunnel-Propagation: inneres DSCP muss kontrolliert in den Outer-Header übertragen werden, sonst ist QoS im Underlay unsichtbar.
Typisches QoS-Loch: DSCP stimmt, aber PCP/TC nicht – dann landet Voice im Metro-Segment plötzlich im Best Effort.
Trust Boundary und Remarking: QoS-Profile gegen Missbrauch absichern
Ein QoS-Profil ist nur so gut wie die Governance dahinter. Ohne Trust Boundary riskieren Sie, dass Endgeräte oder Kunden Premium-Markierungen missbrauchen oder falsch setzen.
- Whitelist-Ansatz: nur definierte DSCP-Werte sind zulässig; alles andere wird normalisiert.
- Conditional Trust: Markierungen werden akzeptiert, aber innerhalb profilierter Budgets pro Kunde/Standort/Service.
- Remarking-Strategie: Überschuss wird herabgestuft (z. B. Video von Premium-Video auf Best Effort), statt harte Drops zu erzeugen.
Das schützt nicht nur das Netz, sondern auch die Echtzeitqualität: Premium-Inflation ist eine der häufigsten Ursachen, warum Voice trotz QoS knackt.
Shaping vs. Policing: Wie Sie Profile an Engpässen sauber durchsetzen
QoS-Profile müssen an Engpässen funktionieren. Dort entscheidet sich, ob Jitter und Drops steigen. Die wichtigste Unterscheidung:
- Shaping: glättet Bursts, reduziert Drop-Cluster, stabilisiert Jitter – besonders am Upstream und vor Rate-Limits.
- Policing: erzwingt Budgets durch Drops/Remarking; für Echtzeit nur sehr vorsichtig, weil Drops sofort hörbar sind.
Ein praxistaugliches Muster ist: Shaping am Egress des Engpasses, LLQ für Voice innerhalb des Shapers, Video/Control gewichtet, Best Effort fair. Policing eher als Governance an der Ingress-Grenze, mit Burst-Toleranz und bevorzugt Remarking statt Drop.
Operationalisierung: Wie Sie QoS-Profile im Betrieb stabil halten
QoS ist kein „Set and forget“. Damit Profile dauerhaft wirken, brauchen Sie Betriebsregeln und Monitoring:
- KPIs pro Klasse: Queue-Drops, Queueing Delay/Perzentile, Traffic pro Klasse, Policer-Hits.
- QoE-KPIs: MOS/R-Faktor, RTP Jitter/Loss, Video Freeze Events/Bitrate-Switching (falls verfügbar).
- Alarme: Drops in Voice = Incident; dauerhaft hohe EF-Auslastung = Fehlklassifizierung oder fehlende Profile.
- Change-Disziplin: Mappingtabellen und Profile versionieren; Änderungen an Trust Boundaries und Scheduler-Weights nachvollziehbar dokumentieren.
Eine einfache, aber sehr wirksame Betriebsregel lautet: Wenn EF/Voice Drops zeigt, wird zuerst der Engpass (Upstream, Policer, Shaping, Queue-Limits) geprüft – nicht der Codec.
Typische Fehler bei QoS-Profilen pro Service
- Zu viele Klassen: operativ nicht beherrschbar, Mappingfehler entstehen.
- Zu wenige Klassen: Voice und Video konkurrieren, Premium-Inflation entsteht.
- Strict priority für Video: Starvation anderer Klassen, Netzinstabilität.
- Kein Shaping am Upstream: Bufferbloat und Drop-Cluster in Busy Hour.
- DSCP-Marking ohne Trust Boundary: Missmarkierung bläht Premium-Klassen auf.
- Security-Hops zerstören Markierungen: Firewalls/VPNs neutralisieren DSCP; Underlay queued falsch.
Praxis-Blueprint: QoS-Profile für Voice, Video, Signaling und Best Effort definieren
- Serviceklassen festlegen: Voice (Audio), Signaling (Control), Video (interaktiv), Best Effort (optional Background).
- Markierungsstandard definieren: DSCP-Werte und Mapping zu CoS/MPLS-TC dokumentieren.
- Trust Boundary setzen: Whitelist zulässiger Markierungen, Conditional Trust, Remarking bei Überschuss.
- Scheduler konfigurieren: Voice LLQ mit Limit, Signaling hoch priorisiert gewichtet, Video gewichtet, BE fair.
- Queue-Limits und Drop-Strategien: Voice klein, Video moderat, BE kontrolliert; Drops in Voice vermeiden.
- Shaping an Engpässen: insbesondere am Upstream und vor Rate-Limits, um Bursts zu glätten.
- Tunnel- und Security-Mapping prüfen: Outer-DSCP, DSCP-Preservation, QoS auf Firewalls, MTU/Fragmentierung vermeiden.
- Monitoring und Alarme: Drops/Delay/Policer-Hits pro Klasse, plus QoE-KPIs.
Häufige Fragen zu QoS-Profilen pro Service
Wie viele QoS-Klassen sind sinnvoll?
So wenige wie möglich, so viele wie nötig. Für viele Netze reichen vier Kernprofile (Voice, Video, Signaling, Best Effort) plus optional Background. Mehr Klassen erhöhen Komplexität und Fehlerwahrscheinlichkeit, besonders an Mappingpunkten.
Warum braucht Signaling eine eigene Klasse?
Weil Signaling volumenarm, aber kritisch für Setup und Stabilität ist. Wenn es in Best Effort verhungert, steigen Call Setup Times und es kommt zu Reconnects. Wenn es in EF landet, bläht es die Voice-Klasse ohne Nutzen auf. Eine eigene Control-Klasse ist operativ stabil.
Was ist die häufigste Nebenwirkung schlecht definierter Profile?
Premium-Inflation: zu viel Traffic landet in der höchsten Klasse, LLQ wird überfüllt, Best Effort verhungert und am Ende wird sogar Voice schlechter. Das verhindern Sie durch Limits, Trust Boundaries, Shaping und klare Profilbudgets.
