要約

  • 第12版で加わった7.4節は、集約・正規化された値が実際のサービス能力を映しているか、定期的に確かめるよう促す。
  • QoEやSLA、基準となるインスタンス、一定の試験負荷を照合に使えるが、頻度とずれの閾値は運用方針に委ねられる。

経路制御に届いたスコアが正しく署名され、期限内で、他社の値と同じ尺度に載っていたとする。それでも、選ばれた先でアプリが快適に動くとは限らない。数値が改ざんされていないことと、数値が現実をよく表していることは別だからだ。

9月29日付のCATS作業部会草案は、この違いを新しい検証節で扱う。前の第11版には、生のLevel 0、分野別のLevel 1、総合したLevel 2という整理があり、複数ベンダー間で計算規則を事前に合わせる版管理の考え方もあった。観測時刻、鮮度、送信元の真正性も新規事項ではない。第12版の焦点は、その仕組みから出た点数を外部の結果で試し直すことにある。

7.4節が挙げる方法は三つ。点数の推移とアプリのQoE・SLAを突き合わせる。信頼できる参照インスタンスの分布と比べる。一定の負荷を流して基準値からのずれを見る。どれか一つを万能な合否判定にする記述ではない。検証間隔と偏差の線引きは運用者の方針に残し、体験との乖離が続くなら再調整するよう求めている。

加わった7.5節は管理情報も分ける。重みや正規化の上下限、測定窓、設定マニフェストの版は「設定」、現在のLevel 1/2の点数や観測時刻・鮮度は「運用状態」、最大・最小・平均・履歴は「統計」だ。この草案自体はYANG管理モデルを定めず、別のCATS文書へ委ねる。複数ベンダーではLevel 1の分野ごとに調整する余地がある一方、Level 2の総合値にはより広い合意が必要と書き足された。合意できなければ、単位と出所を明示したLevel 0を使う道もある。

これは現場障害の報告ではなく、RFCでもない。文書は作業部会の有効なInternet-Draftで、状態はI-D Existsだ。今回の価値は、整った計算の先にある「結果との照合」を、担当者が省略しにくい形で示した点にある。

出典