QoS für Peering-Links ist im Provider- und Telco-Umfeld ein heikler Balanceakt, weil Peering-Ports gleichzeitig technische Engpässe, wirtschaftliche Schnittstellen und SLA-relevante Übergabepunkte sind. Auf der einen Seite steht Kapazität: Wenn ein Peering-Link in der Busy Hour regelmäßig überläuft, entstehen Delay-Spitzen, Drop-Cluster und im Worst Case massive Qualitätseinbrüche bei Voice, Video und interaktiven Diensten. Auf der anderen Seite steht Priorisierung: Selbst bei ausreichender Durchschnittskapazität können Microbursts, asymmetrische Lastverteilung oder schlechte Burst-Profile dazu führen, dass Echtzeitpakete kurzzeitig warten oder gedroppt werden – was für VoIP und WebRTC sofort hör- bzw. sichtbar ist. Gleichzeitig hat QoS an Peering-Links Grenzen, die man offen benennen muss: DSCP-Markierungen werden zwischen Netzen nicht automatisch respektiert; viele Peering-Partner neutralisieren DSCP, oder behandeln alle Klassen als Best Effort. Außerdem ist Peering-Verkehr inhaltlich sehr heterogen (Streaming, Gaming, Cloud, Updates, UC, VoIP, Signaling) und lässt sich nicht zuverlässig nur über Ports klassifizieren. Ein professionelles Design kombiniert deshalb Kapazitätsplanung, saubere Trust Boundaries, realistische Serviceprofile und gezielte QoS-Mechaniken an genau den Stellen, an denen Congestion entsteht – ohne die Beziehung zum Peer zu gefährden oder Premium-Inflation zu erzeugen. Dieser Artikel zeigt, wie Sie Peering-Links so planen und betreiben, dass Qualität messbar stabil bleibt: durch Kapazität als primären Schutz und Priorisierung als kontrollierten Feinschliff.
Was Peering-Links QoS-technisch besonders macht
Im Core können Sie QoS end-to-end in Ihrer Domäne kontrollieren. Am Peering endet diese Kontrolle. Drei Besonderheiten bestimmen daher das Design:
- Domänengrenze: QoS-Semantik (DSCP/CoS) ist zwischen autonomen Netzen nicht automatisch „vertraglich“ oder technisch garantiert.
- Asymmetrie: Inbound und Outbound können komplett unterschiedliche Pfade, Auslastungen und Partnerpolitiken haben.
- Traffic-Mix: Peering trägt oft genau die „spitzen“ Lasten: Streaming am Abend, große Updates, Cloud-Transfers, gleichzeitig UC/Meetings am Tag.
Für Echtzeit bedeutet das: Sie müssen QoS so gestalten, dass es in Ihrer Domäne wirkt, aber Sie dürfen nicht davon ausgehen, dass der Peer Ihre Markierungen übernimmt.
Die wichtigste Designregel: Kapazität schlägt QoS
Peering ist in erster Linie ein Kapazitätsproblem. Wenn ein Peering-Port regelmäßig in Congestion läuft, kann QoS zwar die Verteilung verbessern, aber nicht verhindern, dass ein Teil des Verkehrs verliert. Für Provider gilt deshalb:
- Ausreichende Headroom-Planung: Peering-Links sollten nicht permanent nahe der physikalischen Grenze betrieben werden, weil Microbursts und Trafficspitzen sonst sofort Drops erzeugen.
- Busy-Hour-Perzentile statt Mittelwerte: Entscheidend sind 95./99.-Perzentile und Peak-Fenster (Sekunden bis Minuten), nicht der Tagesdurchschnitt.
- Skalierung durch Port-Add: lieber rechtzeitig zusätzliche Ports oder höhere Portgeschwindigkeit, statt Congestion „wegzupriorisieren“.
QoS an Peering-Links ist am effektivsten, wenn es selten gebraucht wird. Das klingt paradox, ist aber ein Zeichen für gesundes Kapazitätsdesign.
Warum „DSCP über Peering“ oft nicht funktioniert
Viele QoS-Strategien basieren auf DSCP. Am Peering ist DSCP jedoch nicht automatisch vertrauenswürdig:
- DSCP-Neutralisierung: Peers setzen DSCP auf 0, um Missbrauch zu verhindern oder um Policy-Komplexität zu reduzieren.
- Unterschiedliche Klassenmodelle: Ein Peer interpretiert AF/EF anders oder hat andere Queue-Profile.
- Fehlmarkierung: Wenn Sie fremde Markierungen blind akzeptieren, riskieren Sie Premium-Inflation.
Das bedeutet nicht, dass QoS am Peering sinnlos ist. Es bedeutet, dass Sie klar zwischen internem QoS und interdomain QoS unterscheiden müssen: Intern können Sie DSCP sauber nutzen. Interdomain brauchen Sie Trust Boundaries und häufig vertragliche Vereinbarungen.
Trust Boundary am Peering: Welche Markierungen dürfen Sie glauben?
Eine professionelle Peering-QoS-Policy beginnt mit einer klaren Trust-Entscheidung. Typische Modelle:
- Untrusted Peering: Inbound DSCP wird ignoriert/normalisiert; Ihre Outbound-Markierungen gelten nur in Ihrem Netz.
- Conditional Trust: Bestimmte DSCP-Werte werden akzeptiert, aber nur für definierte Quellen/Prefixes oder nur innerhalb profilierter Budgets; Überschuss wird remarkt.
- Trusted/Contracted QoS: QoS-Klassen sind zwischen Partnern abgestimmt (z. B. Wholesale/Resale), inklusive Mess- und Übergabepunktdefinition.
Für klassisches Public Peering ist „Untrusted“ oder „Conditional Trust“ meist die sicherste Wahl. Für Wholesale/Partner-Backbones kann „Trusted“ sinnvoll sein, muss aber vertraglich und technisch sauber abgesichert werden.
Welche Serviceklassen am Peering überhaupt Sinn ergeben
Je näher Sie an der Domänengrenze sind, desto wichtiger ist ein schlankes Klassenmodell. Zu viele Klassen erhöhen Drift- und Missbrauchsrisiko. Bewährt haben sich:
- Voice (Audio): in der eigenen Domäne strikt geschützt (LLQ mit Limit), aber am Peering nur, wenn QoS vertraglich abgestimmt ist oder wenn Sie den Voice-Dienst kontrollieren (z. B. eigene SBC-Interconnects).
- Control/Signaling: kleine, robuste Klasse, um DNS/Signaling/Control-Traffic stabil zu halten – besonders wichtig bei Congestion.
- Video/Interactive: gewichtete Klasse (AF), um Throughput-Fenster zu stabilisieren, ohne Premium-Inflation zu erzeugen.
- Best Effort: Standardklasse für den Großteil des Peering-Traffics.
Wenn Sie keine abgestimmte Interdomain-QoS haben, ist es oft sinnvoller, Voice/Video in Ihrer Domäne bis zum Peering sauber zu transportieren, am Peering aber konservativ zu bleiben und den Schwerpunkt auf Kapazität und Congestion-Management zu legen.
Wo QoS am Peering wirklich wirkt: Egress-Engpässe und Queueing
QoS wirkt dort, wo gequeued wird – meistens am Egress eines Ports. Deshalb sollte Peering-QoS vor allem Egress-orientiert geplant werden:
- Egress-Queues pro Klasse: verhindern, dass Best Effort kurze Premium-Spitzen verdrängt.
- Queueing Delay-Perzentile: sind der Frühindikator für kommende QoE-Probleme.
- Drop-Mechanik: Tail Drops erzeugen Drop-Cluster; kontrollierte Drop-Strategien in Nicht-Premium-Klassen können Wellen glätten.
Wenn Peering-Congestion entsteht, ist die wichtigste Frage nicht „haben wir DSCP“, sondern „in welcher Queue droppen wir und wie clusterig ist das Dropverhalten“.
Shaping vs. Policing am Peering: Welche Strategie ist sicherer?
Peering-Ports sind häufig hochkapazitiv, aber nicht immer „frei“. Engpässe können upstream (Linecard/ASIC), downstream (Peer-Port), oder in einem definierten Vertrag (CIR) liegen. Daraus folgt:
- Shaping: glättet Bursts, reduziert Drop-Cluster und stabilisiert Jitter; besonders hilfreich, wenn der Peer oder ein Interconnect-Element hart policet.
- Policing: erzwingt Budgets hart; kann bei Echtzeitdiensten sofort hörbare Drops erzeugen, wenn Bursts auftreten.
Ein praxisnaher Ansatz ist: Shaping dort, wo Sie Bursts kontrollieren wollen, Policing eher als Governance für klar definierte, nicht-echtzeitkritische Profile. Für Voice/interactive Video sind harte Policer an Peering-Übergängen riskant, weil sie Drop-Cluster erzeugen können.
Peering-Kapazität planen: Headroom, Peaks und Port-Bündelung
Die Kernfrage für Peering lautet nicht „wie viele Gbit/s im Schnitt“, sondern „wie viel Headroom in Peaks“. Sinnvolle Planungsgrößen:
- 95./99. Perzentil-Auslastung: zeigt, wie oft Sie in den riskanten Bereich kommen.
- Peak-Minuten und Peak-Sekunden: Microbursts sind für QoE relevanter als 5-Minuten-Mittelwerte.
- Port-Channel/LAG: Bündelung erhöht Kapazität, aber Hashing kann Hotspots erzeugen; Lastverteilung und ECMP/LAG-Hashing müssen beobachtet werden.
- Geografische Verteilung: mehrere Peering-Standorte reduzieren lokale Peaks und verbessern Pfadoptionen.
Ein gesundes Peering-Design ist erkennbar daran, dass QoS-Queues selten „hart arbeiten“ müssen, weil Congestion selten ist.
QoS und ECMP/LAG am Peering: Hotspots vermeiden
Viele Peering-Links sind als LAG oder über mehrere Ports realisiert. Dann entscheidet Hashing, welche Flows auf welchen Member-Port gehen. Für QoS bedeutet das:
- Hotspot-Risiko: einzelne große Flows (z. B. Video/Download) können einen Member-Port füllen, obwohl die LAG insgesamt Headroom hat.
- Klassenmetriken pro Member: EF/AF/BE Volumen und Drops sollten pro physischem Port sichtbar sein.
- Hash-Optimierung: wenn möglich 5-Tuple, Entropy und konsistente Hash-Policies nutzen.
Wenn QoE-Probleme „sporadisch“ sind, ist ein überfüllter LAG-Member oft der Grund. Das ist kein QoS-Konfigurationsfehler, sondern ein Lastverteilungsproblem.
Interdomain QoS: Wann es sich lohnt, QoS wirklich zu „handeln“
In manchen Fällen ist echte Interdomain-QoS sinnvoll und möglich:
- Wholesale/Resale: vertraglich definierte Klassen (z. B. Voice, Video, Business Data) mit Messpunkten und Übergaberegeln.
- Private Interconnects: direkte Verbindungen zu UC-/Cloud-Partnern, bei denen QoS abgestimmt werden kann.
- Managed Services: z. B. SIP-Trunks/IMS-Interconnects mit klaren EF-Regeln und strikter Trust Boundary.
Hier ist das Kernprinzip: Klassenmodell, Markierungsregeln, Mappings, Messmethoden und Eskalationspfade müssen zwischen den Parteien abgestimmt sein. Ohne diese Abstimmung führt „QoS über Peering“ häufig zu Enttäuschung oder Missbrauch.
Monitoring: Welche Metriken an Peering-Links Pflicht sind
Damit Kapazität und Priorisierung zusammen funktionieren, brauchen Sie Telemetrie, die nicht nur „Link utilization“ zeigt. Pflichtmetriken:
- Utilization-Perzentile: 95./99. und Peak-Fenster.
- Queueing Delay pro Klasse: Perzentile und Peaks, nicht nur Durchschnitt.
- Drops pro Klasse: besonders Premium- oder Control-Drops sind kritisch.
- DSCP/CoS-Verteilungen: Ingress/Egress, Remarking-Raten, Premium-Inflation.
- Policer/Shaper Events: Exceed/Drop und Shaper-Queueing, um Burst-Probleme zu erkennen.
- Active Probes: EF/AF/BE Probes bis zur NNI/Peering-Kante, um Pfadqualität sichtbar zu machen.
Eine klare Betriebsregel lautet: Wenn EF oder Control im Peering-Port dropt oder wenn Queueing Delay-Perzentile sprunghaft steigen, ist das ein Kapazitäts- oder Governance-Problem – nicht „ein bisschen normal“.
Typische Fehlersignaturen bei Peering-QoS
- Voice/UC schlecht nur zu bestimmten Zielen: Interconnect/Peering-Pfad ist Engpass oder DSCP wird neutralisiert; Pfadsegmentierung und NNI-Probes sind entscheidend.
- EF-Volumen steigt plötzlich: Fehlmarkierung aus dem Internet oder aus Kundendomänen; Trust Boundary verschärfen.
- Video buffering am Abend: Kapazität/Peering-Port überlastet; Ausbau oder Lastverteilung über weitere Peers/Ports.
- QoS „wirkt nicht“: DSCP wird am Peer ignoriert; innerhalb eigener Domäne priorisieren, am Peering konservativ bleiben und Kapazität erhöhen.
- Sporadische Peaks trotz Headroom: LAG/ECMP-Member-Hotspot; Hashing und per-member Telemetrie prüfen.
Praxis-Blueprint: Kapazität und Priorisierung am Peering richtig kombinieren
- Schritt 1: Peering-Typ bestimmen (Public Peering, Private Interconnect, Wholesale) und Trust-Level festlegen.
- Schritt 2: Kapazitätsziele definieren (Perzentile, Peak-Fenster, Headroom) und Ausbaupfade planen.
- Schritt 3: Schlankes Klassenmodell implementieren (Voice/Control/Video/BE), mit klarer Governance gegen Premium-Inflation.
- Schritt 4: QoS am Egress des Peering-Ports umsetzen (Queues, Limits, Gewichte, Queue-Limits).
- Schritt 5: Shaping dort einsetzen, wo Bursts und harte Gegenpolicer wahrscheinlich sind; Policing vorsichtig und servicegerecht.
- Schritt 6: LAG/ECMP-Hotspots überwachen (per-member), Hashing/Entropy optimieren.
- Schritt 7: Monitoring auf Klassenmetriken und Perzentile ausrichten, Active Probes bis zur NNI nutzen.
- Schritt 8: Interdomain-QoS nur dort „handeln“, wo es vertraglich und technisch abgestimmt ist; sonst Kapazität priorisieren.
Häufige Fragen zu QoS für Peering-Links
Kann ich über Peering wirklich garantierte Voice-Qualität liefern?
Nur begrenzt, wenn der Peer DSCP neutralisiert oder keine abgestimmten Klassen anbietet. In der eigenen Domäne können Sie Voice bis zur Peering-Kante stabil halten. Für echte End-to-End-Garantien benötigen Sie vertraglich abgestimmte Interdomain-QoS oder private Interconnects.
Was ist wichtiger: QoS oder mehr Bandbreite?
Mehr Bandbreite und Headroom sind die wichtigste Maßnahme, weil Peering primär ein Kapazitätsproblem ist. QoS ist der zweite Hebel, um in Peaks die Verteilung zu steuern und Echtzeit zu schützen. QoS ersetzt aber keinen dauerhaft überlasteten Peering-Port.
Wie verhindere ich Premium-Inflation am Peering?
Mit einer klaren Trust Boundary: Inbound DSCP aus fremden Netzen nicht blind akzeptieren, DSCP-Whitelist nutzen, Remarking für unerwünschte Markierungen, und Premium-Klassen strikt limitieren. So schützen Sie Voice/Control in Ihrer Domäne, ohne dass fremder Traffic Ihre Premium-Queues füllt.