要約

  • RFC 3393はIPDVを、選択した2パケットの片方向遅延の差として定義し、単一の値と、その値から作るサンプル・統計を分けた。
  • RFC 4148はIPPMメトリクスの登録を試みたが、RFC 6248はType-Pやメトリクス、ストリームの選択肢が測定の一意な識別を妨げると判断した。RFC 8911は固定パラメーターと実行時パラメーターを分け、登録要件を厳密にした。

2002年、IP Performance Metricsワーキンググループは、経路上のあらゆる遅延変動を一つの数値に押し込めようとはしなかった。RFC 3393はまず単一測定を定義する。二つの測定点を通るパケットを二つ選び、後のパケットの片方向遅延から先のパケットの遅延を引く。どの二つを選ぶかは重要だ。連続したパケットでも、指定した番号のパケットでも、明示された別の規則で選んでもよい。この単一値は分布でも、パーセンタイルでも、サービス品質の判定でもない。RFC 3393は別にポアソンストリームのサンプルと統計を定義し、結果の意味が分かるよう各パラメーターの記載を求めた。RFC 3393

柔軟さは意図的だった。用途や実験によって、パケット種別、ペアの選び方、統計的な要約は異なり得る。差分測定なら端点間の一定の時計オフセットを相殺できるとも説明する一方、時計のスキューやドリフト、パケット間隔、測定誤差は別に扱う。つまり結果の意味は、名称だけでなく、観測を組み立てる選択に左右される。「jitter」という言葉も一義的ではない。RFC 3393が「遅延変動」を好むのは、信号工学と計算機分野で同じ語が異なる意味を持つからだ。

3年後のRFC 4148は、IPPMメトリクスを登録簿にまとめようとした。定義済みのメトリクスにOBJECT-IDENTITIESを割り当て、遅延や損失などと並んでRFC 3393の遅延変動も載せた。安定した識別子があれば、仕様をまたぐ参照は容易になる。しかし登録簿は、Type-Pパケットの性質、メトリクスのパラメーター、ストリームのパラメーターが持つ可変性を引き継いだ。短い識別子だけで、結果を左右する選択すべてを固定することはできなかった。RFC 4148

2011年、RFC 6248は問題を明示した。登録簿の構造ではIPPMメトリクスを一意に識別できないとして、RFC 4148とIANA登録簿をObsoleteにした。パケット種別、メトリクス・パラメーター、ストリーム・パラメーターの全組み合わせを登録することは現実的でも有用でもない、と説明する。さらに旧登録簿について「利用者はほとんどいない、あるいはいない」と述べ、2010年後半に利用希望を募っても返答がなかったと記す。これは登録簿についての判断であって、遅延変動の測定自体に利用者がいなかった証拠ではない。従来の登録内容は保存され、新規登録だけが止まった。RFC 6248

教訓はパラメーターを消すことではなく、どれを定義に固定し、どれを測定の実行時に選べるようにするかを決めることだった。後のRFC 8911によるPerformance Metrics Registryは、固定パラメーターと実行時パラメーターを区別する。固定値を変えれば別の登録済みメトリクスになる一方、実行時の値は測定エージェントがその都度受け取れる。また候補が人に解釈でき、実装・展開でき、運用上有用で、同等の結果を支えられるほど厳密かを問う。RFC 8912は初期エントリーを登録した。設計の重点は変わった。カタログには名前だけでなく、別の主体が測定を選び、実行するための方法も書く必要があった。RFC 8911 RFC 8912

RFC 4148の廃止によってRFC 3393自体が廃止されたわけではない。後の登録簿も、すべてのIPDV結果が比較可能であると保証するものではない。大切なのは、メトリクスという概念と、実行可能な選択肢の集合である測定方法を区別することだ。登録簿がその調整を担うには、何が固定で、何が可変で、結果をどう読むかを示さなければならない。

出典

RFC 3393情報 · RFC 3393本文 · RFC 4148 · RFC 6248 · RFC 8911 · RFC 8912 · RFC 5481 · RFC 2330 · RFC 2679 · RFC 7679 · RFC 3357 · RFC 5148 · 確認済み編集Erratum 6981 · 確認済み編集Erratum 8282