要約

  • QUICマルチパス草案第21版は複数経路の識別、検証、確認、状態通知、回復を定める一方、パケットの割り当てと詳細な再送方針は実装に委ねている。
  • 失われたデータを速い経路で再送できても、同じ順序付きストリームの先行部分が欠けていれば、アプリケーションへの引き渡しは進まない。
  • 成功判定には、元の経路と再送経路、PMTU、ACKの帰路、並べ替え、ストリームの解放時刻、アプリケーションの締切を結ぶ証拠が必要である。

運用画面では回復時間が劇的に短くなっていた。遅い経路で失われた範囲を、スケジューラが別の高速経路に載せ替えたからだ。回復処理のグラフは緑になった。しかし利用者が待つ処理時間は変わらない。さらに前に送られたストリーム範囲がまだ欠けており、届いた後続データは受信側で止まっていた。

「再送が速い」と「有用なデータを早く渡した」の間には、順序という境界がある。

「Managing multiple paths for a QUIC connection」第21版は2026年3月にIESG承認を得てRFC Editorの工程へ入り、10月2日時点では2人目の編集者を待つ状態だった。まだRFCではない。したがって採用済み標準のように扱うべきではないが、何を共通化し、何を端点へ残すかは明確に読める。

草案はマルチパス能力の交渉、Path ID、経路ごとのパケット番号空間、接続IDとの対応、経路検証、PATH_ACK、AVAILABLEとBACKUP、経路の破棄を定義する。回復と輻輳の状態も経路ごとに扱う。異なる実装が同じ経路状態を理解するための土台である。

一方、次のパケットをどの経路へ置くかは、アプリケーションと実装の判断である。失われたデータを元の経路、別の経路、複数の経路のどこへ再送するかという詳細方針も範囲外だ。規格は選択肢を相互運用可能にするが、最良の選択を宣言しない。

パケット番号とストリーム順序を混同しない

各経路のパケット番号空間は独立し、ゼロから始まる。これは確認と損失検出を経路単位で扱うために重要である。ただし、アプリケーションが読むストリームには別の順序がある。経路Bで後続範囲が到着しても、経路Aで運ばれた先行範囲が欠けていれば、その先はアプリケーションへ渡せない。

このため、回復の評価点をパケット受信時刻に置くと、成果を早く判定しすぎる。少なくとも、再送が到着した時刻、連続したストリーム範囲が完成した時刻、アプリケーションが処理を再開した時刻を区別しなければならない。

ストリームを複数経路へ分けるほど、経路間の遅延差が順序待ちを生みやすい。高速経路を足せば常に速くなるわけではない。スケジューラがどのストリーム範囲をどこへ割り当てたかが、遅い経路の最大遅延をアプリケーションへ持ち込むことがある。

再送先ではパケットの形も変わり得る

経路ごとにPMTUが異なる場合がある。草案は、同じアドレスとポートの四つ組を使う複数Path IDであっても、異なるPMTUを持ち得るとしている。元の経路で使えた大きさが、再送先でもそのまま使えるとは限らない。実装が最小値へ統一するのは安全な簡略化になり得るが、ネットワークそのものが同じPMTUだという証明ではない。

したがって「別経路で再送した」という記録だけでは足りない。元のフレーム範囲、再送時の分割、使用したPMTU、どの欠落を埋めたかを残す必要がある。複数経路へ重複して送る方針なら、余分な負荷と共有ボトルネックへの影響も測らなければならない。

輻輳状態が経路ごとに分かれていることも、物理資源の独立性を保証しない。異なるPath IDは同じ四つ組を使えるうえ、四つ組が違っても上流のキューを共有し得る。二つの制御器が局所的には正しくても、同じボトルネックで合計すると不公平になる可能性がある。

ACKの速さにも帰路が含まれる

PATH_ACKは、確認対象のパケットと異なる経路から返ることがある。観測した往復時間には往路、ACKの帰路、スケジューラの選択が混ざる。単一の「経路RTT」として保存すれば、速く見えた理由を誤る。

さらに、AVAILABLEは利用可能性の信号であって、低遅延、余剰容量、料金、同意を保証しない。BACKUPは他に使える経路がある間は避けてほしいという希望だが、端点はその希望を無視できる。すべてがBACKUPなら共通の優先順位はない。再送先の選択には、規格が持たないローカル情報が必ず入る。

成果までつながる再送記録

監査可能な記録には次の項目が要る。

  • 元のPath ID、接続ID、四つ組、検証時刻
  • 対象ストリームとバイト範囲、アプリケーション上の締切
  • 損失を判定した時点と根拠
  • 元経路と候補経路の輻輳状態、損失、PMTU
  • AVAILABLE/BACKUPの送受信方向と時刻
  • スケジューラの版、選択理由、再送先
  • PATH_ACKが戻った経路
  • 再送時の分割と重複
  • 連続範囲が完成した時刻
  • アプリケーションが再開・完了した時刻
  • 料金、安全、管轄、利用者同意の制約

この記録なら、「再送は遅かった」「再送は速かったが別の穴を待った」「ACKの帰路が測定を歪めた」「PMTU変更で分割が増えた」「両経路が同じボトルネックだった」を分けられる。単に回復成功と数えるより、改善すべき制御面が見える。

経路検証についても同じである。検証は到達可能性を示し、増幅制限に役立つ。空き容量や現在のNAT状態を永続的に保証しない。接続が一つの経路で生きている間、使っていない経路の準備状態を推測してはならない。

IESGでの審査はスケジューラ、経路数、利用枠、同意といった論点にも触れた。文書の承認は、特定実装の再送方針やサービス効果の承認ではない。規格が成立することと、アプリケーションの締切を守ることは、別の証拠で判断される。

正確な成果表現は、「再送を高速経路へ移した」だけで終わらない。「その選択で欠落がこの時刻に埋まり、順序付きデータがこの時刻に解放され、処理が締切内に完了した」と続く。最後まで測れないなら、成功はトランスポート層に限定して述べるべきである。

出典