VPN経由のリアルタイムトラフィックに遅延予算を設定する

リアルタイムVPNへの不満には、失敗を判定する期限が必要であり、「低遅延」は期限ではありません。会話やリモートセッションが何を届けるべきかを決め、その要件に対して明示した条件で経路を測定します。遅延パケットのしきい値がなければ、どの結果も議論の余地があります。以下の配分は設計上の判断であり、測定が答えるべき対象を持つために存在します。

プローブに触れる前に期限を書き留める

期限はアプリとその利用者から来るもので、ベンダーのマーケティングページからではありません。ライブ音声通話、リモートデスクトップセッション、夜間バックアップはまったく異なる待ち時間に耐え、重要な障害は通常、中央値ではなくテールです。その数字を、属するワークロードとともに書き留めます。

次に配分します。キャプチャとパケット化が予算の一部を使い、アクセスリンクとトンネルが別の一部を使い、受信側のデジッターバッファは意図的にパケットを保持し、アプリの処理が残りを使います。これらの段階に名前を付けることで、トンネルの暗号化は、すべての遅いパケットの既定の容疑者にされる代わりに、釣り合った割合に保たれます。

最後に、測定契約を四行で定義します。端点と方向、トラフィックの形、実行中の条件、そして報告する結果です。静かな日曜日のサンプルと負荷のかかった火曜日のサンプルは別の問いに答えるので、どちらを集めたかを明記します。四行すべてを埋められないなら、実行は始める準備ができていません。そのチェックリストは、何も覚えていない数か月後に二つのレポートを比較可能にするものでもあります。

すべての段階に予算を配分する

表は計画の補助であり、取得したデータではありません。最初のプローブの前に各行の担当者を記入します。その段階が取り分を超えたときに電話する相手が担当者だからです。

たいてい二つの行が人を驚かせます。受信バッファが遅延を加えるのは不具合ではありません。設定されたとおりの仕事をしているからです。またトンネルの取り分は、その手前のキューより小さいことが多く、特にアップロード中に飽和する上りリンクではそうです。

段階に担当者がいなければ、予算は虚構です。測定する前に一人を指名してください。さもないと次の会議は、誰の数字が間違っているかの議論に費やされます。

正直な時計で片道遅延を測る

片道遅延は期限が気にする数字であり、両端に同期した時計が必要です。片道遅延のメトリックは、結果とともに同期方式、分解能、推定偏差を報告することを求めます。同期していない二台のホストは、間違った量に対して非常に精密な数字を出せます。

一握りではなく数百パケットを取得し、同じ時点で時計の状態を記録します。

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

往復時間は別の測定であり、片道の値を二つ足し合わせたものではありません。RTTを半分にすることは対称な経路と対称なキューを仮定しますが、モバイル上りリンク上のトンネルはその両方の仮定を日常的に破ります。RTTはRTTとして報告し、片道予算の外に置いてください。

テールと遅延パケットを報告する

分布を要約すると、中央値、95パーセンタイルと99パーセンタイル、最悪ケース、損失、そして期限より遅れて到着したパケットの数です。リアルタイムのワークロードでは平均はこれらの数の中で最も役に立たず、滑らかな平均は三回に一回の通話を台無しにするテールを隠せます。

遅延の変動は受信バッファに直接影響します。バッファを増やすと変動が隠れ、待ち時間が増えるため、ストリームは期限を超えていても安定して見えることがあります。変動の定式化を選び、測定した区間を明記し、実行間で一貫させてください。

代表的なクロストラフィックで実行を繰り返します。アイドル時に予算を満たし、バックアップ時間帯に満たせない経路は、静かな単一の測定では決して明らかにならない、スケジューリングについての有用な事実を教えてくれました。結果の隣に条件を記録しないと、次の技術者は決して比較可能でなかった二つのサンプルを比較することになります。

実際に実行するワークロードの下で測定したテールが予算に収まるときに設計を受け入れ、レポートで超過した段階を名指しして却下します。