要約

  • RFC 9959のCareful Resumeは、以前の接続が実際に使った輻輳ウィンドウ、最小RTT、Remote Endpoint、Lifetimeを保存し、後続接続の立ち上がりに条件付きで使う。
  • 保存値は過去の観測であり、現在の容量ではない。新規接続は通常の初期ウィンドウから始め、保存状態を一接続だけが確保し、経路を偵察した後も旧ウィンドウの半分以下を現在RTTでペーシングして試す。
  • 損失、ECN、経路変化が仮説を否定したら、Safe Retreatは保存状態を削除し、未検証データを排出し、他フローが容量を取り戻せる水準までウィンドウを落とす。

問題は「速く始めるか、遅く始めるか」だけではない。ある配信基盤が、前回の接続で200パケット相当を一RTTに通したと記録したとする。次の接続には100パケットまで試せる余地がある。ところが負荷分散された四つのワーカーが同じ記録を同時に読み、それぞれ100を送れば、共有キューが受ける試行は400になる。

各ワーカーの計算は半分でも、システム全体では二倍である。

RFC 9959は2026年5月にIETF Standards Trackとして公開され、こうした過去状態の再利用をCareful Resumeとして定義した。狙いは、高RTT・高BDPの経路で、新しい接続が毎回slow startを一から繰り返す費用を減らすことにある。ただし、仕様が与えるのは大きな初期ウィンドウではない。観測、期限、単回確保、偵察、限定的な跳躍、検証、撤退という一連の手続である。

保存されたCWNDは残高ではない

確立済み接続は、一RTTに実際に使った容量をsaved_cwndとして、当時の最小RTTをsaved_rttとして残せる。さらに実装依存のsaved_remote_endpointとLifetimeを結び付ける。同じRemote Endpointには一組しか保持してはならず、新しい観測で更新または置換する。観測が初期ウィンドウの四倍未満なら、手間に見合わないとして保存しなくてもよい。

この値が証明するのは、過去の一フローが、その時の経路と競合状況で、その量を使えたことだけだ。物理回線速度、契約帯域、現在の空き、次のフローの公平な取り分は証明しない。

RFC 2914が示す輻輳制御の原則は、ここで性能論を責任論に変える。送信側の短縮効果は可視化しやすいが、誤った再利用による遅延、損失、ジッタ、飢餓は同じボトルネックの他者に転嫁される。履歴を使う主体と損失を負う主体が一致しないからこそ、記憶は権利になれない。

Remote Endpointは現在経路の証明書ではない

Remote Endpointには送信インターフェースと宛先識別子が含まれ、宛先はunicastでもanycastでもよい。DSCPなどを加えることもできる。キーを細かくすれば混同は減るが、再利用機会も減る。

同じキーでも経路は変わり得る。anycastが別サイトを選び、ECMPが別の内部経路を通し、NAT、トンネル、アクセス切替が最小ボトルネックを動かす。経路が同じでも、他フローの占有は変わる。

そこでRFC 9959は現在の情報を要求する。ローカルスタックが経路変更を示せば中止する。Lifetimeが切れれば削除する。現在の最小RTTが保存値の半分以下なら、半分の旧CWNDを短いRTTで送ることで以前より高いレートになり得る。逆に十倍を超えるRTTも経路変更の兆候とする。

RTTが似ていても同一性は証明できない。偵察は明らかな不一致を落とす入口であり、最終判断ではない。

最初の一RTTは通常どおりに送る

新規接続は通常の輻輳制御と初期ウィンドウで始まる。RFC 5681がTCPの基本動作を、RFC 6928が現代のIWの背景を示す。昨日のウィンドウを接続開始時にそのまま入れるわけではない。

Reconnaissanceでは初期データを通常どおり送る。損失またはECN-CE、期限切れ、キーや経路信号の変化、RTT不一致、あるいは別接続が既に同じ保存状態を使っている場合、Careful Resumeを終了する。初期データ全体が輻輳なしに確認されて初めてUnvalidated Phaseへ進める。

その跳躍は次を超えない。

jump_cwnd ≤ Min(max_jump, saved_cwnd / 2)

半分は許可の上限であって容量測定ではない。max_jumpはさらに小さくできる。未検証パケットはすべて現在RTTに基づいてペーシングし、ウィンドウ拡大を一回のバーストにしない。進入時のflight sizeをPipeSizeとし、新たにACKされたデータだけを検証済み容量として積む。

未検証状態は短い。跳躍分を送り終えた時、最初の未検証パケットがACKされた時、または一RTTを超えた時に検証へ移る。アプリケーションが窓を使い切れなければ、未使用分は信用として残らず、実際に使った量へ戻る。

Validatingでは通常の制御則がACKに反応できるが、未検証パケット全体が輻輳なしに受領されるまで、跳躍の正当性は確定しない。

単回利用は分散システムの不変条件である

一つの保存状態は一接続しか使えない。単一プロセスならテーブルのロックで実装できる。四タプルで接続を別ワーカーや別ホストへ振り分ける基盤では、再試行、フェイルオーバー、ネットワーク分断を含めた原子的な所有権が要る。

調整できない時は通常のslow startへ戻る。キャッシュの可用性を高めるための複製が、送信権限の複製になってはならない。

RFC 9040はTCP Control Blockの情報を接続間で時間共有する広い枠組みを示す。再利用の価値とスコープの必要性は説明するが、RFC 9959のLifetimeや分散ロックを決めない。実運用の所有者が負う部分である。

Safe Retreatは誤った推論を将来にも残さない

跳躍後に損失、ECN-CE、経路変化が現れた場合、単なる通常の減速では足りない可能性がある。新フローはslow startなら到達しなかった量を急に投入し、他フローをバッファから押し出したかもしれない。

Safe Retreatは、まず保存パラメータを削除して後続接続の再試行を防ぐ。次にCWNDをPipeSize / 2以下へ落とし、その窓で損失回復を行い、未検証パケットを排出する間はCWNDを増やさない。退出時のssthreshはPipeSize × Beta以下、既定Betaは0.5である。

RFC 9937のPRRは通常の輻輳応答で選んだ目標へ送信量を比例的に近づける。RFC 9959は、大幅なオーバーシュートがあり得るSafe RetreatにはPRRが適さないと述べる。RFC 9438にあるCUBICの通常Beta 0.7も、この失敗処理を上書きしない。

BBRのようなレート型制御はボトルネック帯域に相当する値を保存できる。それでも、試して失敗したフローが共有容量を早く返す義務は同じである。persistent congestionやTCPのRTOはCareful Resumeを終了させる。遅延ACKは過去の判断を追認しない。

Lifetimeは公平性の設定でもある

RFC 9959は一律のLifetimeを定めない。変動する経路なら分単位、安定し多数の送信者で共有されない経路なら時間単位を検討できる。共有度が高いほど、古い状態による繰り返しオーバーロードの危険が増し、短くすべきである。構成変更後に明示的に消去する方法も必要だ。

Lifetimeを延ばすとヒット率は上がるが、ルート、サイト、アクセス、競合が変化する期間も広がる。キーを広くすると再利用と誤同一視が同時に増える。max_jumpを小さくすると事故は限定されるが効果も減る。最適値は自サービスの完了時間だけからは求められない。

RFC 7661は、現在接続がアプリケーション制限を受ける間のnon-validated CWNDを扱い、NVPを五分以内とする。Careful Resumeは別接続の記憶を使う。どちらも未使用の窓を事実にしないが、対象と退出条件は異なる。

RFC 4782のQuick-Startは、経路上のルーターに要求レートの承認を求めた。Careful Resumeはルーターの許可も予約も得ない。端点が推論し、現在のフィードバックで試すだけである。

受信側とアプリケーションにも決定権が残る

受信側は、インターフェース変更、ハードウェア制約、短い転送、別フローの予定を知っていることがある。RFC 9959は、個別のトランスポートが有効化または抑止の希望を伝える余地を残すが、万能な信号は定めない。

RFC 9293のTCP受信ウィンドウ、RFC 9000のQUIC flow controlやanti-amplification、アプリケーションのデータ不足も送信量を制限する。QUIC接続の識別子が移行後も続いても、輻輳状態は新経路で作り直す必要がある。

RFC 9002はQUICのIW、ペーシング、損失、persistent congestionを定める。RFC 8085はUDP利用にも輻輳責任があることを示す。過去観測はアプリケーションレートの例外規定ではない。

実行された遷移が監査証拠になる

Heng LuのRunning-Code Primacyを適用すれば、「機能オン」という設定値では不十分である。キー、観測時刻、旧・現RTT、Lifetime、単回取得、初期flight、jump、ペーシング、PipeSize、ACK/損失/ECN、遷移、削除、退避後の窓を残す必要がある。

最小初期仕様とローカルな将来判断は分担を明確にする。RFCは安全不変条件を共有し、Remote Endpoint、Lifetime、max_jump、キャッシュ、受信側信号、導入範囲は現場が決める。自由には責任と検証が伴う。

現実レイヤーで見れば、記録の存在、経路の類似、未検証状態への進入、ACK受信、他者を害さないサービス改善は別々の事実である。