QoS Baseline für Telcos: Standardwerte für Queues, Shaping, Policer

Eine QoS Baseline für Telcos ist der pragmatische Startpunkt, um Sprache und Video über große, heterogene Netze hinweg stabil zu transportieren, ohne jedes Segment „von Hand“ neu zu erfinden. Im Carrier-Alltag ist nicht die Existenz von QoS das Problem, sondern die fehlende Einheitlichkeit: In Region A ist die Voice-LLQ zu groß, in Region B fehlt Shaping am Engpass, in Region C werden Kundemarkierungen ungeprüft übernommen, und plötzlich ist die Nutzerqualität abhängig vom Standort statt vom SLA. Eine Baseline schafft einen gemeinsamen Nenner: Standardwerte für Queues, Shaping und Policer, die auf typischen Echtzeitprofilen (Voice, interaktives Video, Signaling/Control) beruhen und die in Access, Aggregation, Metro und Core reproduzierbar funktionieren. Wichtig ist dabei ein realistischer Anspruch: Baseline bedeutet nicht „für immer optimal“, sondern „sicher und robust als Default“. Sie verhindert Premium-Inflation, reduziert Bufferbloat, begrenzt Drop-Cluster und liefert klare Verifikationssignale (Classify-Hits, Queueing Delay, Drops). Dieser Artikel beschreibt eine vendor-neutrale QoS Baseline für Telcos mit praxisbewährten Standardwerten und Designregeln: Wie groß sollte die Echtzeit-Queue sein? Wie dimensioniert man Queue-Limits in Millisekunden statt in Bytes? Wann ist Shaping Pflicht und wie wählt man die Shaping-Rate? Wie setzt man Policer so, dass sie Governance liefern, ohne Voice zu zerstören? Das Ziel ist eine Baseline, die Sie als Template-Grundlage nutzen und später mit Messdaten (Perzentile, Busy Hour, Probes) feinjustieren können.

Was „Baseline“ bei QoS bedeutet – und was nicht

Eine QoS-Baseline ist ein standardisiertes Set aus Klassen, Mappings und Mechaniken, das als Default auf definierten Netzrollen ausgerollt werden kann. Sie beschreibt typische Wertebereiche, nicht eine magische Zahl. Die Baseline muss drei Bedingungen erfüllen:

• Sicher: Echtzeit darf nicht durch Fehlmarkierung oder falsche Limits destabilisiert werden.
• Robust: Sie funktioniert über unterschiedliche Plattformen und Linkraten, ohne an jedem Port neu parametriert zu werden.
• Messbar: Sie erzeugt klare Telemetriesignale, damit Drift und Engpässe früh erkennbar sind.

Keine Baseline ersetzt Kapazität. Wenn ein Uplink dauerhaft überlastet ist, kann QoS nur entscheiden, wer verliert – aber nicht verhindern, dass irgendwer verliert.

Baseline beginnt mit einem schlanken Klassenmodell

Zu viele Klassen erhöhen Drift und Mapping-Risiko. Für Telcos ist ein 4–5-Klassenmodell in der Praxis meist der beste Kompromiss:

• Real-Time Voice: Audio-Medien (RTP/SRTP), sehr niedrige Latenz, strict priority (LLQ) mit Limit.
• Signaling/Control: SIP/IMS-Signaling, DNS/AAA/Steuertraffic, hoch priorisiert gewichtet.
• Interactive Video: WebRTC/Video Calls/Meetings, gewichtet, bursttolerant.
• Best Effort: Standarddatenverkehr.
• Background (optional): Updates/Backups, klar niedriger priorisiert.

Diese Semantik ist die Grundlage für Standardwerte. Ohne klare Semantik sind Queue- und Shapingwerte nicht interpretierbar.

Standardwerte in „Zeit“ denken: Queue-Limits als Millisekunden

Queue-Größen in Bytes sind schwer über Linkraten hinweg vergleichbar. Für Echtzeit ist es sinnvoll, Zielwerte als „Wartezeitbudget“ zu formulieren. Eine praktische Umrechnung lautet:

$\mathrm{QueueBytes}\approx \mathrm{RateBytesPerSec}\times \mathrm{QueueDelaySec}$

Damit können Sie z. B. sagen: „Voice darf maximal 5 ms warten“ und berechnen daraus eine passende Queue-Größe für 100 Mbit/s oder 10 Gbit/s.

Baseline für Queues: Standard-Queueing pro Klasse

Die folgenden Werte sind als robuste Startwerte gedacht, die Sie über Telemetrie (Perzentile, Drops, Jitter/MOS) validieren und feinjustieren.

Real-Time Voice (LLQ) – Standardwerte

• Scheduling: strict priority (LLQ) mit hartem Limit.
• LLQ-Bandbreitenlimit: typischer Baseline-Bereich 5–10 % der Linkrate pro Engpassinterface. In sehr echtzeitlastigen Business-Segmenten bis 15 %, aber nur mit strikter Trust Boundary.
• Queueing Delay Ziel: 1–5 ms (95./99. Perzentil) am Engpass.
• Queue-Limit: so dimensionieren, dass max. 5–10 ms Warteschlange möglich ist; eher klein als groß (große Voice-Queues erhöhen Jitter).
• Drops: 0 Drops als Betriebsziel; EF-Drops sind Incident-Signal.

Warum so konservativ? Weil Voice sehr empfindlich ist und weil eine zu große LLQ im Carrierbetrieb schnell durch Fehlmarkierung „aufgeblasen“ wird (Premium-Inflation). Das Limit schützt das Netz.

Signaling/Control – Standardwerte

• Scheduling: gewichtete Klasse (keine strict priority), aber mit hoher Priorität.
• Bandbreitenanteil: 2–5 % als Baseline, weil Control meist volumenarm ist, aber in Congestion nicht verhungern darf.
• Queueing Delay Ziel: 5–20 ms Perzentile, abhängig vom Segment; wichtiger ist Stabilität.
• Queue-Limit: moderat, z. B. 20–50 ms Warteschlangenbudget, um kurze Peaks abzufangen, ohne Bufferbloat zu erzeugen.

Control ist die „Netzgesundheit“: Wenn Routing/Signaling in Best Effort untergeht, verlängern sich Convergence und Setup-Zeiten – und dann wirkt alles „instabil“, obwohl nur die Steuerung leidet.

Interactive Video – Standardwerte

• Scheduling: gewichtete Klasse mit garantiertem Anteil.
• Bandbreitenanteil: Baseline 15–30 % je nach Produktmix (Consumer vs. Business). In UC-lastigen Netzen eher am oberen Ende, aber niemals als LLQ.
• Queueing Delay Ziel: 20–60 ms Perzentile; Video toleriert mehr als Voice, aber Peaks und Drop-Cluster müssen klein bleiben.
• Queue-Limit: moderat, z. B. 50–150 ms Warteschlangenbudget. Zu klein führt zu Drop-Clustern bei Bursts (Keyframes), zu groß zu Bufferbloat.

Video profitiert von stabilen Throughput-Fenstern. Ziel ist nicht „keine Warteschlange“, sondern „keine extremen Peaks“.

Best Effort – Standardwerte

• Scheduling: fair/gewichtet (Restklasse), ggf. mit Congestion Avoidance.
• Bandbreitenanteil: „Rest“ nach Premiumklassen; in vielen Designs bleiben 50–75 % für BE.
• Queue-Limit: kontrolliert, typischer Baselinebereich 100–300 ms Warteschlangenbudget am Engpass (je nach Linkrate und Segment). Ziel ist, Bufferbloat zu begrenzen.

Best Effort ist die Klasse, die in Congestion „verlieren“ darf. Aber sie darf nicht so gepuffert werden, dass sie die gesamte Latenzdomäne aufbläht.

Background – Standardwerte

• Scheduling: niedrige Priorität, kleiner garantierter Anteil.
• Bandbreitenanteil: 1–5 % oder opportunistisch (nur wenn frei), abhängig davon, ob Sie Backups/Updates bewusst in eine „Nachtklasse“ drücken.
• Queue-Limit: eher klein bis moderat; Background soll nicht unnötig puffern, sondern bei Bedarf zurückstehen.

Baseline für Shaping: Wo Shaping Pflicht ist und welche Standardwerte gelten

Shaping ist im Carrierbetrieb oft der wichtigste QoS-Baustein, weil es Microbursts glättet und Bufferbloat an unkontrollierten Punkten verhindert. Eine Baseline sollte klar definieren, wo Shaping standardmäßig aktiv ist:

• Access/Edge Uplinks: besonders Upstream (CPE/BNG/PE-Egress Richtung Access), weil dort Rate-Limits und Pufferprobleme dominieren.
• Rate-limitierte Übergänge: überall dort, wo ein Vertrag oder eine physische Rate hart begrenzt (CIR, NNI-Profile, Backhaul-Links).
• Ring-/Metro-Engpässe: wenn Schutzschaltungen/Failover Bursts erzeugen.

Shaping-Rate: Standardansatz

• Prinzip: Shape knapp unter der realen oder vertraglichen Rate, damit Drops nicht in fremden Policern oder unkontrollierten Puffern entstehen.
• Baseline-Abschlag: 1–5 % unter der Nominalrate als Startwert (bei sehr stabilen Links eher 1–2 %, bei Access/Shared Medium eher 3–5 %).
• Ziel: Queueing kontrollieren, nicht Kapazität „verschenken“. Der Abschlag ist ein Stabilitätsbudget.

Beispiel als Denkmodell: Wenn ein Uplink real 1 Gbit/s tragen kann, ist ein Shaper von 970–990 Mbit/s oft stabiler als „1 Gbit/s ohne Shaping“, weil der Stau dann im kontrollierbaren Shaper entsteht statt in CPE/Modem/Providerpolicer.

Shaping-Queueing: Standardwerte

• Parent-Shaper Queue Budget: häufig 20–50 ms als Baseline, damit kurze Bursts geglättet werden.
• Child-Queues innerhalb des Shapers: Voice muss innerhalb des Shapers priorisiert werden (LLQ), Video gewichtet, BE fair.

Wichtig: Shaping ohne Klassenpriorisierung kann Echtzeit sogar verschlechtern, weil Voice dann im Shaper „mitstaut“.

Baseline für Policer: Governance ohne Echtzeit zu zerstören

Policer sind im Carrierumfeld notwendig, um Kundentarife, Wholesale-Profile und Trust Boundaries umzusetzen. Gleichzeitig sind Policer für Echtzeit riskant, weil sie hart droppen. Eine Baseline sollte Policer-Entscheidungen deshalb klar regeln.

Policer-Grundregeln

• Voice nicht hart policen: Drops in der Voiceklasse sind sofort hörbar. Wenn Governance nötig ist, dann eher über Trust Boundary (nur bestimmte Quellen dürfen EF) und über LLQ-Limits.
• Video vorsichtig policen: harte Drops erzeugen Drop-Cluster und Freezes. Besser: Shaping oder Remarking von Überschuss in BE.
• BE/Background policen: hier ist Policing als Tarif-/Fairnessinstrument am unkritischsten.

Policer-Parameter: Standardwerte für Burst-Toleranz

Wenn Sie policen müssen, ist Burst-Toleranz entscheidend, um Microbursts nicht unnötig zu zerhacken. Als Baseline gilt:

• CIR: entspricht dem vertraglichen Profil (pro Kunde/Service).
• Burst (Token Bucket): nicht „minimal“, sondern realitätsnah. Ein robuster Startwert ist, Burst in der Größenordnung von 10–50 ms der CIR zu erlauben, abhängig vom Service.

Das lässt sich als Näherung formulieren:

$\mathrm{BurstBytes}\approx \mathrm{CIRBytesPerSec}\times \mathrm{BurstWindowSec}$

Für Video wählen Sie tendenziell ein größeres Burstfenster als für BE, weil Video keyframe-bedingt spitz sein kann. Für Voice sollten Sie ohnehin vermeiden, dass ein Policer überhaupt in Drop gerät.

Policer-Aktion: Drop vs. Remarking als Baseline

• Voice: Ziel ist „nicht droppen“. Wenn überhaupt, dann Überschuss in eine niedrigere Klasse remarken und über LLQ-Limit schützen.
• Video: Überschuss bevorzugt remarken (z. B. von Video-AF zu BE), statt hart zu droppen.
• BE/Background: Drop ist akzeptabler, aber auch hier sind Drop-Cluster zu vermeiden (Burstfenster nicht zu klein).

Baseline für Markierung und Trust Boundary: Standardregeln gegen Premium-Inflation

Ohne Trust Boundary werden Baseline-Queues wertlos, weil jeder alles als Premium markieren kann. Eine Carrier-Baseline sollte deshalb „Trust“ standardisieren:

• Managed Edge: Markierungen von eigenen SBCs/CNFs/Managed CPE können vertraut werden, aber innerhalb profilierter Budgets.
• Unmanaged Customer Edge: DSCP wird normalisiert; nur definierte Markierungen werden akzeptiert (Whitelist).
• Interconnect/Peering: grundsätzlich konservativ; Inbound-DSCP oft untrusted oder conditional trust.

Eine einfache, robuste Regel lautet: EF wird nur akzeptiert, wenn Quelle und Servicekontext bekannt sind. Alles andere wird in Video/BE gemappt. So bleibt die LLQ klein und stabil.

Baseline pro Netzrolle: Gleiche Semantik, andere Schwerpunktsetzung

Standardwerte müssen je Netzrolle interpretierbar sein. Die Semantik bleibt gleich, aber die Mechanik-Schwerpunkte unterscheiden sich:

• Access Edge: Shaping ist häufig Pflicht, Policer pro Kunde/Service, strenge Trust Boundary, HQoS (Parent pro Kunde, Child pro Klasse).
• Aggregation/Metro: Fokus auf Microburst-Handling, konsistente CoS-Mappings, stabile Queue-Limits, Schutzschaltungsresilienz.
• Core: hohe Kapazität, konsistente MPLS-TC-Mappings, geringe Drops, klarer Schutz der Control-Klasse, weniger aggressive Policer.
• NNI/Peering: Kapazität und Headroom sind zentral, Shaping ggf. gegen Gegenpolicer, konservatives Trust, sehr gute Telemetrie pro Klasse.

Baseline-Verifikation: Welche Standard-Checks dazugehören

Eine Baseline ist nur dann wertvoll, wenn sie standardisiert verifiziert wird. Pflichtsignale:

• Classify-Hits: Jede Klasse muss Treffer zeigen, wenn Traffic existiert; 0 Hits sind Alarmzeichen.
• DSCP/CoS/TC-Verteilung: Premiumvolumen muss plausibel sein; plötzliche Anstiege deuten auf Fehlmarkierung.
• Queueing Delay Perzentile: 95./99. pro Klasse, besonders Voice und Control.
• Drops pro Klasse: EF-Drops sind Incident; Video-Drop-Cluster sind QoE-Risiko.
• Policer/Shaper Events: Exceed/Drop/Remarking, Shaper-Queueing, um Burst- und Profilprobleme zu erkennen.

Ergänzend sind kleine aktive Probes pro Klasse (EF/AF/BE) sinnvoll, um die End-to-End-Wirkung unabhängig vom Realtraffic zu prüfen.

Typische Baseline-Fehler und wie Sie sie vermeiden

• LLQ ohne Limit: führt bei Fehlmarkierung zu Starvation und Premium-Inflation.
• Zu große BE-Queues: erzeugen Bufferbloat, steigern Latenz und Jitter ohne Drops.
• Zu harte Policer: kleine Burstfenster erzeugen Drop-Cluster, besonders bei Video.
• Shaping vergessen: Congestion entsteht dann in unkontrollierten Puffern (CPE/Modem/Providerpolicer), Echtzeit leidet trotz QoS.
• Mapping-Drift: unterschiedliche DSCP↔CoS↔TC-Tabellen machen jede Baseline wirkungslos.

Praxis-Blueprint: QoS Baseline als Templates ausrollen

• Schritt 1: Klassenmodell finalisieren (Voice, Control, Video, BE, optional Background) und Mappings definieren.
• Schritt 2: Standardwerte pro Klasse festlegen (LLQ-Limit, Weights, Queueing-Budgets in ms, Drop-Strategie).
• Schritt 3: Shaping-Regeln definieren (wo Pflicht, Rate-Abschlag 1–5 %, Parent/Child-Logik).
• Schritt 4: Policer-Regeln definieren (wo erlaubt, Burstfenster 10–50 ms als Start, Remarking-Strategie).
• Schritt 5: Templates pro Netzrolle erstellen (Access, Aggregation/Metro, Core, NNI) mit gleicher Semantik.
• Schritt 6: Verifikation standardisieren (Hits, Perzentile, Drops, Remarking, Probes) und Baselines in Dashboards sichtbar machen.
• Schritt 7: Canary-Rollout, Busy-Hour-Verifikation, dann Wellenrollout; Abweichungen als Drift behandeln.

Häufige Fragen zur QoS Baseline

Warum sollte ich Standardwerte nutzen, wenn jedes Segment anders ist?

Weil Standardwerte die häufigsten Fehler verhindern und eine gemeinsame Sprache schaffen. Sie liefern einen sicheren Default, den Sie danach mit Messdaten segmentweise verfeinern können. Ohne Baseline endet QoS oft als Sammlung lokaler „Tuning-Kunst“, die driftet und schwer zu betreiben ist.

Wie erkenne ich, dass meine Baseline zu aggressiv oder zu lax ist?

Zu aggressiv ist sie, wenn Policer-Drops steigen, Video Drop-Cluster entstehen oder Control-Setup-Zeiten leiden. Zu lax ist sie, wenn BE-Queues Bufferbloat erzeugen (Delay-Perzentile steigen) oder wenn Premium-Inflation EF/LLQ aufbläht. Die wichtigsten Indikatoren sind Queueing Delay 95/99, Drops pro Klasse und DSCP-Verteilungen.

Was ist der wichtigste Baseline-Wert für Voice-Qualität?

Eine strikt limitierte LLQ für Voice kombiniert mit kontrolliertem Shaping am Engpass. Damit bleiben Jitter und Delay-Spitzen klein, und Fehlmarkierung kann das Netz nicht destabilisieren. EF-Drops sollten als klares Incident-Signal behandelt werden – wenn EF dropt, ist die Baseline oder die Kapazitäts-/Governanceannahme verletzt.