One-Way Delay messen ist eine der wichtigsten Disziplinen im QoS- und Echtzeitbetrieb, weil Sprach- und Videodienste nicht auf „gefühlte“ Netzqualität reagieren, sondern auf Laufzeit in eine Richtung. Genau hier scheitert der Klassiker „Ping“: ICMP-Ping liefert eine Round Trip Time (RTT), also Hin- und Rückweg zusammen, und sagt damit nur begrenzt etwas darüber aus, wie lange ein Sprachpaket von A nach B wirklich braucht. In der Praxis sind Pfade häufig asymmetrisch (unterschiedliche Routen, unterschiedliche Engpässe, unterschiedliche QoS-Policies pro Richtung). Gerade im Provider-Netz, in VPN/Overlay-Setups, in Mobilfunk-Backhaul oder bei Cloud-Interconnects ist es normal, dass Uplink und Downlink völlig unterschiedliche Delay-Profile haben. Für SLAs, MOS-Optimierung und Troubleshooting ist deshalb One-Way Delay messen unverzichtbar: Es zeigt, ob der kritische Weg im Uplink liegt, ob Bufferbloat den Upstream „klebrig“ macht, ob eine Security-Kette zusätzliche Latenz einbringt oder ob ein bestimmter Metro-Knoten bei Peak-Last Delay-Spitzen erzeugt. Dieser Artikel erklärt, warum Ping nicht reicht, wie One-Way Delay sauber gemessen wird, welche Methoden und Tools sich im Telco- und Enterprise-Umfeld bewährt haben, und wie Sie typische Messfehler vermeiden, die zu falschen Schlussfolgerungen führen.
Was One-Way Delay genau ist und warum es für Echtzeit zählt
One-Way Delay ist die Laufzeit eines Pakets in eine Richtung: von Sender A zu Empfänger B. Für Echtzeitdienste (VoIP, WebRTC, interaktives Video) ist diese Größe entscheidend, weil der Empfängerpaketstrom zeitkritisch ist. Wenn Pakete zu spät eintreffen, entstehen Jitter-Buffer-Unterläufe oder „Late Loss“ – das fühlt sich wie Paketverlust an, obwohl das Paket technisch ankommt.
- Voice: hohe One-Way-Delay-Werte verschlechtern Gesprächsführung, erhöhen Echo-Risiko und reduzieren MOS.
- Interaktives Video: Delay wirkt sich auf Interaktion (Sprechwechsel) und auf Stabilität bei geringem Puffer aus.
- Signaling/Control: Setup-Zeiten (z. B. SIP/ICE) steigen, wenn Control-Flows verzögert werden.
Für das Netzwerkdesign bedeutet das: One-Way Delay ist nicht nur ein „Messwert“, sondern eine Zielgröße, die über Queueing, Shaping und Routing beeinflusst wird.
Warum Ping nicht reicht: RTT ist nicht One-Way Delay
Ping misst RTT: Hinweg A→B plus Rückweg B→A. Das ist nützlich als grober Connectivity-Check, aber nicht ausreichend für SLA-nahe Aussagen. Die wichtigsten Gründe:
- Asymmetrische Pfade: A→B und B→A können unterschiedliche Routen nehmen (Policy Routing, ECMP, Interconnects, Mobilfunkpfade, MPLS-TE/SR-TE).
- Asymmetrische Engpässe: Upstream ist oft knapper als Downstream (Access, DOCSIS, DSL, mobile Uplinks).
- Unterschiedliche QoS pro Richtung: Queues und Shaper wirken pro Egress; ein Richtungspfad kann sauber priorisiert sein, der andere nicht.
- ICMP wird anders behandelt: ICMP kann gefiltert, rate-limitiert oder in Best Effort gequeued werden; Echtzeittraffic nutzt dagegen häufig UDP/RTP oder QUIC.
Ein typischer Fehler ist die Schlussfolgerung: „Ping ist stabil, also ist Voice stabil.“ In Wirklichkeit kann RTT stabil sein, während der Uplink One-Way Delay in Peaks explodiert, weil Bufferbloat im CPE oder Policer im Access greifen.
Asymmetrie in der Praxis: Warum eine Richtung oft „schuld“ ist
In realen Netzen ist Asymmetrie eher Normalfall als Ausnahme. Häufige Szenarien:
- Access-Upstream: Upload ist kleiner und stärker gepuffert; Delay-Spitzen entstehen bei Cloud-Sync, Backups oder Screen Sharing.
- Peering/Transit: Rückweg läuft über anderen Provider oder anderen Interconnect-Port, der anders ausgelastet ist.
- Mobilfunk: Scheduling im Funk und Backhaul kann pro Richtung unterschiedlich wirken; Handover beeinflusst Richtungen anders.
- VPN/Overlay: Outer-Path und Underlay-Routing unterscheiden sich pro Richtung; CPU/Encap kann Richtungseffekte erzeugen.
Ohne One-Way-Messung sehen Sie nur die Summe – und die Summe sagt Ihnen nicht, wo Sie optimieren müssen.
Welche One-Way-Delay-Kennzahlen wirklich sinnvoll sind
Wie bei Jitter gilt: Eine Zahl reicht selten. Für One-Way Delay sollten Sie mindestens diese Kennzahlen betrachten:
- Durchschnitt: gut für Trend, aber oft zu glatt.
- 95./99. Perzentil: zeigt Delay-Spitzen, die MOS und Video-Interaktion dominieren.
- Max/Peak: nützlich für Incident-Korrelation, aber anfällig für Ausreißer.
- Short-Window: z. B. 1s/10s Fenster, um Microbursts und Bufferbloat-Spitzen sichtbar zu machen.
Praxisregel: Für Echtzeit-SLAs sind Perzentile Pflicht. Mittelwerte allein führen zu trügerischer Sicherheit.
Die technische Voraussetzung: Zeit-Synchronisation
One-Way Delay setzt voraus, dass Sender und Empfänger eine gemeinsame Zeitbasis haben. Wenn die Uhren nicht synchron sind, ist One-Way Delay rechnerisch falsch. Das ist der wichtigste Grund, warum viele Teams bei RTT bleiben. In professionellen Netzen ist Zeitdisziplin jedoch lösbar:
- NTP: oft ausreichend für viele Betriebsfälle, wenn sauber betrieben, überwacht und nicht durch Firewalls/Rate-Limits gestört.
- PTP: sinnvoll, wenn sehr präzise One-Way-Messungen nötig sind oder wenn Mobilfunk-/Timing-Disziplin ohnehin PTP nutzt.
- Time-Health: Offset/Drift müssen überwacht werden; sonst sind One-Way-Reports schwer vertrauenswürdig.
Ohne Time-Health-Monitoring ist One-Way-Messung riskant, weil ein Uhrdrift wie „Delay“ aussieht. Deshalb gehört Zeitüberwachung zum Messdesign.
Methode 1: Aktive One-Way-Messung mit TWAMP
Im Provider-Umfeld ist TWAMP (Two-Way Active Measurement Protocol) ein verbreiteter Standard für aktive Delay- und Loss-Messungen. Trotz des Namens kann TWAMP in der Praxis One-Way-Analysen unterstützen, wenn Messpunkte synchronisiert sind. Typische Stärken:
- Standardisiert und SLA-tauglich: gut für Reporting, NOC-Runbooks und Vergleichbarkeit.
- Messung pro Klasse möglich: Probes können DSCP-markiert werden (Voice/EF, Video/AF, Best Effort), um QoS-Wirkung zu prüfen.
- Segmentierung: Messungen zwischen PoPs, Access-Aggregation, Metro-Knoten und NNI sind gut operationalisierbar.
Wichtig ist der Aufbau: TWAMP nur im Core zu messen ist selten genug. Die meisten Delay-Spitzen entstehen im Access/Metro oder an rate-limitierten Übergängen.
Methode 2: UDP-Probes im „RTP-Stil“
Wenn Sie Voice-Realität abbilden wollen, sind UDP-Probes mit definiertem Paketabstand sehr effektiv. Sie können z. B. 50 Pakete pro Sekunde (20 ms Intervall) senden und so ein Voice-ähnliches Timing simulieren. Vorteile:
- Dienstähnlich: Timing und Paketgröße lassen sich so wählen, dass sie RTP/SRTP ähneln.
- DSCP-Tests: EF/AF/BE können gezielt getestet werden, um Markierungs- und Queueing-Loops aufzudecken.
- Feinauflösung: Delay-Spitzen in Sekundenfenstern werden sichtbar.
Für Provider ist das besonders nützlich, um Microbursts und Queueing-Delay-Spitzen an Engpässen sichtbar zu machen, die Ping nie zeigen würde.
Methode 3: Ethernet-OAM bei L2-dominierten Services
In Carrier-Ethernet-Umgebungen (Metro/Access) wird One-Way Delay häufig als Delay Variation und One-Way Delay auf Layer 2 betrachtet. Wenn der Dienst primär Ethernet-basiert ist und QoS über 802.1p CoS wirkt, ist Ethernet-OAM sehr aussagekräftig.
- L2-nahe Sicht: zeigt Delay-Spitzen in Metro-Ringen und Aggregationssegmenten.
- CoS-Korrelation: Messungen pro Serviceklasse im Ethernet-Kontext sind möglich.
- Wholesale-/Business-Ethernet: passt gut zu SLA-Formulierungen in Carrier-Ethernet-Produkten.
Für IMS/VoIP-Services sollten Sie diese Sicht dennoch mit IP-/RTP-nahen KPIs ergänzen, weil Tunnel, Firewalls und IP-Routing zusätzliche Delay-Quellen sein können.
Methode 4: Passive Messung aus Diensttelemetrie (RTCP, SBC, IMS, UC Analytics)
Wenn Sie echte Sprach- und Videosessions haben, liefern RTCP und Plattform-Analytics wertvolle Hinweise. Sie messen zwar nicht immer „One-Way IP Delay“ im strengen Sinn, aber sie geben Richtungssicht und QoE-Korrelation.
- RTP/RTCP-Reports: Jitter, Loss und oft Delay-ähnliche Indikatoren aus Sicht der Endpunkte.
- MOS/R-Faktor: zeigt, ob Delay/Jitter/Loss in der Praxis relevant werden.
- Call Setup Times: Delay in Control/Signaling zeigt sich hier oft früh.
Diese Daten sind besonders stark, wenn Sie sie mit Netzmetriken korrelieren (Queueing Delay, Policer Events). Dann wird aus „Qualität schlecht“ eine klare Ursache.
Methode 5: Queueing Delay als One-Way-Delay-Ursache messen
Viele One-Way-Delay-Spitzen entstehen durch Queueing, nicht durch physische Distanz. Deshalb ist Queueing Delay in Routern/Switches/Firewalls ein Schlüsselindikator. Zwar ist Queueing Delay nicht identisch mit One-Way Delay, aber es erklärt die Peaks, die Echtzeit zerstören.
- Queue Depth/Queueing Delay pro Klasse: zeigt, wann Voice/Video warten mussten.
- Perzentile: 95./99. Queueing Delay ist oft der beste Frühindikator für kommende QoE-Probleme.
- Scheduler Share: zeigt, ob Klassenbudgets eingehalten werden.
Praxisregel: Wenn One-Way-Delay-Spitzen auftreten, finden Sie fast immer eine korrelierende Queueing Delay-Spitze auf einem Engpassinterface – besonders am Upstream.
Warum Ping besonders bei QoS-Tests irreführend ist
Viele nutzen Ping, um „QoS zu testen“. Das klappt selten zuverlässig. Gründe:
- ICMP-Klasse: ICMP wird in vielen Netzen nicht wie Voice/Video behandelt und kann in Best Effort oder sogar in einer Control-Policer-Klasse landen.
- Rate-Limits: ICMP wird oft gedrosselt, wodurch RTT-Jitter entsteht, der nichts mit Echtzeit zu tun hat.
- Paketgröße: Standard-Ping nutzt kleine Pakete; echte Engpassprobleme treten oft bei größeren Frames oder bei Bursts auf.
- CPU-Pfad: auf manchen Geräten wird ICMP anders verarbeitet als Forwarding-Traffic, was Messwerte verfälscht.
Wenn Sie QoS testen wollen, nutzen Sie DSCP-markierte UDP-Probes oder TWAMP mit Serviceprofilen. Damit testen Sie das, was Ihre Echtzeitklassen wirklich erleben.
Messdesign: Wo und wie oft Sie messen sollten
One-Way-Delay-Messung ist nur so gut wie die Messpunkte. Provider-typische Pflichtpunkte sind:
- Access-Aggregation: hier entstehen viele Peaks durch Überbuchung und Microbursts.
- Metro-Knoten: CoS-Queuing und Ringlast, häufige Hotspots.
- Core-PoPs: Baseline und Pfadvergleich; weniger häufig Engpass, aber wichtig für End-to-End.
- NNI/Interconnect: Übergang zu Partnern/Transit; häufige SLA-Grenze.
Messfrequenz: Für SLA und Incident-Korrelation sind Sekundenfenster sinnvoll. Zu grobe Intervalle verschlucken Peaks. Gleichzeitig sollten Probes klein bleiben, um das Netz nicht zu belasten.
Interpretation: Delay, Jitter und Loss hängen zusammen
In Echtzeitnetzen treten Probleme selten isoliert auf. One-Way Delay ist eng gekoppelt an Jitter und Loss:
- Hoher One-Way Delay ohne Drops: häufig Bufferbloat; MOS sinkt durch erhöhte Interaktionslatenz.
- Delay-Spitzen + Drops: Congestion mit Tail Drops; Voice knackt, Video friert ein.
- Delay-Spitzen ohne sichtbare Drops, aber QoE schlecht: Late Loss; Pakete kommen zu spät, werden verworfen.
Deshalb ist es sinnvoll, One-Way Delay gemeinsam mit Queueing Delay und dienstnahen KPIs zu betrachten, statt isoliert eine „Ping-Zahl“ zu diskutieren.
Typische Fehler bei One-Way-Delay-Messungen
- Keine Zeitdisziplin: Uhren driftig, One-Way-Werte unbrauchbar.
- Nur RTT betrachtet: Richtungseffekte bleiben unsichtbar, falsche Maßnahmen werden gewählt.
- ICMP als Proxy: Ping spiegelt QoS für RTP/Video nicht zuverlässig wider.
- Zu grobe Auflösung: 5-Minuten-Aggregate übersehen Microbursts und Bufferbloat-Spitzen.
- Keine Klassenmessung: ohne DSCP-tagged Probes erkennen Sie Mapping-Loops und Premium-Inflation zu spät.
- Messpunkte falsch gesetzt: nur Core gemessen, obwohl der Engpass im Access liegt.
Praxis-Blueprint: One-Way Delay messen, SLA-tauglich und operativ
- Zeitbasis stabilisieren: NTP/PTP sauber betreiben und Time-Health überwachen.
- Pro Serviceklasse messen: EF (Voice), AF (Video), BE (Standard), um QoS-Wirkung zu validieren.
- Aktive OAM nutzen: TWAMP oder UDP-Probes mit Sekundenauflösung und Perzentilen.
- Segmentieren: Access→Metro, Metro→Core, Core→NNI getrennt messen, um Richtung und Ort zu isolieren.
- Mit Queueing korrelieren: Queueing Delay/Depth und Drops pro Klasse als Ursachenmetrik.
- Mit Dienst-KPIs verknüpfen: RTCP-Jitter/Loss, MOS, Setup Times, Freeze-Events für die Nutzerwirkung.
- Alarmregeln definieren: Perzentile und Peaks als Trigger, nicht nur Mittelwerte.
Häufige Fragen aus dem Betrieb
Kann ich One-Way Delay ohne PTP messen?
Ja, wenn NTP sauber betrieben und überwacht wird, kann es für viele Zwecke ausreichend sein. Wenn Sie jedoch sehr präzise One-Way-SLAs oder sehr kleine Delay-Budgets nachweisen müssen, ist PTP oder eine sehr strenge Zeitdisziplin empfehlenswert. Entscheidend ist, dass Sie die Time-Health als Teil der Messung überwachen.
Warum sieht Ping gut aus, aber Voice ist schlecht?
Weil Ping RTT misst und ICMP häufig anders behandelt wird als RTP. Voice leidet oft an Upstream-Bufferbloat, Queueing Delay-Spitzen oder Policer-Drops, die in RTT-Mittelwerten nicht sichtbar sind. One-Way-Tests mit DSCP-markierten UDP-Probes zeigen diese Effekte deutlich besser.
Welche Messung ist für Provider am praxisnächsten?
Eine Kombination: aktive One-Way-Messung pro Klasse (TWAMP oder UDP-Probes) an den richtigen Messpunkten plus Queueing Delay/Drops pro Klasse als Ursachenmetrik. Ergänzt um RTCP/MOS aus IMS/SBC erhalten Sie sowohl SLA-Nachweis als auch schnelle Root-Cause-Fähigkeit.
