要約

  • XCPでは、送信側が望むスループットの増減をパケットごとに分けて記し、経路上の各ルーターが自分の割当てより大きい値を縮めた。受信側に残るのは、その制御巡回で最も厳しい地点の判断である。
  • 返された差分は送信上限を動かすが、容量を予約せず、実測スループットも証明しない。要求、ネットワークの割当て、実現した結果を別の事実として扱う設計だった。

混雑を知らせる方法として、パケットを落とすことは強いが粗い。ECNの一ビットは、落とす前に混雑の有無を伝えられるが、どれだけ速度を変えるべきかまでは語らない。Dina Katabi、Mark Handley、Charlie Rohrsが2002年に発表したXCPは、そこへ量を持つフィードバックを入れた。

狙いは、高速で遅延の長い経路だった。帯域遅延積が大きいと、一つの往復時間に大量のデータが飛行中になる。TCPの増加と損失による調整は、空いた帯域を埋めるまで時間がかかり、行き過ぎれば大きなキューを作る。XCPは、ルーターが明示的に増減量を計算すれば、信号を速く、細かくできると考えた。

しかし、明示的という言葉は保証を意味しない。XCPの数値は、誰が書き、誰が削り、誰が実行するかを決めた制御メッセージである。正確に読めば、ネットワークが約束した総帯域ではなく、現在値からの差分だと分かる。

最後まで残った数が経路の答えになる

後期のInternet-Draftでは、混雑ヘッダーにRTT、X、Delta_Throughput、Reverse_Feedbackが置かれた。Xは送信側が見積もるパケット間隔、RTTは往復時間である。Delta_Throughputには、送信側が望む、またはルーターによって割り当てられたスループット変化が符号付きで入る。

送信側が一往復で毎秒二十単位だけ増やしたいとしても、各パケットに二十をそのまま書くわけではない。次のRTTに送ると見込むパケット数で差分を割り、各パケットが小さな要求を運ぶ。ルーターはフローごとの混雑表を持たないため、到着した一個ずつを独立に処理できる形が必要だった。

ルーターは出口について正と負のフィードバックを算出する。パケットの要求が自分の割当てを上回れば、Delta_Throughputを割当て値まで下げる。すでにもっと小さければ、その小さい値を上げない。したがって、受信側へ届く値は、参加したルーター群の最小値になる。

受信側は到着した差分を戻りのパケットのReverse_Feedbackへ写す。遅延ACKなどで戻りのパケットが少なければ、複数の到着分をまとめる。送信側は戻った値で許可レートや輻輳ウィンドウを調整する。要求から行動までが一往復で閉じる。

ここで「割当て」という語を消す必要はない。アルゴリズム内では実際に経路のボトルネック割当てである。ただし、その効力は次の調整に限られる。アプリケーションがウィンドウを使い切るとは限らず、新しいフローが加われば状態は変わる。パス変更も起こる。戻った値は予約容量の残高ではない。

一本の物差しで効率と公平を測らない

XCPのもう一つの特徴は、効率制御と公平制御を分離したことだ。効率コントローラーは、出口に入るトラフィックとキューの状態から、リンク全体としてどれだけ増やすか、減らすかを決める。目標は、リンクを遊ばせず、常時たまるキューも小さくすることだった。

公平コントローラーは、その総量をフローへ配る。原論文の方式では、正のフィードバックを各フローが公平な比率へ近づくように割り当て、負のフィードバックは使用中の帯域に応じて負担させる。この二段階によって、リンクの安定性と資源配分を別々に議論できた。

分離は変更可能性も生む。重み付きサービスを選べば、公平の定義だけを変えられる。効率側の制御則を変えても、配分の原理をそのまま保てる場合がある。逆に言えば、返ってきた一つの差分には、リンク状態と政策判断の両方が折り畳まれている。

そのため観測者には、数値以外の来歴が要る。どの出力ポートがボトルネックだったのか。平均RTTをいくつと見積もり、どの制御間隔を使ったのか。公平性は等分か、重み付きか。最終フィールドだけでは、途中で消された大きな要求も、値を書き換えた装置も分からない。

フロー表を持たない代わりに、申告を運ばせた

XCPルーターがフローごとの状態を持たないという説明は、設計の魅力であると同時に誤読の入口でもある。ルーターは無記憶ではない。到着率、キュー、平均RTT、制御パラメーター、配り残した正負のフィードバックを出口単位で保持する。

持たないのは、各フローをキーにした長期の混雑レコードだ。代わりに、パケットがRTTと送信レートに関する申告を運ぶ。ルーターはその申告と集約状態を合わせ、パケット単位の配分を行う。状態を消したのではなく、集約状態と携行情報に分解したのである。

この選択は中核の規模問題を軽くするが、送信側への信頼を増やす。申告したRTTやパケット間隔が真実か、戻された減速を守るかは別に検証しなければならない。原論文は概ね協力的な送信側を想定し、境界での監視などを論じた。

Katabiの後続研究は、ヘッダーで嘘をつく送信側と、正しい情報を出してもフィードバックに従わない送信側を区別した。スループットの虚偽は主に公平性、極端なRTT虚偽は条件によって効率へ影響した。完全に無反応なフローと、都合よく反応を弱めるフローでも結果は異なる。

ここから得られるのは単純な安全・危険判定ではない。自己申告は測定値ではなく入力であり、ルーターの差分は観測結果ではなく制御判断である。実際に送られ、届いたレートはさらに別の記録だ。それぞれの出所を混ぜないことが、攻撃分析にも運用分析にも必要になる。

実験仕様を標準配備の記録に変えない

2002年論文は制御理論による解析と大規模なパケットレベル・シミュレーションを示した。試した条件では、高い利用率、小さいキュー、長い遅延に対する安定性を報告した。後に実装、IETFでのチュートリアル、より詳細な草案が作られた。

それでも2007年の草案は、XCPが公共インターネットへ大規模配備できる段階ではないと明記した。端末だけでなくルーターも変える必要がある。ボトルネックになり得るキューが参加しなければ、最小値のきれいなモデルは経路全体を表さない。既存TCPや非対応キューとの共存も残った課題だった。

固定小数点のヘッダーにも現実的な制約があった。小さすぎる差分はゼロへ丸められ、パケットごとの誤差は制御間隔の中で累積する可能性がある。暗号化や認証、トンネル、中間装置との整合にも検討が要る。草案は完成品の宣伝ではなく、実験の開始点としてそれらを書いた。

ACM SIGCOMMのTest of Time受賞は、思想が後の研究へ長く効いた証拠である。導入台数の証明ではない。この区別を保つと、XCPの貢献はむしろ鮮明になる。多ビットの明示的フィードバック、効率と公平の分離、フロー表を置かない配分という三つの問いを、検証可能な形で提示したからだ。

数値を名詞ではなく履歴として読む

XCPのDelta_Throughputは、経路を通る間に役割が変わる。出発時は希望、ルーター通過後は上限付きの配分、戻り道では送信側への命令材料になる。同じビット列でも、工程を知らなければ意味を取り違える。

現代のテレメトリーでこの発想を使うなら、最終値だけを保存すべきではない。元の要求、観測可能な各段階の書換え、出口識別子、制御設定、戻り値、実現レートを分けて残す必要がある。そうして初めて、需要不足、経路ボトルネック、非対応区間、丸め、虚偽申告を区別できる。

帯域保証書なら、発行者、対象、量、有効期限、条件が必要だ。XCPの差分にはその持続的な構造がない。あるのは、協力する経路がその瞬間に作った、次の動作へ向けた限定的な判断である。

Katabiらの設計は、フィールド名より動詞を読めと教える。誰が書くのか。誰が小さくできるのか。どの時間幅に有効か。何を実行させるのか。その問いに答えたあとで初めて、要求、割当て、測定、保証を正しく呼び分けられる。

情報源