Latenzzeiten und 200ms
Die Verzögerung von Signalen auf dem Übertragungsweg ist in unserer heutigen Zeit immer ein Ärgernis. In Verbindung mit VoIP und der Übertragung von Audio und Video sind die Grenzen aber noch mal enger gesteckt. Wenn zwei Personen miteinander sprechen und zwischen dem gesprochenen Wort und dem gehörten Wort eine längere Zeitspanne liegt, dann wird das Gespräch weniger harmonisch verlaufen. Das Risiko steigt, dass man sich ins Wort fällt. In der VoIP-Welt werden hier gerne 200ms als Grenzwert angesetzt, wobei das individuelle Empfingen von Menschen natürlich subjektiv ist.
Siehe dazu auch TCP Window Scaling, Latenz und Durchsatz, RWIN
Latenz auf dem Netzwerk
Ehe ich auf die verschiedenen Protokolle eingehe, möchte ich an einem Bild ein paar Feinheiten von Latenz erläutern. Auf dem Bild sehen sie vier Szenarien. Die Legende rechts zeigt, welche Farben welche Stelle repräsentieren.
- Fall 1: Einfache Kommunikation
Hier ist der zeitliche Ablauf einer eine klassische Kommunikation zu sehen. Der Client sendet das Paket los und nachdem es über das LAN gelaufen ist, kommt es beim Service an. Der sendet nach einer Bearbeitungszeit dann die Antwort los, die ebenfalls auf dem LAN verzögert wird. Kaum ist die Antwort angekommen, kann der Client die nächste Anfrage absetzen. Sowohl auf dem Hin als auch auf dem Rückweg ist die Latenzzeit ein verzögernder Faktor - Fall 2: Einfache schnellere
Kommunikation
Das zweite Beispiel ist genau der gleiche Ablauf aber diesmal mit halbierter Latenzzeit. Sie sehen zwar, dass die Pakete in kürzerer Zeit übertragen wurden aber so berauschend schneller ist es doch nicht. Es liegt also durchaus noch Potential im Protokoll selbst.
- Fall 3: Parallele Anfragen
Eine Option ist z.B. die Nutzung mehrerer Verbindungen parallel. Das ist insbesondere hilfreich, wenn unterschiedliche Aufgaben anstehen und damit diese parallel bedient werden können. Schauen Sie mal, wie viele Verbindungen Outlook z.B. öffnet.
Allerdings kostet das natürlich auch viel mehr TCP-Sessions in der Firewall und NAT-Router, was mit Office 365 dann neue Herausforderungen an die Firewall stellt. - Fall 4: Streaming
Die Latenz hat einen sehr geringen Einfluss, wenn der Service die Daten kontinuierlich sendet und quasi keinen Dialog erwartet. Sicher gibt es auch da den TCP-ACK-Handshake, aber der kann durchaus mit einem "Sliding Window" arbeiten, d.h. Pakete kommen weiter, auch wenn die Quittung für das vorherige Paket noch nicht angekommen ist.
Klassische Beispiele sind neben Downloads natürlich auch Streaming-Dienste (Radio, Video, YouTube). Bei YouTube ist aber nicht nur das Netzwerk der Bremser sondern der Empfänger hat ebenfalls einen "Puffer". Sie können ja mal ein Video betrachten und dann die Netzwerkverbindung kappen. Das Video läuft in der Regel noch einige Sekunden weiter. Nur für VoIP ist das gar nicht das, was man erwartet, da hier ja ein Dialog gefordert ist.
Für VoIP ist natürlich nur die Option 2 überhaupt eine Verbesserung, denn nur diese Option schafft es, die Laufzeit und damit die Sprachverzögerung zu reduzieren.
Latenz und Anwendungen
Die Frage der Latenzzeit im Netzwerk stellt sich aber nicht immer in jedem Fall. Ist nämlich sehr von der Anwendung abhängig, on diese auf höhere oder wechselnde Latenzzeiten empfindlich reagiert. Hier ein paar Beispiele:
Anwendung/Protokoll | Empfindlich | Beschreibung |
---|---|---|
DNS- Abfragen |
Unkritisch |
Wenn ein Client zu einem Namen die IP-Adresse auflösen möchte, dann passiert dies meist nur einmalig am Anfang der Verbindung. Zudem nutzen Clients in der Regel einen lokalen DNS-Server, der entweder ein Kopie der Zone als Replikat vorliegen hat oder die Information einmal besorgt und dann im Cache auch an andere Clients ausliefern kann. |
AD-Replikation/AD-Anfragen / NetLogon / Kerberos / Gruppenrichtlinien |
Meist unkritisch |
PCs können sich heute ja sogar "offline" anmelden aber in Firmen ist die Anmeldung am DC immer noch der Regelfall. Aber jeder halbwegs ernstzunehmende Standort hat entweder einen DC vor Ort, der nebenbei vieleicht noch ein kleiner Druckserver/Dateiserver/Softwareverteilpunkt sein kann. |
SMB |
Knifflig |
SMB ist ein sehr altes Protokoll und was primär für LANs gedacht. Daher hat es je nach Version noch Einschränkungen auf WAN-Leitungen. |
Outlook/CachedMode |
Unkritisch |
Wer Outlook im Cached Mode nutzt, greift fast immer auf die lokale OST-Datei zu und merkt eigentlich nichts von einer größeren Latenzzeit. Ausnahme ist z.B. die Anzeige der Frei/Belegt-Zeiten bei Terminplanungen oder die Anzeige der OOF-Regeln. |
Outlook /Online |
Kritisch |
Anders sieht es aus, wenn Outlook z.B. auf einem Terminal Server genutzt wird. |
Terminal Dienste |
Kritisch |
Bei RDP und ICA gibt es keinen Cached Mode. Sicher gibt es hier einen Icon-Cache etc. aber Tastatureingaben und Mausbewegungen gehen nun mal über die Leitung zum Server und kommen als Bild zurück, auch wenn die ein oder andere Optimierung schon stattfinden. |
SharePoint |
Tolerant |
Sicher wirkt eine Webseite "langsam", wenn die Laufzeit auf den Paketen länger ist aber da es sich meist doch um weniger als Sekunden handelt, ist die Reaktion einer Webseite eher eine Frage des Servers und der Leitungskapazität. Das gilt umso mehr beim Download/Upload von Dokumenten in Sharepoint. Diese HTTP-Transfers sind einem Streaming nicht unähnlich. und beim Seitenaufbau profitieren die Anwender von mehreren parallelen Verbindungen zum Download der verschiedenen Webbestandteilen. Bandbreit ist hier also deutlich kritischer als |
VoIP/Lync/Skype für Business |
Sehr kritisch |
Wenn wir mal von Video-Übertragungen absehen, dann benötigt ein Sprachkanal meist weniger als 100kbit. Dies sollten dann aber bitte kontinuierlich und ohne stark schwankende Laufzeiten ermöglich werden. |
NetFlix, YouTube, Mediastreaming |
Unkritisch |
Zuerst könnten Sie vermuten, dass diese Dienste genauso anspruchsvoll sind, wie VoIP. Dem ist aber nicht so, dass es sich hier um eine unidirektionale Kommunikation handelt. Dem Abnehmer fällt es gar nicht auf, wenn die Medien mit einigen Sekunden Verzögerung ankommen. So kann die Wiedergabe einen Buffer pflegen und Aussetzer und veränderte Laufzeiten einfach überspielen. |
Nur weil bei einer Anwendung aber "unkritisch" steht, heißt das nicht, das die Latenz dann in Minuten gerechtet werden darf. Speziell wenn die Bandbreite zu knapp ist, dann geht die Latenz natürlich nach oben.
Latenz und QoS
Bei Autos wird gerne mit dem Spruch kolportiert, dass Hubraum durch nichts zu ersetzen ist als durch mehr Hubraum". Bei Netzwerken könnte der Spruch passen, wenn Sie die Bandbreite als Maßstab nehmen. Und tatsächlich können Schwächen beim Design und der Konfiguration durch viel Bandbreite einige Zeit lang kaschiert werden.
Auf Dauer wird das aber nicht funktionieren, da Bandbreite nicht endlos zu steigern ist und die Kosten mitwachsen. Wenn ich mir die meisten Netzwerkdiagramme anschauen. dann sind diese in den seltensten Fällen voll ausgelastet. Aber eine niedrige Auslastung ist dennoch kein Garant für qualitativ gute Übertragungen für die verschiedenen Anwendungsfällen.
Im Idealfall laufen die Pakete so schnell sie können durch die Netzwerkkomponenten. Eine Leitung ist, abgesehen von der Signallaufzeit, kein Zwischenspeicher im eigentlichen Sinne und Router puffern Pakete in einer Queue nur dann, wenn in die Richtung des nächsten Hops gerade eine Übertragung stattfindet. Aber wenn mehrere Pakete in die gleiche Richtung wollen, dann ist eine Priorisierung nach vorbestimmten Kriterien essentiell, damit z.B. die kleinen VoIP-Pakete zwischen den bandbreitenintensiven Paketen ihre Lücke finden,. vergleichbar einer Schnellkasse am Supermarkt für kleine Einkäufe.
Wenn während Outlook im Cached Mode hier sehr tolerant sind und sich auch durch Laufzeiten über Sekunden nicht stören lassen ist Skype für Business hingegen bei Video und erst Recht bei Audio hier sehr empfindlich. 200ms von Ende zu Ende sind schon grenzwertig und hier muss man die Zeit für Codierung, Kompression und Jitter-Buffer noch einrechnen, so dass auf dem Kabel viel weniger Zeit vergehen darf. <50ms ist anzustreben. Latenz und Bandbreite sind insofern miteinander verknüpft, dass bei einer Sättigung einer Strecke aufgrund des Queueing auch die Latenzzeit in der Regel ansteigt und bei einer Überlastung aus "zu viel Latenz dann schnell mall "Packet Loss" wird.
Latenz-Verursacher
Auch wenn das LAN und insbesondere das WAN einen wesentlichen Anteil an der Latenz haben, gibt es durchaus noch einige andere Stationen zwischen bei Endpunkten, die Pakete verzögern. Hier eine lockere Aufzählung:
-
Headsetaudio Delay
Schon auf dem Weg vom Mikrofon zum Digitalsignal geht Zeit verloren -
Headset
Funkdelay
Wenn die Sprache dann nicht per USB-Kabel sondern per Funk übertragen wird, kostet das wieder ein paar ms -
Audiolaufzeit
Eine Zusammenfassung der Verzögerungen für Audio -
End2End:Bandbreite und Performance
Richtig Messen am Beispiel von Bandbreite und Latenz - A/D-Wandlung/Encoding
Die A/D-Wandlung kostet weitere ms, da hier ja erst mal 20ms empfangen sein müssen, um das Paket dann zu schnüren - Kompression
Wenn statt G.711 ein komprimierender Codec zum Einsatz kommt, dann müssen dennoch die 20ms empfangen worden sein, nur das Ergebnispaket ist dann kleiner. - Netzwerk Leitung
Bandbreite hat nichts mit "Breite" zu tun sondern mit Laufgeschwindigkeit eine schnelle Leitung kann zwar mehr Daten in der gleichen Zeit übertragen, aber wichtiger ist, dass die einzelnen Pakete schneller den Weg zurück legen. - Netzwerk Router -Store and Forward
In den seltensten Fällen ist der Weg über die nächste Station frei, so dass die Bit schon während des Empfangs auf einer Seite an der anderen Seite weiter gereicht werden. Das würde sowieso erst gehen, wenn zumindest der Header mit der Ziel-IP-Adresse auswertbar angekommen ist. Es macht aber dennoch keinen Sinn, dann dann ist noch nicht sichergestellt, dass das Paket komplett und korrekt (Prüfsumme) angekommen ist.
- Netzwerk Queues
Auf dem WAN wird nicht überholt. Wollen also zwei Pakete nahezu zeitgleich los, dann sortiert der Router diese hintereinander ein. Er beachtet dabei Prioritäten (QoS). Dennoch dauert es ggfls. doch ein paar ms, bis das Paket losgesendet wird. - Jitter Buffer
All diese Faktoren sorgen dafür, dass die Laufzeit der Pakete nicht immer identisch ist. Einige Pakete sind schneller, andere langsamer unterwegs und wenn sie immer im gleichen Abstand versendet werden, kommen Sie beim Ziel sicher mit unterschiedlichen Abständen an. Eventuell sogar in anderer Reihenfolge. Daher muss der Empfänger die Pakete wieder sortieren. Aber er verzögert die Wiedergabe, damit es kleine Lücken gibt. Auch das kostet einige ms. Da ein Paket aber 20ms Ton enthält und beim Einsatz von ECC das folgende Paket die Daten auch enthält, muss der Jitter-Buffer mindestens 20ms groß sein. - Decodierung
Aber auch beim Empfänger muss das komplette Pakete natürlich empfangen sein, ehe er es anspielen kann. - Analogweg
Und von der Soundkarte bis zum Lautsprecher gehen natürlich noch ein paar ms über den Funkweg oder USB-Bus verloren.
Es gibt also ganz viele Punkte, die sich auf die Latenz auswirken.
Einfluss des WAN
Ein wesentlicher Faktor bei einem WAN ist die Entfernung. Hier kann eine Tabelle z.B. von Verizon ( Stand Feb 2016 http://www.verizonenterprise.com/about/network/latency/) eine erster Orientierung bieten. Andere Provider dürften ähnliche Latenzzeiten anbieten.
Region | SLA | Min/Max |
---|---|---|
TransAtlantic |
90ms |
70-75 |
Europe |
30ms |
10-12 |
NorthAmerica |
45ms |
34-36 |
IntraJapan |
30ms |
8-10 |
TransPacific |
160ms |
109-111 |
AsiaPacific |
125ms |
94-112 |
LatinAmerica |
140ms |
134-142 |
EMEAtoAsiaPacific |
250ms |
117-167 |
Interessant ist hier, dass im Feb 2016 die asiatische Region schon relativ "langsam" angebunden war. Der Abstand von Europa (EMEA) zu Asien ist mit bis zu 250ms schon per Definition zu weit um VoIP darüber sinnvoll machen zu können. Die echten Daten zeigen zwar, dass es schneller geht aber es ist nicht garantiert.
Aber auch der Weg von Asien an die US Ostküste muss ja einmal über den Pazifik (160ms) und dann natürlich noch mal +45ms über Nordamerika. Diese Zahlen sind insofern relevant, dass ein Office 365 Tenant aktuell immer nur in genau einer Region (EMEA, US, APAC) gehosted wird. Eine Firma mit weltweit verteilten Niederlassungen wird immer ein paar Standorte haben, die lange Laufzeiten haben. Das Thema ist aber primär für Skype für Business relevant.
Im Jahr 2022 hat Microsoft die Firma Lumenisity gekauft, welche Glasfaser mit "Luft" entwickeln. Das Licht wird dabei nicht mehr durch Glas geleitet und an der Kante gebrochen, sondern durch Luft mit Spiegelungen, was wohl eine ca. 30%tige Reduzierung der Latenzzeit bringen kann.
- Microsoft acquires Lumenisity®, an
innovator in hollow core fiber (HCF) cable
https://blogs.microsoft.com/blog/2022/12/09/microsoft-acquires-lumenisity-an-innovator-in-hollow-core-fiber-hcf-cable/ - Hollow Fiber: The New Option for Low
Latency
https://www.nojitter.com/enterprise-networking/hollow-fiber-new-option-low-latency
So viel zu "Latenzzeit ist wichtig"
Latenzen bei WiFi
Unterschätzen Sie aber nicht die Probe im WLAN. Hier habe ich mich an einem öffentlichen HotSpot der Telekom angemeldet und einfach nur das Standardgateway angepingt.
Schon auf der ersten Teilstrecke gibt es hier Schwankungsbreiten von 4ms bis 2270ms. An der Stelle ist es also gar nicht mal der "Uplink" zum nächsten Knoten, sondern schon die lokale Zellengruppe hat wohl einen Engpass oder wird durch viele Geräte oder Fremdsignale gestört. ICMP ist aber im Gegensatz zu TCP nicht verbindungsgesichert. Es ging aber kein Paket verloren was schon bedeutet, dass die Pakete nicht verworfen wurden. Wenn der Link von der Funkzelle zum Default Gateway nicht das Problem war, dann muss es wirklich eine sehr belastete Funkzelle gewesen sein.