要約

  • 2026年9月4日のdraft-ietf-cats-metric-definition-11は、複数ベンダー間の計算合意、更新頻度、古い値へのフォールバック、警報を扱う運用章を追加した。まだInternet-DraftでありRFCではない。
  • CATSは計算、通信、サービスの測定を、単位のない1バイトのスコアにできる。形式が同じでも、関数、境界、重みが違えば値は比較できない。
  • 11版は意味を版管理されたオフライン同期の設定マニフェストに置く。各装置が同じ版を実行し、選択先が実際に要求を処理したことは別に確かめる必要がある。

経路選択装置が、二つのサービス候補から同じ八点を受け取ったとする。一方はCPU余力とメモリ圧力をmin-maxで縮尺した。もう一方は遅延、待ち行列、要求成功率を重み付けし、sigmoidで丸めた。形式、署名、時刻はいずれも正しい。

同点だから同等、とは言えない。

数字は単位を失っただけではない。何を測り、何を重く見て、どの範囲を通常としたかも失っている。二つの八点を同じ温度計の目盛りとして扱えば、簡潔さが偽の精密さに変わる。

CATS Metrics Definition 11版が追加した運用上の論点はここにある。Computing-Aware Traffic Steeringは、ネットワーク状態だけでなく計算資源やサービス状態も使い、要求をサービス接点インスタンスへ導く。CATS frameworkでは、C-SMAがサービスと計算の情報、C-NMAがネットワーク情報を集め、C-PSが経路を選ぶ。

指標は三段階だ。Level 0はプラットフォーム固有の生の測定。Level 1はcomputing、communication、service、composedの分類にまとめる。Level 2は下位情報を一つのglobal normalized scoreへ圧縮する。

圧縮には実益がある。ネットワーク機器が数百のサービス固有カウンターを理解せずに済む。草案の比較表は代価も示す。Level 0は符号化が複雑で精度が高い。Level 2は簡単で安定する反面、精度は低い。Level 2は1オクテット、物理単位なし、Sourceはnormalizationである。

共通の箱に入っても、共通の尺度にはならない

提案される出力範囲は0から10で、正規化例はmin-maxとsigmoid、集約例は平均、最小、最大、加重平均だ。しかし具体的な関数は標準化されない。実装と運用方針が決める。

min-maxは上下限に依存する。同じCPU値でも基準範囲が変われば点数が変わる。加重平均は各入力に与える力を変える。比較方向が異なれば、大きな数を選ぶ装置と避ける装置が生じる。共通フォーマットが保証するのは運搬であって、意味の一致ではない。

メッセージには一部の文脈が残る。Sourceはnominal、estimation、directly measured、aggregation、normalizationを区別する。Statisticsはmax、min、mean、curを示せる。Observation_TimeはRFC 3339形式の観測時刻、Validity_Intervalは利用可能期間で、省略時はローカル方針が決める。RFC 5835は指標合成を、RFC 9439は出所表現を支える。

それでもSource: normalizationだけでは、入力列、外れ値処理、式、境界、重み、校正用負荷、実装版を再現できない。真正で新しい値が、古い方針から正確に計算されることもある。

11版の新章は、同じ管理ドメイン内の異なるベンダーが、範囲、正規化方式とパラメータ、集約式と重み、値が大きいほど良いのか小さいほど良いのかを合わせるよう求める。不一致なら選択は偏り得る。

合意は正式な設定マニフェストにまとめ、版管理し、初期化時にオフラインで同期する。稼働後は、受信値がその合意に従うと各部品が仮定し、動的な実行時交渉は行わない。合意できなければ、正規化を中央に集めるか、特定のLevel 0指標を使う選択肢がある。

薄い共通層としては合理的だ。ただし証明の場所がメッセージ外に移る。保管庫に正しいマニフェストがあっても、全C-SMAとC-PSが読み込んだとは限らない。署名が証明するのは発行者と改ざんの有無であり、その発行者が現在版の重みを実行したことではない。

古い良好値は、良好でも現在ではない

計算状態は頻繁に変わる一方、更新を増やせば制御面が重くなる。草案はインスタンスごとの更新を測定窓一回以内に抑えることを勧め、数百・数千インスタンスで合計負荷を評価するよう促す。

更新窓を例示の10秒から30秒、60秒へ伸ばせば、通信量とともに鮮度も下がる。Level 2だけを送れば、どの分類が悪化したか見えない。max、min、mean、curは同じ系列に別の問いを投げる。制御面で捨てた情報は、判断の不確実性として戻る。

収集に失敗した場合、11版は最後の良好値を限られた期間、例として二、三窓だけ使い、その後はインスタンスを格下げまたは除外するよう勧める。最後の手段は計算情報を無視したnetwork-only steeringだ。鮮度失敗、部品停止、急落、値の固着、Level 1とLevel 2の大きな矛盾には警報が必要になる。

10秒窓で三窓の猶予なら、源が止まってから約30秒、古い八点が選択を左右し得る。継続性のための妥当な方針かもしれないが、現在の余力ではない。観測時刻、受信時刻、最後の良好値への移行、期限超過、除外を別々に残さなければならない。

安全章は、完全性、発行者認証、サービス別の発行権限、リプレイと鮮度、通信の暗号化を要求する。転送を変える入力だから当然である。しかし暗号はセンサーや重みの妥当性まで保証しない。認証済み発行者も、誤った境界を使える。

点数の先までつながって初めて運用証拠になる

Heng Luのreality layersに沿えば、生観測、統計窓、集約、正規化、選択、転送、アプリ受領、利用者結果は別の層だ。八点は容量八単位ではない。選択は配送ではない。配送は有用な応答ではない。

Running-Code Primacyが必要とするのは、観測ID、単位、窓、統計、マニフェストhash、発行側と受信側の有効版、スコア、鮮度判定、C-PS入力、選択CSCI-ID、転送設定、要求到着、エラー、遅延、完了を結ぶ実行記録だ。

Minimum Initial Specificationは、世界共通のCPU重みを求めない。共通項目、出所、時間、マニフェスト識別を薄い層にし、境界、重み、更新、フォールバックをローカルに残せる。ただし、どのローカル判断が通信先を変えたかは可視でなければならない。

11版はCATSの展開や性能向上を証明していない。むしろ重要なのは、意味が稼働前に設定され、稼働中には前提として扱われる、と明記したことだ。事故の後に二つの八点が別物だったと知るのでは遅い。

情報源