Traffic Simulation

Wenn Sie Lync einführen, dann addieren Sie "Real Time-Protocol" (RTP) in ihrem Netzwerk, für den besondere Voraussetzungen gelten. Zumindest wenn Sie ein erfolgreiches Lync-Projekt mit Audio/Video umsetzen wollen. Diese Seite bescheint, wie sie mit einer Simulation die Eignung ihres Netzwerks überprüfen und später überwachen können.

Hinweis:
Die Simulation durch echte Last und deren Auswertung kommt erst nach der Bandbreitenberechnung. Siehe auch Network Assessment.

Relevante Messwerte

Eine Simulation macht natürlich erst Sinn, wenn sie wissen was wir müssen wollen:

Kriterium Beschreibung Gut/Mittel/Schlecht
Laufzeit / Latenz / Roundtrip (RTT)

MAX und AVG

Die Laufzeit der Pakete von einem System zum anderen System ist sehr wichtig, da sie direkt hörbar wird. Mehr als 200ms wird schon deutlich als Verzögerung bemerkt und führt oft dazu, dass sich die Teilnehmer ins Wort fallen. Es ist nicht einfach dies in eine Richtung zu müssen, da dazu beide Stationen eine auf wenige Millisekunden synchrone uhrzeit haben müssen. Daher wird oft ein "Roundtrip" gemessen, bei der die Gegenstelle sofort antwortet.

Laufzeit ist von der Entfernung (Signallaufzeit < Lichtgeschwindigkeit) und die Anzahl der Hops (Store and Forward) abhängig. 160ms ist zwischen Peking und Frankfurt schon sehr gut, zwischen Frankfurt und Paris aber sehr schlecht. Es besteht also Interpretationsbedarf.

Idealerweise wird die Laufzeit getrennt nach Richtung ermittelt, was aber hohe Ansprüche an die Zeitbasis stellt.

<200ms
>200ms
>500ms
Jitter / Misordering

AVG

Nicht alle Pakete nehmen den gleichen Wege, und so weichen die Laufzeiten der einzelnen Pakete voneinander ab. Es kann sogar passieren, dass Pakete "überholen". Der Jitter-Buffer am Ziel sortiert die Pakete richtig ein aber wartet natürlich nicht ewig auf ein Paket. Zumindest nicht wenn UDP (default) zum Einsatz kommt. Wird TCP genutzt, macht der IP-Stack diese Arbeit und fordert im schlimmsten Fall die Pakete überflüssigerweise noch mal an. Ein Grund warum VoIP over VPN (TCP gesichert) ineffektiv ist. Lync nutzt einen Jitter-Buffer von bis zu 120ms.

Der Max Jitter ist sekundär wenn man Jitter> Jitterbuffer als "PaketLoss" zählt.

<20ms
>30ms
>45ms
Paketloss (Max und Avg)

PacketLoss passiert immer dann, wenn ein Paket zu spät oder nie ankommt. Es ist bei Routern mit QoS durchaus erlaubt, Pakete zu verwerfen. Bei TCP-Verbindungen ist das natürlich kontraproduktiv, da die fehlenden Pakete vom Empfänger bemerkt und wieder angefordert werden. Bei VoIP ist es aber durchaus tolerierbar mal ein Paket zu verlieren. Der Mensch überhört so etwas und beim Video ist es kurzfristig das Bild etwas verwaschener und hängt. Aber auch hier sollten gewisse Grenzen nicht überschritten werden.

Der MAX-Wert kann man z.B. pro Minute ermitteln, denn der AVG-Wert kann viele temporäre Aussetzer innerhalb einer Minute nicht sauber darstellen, z.B.: von 50 Pakete sind 3 hintereinander weg, dann sind das 6% aber gehört 60ms Verlust

<3%
>5%-7%
>10%

Wobei sie diese Werte nicht "Absolut" betrachten sollten, sondern miteinander verknüpft werden müssen. Wenn ein Paket so spät kommt, dass es nicht mehr passend eingespielt werden kann, dann ist das zwar aber eine "große Laufzeit" aber könnte genauso gut als "Paketloss" eingestuft werden.

Eine Simulation hat aber nicht die Aufgabe eine Bandbreite zu müssen. Das kann eine Simulation nicht leisten, da die Bandbreite ja nicht "frei" und unbelastet ist. Sie könnte also eh nur müssen, wie viel Bandbreite von diesem Prozess genutzt werden könnten. Die Bandbreite wird definiert durch die WAN-Betreiber und die QoS-Konfiguration beschrieben und der Bedarf kann durch den Bandbreitenkalkulator geschätzt werden. Eine Simulation kann diese Daten natürlich nutzen, um eine vergleichbare Last auf die Leitung zu legen

Die Frage einer "Congestion" kann nur indirekt gemessen werden, da sie nur auftritt, wenn eine Überlastsituation anliegt. Ohne einen "Stau" kommen Prozesse zur Gewichtung, Priorisierung und Buffering gar nicht erst zum Einsatz.

Insofern ist auch ein "PING" bei einem unbelasteten Netzwerk kein gültiger Test, da Standard-ICMP-Pakete nur 64byte (statt 160 Byte bei RTP) lang sind, ein andere Protokoll (ICMP statt UDP/TCP) nutzen und damit auch keine Ports nutzen. Alle Regeln bezüglich QoS sind damit nicht vergleichbar.

Probe Platzierung

Die Simulation kann nicht auf dem Papier erfolgen. Wer WAN-Leitungen proben möchte, muss entsprechende Gegenstellen verteilen und steuern. Gerade im WAN mit vielen Standorten an verschiedenen Orten ist es nicht immer einfach eine Hardwareprobe überall zu platzieren. Das kann am Netzteil (110V vs. 230V, Steckverbinder, Regularien/Zulassungen) scheitern, teilweise an politischen Beschränkungen (z.B. sind israelische Geräte kaum in arabischen Staaten importierbar) oder auch einfach am Netzwerkport. Probes unterstützen meist keine 802.1x-Authentifizierung oder es gibt einfach keinen freien Port mehr.

Es mach auch keinen Sinn alle Standorte und Subnetze mit Proben zu versehen. Also suchen wir nach "repräsentative Sites" und nach "wichtigen Sites", die sinnvolle Ergebnisse liefern. Wichtig sind z.B.

Hierbei muss auch beachtet werden,. dass Standorte an eine "Wolke" (MPLS) angebunden sein können und ihre lokalen Link damit belasten und die Reduzierung auf eine Teilmenge z.B. die Last auf der zentralen Site niedriger ausfällt. Nur wenn Standorte mit einer dedizierten 1:1 Verbindung arbeiten, sind diese Abhängigkeiten nicht vorhanden.

Innerhalb eines Standorts gibt es natürlich auch noch unterschiedliche Stellen, eine Probe zu platzieren. Wird diese im Serverraum am Serversegment angeschlossen, was für für eine Simulation der Last zu einer Konferenz-MCU spricht oder sollte die Probe doch besser "im Feld" installiert werden, um die Situation an einem Client nachzustellen. Hoffentlich erwischen Sie dann auch ein "repräsentatives" Netzwerksegment und nicht das CAD-Segment, in dem leistungsstarke Clients große CAD-Daten übertragen und damit den Trunk zwischen Etagenswitch saturiert.

Die sinnvolle Auswahl hat auch das Ziel die Anzahl der Probes zu reduzieren, was zum einen Kosten und Installationsaufwand reduziert aber auch den Betrieb und die Auswertung vereinfacht. Laut Microsoft sollten Sie mit maximal 20 Probes arbeiten, eher viel weniger. Relevant sind "kritische Sites" laut Bandwidth Calculator.

Achtung: Simulationsproben sind keine Monitoring-Probes, die Datenverkehre mitschneiden um Probleme zu analysieren. Um eine bereits etablierte VoIP-Umgebung auf Fehler zu überprüfen, müssen Sie einen ganz anderen Ansatz wählen, der hier nicht weiter beschrieben wird.

Nun gibt es in Lync natürlich auch immer Personen, die unterwegs sind und damit Bandbreite über den Internet-Link nutzen. Nun ist das Internet generell (noch) nicht QoS gesichert und eine Probe an einem kleinen DSL-Anschluss kann keine 1000 Benutzer simulieren. Hier wird man "rechnen und schätzen" aber letztlich nicht simulieren.

Ebenso wenig können sie sinnvoll eine Probe für "Telefonie-Verbindungen" platzieren. Die Leitungen und die Gateways sind vor der Installation von Lync gar nicht vorhanden oder durch die bestehende TK-Anlage belegt.

Wie kann man simulieren und müssen ?

Achtung bei Migrationen
Wenn in der Umgebung schon VoIP genutzt wird, dann sollten Sie dessen Daten heran ziehen und die aktuelle VoIP-Last mit einrechnen. Nicht dass sie plötzlich doppelt so viele Gespräche simulieren und die Ergebnisse erschreckend schlecht sind.

Also stellt sich die Frage wie man sinnvoll simulieren und testen kann, damit die Ergebnisse auch aussagekräftig sind. Natürlich muss man zuerst den Überblick über die WAN-Verbindungen haben und definieren, welche VoIP-Last zu erwarten ist um dann daraus die Maximalbandbreite pro Link festzulegen. Allerdings müssen Sie gar nicht diese volle Bandbreite simulieren, denn die haben Sie ja errechnet und wird gefordert und muss bereit gestellt werden. Interessanter ist ob das System mit der zur Simulation bereitgestellten Kapazität bezüglich Jitter, PacketLoss und Laufzeit die gesetzten Erwartungen erfüllen kann.

Dazu müssen wir aber schon Daten senden, die möglichst auch von den Routern und QoS-Systemen als gültige VoIP-Pakete angesehen werden und gemäß der Konfiguration mit DSCP-Klassen bzw. QoS-Prioritäten versehen werden. Einige Kommerzielle Tools simulieren wirklich synthetische Anrufe und übertragen auch Audiodaten mit dem entsprechenden Codec. Wenn der Codec mit Lync nicht übereinstimmt ist das aber nicht kritisch, da man die Bandbreiten entsprechend umrechnen kann.

Dann sollte der Test natürlich über einige Tage laufen und nicht gerade in der Urlaubszeit, bei Feiertagen oder Betriebsferien stattfinden. Ideal ist der Test nur dann, wenn auch die "Busiest Hour" im Prüfungsfenster ist. Natürlich sollte man die Simulation über die komplette Zeit durchführen, also durchaus 24x7 über mehrere Tage.

Sie müssen sich überlegen ob die Simulation gleich mit 100% arbeitet oder ob sie langsam die Last ansteigen lassen. Auf der einen Seite können Sie sagen, dass später die Clients auch keine Rücksicht nehmen. Auf der anderen Seite können Sie den Einfluss bei einer falschen WAN-Konfiguration so lange erahnen. Nur wie steil darf dann die "Rampe" sein?. Reicht es, wenn sie die erste Stunde nur 20% Last anlegen, dann 50%, 70% und erst dann 100% ?. Was passiert, wenn das Problem erst einige Stunden später auftritt, wenn eine andere Last dann erst dazu kommt?

Ebenso können Sie überlegen, ob die Last wirklich dauerhaft auf gleichem Niveau anliegen soll, oder ob sie vielleicht die Betriebsabläufe nachbilden und die Last außerhalb der Arbeitszeit an die späteren Gegebenheiten anpassen. Gerade wenn Nachts andere Prozesse (Dateitransfer, Backup, Softwareverteilung) dazu kommen, ändern sich wieder die Randparameter.

Genauso sollten Sie alle Beteiligten informieren und ansprechbar sein. Denn wenn die Simulation ein echtes Problem im Netzwerk verursacht, muss jemand den "NOTAUS"-Schalter drücken. Allerdings ist genau das auch das Ziel einer Simulation mit echter Last, weil sie diesmal noch die Last schnell herunternehmen können um die Fehlkonfiguration bei QoS o.ä. zu korrigieren. Sobald Lync produktiv ist ist so eine Korrektur deutlich hektischer. Die Simulation ist also vor allem auch ein Test für die Netzwerkadministratoren, die idealerweise ihren Teil der Überwachung beisteuern.

Modality: P2P oder auch Konferenz und was ist mit Sharing ?

Ideal wäre es natürlich, die komplette Last einer Lync-Umgebung zu simulieren. Das geht ohne Server aber nicht so einfach und man muss auch überprüfen, ob es denn überhaupt erforderlich ist. Eine Konferenz kann auch als P2P-Verbindung zwischen den Teilnehmern und der zentralen MCU dargestellt werden. Das stimmt aber nicht ganz, denn in einem Meeting müssen nicht alle auch Daten senden, wenn z.B. die Teilnehmer "stumm"-geschaltet sind oder ihr Video pausiert ist.

Datenverbindungen wie bei Desktop-Sharing oder Powerpoint-Sharing anfallen, zählen aber nicht mehr als RTP-Verkehr. Oft werden diese Daten auch bezüglich QoS nicht mehr als priorisierter Verkehr behandelt.

Kritisch sind primär natürlich Audio-Verbindungen und daher sollte die Simulation auf jeden Fall diese Payload priorisiert betrachten. Aber die Schwerpunkt können natürlich von Kunde zu Kunde unterschiedlich sein.

Testen im im Betrieb (=Monitoring)

Eine Simulation vor der Einführung ist natürlich ideal. Die Realität sieht aber anders aus, ,z.B.

  • Es gibt schon VoIP
    Vielleicht wird die Leitung schon per VoIP durch ein anderes Produkt belegt, welche durch die Einführung von Lync abgelöst werden soll.
  • Es gibt schon Lync
    In dem Fall ist natürlich der Lync Monitoring Server die erste Anlaufstelle um Probleme und Lastsituationen zu erkennen.

In beiden Fällen können Sie nicht erneut die erwartete "Last" auf die Leitung legen, denn dies würde die Leitungen komplett überlasten. Monitoring kann über andere Wege erfolgen, z.B. die Queues der Router, die Daten des Lync Monitoring Servers oder durch Monitoring-Geräte, die Pakete mitschneiden und analysieren.

Aber auch mit den Simulationsprobes kann eine indirekte Überwachung erfolgen. Die Simulation darf nun nur nicht zu viel Pakete erzeugen und damit stören.

Ein VoIP-Call sendet ein Paket alle 20ms mit 160bytes Nutzlast so dass pro Sekunde 50 Pakete mit 8kByte = 64Kbit übertragen werden. In der Simulation werden viele Anrufe simuliert. Im Betrieb könnte die gleiche Probe aber einfach eine minimale Grundlast auf die Leitung legen. Wenn die Probe nur 10 Pakete/Sek mit 160Bytes sendet, dann werden 1,6kBit/Sek übertragen, was jede Leitung verkraften sollte. Der große Vorteil ist aber, dass die Gegenseite beim Empfang erkennen kann, ob Pakete in dieser Situation nicht die Qualität bezüglich Jitter, Laufzeit und PacketLoss einhalten und entsprechend alarmieren.

Tools

Leider gibt es von Microsoft hier keine Tools oder Werkzeuge, um solch eine Simulation auszuführen. ich frage mich natürlich, warum es nicht zumindest einfache Testgeneratoren gibt. für verschiedene andere Plattformen habe ich das ja schon selbst gebaut. Siehe End2End-File und andere. Ein einfacher End2End-Ping reicht aber nun nicht, wie sie weiter oben gelesen haben. Also müssen wir nach anderen Lösungen suchen. Ein paar Ideen:

  • UCMA ?
    Mit der Unified Communication Managed API stellt Microsoft einen kompletten SIP-Stack für Windows bereit, der sogar ohne Lync funktioniert. Er kann selbst z.B. auf Port 5060 lauschen und ein anderes System mit UCMA könnte den Call ausführen. Aber es gibt keine passende Software dafür
  • Automated Lync Client/SilentCall
    Über die Lync Client API könnte man auch entsprechende Calls aufsetzen und damit sogar im Monitoring-Server ablegen lassen. Dazu müsste aber schon Lync als Server mit Monitoring und die komplette Infrastruktur installiert sein.
    Ganz genial fände ich, wenn man einen Lync Client "Silent" anrufen kann und dieser die Verbindung mit niedriger Bandbreite einfach hält und z.B. das gesendete Audiosignal wieder zurücksendet. So könnte man jeden Lync Client zur Monitoringprobe aufbohren.
  • Router als Testsystem
    Es gibt verschiedene Router, die in ihrer Firmware auch grundlegende Testfunktionen enthalten. So gibt es in bestimmten Cisco-Routern entsprechende Funktionen
    http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/15-mt/sla_call_setup_voip.html

So kommen wir also erst mal nicht weiter. Natürlich gibt es auch verschiedene kommerzielle Tools, die bei Kunden eingesetzt werden können. Die Auflistung erhebt keinen Anspruch auf Vollständigkeit

Weitere Links