Ein Verzögerungsbudget für Echtzeitverkehr über ein VPN festlegen
Beginnen Sie mit der Frist, die die Anwendung einhalten muss, und messen Sie dann Einwegverzögerung und Jitter unter angegebenen Bedingungen. Ein Mittelwert ohne Verspätungsschwelle beweist nichts.
Beschwerden über Echtzeit-VPN brauchen eine Frist, gegen die sie scheitern können, und „niedrige Latenz“ ist keine. Legen Sie fest, was das Gespräch oder die Remote-Sitzung leisten muss, und messen Sie dann den Pfad an dieser Anforderung unter angegebenen Bedingungen. Ohne eine Schwelle für verspätete Pakete ist jedes Ergebnis bestreitbar. Die folgende Aufteilung ist eine Designentscheidung, und sie existiert, damit die Messung etwas zu beantworten hat.
Schreiben Sie die Frist auf, bevor Sie eine Sonde anfassen
Die Frist kommt von der Anwendung und ihren Nutzern, nicht von der Marketingseite eines Anbieters. Ein Live-Sprachanruf, eine Remote-Desktop-Sitzung und eine nächtliche Sicherung vertragen völlig unterschiedliche Wartezeiten, und der Fehler, auf den es ankommt, ist meist der Tail und nicht der Median. Schreiben Sie die Zahl mit der Arbeitslast auf, zu der sie gehört.
Dann verteilen Sie sie. Erfassung und Paketierung verbrauchen einen Teil des Budgets, der Zugangsweg und der Tunnel einen weiteren Teil, der De-Jitter-Puffer des Empfängers hält Pakete absichtlich zurück, und die Anwendungsverarbeitung nimmt den Rest. Diese Stufen zu benennen hält die Tunnelverschlüsselung in Proportion, statt sie zum Standardverdächtigen für jedes langsame Paket zu machen.
Definieren Sie schließlich den Messvertrag in vier Zeilen: Endpunkte und Richtung, Verkehrsform, Bedingungen während des Laufs und das Ergebnis, das Sie berichten werden. Eine ruhige Sonntagsstichprobe und eine belastete Dienstagsstichprobe beantworten verschiedene Fragen, geben Sie also an, welche Sie erhoben haben. Wenn Sie nicht alle vier Zeilen ausfüllen können, ist der Lauf nicht startbereit. Diese Checkliste ist auch das, was zwei Berichte Monate später vergleichbar macht, wenn sich niemand mehr daran erinnert, was die Verbindung sonst noch trug.
Teilen Sie das Budget auf jede Stufe auf
Die Tabelle ist eine Planungshilfe, keine erfassten Daten. Tragen Sie den Verantwortlichen für jede Zeile vor der ersten Sonde ein, denn der Verantwortliche ist derjenige, den Sie anrufen, wenn diese Stufe ihren Anteil überschreitet.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Zwei Zeilen überraschen die Leute meist. Der Empfängerpuffer ist kein Fehler, wenn er Verzögerung hinzufügt, denn er erledigt die Aufgabe, für die er konfiguriert wurde. Und der Anteil des Tunnels ist oft kleiner als die Warteschlange davor, besonders auf einem Uplink, der beim Hochladen gesättigt wird.
Wenn eine Stufe keinen Verantwortlichen hat, ist das Budget Fiktion. Benennen Sie einen, bevor Sie messen, sonst verbringen Sie das nächste Meeting mit dem Streit, wessen Zahl falsch ist.
Messen Sie die Einwegverzögerung mit einer ehrlichen Uhr
Die Einwegverzögerung ist die Zahl, auf die es bei der Frist ankommt, und sie braucht synchronisierte Uhren an beiden Enden. Die Metrik für Einwegverzögerung verlangt, dass Sie Synchronisierungsverfahren, Auflösung und geschätzten Versatz zusammen mit dem Ergebnis berichten. Zwei nicht synchronisierte Hosts können eine sehr genaue Zahl für die falsche Größe liefern.
Erfassen Sie ein paar hundert Pakete statt einer Handvoll und zeichnen Sie den Uhrzustand gleichzeitig auf:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3Die Umlaufzeit ist eine separate Messung, nicht zwei addierte Einwegwerte. Eine RTT zu halbieren setzt symmetrische Pfade und symmetrische Warteschlangen voraus, und ein Tunnel über einen mobilen Uplink bricht beide Annahmen regelmäßig. Berichten Sie RTT als RTT und halten Sie sie aus dem Einwegbudget heraus.
Berichten Sie den Tail und die verspäteten Pakete
Fassen Sie die Verteilung zusammen: Median, 95. und 99. Perzentil, Worst Case, Verlust und die Anzahl der Pakete, die später ankamen, als die Frist erlaubt. Der Mittelwert ist für eine Echtzeit-Arbeitslast die am wenigsten nützliche dieser Zahlen, denn ein glatter Mittelwert kann einen Tail verbergen, der jeden dritten Anruf ruiniert.
Die Verzögerungsschwankung speist direkt den Empfängerpuffer. Mehr Pufferung verbirgt Schwankung und fügt Warten hinzu, sodass ein Stream stabil aussehen kann, während er seine Frist überschreitet. Wählen Sie eine Formulierung der Schwankung, geben Sie das Intervall an, über das Sie gemessen haben, und halten Sie sie zwischen Läufen konsistent.
Wiederholen Sie den Lauf mit repräsentativem Querverkehr. Ein Pfad, der das Budget im Leerlauf einhält und es während eines Backup-Fensters verfehlt, hat Ihnen etwas Nützliches über Planung gesagt, was keine einzelne stille Messung zeigen würde. Notieren Sie die Bedingungen neben dem Ergebnis, denn sonst vergleicht der nächste Ingenieur zwei Stichproben, die nie vergleichbar waren.
Akzeptieren Sie das Design, wenn der gemessene Tail unter der Arbeitslast, die Sie tatsächlich fahren, ins Budget passt, und lehnen Sie es ab, wobei Sie die Stufe benennen, die im Bericht überschritten wurde.