要約

  • draft-ietf-tiptop-quic-profile-00 は、深宇宙では閉ループのフィードバックが遅すぎ、保存転送による待ち時間を輻輳と誤認し得るため、予定駆動の管理・制御面から期待RTT、送信ペース、ウィンドウ、MTU、ACK方針を与えられる構成を示す。
  • 予定が通信動作を直接変えるなら、発行者、承認権限、対象経路、適用時刻、容量・バッファ仮定、計算式、優先順位、失効時の挙動、後日の実測を結ぶ「予定からトランスポートへの受渡記録」が必要になる。

ACKより先に運用予定が届く

火星表面の探査機が低軌道中継機と通信できるのは、一周約二時間のうち十数分だけだとする。地球側の送信機がACKを待って空き容量を推定していたら、使うべき可視時間は終わっているかもしれない。中継機内で次の接触を待つ時間を通常のキュー遅延と解釈すれば、リンクが開く直前に送信量を減らすという逆の行動さえ起こる。

この場面では、パケットが教える前に運用側が決める。どの時刻にアンテナを向けるか、どの周波数と地上局を使うか、地球—軌道間と軌道—表面間の帯域差をどう扱うか、搭載メモリのどこまでを一つの転送に与えるか。ミッション管制が組んだ予定が、QUICの設定へ投影される。

2026年9月10日に公開された QUIC Profile for Deep Space の00版は、この構図を明示する。個人草案を引き継いだTIPTOPの作業部会文書であり、採用呼びかけは9月2日に終了した。採用は共同作業の対象になったことを示すが、RFC完成、IESG承認、全IETFの合意、実配備を意味しない。文書はInformationalを想定する作業中の草案で、IANAへの依頼もない。

にもかかわらず、問いはすでに現実的である。一般のQUIC実装は数百ミリ秒程度と比較的連続した到達性を前提に初期値を置く。深宇宙では伝搬だけで数分、中継接触の間隔で数時間が加わり、軌道機がL2フレームやL3パケットを次のリンクまで保存する。時計に見える遅れが、同じ原因を表していない。

閉ループは公平性を作るが、軌道を待てない

地上の輻輳制御が閉ループであることには大きな利点がある。中央管理者が全フローを先に割り当てなくても、送信端はACK、損失、RTT、ECNを通じて共有経路の状態へ反応できる。観測と制御が同じネットワーク内で回る。

ところが片道遅延が何分にもなると、その反応は現在ではなく過去への反応になる。さらに、保存転送で生じた待機は、稼働中リンクの容量不足ではない。トランスポートには「次の周回を待っている」という理由が見えず、単に応答がないように映る。

草案が参照するシミュレーションでは、通常型の制御でもQUICの損失回復により最終的な信頼性は維持される。一方、CUBICがチャネル損失を輻輳として扱い、完了が遅れたり、間欠経路で周回単位の機会を逃したりする。届いたかどうかと、希少な通信時間を適切に使ったかどうかは別の評価である。

そこで文書は、レートベースの開ループ制御を設定可能にするよう求める。送信ウィンドウ、ペーシング、期待RTTなどを、予定駆動の管理面・制御面の手掛かりで支配する。ACK頻度を時間変化させ、経路オーケストレーターが既知MTUを与える案も含む。下流の低速リンクより速く中継機へ注ぎ込んでも完了時刻は改善せず、宇宙機上のバッファだけを消費するという結果も示されている。

開ループは無統制ではない。制御の根拠が、回線上の直近観測から、事前に調整されたミッション情報へ移る。その情報を作る組織が、事実上どのフローがどの接触を使うかに影響する。

最初のRTTには測定者がいない

最初のACKが戻るまで、その接続固有のRTT標本は存在しない。RFC 9002の損失検出は初期推定値からプローブ時間を計算する。地上向けに一般的な333ミリ秒では、火星からの返事を待てない。

TIPTOP草案の間欠的な地球—火星例では、最大RTTに伝搬遅延だけでなく次の中継接触までの間隔も含める。小さすぎる初期値は無駄な再送を起こし、最初の応答前に接続を閉じる。大きすぎる値は接続を保ちやすいが、最初のInitialパケットを失った場合の再送を何時間も遅らせる。必要な最大値に近づけ、根拠なく何倍にも膨らませないというのが草案の線引きである。

この値は測定結果ではない。どの軌道条件を最悪とするか、どの中継経路を使うか、どの故障余裕を足すかを、人と組織が選んだ予測である。接続開始に不可欠でも、実測RTTと同じ証拠欄へ入れてはならない。

アイドルタイムアウトはさらに相互依存する。実効値は双方が提示した値の小さい方になる。一方が六時間のブラックアウトを見込んでも、相手が短い値なら接続は閉じる。自分の設定が正しいことは、相手との運用合意の証明にならない。

正しい予定が正しい命令とは限らない

接触予定は、天体運動の予測として正確でも、共有資源への命令として権限不足かもしれない。署名は発行元を証明するが、その発行元が他機関の中継バッファやアンテナ時間を配分できるかまでは証明しない。

対象範囲も細かい。一つのミッション、一組のピア、一方向、一経路、一サービスクラスに有効な値が、同じホストの別接続へ広がるべきではない。長寿命接続の途中で軌道機や地上局が切り替わるなら、どの時点で再投影するかを決める必要がある。

時間の意味も一つではない。予定作成、承認、配信、発効、失効、置換を分ける。真正な星暦でも古くなる。太陽合の前に積み込まれた命令は、数週間にわたり更新不能になる可能性がある。

そして衝突がある。異なる権限者が出した二つの真正な予定が、同じアンテナ、周波数、下流リンク、メモリ領域を予約することはあり得る。トランスポート実装が新しいタイムスタンプや大きいレートを見て優先権を発明してはならない。

予定からスタックまでの受渡記録

私は、動作を変える投影ごとに小さな版管理付きの受渡記録を作るべきだと考える。機密情報を一般公開する必要はない。少なくとも責任を負う運用者が、なぜその時刻にそのレートで送ったかを再現できればよい。

記録には、発行組織と承認役割、ミッション、ピア、方向、想定経路、予定IDと親データ、発効区間と期限を結ぶ。根拠となった観測、星暦、契約容量、最小・最大RTT、ペーシングレート、ウィンドウ、ACK方針、アイドルタイムアウト、MTUを列挙し、各数値の式、単位、余裕を残す。

中継容量、バッファ予約、最遅下流リンク、サービス優先順位、競合解決規則も必要である。予定をQUIC APIへ変換したプロジェクションソフトウェアの版も記録する。同じ入力でも変換規則が変われば、動作は変わるからだ。

予定が欠落、期限切れ、署名不明、経路不一致になった場合の扱いは、暗黙のデフォルトにしない。拒否するのか、劣化モードへ入るのか、最後の有効値を保持するのか。地上向け初期値へ無言で戻ること自体が重大な判断である。

新しい版は置換対象を指し、既存接続も変更するか新規接続だけかを明記する。管理面の「送信済み」と、遠隔端末の「受領済み」「採用済み」「稼働中」を分離する。両端の値がそろって初めて、相互依存するタイマーを評価できる。

実測は別欄に積む。実際の可視開始・終了、RTT、送信量、損失、バッファ最大値、逃した接触を、予測と並べる。次版の改善には使うが、過去の予測を上書きしない。後から得た真実で当初の意思決定を化粧すれば、説明責任は失われる。

協調は数値だけを渡して終わらない

TIPTOPの憲章はQUIC、TLS、TVR、DNSOP、DTNとの連携に加え、CCSDS、宇宙機関、民間部門との対話を挙げる。今回のプロファイルも、予定属性、ACK頻度、Careful Resume、鍵更新、MTU、保存転送にまたがる。複数仕様と複数組織が一つのパラメータを作る構図である。

実装APIは、値だけでなく出所を扱える必要がある。initial_rttを設定できても、それがどの予定の、どの経路の、いつまでの値か分からなければ運用できない。ログは外部から提示された値、スタックが受け入れた値、実際に使った値を分ける。衝突を最後の書き込みで消すのではなく、運用者へ返す。

これは惑星間ネットワークを一組織が中央統制せよという主張ではない。各機関は判断権を保てる。相互運用に必要なのは、境界を越えるたびに「誰が何を決めたか」が失われないことである。IETF文書がタイマーを説明しても、個別ミッションの資源配分までIETFが承認したことにはならない。

現時点の証拠の限界

調査した資料は、偽造または期限切れのQUIC予定が飛行中の事故を起こしたとは示していない。シミュレーションは制御された検証であり、全実装の配備調査ではない。00版は今後変わる。間欠火星中継に良い制御が、連続した月経路にも最適とは限らない。

閉ループを捨てるべきだという結論も出ない。観測が届けば予測を修正でき、草案自身も場面を分けている。ここで守る境界は狭い。外部予定が生きたトランスポート設定になる場合、その予定の権限、対象、導出、期限もネットワークの正しさに含めるべきだということだ。

深宇宙は、地上でも起きる問題を時間軸で拡大する。自動化は判断を消さず、信頼する入力へ移す。最初のパケットが飛ぶ前に、輻輳制御の最初の選択はすでにミッション会議で行われている。

出典

  1. IETF Datatracker — 深宇宙向けQUICプロファイル
  2. 改訂履歴
  3. 保存版00
  4. 草案ソースリポジトリ
  5. TIPTOP作業部会憲章
  6. 作業部会草案の公開通知
  7. 採用呼びかけ
  8. 採用結果
  9. IETF 126 TIPTOP議事録
  10. 深宇宙IPの特性とユースケース
  11. 深宇宙IPアーキテクチャ
  12. RFC 9000 — QUIC
  13. RFC 9002 — QUIC損失検出と輻輳制御
  14. RFC 9308 — QUIC適用性
  15. RFC 9959 — Careful Resume
  16. QUIC ACK頻度草案
  17. 予定属性のYANGモデル
  18. BBR輻輳制御草案
  19. IANA QUICレジストリ
  20. 深宇宙QUICシミュレーション環境