要約

  • RFC 3432 は開始窓 [T,T+dT] から T0 を無作為に選んだが、その後のパケットは名目間隔 incT で Tf まで送った。開始の予測しやすさは減っても、周期標本は無偏な Poisson 標本にはならない。
  • 数字を解釈するには Type-P、遅着を損失とみなす dTloss、有効な singleton の条件、時計とホストの校正、経路、背景トラフィックが必要だった。それらを外した平均値はネットワーク全体の評価ではない。

乱数が決めたのは入口だけだった

測定装置が一時間の開始窓を持ち、窓の中から一時点だけを無作為に引くとする。開始後は二十ミリ秒ごとに一個のパケットを送る。外部から最初の瞬間を当てるのは難しい。しかし、いったん始まれば拍子は明瞭である。

2002年11月の RFC 3432 は、この構造を「Network performance measurement with periodic streams」として標準化した。テキスト版、RFC Editor の記録、IETF Datatracker、履歴、参照関係、正誤表検索 が示すのは測定方法であって、現在の特定回線を採点した報告書ではない。

ほぼ同じ大きさのパケットを一定間隔で送れば、音声や会議のような CBR または CBR に近い流れを模倣できる。密な列は、疎な一般測定が取りこぼす短い遅延変化、連続損失、並べ替えを見つけやすい。周期性は欠陥ではなく、問いに合わせた観測レンズだった。

「既知の偏り」を隠さない設計

RFC 2330 の IPPM 枠組みは、等間隔の singleton が性能の一部しか標本化しないと注意した。一般的な無偏標本が必要なら Poisson 過程が適する。一方 RFC 3432 は、用途に合わせた周期パラメータが「関心のある既知の偏り」を作れるとした。

毎秒五十パケットのメディア風ストリームに対する挙動を知りたいなら、その周期で測ることには意味がある。ただし結論は「この定義済みストリームがどう扱われたか」であり、「このネットワークは常にこうである」ではない。

周期的な障害とプローブの位相が一致すれば、毎回悪い瞬間を踏む。逆に障害の谷間だけを通れば、問題は見えない。規則的な試験流が輻輳を作ったり、他の送信者と同期したり、装置から特別扱いされたりする可能性もある。T0 の独立した無作為抽出は予告と一部の同期を緩和するが、各 incT を無作為化しない。偏りは消えず、開示すべき測定条件として残る。

Type-P は指標名の一部だった

単に「遅延」と書くだけでは足りない。指標は Type-P-One-way-Delay-Periodic-Stream であり、Type-P には IP バージョン、UDP/TCP、ポート、パケット長、優先度、特別な処理条件などが入り得る。パケットが変われば、経路やキューでの扱いも変わり得る。

能動測定で複数サイズを使うなら、対象アプリケーションの分布を再現する必要がある。RFC 2679 と更新版 RFC 7679 は一方向遅延の背景を、RFC 2680 と更新版 RFC 7680 は一方向損失の背景を与える。小さく優遇されたプローブを、別種の実トラフィックの代理にしてはならない。

値がない観測をゼロにしてはいけない

送信側と受信側は時刻、パケット識別子、実サイズを記録する。任意の状態欄でヘッダー破損、ペイロード破損、重複、断片化を区別できるが、分類規則そのものを説明しなければならない。

一方向遅延は受信時刻から送信時刻を引く。送信記録のない spurious packet、受信されなかったパケット、識別不能な破損ヘッダーには有効な遅延値がない。重複時は最初の非破損コピーだけを使う。したがって平均値の分母は有効な singleton に限られ、欠測をゼロに置き換えることはできない。隣接パケットのどちらかに遅延値がなければ、その対の変動も未定義である。RFC 3393 と RFC 5481 は遅延変動の異なる定義と適用範囲をさらに整理した。

受信済みだけの平均が低くても、利用者を苦しめる損失バーストが併存し得る。最も悪い事象が分母から消えている場合、見栄えのよい平均は安全性の証明にならない。

遅着と損失の境界は dTloss が作った

観測中には、届かないパケットと非常に遅いパケットを即座に区別できない。RFC 3432 は最大待ち時間 dTloss を置き、それを超える遅延を損失として解釈した。報告には閾値か、その決定方法が必要である。

再生期限を過ぎた音声パケットは、後で届いても役に立たないかもしれない。別のアプリケーションなら価値が残る。RFC 6673 の往復損失や RFC 6534 の二連パケット損失も、観測手順を損失の意味から分離できないことを示す。同じ到着記録でも dTloss が違えば損失数は変わる。閾値は注記ではなく、主張を作る入力である。

計器自身にも遅延と負荷があった

一方向測定は二つの時計の同期誤差、分解能、ドリフトを引き受ける。ソフトウェアのタイムスタンプはスケジューリングやプロトコルスタックの処理を含み、必ずしも線上時刻ではない。CPU、割り込み、ディスク I/O の負荷は、実際の送信間隔を名目値からずらす。

RFC 3432 は既知の系統誤差を除き、真値が報告値のプラスマイナス e に95パーセント信頼で入る校正誤差を報告するよう求めた。空いている実験台だけでなく、現場に近い測定負荷で校正する必要もある。後の RFC 7312 は高度なストリーム測定を扱い、RFC 2119 は実装間の比較を支える規範語を定義した。

数値と一緒に保存すべき五つの文脈

Type-P、損失とみなす遅延閾値、校正結果、経路、背景条件は結果の一部である。正確な経路は分からないことがある。IP Record Route は対応されず、例外処理によって測定対象を変えてしまうことさえある。それでも最初のリンクなど部分的な手掛かりは有用だ。

IP 層の列だけから、人が聞いた音声品質を断定することもできない。遅着、重複、並べ替え、破損、spurious packet はアプリケーションごとに意味が異なる。

資料が証明する範囲

この読み方は、Heng Lu の現実の層についての議論と動くコードを一次資料とする議論にも沿う。仕様、生成されたプローブ、観測されたパケット、校正済み singleton、集計値、利用者の結果は相互に関係するが同一ではない。

資料は方法を定義する。現在の配備状況、特定経路の障害、QoS 機構、操作意図、普遍的な利用者体験は証明しない。無作為開始は一部の予測可能性を下げるだけで、周期位相も説明責任も消さない。