要約

  • CATSはネットワーク状態だけでなく計算能力や負荷も使ってサービス拠点を選ぶ。RFC 10054は、利用者が移動する状態付きサービスについて、CATSを使ってよいかアプリケーションが明示することを求めている。
  • パケットの経路変更、フローのインスタンス親和性、アプリケーション状態の移行完了は別々の事実だ。低遅延な拠点が見つかっても、そこからセッションを継続できるとは限らない。

近い拠点に状態があるとは限らない

拠点間を移動する端末で、遠隔協働の3D画面を操作している場面を考えてほしい。端末の入力を受けて次の描画を返すエッジ拠点が、これまでの操作履歴を保持している。移動に伴い、別拠点の経路が短くなり、計算余力も増えた。ネットワークから見れば有力な候補だ。しかし、その拠点が操作の続きに必要な状態を持つかは、ネットワーク指標から分からない。

RFC 10054が扱うのは、この「候補選択」と「セッション継続」の境界である。Computing-Aware Traffic Steering（CATS）は、計算資源や能力とネットワーク状況を合わせてサービスインスタンスを選び、トラフィックを向ける。物理的に近いサイトが最良とは限らず、負荷や端末の位置も変わるため、開始時の最適解が維持されないこともある。

ルーティングの見方では、CATSはアプリケーションに透過的に、状態あり・なしのサービスを選択できる。毎回の経路決定をアプリに委ねなくてよいのは利点だが、アプリの状態まで透過になるわけではない。端末が移動し、サービスが状態を持つ場合には、CATSの利用を許可するかアプリケーションが明示しなければならない、とRFC 10054は述べる。表示がないままセッション途中で振り分けると、サイト間で状態が食い違い、サービスが中断するおそれがある。

ここでいう「許可」は、文書に書かれた運用上の表示を指す。RFC 10054は共通の信号形式やAPI、利用者向けの同意画面、法律上の承認手続きを定めていない。また、許可が出たことだけで移行先の状態が正しいと証明されるわけでもない。移動後の復元をどう確認するかは、サービス側の設計課題として残る。

「切替済み」が隠している三つの確認

運用画面の「切替」は、三つの異なる出来事をまとめてしまう。第一はパケットの転送先が変わること。第二は同じフローを同じサービス接点インスタンスと経路に結び付けること。第三はアプリケーション状態を別のインスタンスへ移し、意味を保ったまま再開することだ。第一は転送操作、第二は親和性、第三はサービスの状態遷移である。

RFC 10053はサービス接点インスタンスの親和性を、フローのパケットを同一インスタンス・経路へ送る性質として説明し、順序の乱れや予期しない遅延変動を避ける意義に触れる。一方、同フレームワーク自体は親和性を定義・強制する仕組みを導入しない。RFC 10054のR14は状態付きセッションや取引にフロー単位の親和性を求め、R15はそのためにネットワーク装置へアプリケーション固有のフロー状態を持たせないよう求める。R16は端末やサービスインスタンスの移動時の継続性を推奨する。

この組み合わせは、完成した移行プロトコルではなくアーキテクチャ上の条件を示す。ネットワークはフローを一貫して扱う情報を必要としながら、アプリケーション状態の保管場所にならないことが望ましい。アプリケーションは移動可能な状態と、複製・再構成・保持が必要な状態を定義する。RFC 10054のAR/VR例でも、共通の基礎資産と、クライアント固有の入力を処理する状態付きインスタンスが区別される。新しい拠点が次のパケットを受信しただけでは、前の操作履歴から正しく描画できるとは確認できない。

したがってネットワーク指標は候補を示すが、状態の移行証明にはならない。経路更新は復元完了の受領証ではなく、新しい拠点から応答があっても長い取引の意味が連続している証拠にはならない。

要件文書と実装済み能力は違う

RFC 10054はIETFコミュニティの合意を表しIESGの承認を受けているが、Informational文書でありInternet Standards Trackの仕様ではない。ユースケースと要件の対象は単一ドメインである。この文書は必要な振る舞いを示すが、各事業者がすべてのサービスを安全に移行できることや、複数事業者が状態の意味を共有することを証明しない。

「CATS対応」という一つのラベルでは運用条件が不足する。どのサービス・セッションを移動可能とするのか、どの事象で候補になるのか、誰が許可を示すのか、経路を変える前に何を確認するのかを契約として定めるべきだ。独立した新規要求と、現拠点の状態に依存するセッションを同じ既定値にまとめない。

明示表示がないなら、アプリケーションの移行手順が引き継ぐまでは既存フローの親和性を保つ、または新規要求だけを再選択するのが妥当な運用策になる。これはRFCの追加要件ではない。利用率や遅延の改善を継続性の保証と取り違えないための判断だ。

参照資料と位置付け