SR Policyの品質点を決めるのは誰か

要約

2026年10月28日付の個人提出Internet-Draftは、稼働中のCandidate Pathに属するSegment Listごとに品質を測り、点数に応じて相対的な重みを動かす案を示す。品質の定義と計算関数は設定可能なままだ。
RFC 9256では重みから割り当てる対象はフローの割合であり、重み付き分散の精度は機器の実装に左右される。スコアの上昇だけではバイト数やアプリケーションの改善を証明できない。

経路が悪くなった後、最初に動くのは数式だ

草案の図には、同じ重みを持つ三つのSegment Listがある。一つの経路が劣化しても、固定された配分はそこへ三分の一を送り続けるという例だ。別の経路に余裕があるなら、悪い方の取り分を減らせばいい。直感には合う。ところが「悪い」の判定は、遅延、損失、利用率をどう評価するかで変わる。自動化の入口に置かれるのは中立な温度計ではなく、ある目的を選んだ採点表である。

草案は工程を細かく分ける。中間または終端のノードが経路に関係する指標を測る。報告を集める論理主体はCandidate Path Quality Agent、略してCPQAだ。CPQAはSegment Listごとに指標を集約し、関数Fから新しい重みを計算する。head-endがその重みを転送面に適用する。監視、報告、集約、計算、適用のどこか一つを記録しても、残りの工程を見たことにはならない。草案は品質点に比例した重みを原則とする一方、遅延と損失と利用率を一つの点数にする普遍的な式を定めていない。品質の定義は設定で決める。

その設定は、利用者によって違う。ある経路は低遅延だが空き容量が少ない。別の経路は大きな転送を受け止めても、短い要求の末尾遅延が悪いかもしれない。01版はAI計算を動機として加えた。学習に伴う大きな集合通信は持続的なスループットを求め、推論や制御の短い通信は応答時間に敏感だという説明である。実在のネットワークの性能測定ではない。それでも、一つの「品質」点で両者を並べる以上、どの通信を優先するかを決めなければならないことはよく分かる。

重みの分数はバイトの分数ではない

RFC 9256のSR Policyアーキテクチャを読むと、重みの効き方は明確だ。ポリシーには複数のCandidate Pathを置ける。転送に使うのは原則として稼働中の一つのCandidate Pathで、その中の複数のSegment Listを重み付きECMPで選ぶ。あるリストの重みをwとすれば、そのリストへ向けられるフローの割合はw / 重みの合計となる。RFCは分散精度がプラットフォームの実装に依存するとも書く。重みはトラフィックの行き先を指定する値であって、帯域の予約量やアプリケーション遅延の計器ではない。

三つが等重みなら、モデル上は三分の一ずつのフローだ。大きな一つのフローが別の多数の小さなフローより多くのバイトを運ぶことは普通にある。品質点の高いリストに重みを足しても、移るフローが小さければバイト数はほとんど変わらない。逆に、重みを減らしたリストに大きな転送が残れば負荷は続く。草案の図は問題を示すための構成例である。採点結果が実際に利用者の待ち時間を減らしたかどうかは、head-endの設置状態、フローの分布、転送量、アプリケーションの測定を結ばないと読めない。

草案の対象は、現在有効なCandidate Pathの内側にあるSegment Listの重みだ。Candidate Pathの優先順位も、リストの構成も変えない。別に、混雑した特定のフローを見つけて空いているリストへ移す「動的フロー調整」も書かれている。前者は配分規則を改め、後者は対象のフローを選ぶ。運用記録では二つの操作を同じ「自動迂回」に畳めない。後者なら、どのフローを選んで、いつ元へ戻すかまで決める必要がある。

中央の採点者か、現場の採点者か

CPQAには二つの置き場所が用意される。集中方式ではControllerが報告を受け、点数と新しい重みを計算し、PCEPのような南向きインターフェースを通じてhead-endへ重みの組を送る。分散方式ではhead-end自身が直接報告を受け、計算して転送表を更新する。この枠組みは新しいPCEPメッセージを定義していない。IANAへの割当要求も今回はなく、将来のプロトコル拡張で必要になる可能性を記すにとどまる。

中央で採点すればルールをそろえやすい。そのルールが悪ければ、影響も複数のhead-endへ広がる。現場のhead-endなら近い状態で判断できるが、各所が別々の品質観を持ちうる。どちらを採るにせよ、測定した人、採点式を変えた人、重みを適用した機器の三者を一つの監査可能な時間線につなぐ必要がある。特にFの版、観測窓、欠けた報告の扱い、古い重みと新しい重みを残すべきだ。トポロジー図に同じ三本の線が残っていても、採点式だけでフローの行き先は変わる。

通信路の保護も一段だ。草案は監視ノード、CPQA、実行主体の間のメッセージに認証を必須とし、TLSまたはTCP-AOを推奨する。報告が内部状態を明かす可能性があるため、プライバシーが問題になる場合は暗号化の検討を求める。偽報告の洪水への耐性にも触れ、送信元の検証と流量制限を勧める。認証が通った報告でも、観測地点が経路全体を代表するとは限らない。誰が送ったかと、その数値で経路を選ぶべきかは別の審査になる。

草案は一時的な変動で重みが往復しないよう、変化を抑制する仕組みにも言及する。しかし、この枠組みには全ネットワークに共通の閾値やアルゴリズムはない。敏感すぎる制御は、移したフローが変えた利用率を見てまた移し、自己追跡を始める。鈍すぎれば悪化した経路に送り続ける。スコアの係数と同じく、反応速度も運用者が責任を持つ設定である。

版番号を過大評価してはいけない。2026年7月の00版にはすでに測定から適用までの仕組みがあった。10月の01版はAI計算の動機と三人目の著者を加えた。Datatracker上は個人提出のInternet-Draftだ。公式の原本には、Fの設定、更新前後の重み、head-endの実際の転送、アプリケーションの結果を結んだ、名前のある稼働記録はない。そうした記録が出れば、特定の実装について採点の効き目を判定できる。