Interconnect QoS ist im Provider-Alltag der Punkt, an dem viele QoS-Versprechen „in der Realität ankommen“ – oder scheitern. Selbst wenn ein Telco-Backbone mit sauberem Klassenmodell (EF für Voice, AF für Video, Best Effort für den Rest), konsistentem Mapping und stabilen Queues betrieben wird, kann die Nutzererfahrung bei Voice & Video abrupt einbrechen, sobald der Traffic über Peering oder Transit in fremde Netze übergeht. Genau dort greifen andere Regeln: Manche Partner neutralisieren DSCP konsequent, andere mappen Markierungen in eigene Klassen, wieder andere behandeln alles als Best Effort, weil sie keine Premium-Zusagen über den Interconnect machen. Hinzu kommen harte Realitäten wie rate-limitierte Interconnects, Microbursts an IXPs, asymmetrische Pfade, unterschiedliche Traffic-Engineering-Entscheidungen sowie unklare Verantwortungsgrenzen bei Störungen. Interconnect QoS bedeutet daher nicht nur „Markierung durchreichen“, sondern: QoS über Peering und Transit bewusst zu verhandeln, technisch sauber zu implementieren, an der NNI zu kontrollieren (Trust Boundary, Remarking, Profilierung) und das Ganze mit Messpunkten und operativen Prozessen abzusichern. Dieser Artikel zeigt praxisnah, wie Sie QoS über Interconnects richtig handhaben – von der Vertragslogik über Mapping-Strategien bis zur technischen Umsetzung und zum Monitoring – damit Echtzeittraffic auch außerhalb Ihres eigenen Netzes möglichst stabil bleibt.
Warum Interconnects so oft die QoE dominieren
Viele Echtzeitprobleme wirken wie „Core-Probleme“, sind aber Interconnect-Probleme. Der Grund: Peering- und Transit-Links sind typische Engpässe und gleichzeitig die Stelle, an der Sie am wenigsten Kontrolle über das Gegenüber haben. Typische Effekte:
- Kapazitäts-Hotspots: Interconnects sind bewusst knapp dimensioniert oder wachsen verzögert; Peak-Zeiten treffen zuerst dort.
- Microbursts am IXP: Viele Quellen senden gleichzeitig; kurze Burst-Spitzen erzeugen Queueing Delay und Drop-Cluster.
- Asymmetrie: Hin- und Rückweg laufen über unterschiedliche Partner; QoS wirkt dann nur in eine Richtung.
- DSCP-„Black Hole“: Markierungen werden am Übergang entfernt oder neu interpretiert.
- Routing-Events: BGP-Änderungen verschieben Traffic plötzlich auf andere Interconnects; QoE kippt scheinbar „zufällig“.
Die Konsequenz: Wenn Sie Voice/Video stabil anbieten wollen, müssen Sie Interconnects als Teil Ihres QoS-Designs betrachten – technisch und organisatorisch.
Peering vs. Transit: Unterschiedliche Spielregeln für QoS
Ob QoS überhaupt verhandelbar ist, hängt stark vom Interconnect-Typ ab.
- Settlement-free Peering: häufig „Best Effort“ als Standard; QoS-Zusagen sind selten, Markierungen werden oft ignoriert.
- Paid Peering: mehr Gestaltungsspielraum, weil es eine wirtschaftliche Grundlage gibt; QoS-Optionen sind eher verhandelbar.
- IP Transit: Transitprovider bieten meist standardisierte QoS-Optionen nur eingeschränkt; häufig wird DSCP neutralisiert oder nur intern genutzt.
- Private Interconnect (PNI): technisch am besten für kontrollierbare QoS-Umsetzung, weil die Übergabe dedizierter ist und weniger „Public IXP“-Effekte hat.
Für Echtzeitdienste ist der wichtigste Grundsatz: Je dedizierter und vertraglich klarer der Interconnect, desto realistischer ist echte QoS-Koordination. Bei öffentlichem Peering sollten Sie eher davon ausgehen, dass DSCP nicht zuverlässig erhalten bleibt.
Die zwei Ebenen von Interconnect QoS: Technik und Vertrag
Interconnect QoS funktioniert nur, wenn technische und vertragliche Ebene zusammenpassen.
- Vertragsebene: Welche Klassen sind definiert? Gibt es eine DSCP/CoS-Whitelist? Welche Profile (CIR/PIR) gelten? Welche KPIs werden gemessen?
- Technikebene: Wie werden Markierungen an der NNI behandelt? Wie werden sie auf Queues/Scheduler gemappt? Wo wird geshaped oder profiliert?
Wenn eine der Ebenen fehlt, entstehen typische Missverständnisse: „Wir senden EF“ vs. „Wir transportieren nur Best Effort“, oder „Video ist priorisiert“ vs. „Video ist im Transit nicht gesondert behandelt“.
Trust Boundary an der NNI: Der zentrale Hebel im Interconnect
Die NNI ist die Trust Boundary zwischen zwei Netzen. Hier muss entschieden werden, ob Markierungen akzeptiert, normalisiert oder neutralisiert werden. In der Praxis gibt es drei stabile Modelle:
- Untrusted: DSCP wird auf Best Effort gesetzt; QoS gilt nur im eigenen Netz.
- Conditional Trust: nur definierte Markierungen werden akzeptiert; Überschuss wird remarkt oder profiliert.
- Trusted: Markierungen werden übernommen; nur sinnvoll bei klaren QoS-Verträgen und stabiler Governance.
Für Peering/Transit ist Conditional Trust häufig der beste Kompromiss: Sie vermeiden Missbrauch und halten Markierungen konsistent, ohne Premium völlig auszuschalten.
QoS-Klassen über Interconnects: Weniger ist mehr
Je mehr Klassen Sie über Partnernetze „mitnehmen“ wollen, desto höher ist die Wahrscheinlichkeit von Mapping-Fehlern. Im Interconnect haben sich daher wenige Standardklassen bewährt:
- Voice Media: Real-Time (typisch EF), nur wenn vertraglich akzeptiert und technisch abbildbar.
- Interaktives Video: bevorzugt (typisch AF-Klasse), gewichtet, keine strict priority.
- Signaling/Control: hoch priorisiert, gewichtet.
- Best Effort: Defaultklasse.
Wenn der Partner keine Premium-Klassen annimmt, sollte Ihr Design trotzdem stabil bleiben: Dann muss die Strategie eher auf Kapazität, Pfadwahl und dem Schutz des eigenen Netzes abzielen.
Mapping: DSCP, CoS und MPLS-TC am Interconnect konsistent halten
Interconnects sind häufig multi-layer. Selbst wenn DSCP im IP-Header korrekt gesetzt ist, kann ein Partner nach CoS oder MPLS-TC queueen. Deshalb ist ein Mapping-Standard entscheidend:
- DSCP-Whitelist: Welche DSCP-Werte sind an der NNI zulässig?
- DSCP->CoS: Bei Ethernet-Interconnects müssen DSCP und 802.1p konsistent zusammenpassen.
- DSCP->MPLS-TC: Wenn MPLS/SR genutzt wird, muss die Interconnect-Edge korrekt in TC übersetzen.
- Restore/Remarking: Auf der Egress-Seite muss klar sein, ob DSCP wiederhergestellt, beibehalten oder neutralisiert wird.
Ein praxistauglicher Ansatz ist eine gemeinsame Mapping-Matrix, die pro Klasse die zulässigen Codes und die erwartete Queue-Behandlung beschreibt – nicht nur Zahlen, sondern „Bedeutung“.
Profilierung und Burst-Handling: Warum Interconnect QoS oft bei Peak kippt
Viele Interconnect-Probleme sind Burst-Probleme. An IXPs und Peering-Ports sind Microbursts normal. Wenn Sie dort nur Tail Drop oder harte Policer haben, entstehen Drop-Cluster – für Voice & Video besonders schädlich.
- Shaping am Egress: glättet Bursts und reduziert Drop-Cluster vor rate-limitierten Interconnects.
- Policing vorsichtig: harte Drops erzeugen Cluster; Überschuss besser remarken oder per Drop-Precedence steuern.
- Queue-Limits kontrollieren: zu große Puffer erzeugen Bufferbloat, zu kleine Puffer droppen bei Microbursts.
- WRED/Conestion Avoidance: für Video und Best Effort oft hilfreich, um Tail Drop zu vermeiden und TCP-Synchronisation zu reduzieren.
Für Echtzeit gilt: Voice sollte nicht durch Interconnect-Policer gedroppt werden. Wenn Premium über den Interconnect nicht garantiert ist, ist Kapazitätsplanung und Pfadsteuerung häufig der realistischere Hebel.
Interconnect QoS ohne DSCP-Trust: Was Sie trotzdem tun können
In vielen Peering-Szenarien ist DSCP-End-to-End nicht verlässlich. Das bedeutet nicht, dass Sie machtlos sind. Sie können QoE stabilisieren, indem Sie den Interconnect als Engpass managen:
- Kapazität rechtzeitig ausbauen: Interconnects sind QoE-sensibel; Overprovisioning ist oft günstiger als SLA-Diskussionen.
- Mehrere Peering-Pfade: Redundanz und Traffic Engineering reduzieren Hotspots.
- PNIs für kritische Dienste: dedizierte Übergänge für UC/Voice/Video-Partner sind deutlich kontrollierbarer.
- Service-Edge nahe an Content/Cloud: kürzere Pfade reduzieren Variabilität; weniger Zwischenhops, weniger Jitter-Risiko.
- Monitoring und schnelle Eskalation: klare Alarme bei Queue-Drops und Paketverlust, um schnell zu reagieren.
Diese Maßnahmen sind oft die realistischsten „QoS-Hebel“ in der öffentlichen Interconnect-Welt.
QoS über Transit: Erwartungen realistisch gestalten
Über Transit ist QoS häufig am schwierigsten, weil Sie mehrere Netze in der Kette haben. Selbst wenn Ihr Transitprovider DSCP akzeptiert, kann der nächste Hop es neutralisieren. Deshalb ist ein pragmatisches Ziel:
- QoS im eigenen Netz garantieren: bis zur definierten SLA-Grenze (z. B. bis zum Transit-Übergang).
- Transitzusagen klar eingrenzen: welche Klassen gelten bis wohin, welche Ausnahmen gibt es?
- QoE-Probleme datenbasiert eskalieren: messen, wo Loss/Jitter entsteht, statt pauschal „Transit ist schlecht“.
Wenn echte Premium-Qualität über Transit nötig ist, sind dedizierte Interconnects oder spezielle Partnerverträge meist der bessere Weg.
Messbarkeit und SLA: KPIs am Interconnect sauber definieren
Interconnect QoS braucht klare Messpunkte. Typisch sind Messungen direkt am NNI/Peering-Port und an definierten Service-Edges. Sinnvolle KPIs:
- Latenz und Jitter: idealerweise in kurzen Intervallen, Perzentile statt Durchschnitt.
- Paketverlust: besonders Drop-Cluster sind für Video/Voice kritisch.
- Queue-Drops pro Klasse: zeigen Congestion, Microbursts und falsche Profile.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
- Traffic pro Klasse: erkennt Premium-Inflation oder Fehlmarkierung.
Für managed Voice kann MOS/R-Faktor als Service-KPI hilfreich sein, aber nur, wenn Sie den End-to-End-Pfad ausreichend kontrollieren. In vielen Interconnect-Fällen sind netzseitige KPIs pro Klasse die stabilere Basis.
Operative Koordination: Interconnect QoS ist auch Prozess
Gerade bei QoS über Partnernetze sind Prozesse entscheidend:
- Versionierte Mapping-Tabellen: DSCP/CoS/TC-Mappings müssen dokumentiert und bei Änderungen abgestimmt werden.
- Gemeinsame Testfälle: Markierung, Mapping und Queue-Behandlung vor Produktlaunch validieren.
- Incident-Handshake: welche Daten werden geteilt (Drops, Queue-Depth, Pfadwechsel), wie schnell, in welchem Format?
- Kapazitäts- und Peak-Reviews: Peering-Links regelmäßig auf Peak-Auslastung, Microbursts und Drop-Cluster prüfen.
Ohne diese Governance entsteht Mapping-Drift: QoS bricht „plötzlich“ nach einem scheinbar kleinen Change.
Typische Fehler bei Interconnect QoS
- DSCP wird als garantiert angenommen: Partner neutralisiert DSCP; Voice/Video fallen auf Best Effort.
- Zu viele Klassen an der NNI: Partner kann nicht konsistent umsetzen; Mapping wird fehleranfällig.
- Harte Policer ohne Shaping: Drop-Cluster bei Bursts, Voice knackt, Video friert ein.
- Unklare SLA-Grenzen: Verantwortlichkeiten sind nicht messbar, Diskussionen dauern länger als die Störung.
- Monitoring nur auf Linkauslastung: Queue-Probleme und Microbursts bleiben unsichtbar.
Praxis-Blueprint: QoS über Peering und Transit richtig handhaben
- Interconnect-Typ klären: Peering, Paid Peering, Transit, PNI – daraus realistische QoS-Erwartung ableiten.
- Gemeinsames Klassenmodell definieren: wenige Klassen mit klarer Bedeutung; Voice und Video getrennt.
- NNI als Trust Boundary behandeln: Conditional Trust, Whitelist, Normalisierung, Profilierung pro Klasse.
- Mapping-Matrix festlegen: DSCP/CoS/MPLS-TC konsistent, dokumentiert, versioniert.
- Burst-Handling integrieren: Shaping an rate-limitierten Links, Queue-Limits, optional WRED für Video/BE.
- Messpunkte definieren: KPIs pro Klasse am NNI, Perzentile, Drop-Cluster, Queue-Drops.
- Governance etablieren: Change- und Incident-Prozesse über Partnergrenzen hinweg.
- Kapazitätsstrategie ergänzen: PNIs oder zusätzliche Peering-Pfade für kritische Echtzeitdienste.
Häufige Fragen zu Interconnect QoS
Kann ich DSCP über öffentliches Peering zuverlässig nutzen?
Oft nicht. Viele Peering-Partner neutralisieren DSCP oder behandeln es nicht konsistent. Wenn QoS-End-to-End kritisch ist, sind private Interconnects (PNI) oder vertraglich definierte QoS-Übergaben deutlich realistischer.
Warum knackt Voice häufig genau am Interconnect?
Weil Interconnects typische Engpässe und Burst-Hotspots sind. Ohne Shaping und mit harten Policern entstehen Drop-Cluster. Zusätzlich wird EF häufig an Übergängen nicht korrekt gemappt oder neutralisiert, sodass Voice in Best Effort landet.
Was ist der größte Hebel für stabile Echtzeit über Interconnects?
Ein klares NNI-Regelwerk: wenige Klassen, Conditional Trust, sauberes Mapping und Burst-Handling (Shaping/Queue-Limits). Ergänzt durch Kapazitäts- und Pfadstrategie: ausreichend Interconnect-Kapazität und, für kritische Partner, dedizierte PNIs statt reines Public Peering.
