要約

  • RFC 9959のCareful Resumeは、前の接続で観測した輻輳制御パラメータを次の接続の慎重な加速に使う。保存値は過去の経路証拠であり、予約済み帯域ではない。
  • 同じ saved_cwnd を同時に使える接続は一つだけである。ロードバランサーの背後では、各プロセスが正しく動くだけでなく、複製全体で排他性を成立させなければならない。
  • 状態の世代、有効期限、唯一の取得者、経路確認、ジャンプ上限、段階遷移、失効を結ぶ「保存状態再利用リース」を残すべきだ。これはDaniel Kadeの編集上の提案であり、IETFの要件ではない。

速かったという事実には主語と時刻がある

輻輳ウィンドウは回線商品の公称速度ではない。送信、ACK、損失、ECN、RTTという往復のなかで、ある接続の送信側が形成した推定値である。接続が終われば、その値を生んだ共有ボトルネックの占有状況も終わるとは限らない。むしろ他のフローが増え、経路が切り替わる余地が生まれる。

それでも、直前の実測を毎回忘れるのは効率が悪い。RFC 9959 は saved_cwnd、最小RTT、Remote Endpoint、有効期間を保存し、後続接続が通常より早く妥当な速度へ近づく方法を定める。

ただし、新しい接続は古い値から出発しない。通常の初期ウィンドウで開始し、現在のACKとRTTを確認する。条件が整ったあとも、増加は制限され、ペーシングされ、未検証として扱われる。過去の事実は、現在の試験を始める材料にはなるが、試験結果そのものにはならない。

RFC Editorの記録 ではRFC 9959はIETF Proposed Standardである。この分類は、特定事業者の導入、実性能、製品の適合、将来の容量を証明しない。

保存時の測定にも境界がある。slow startの終端では cwnd が実利用容量を上回ることがある。アプリケーション側が送信を制限していれば、許可された窓すべてが経路で検証されたわけではない。したがってRFCは、一RTTで実際に使われた容量を中心にし、不適切なオーバーシュートをそのまま保存しない。

Remote Endpointは経路の代理変数である

Remote Endpointは実装依存の値で、送信インターフェースと宛先を含む。宛先はunicastでもanycastでもよく、DSCPなどを加えることもできる。識別情報を増やせば誤対応は減るが、再利用できる機会も減る。

この設計判断はキャッシュ効率だけの問題ではない。同じキーだと判断することは、現在のパケットが過去と十分似た経路を通るという仮説を採用することだからだ。

ECMPは同じ宛先でも別のメンバーを選ぶ。anycastは別拠点へ到達し得る。NAT、モバイルアクセス、ロードバランシングも転送経路を変える。アドレス一致は便利だが、ボトルネック一致の証明ではない。

偵察段階では、初期データを通常制御で送り、現在RTTを測る。損失やECN、既知の経路変更、有効期限切れ、RTTの大きな不一致、または同じ保存状態の先行利用があればCareful Resumeを中止する。現在RTTが保存最小RTTの十倍を超える条件は変更を示す一つの基準であり、十倍未満なら同一経路だという保証ではない。

送信インターフェース選択、DSCP、anycast構成、ハッシュ規則が変われば、古いキーの意味も変わる。RFCが設定変更後の保存値をflushできるよう求めるのは、単なる掃除ではなく、意味の境界を守るためである。

一つの履歴を二つの接続で割ってはいけない

RFC 9959は、特定の保存済みウィンドウを同時に複数接続が使うことを認めない。

保存値が32だとする。二つのworkerがそれぞれコピーを読み、上限どおり半分の16へジャンプする。接続ごとの計算は正しい。しかし同じボトルネックに入る未検証増分は合計32になる。局所的な上限は、決定者の数まで制限しなければ全体の上限にならない。

一台のプロセスなら、ハッシュテーブルの原子的な更新で占有を示せるかもしれない。分散環境では、同じクライアントからの接続が別workerへ振り分けられる。複製遅延、タイムアウト後の再試行、クラッシュ、フェイルオーバーが、同じ世代に二人の正当な所有者を作り得る。

そのため、参照と消費を分ける必要がある。参照は過去の観測を読む行為である。消費は、その観測を根拠に一度だけ試す権限を取得する行為だ。取得結果が不明なら、通常開始へ戻るのが保守的な結論になる。

Policy Mirrorの観点では、RFCの制約をコードへ移しただけでは足りない。権限が複数プロセスへ複製されるなら、その複製モデルも標準の安全性を映していなければならない。

半分は配分ではなく、誤りの上限である

未検証段階の増加は max_jump と saved_cwnd の半分の小さい方に制限され、現在RTTに基づきペーシングされる。これは古い帯域の半分を新しい接続へ予約する規則ではない。

以前の接続以後、別フローが容量を使っているかもしれない。観測にslow startの過大値が混じっているかもしれない。ボトルネックそのものが変わった可能性もある。半分という値は、誤った仮説が他者へ与える負担を抑える安全境界である。

Careful Resumeは偵察、未検証、検証、通常、Safe Retreatを区別する。未検証パケットのACK、一定量の送信、一RTTの経過が段階を進める。現在のACKによって初めて、新しい経路が容量を受け止めたという根拠が生まれる。

運用画面が最終 cwnd だけを保存すれば、値の出所は消える。通常制御で得た16、古い記録から暫定的に得た16、現在ACKで検証済みの16は同じ数字でも別の主張である。

qlog向けCareful Resume草案02 は段階遷移、トリガー、保存ウィンドウ、保存RTTを表すイベントを提案している。個々の実装を観測する有用な語彙だが、まだ作業中の文書であり、一つのworkerのイベントは全体の排他取得を証明しない。

Safe Retreatは記憶の取消しである

暫定送信中に損失、ECN輻輳、経路変更が見つかれば、仮説は破れた。RFC 9959は使用した保存パラメータを無効として削除し、Safe Retreatでウィンドウを大きく減らす。

通常より強い反応が必要なのは、ジャンプがボトルネックでオーバーシュートし、すでに適応していた接続のパケットを押し出した可能性があるからだ。新しい接続の失敗だけを処理するのではなく、共有相手へ移したコストを早く止める。

分散システムでは、検出したworkerのローカル削除だけでは不十分である。同じ世代を消費できる全レプリカへ失効が届かなければ、別のworkerが再び古い値を貸し出す。Safe Retreatをシステム全体の取消しとして追跡する必要がある。

Lifetimeも取消し条件である。動的な経路には分単位、安定し共有の少ない経路には時間単位という例が示されるが、普遍的な推奨値ではない。長期保存は命中率を高める一方、現在との乖離期間を延ばす。

保存状態再利用リース

ここでいうリースは、期限付き排他権を表す分散システム上の比喩である。法的権利、回線契約、帯域予約、RFC上の新オブジェクトではない。

最小の記録は次を結ぶ。

  1. ローテーションされたRemote Endpoint範囲識別子と、その定義の設定版；
  2. 保存状態の世代とダイジェスト、観測時刻、saved_cwnd、saved_rtt、Lifetime；
  3. 原子的取得を要求した接続／worker、成否、取得期限；
  4. 通常初期ウィンドウの送信、現在RTT、経路整合と判断した理由；
  5. 基礎制御方式、max_jump、半分上限、ペーシング、実際の増加量；
  6. 各段階の遷移とトリガー；
  7. 解放、置換、期限切れ、設定flush、Safe Retreatによる無効化とレプリカへの伝播；
  8. 取得競合、損失、ECN、オーバーシュート、既存フロー影響の集計。

本文、URL、アカウント、Cookie、認証情報、恒久的な平文クライアント識別子は不要だ。関連キーは短期間でローテーションし、詳細はアクセスと保持を制限する。公開面では版・地域・コホート別の競合率、期限後試行、経路不一致、Safe Retreat、失効遅延で足りる。

Minimum Initial Specificationは一つの中央DBを強制しない。強整合取得、一意所有者へのシャーディング、識別困難なanycast群での無効化など実装は選べる。共有すべき命題は、一世代が同時に一つの試行だけを支えたという検証可能性である。

限界

参照資料は導入率、ベンダー対応、実効改善、固有の障害を示していない。分散環境で二重利用が起きたとも主張できない。小さい窓を保存しない、短いLifetimeを使う、Careful Resumeを使わない選択も正当である。

RFC 2914は輻輳崩壊と不公平を避ける原則、RFC 7661は送信量が限られたTCP内の未検証窓、RFC 9002はQUIC制御、RFC 9040はTCP制御ブロック間の情報共有を扱う。いずれも過去のスループットを将来の所有容量にしない。

Reality, Not Advocacyに従えば、結論は限定される。昨日の接続が使えた。今日の接続はその一部を慎重に試せる。今日も使えると述べる権限は、今日のACKにしかない。

Sources