"アイドル"状態ではない：Linux カーネルの最適化が QUIC のバグに

RFC 9438 で標準化された CUBIC は Linux のデフォルトの輻輳制御器であり、その結果、パブリックインターネット上のほとんどの TCP および QUIC 接続が利用可能な帯域幅をプローブし、損失を検知した際にバックオフし、その後回復する方法を支配しています。Cloudflare では、QUIC のオープンソース実装である quiche が CUBIC をデフォルトの輻輳制御器として使用しており、つまりこのコードは私たちが提供するトラフィックの大きな割合においてクリティカルパス上に存在します。 本稿では、CUBIC の輻輳ウィンドウ（cwnd）が最小値に永久に固定され、輻輳崩壊イベントから回復しないバグの物語を語ります。 この物語は、RFC 9438 §4.2-12 で記述されているアプリケーション制限除外（app-limited exclusion）に CUBIC を合わせることを目的とした Linux カーネルの変更から始まります。これは TCP における実際の問題に対する修正ですが、これを QUIC の実装へ移植したところ、quiche で予期せぬ動作が表面化しました。結末はハッピーエンドで、サイクルを断ち切るエレガントな（ほぼ）一行の修正です。 CUBIC のロジックを一言で言えば コアとなる問題に深入りする前に、輻輳制御アルゴリズム（CCAs: Congestion Control Algorithms）に関する簡単な復習が状況を理解する助けになるかもしれません。 CCA が調整する中心的なノブは、輻輳ウィンドウ（cwnd）です。これは、任意の瞬間に飛行中（送信済みだがまだ確認されていない）となるバイト数の送信側における上限を指します。cwnd を大きくすると、1 ラウンドトリップあたりにより多くのデータを転送できるようになり、小さくすると速度が制限されます。損失検知型 CCA のすべて、CUBIC も含め、最終的にはネットワークが健全に見えるときに cwnd をどのように拡大し、そうでないときにどのように縮小するかというポリシーです。 本質的に、CC はネットワークの「利用可能な帯域幅」を推定することでデータ転送を最大化することを目指します。なぜなら、誰も 1 Gbps のサブスクリプション料金を支払いながらその一部しか使用したくないからです。CUBIC が属する損失検知型アルゴリズムのファミリーは、以下の基本的な前提に基づいて動作します。(1) パケットロスが発生しない場合は送信レートを増加させる（つまり帯域幅利用率を高める）、(2) ロスが発生した場合、ネットワークの容量を超えたとみなし、送信側がバックオフする（つまり帯域幅利用率を下げる）。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2f9eyD4uXGCNm7Ni7yHhLB/55f2b686d474173dca610fa74796299d/BLOG-3273_image5.png) このロジックは、長年にわたり再検討されてきたいくつかの仮定に基づいています。ただし、その議論については別の機会に譲ります。 症状：61% の確率で失敗するテスト 調査は、イングレスプロキシの統合テストパイプラインにおける予期せぬ障害の報告から始まりました。この不安定な動作は、接続の初期段階で大量のパケットロスが発生するシナリオにおいて CUBIC が評価されたテストで現れました。 輻輳崩壊後の回復は稀な状態ですが、まさに輻輳制御アルゴリズムが存在して対処すべき領域です。ほとんどの輻輳制御テストは、アルゴリズムの定常状態と成長フェーズを扱いますが、接続が大幅に低下した後の最小 cwnd（ウィンドウサイズ）で何が起こるかを調べるものは極めて少ないです。この状態空間の隅にあるバグはスループットダッシュボードでは見えず、静的レビューでも検出できず、CCA（輻輳制御アルゴリズム）を意図的にその領域に駆動し、そこから回復できるかどうかを観察したときに初めて表面化します — これがまさに今回のテストが行ったことです。 シミュレーションされたテスト設定には以下の詳細が含まれます： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/67OlSQr35J5HGJwEEkrab/d0dd56faffd4b725a3d8654d856e67c9/BLOG-3273_image6.png) ローカル（localhost）で実行される Quiche HTTP/3 クライアントとサーバー RTT = 10ms（設定ファイルで指定） HTTP/3 を介した 10 MB ファイルのダウンロード CUBIC 輻輳制御の使用 最初の 2 秒間に 30% のランダムなパケットロスを注入 2 秒後、ロスが完全に停止 テストにはダウンロード完了のための寛容な 10 秒間のタイムアウトが設定されており、通常は 4〜5 秒で完了するはずです 期待される動作は単純明快です：CUBIC は損失フェーズ中にいくつかの打撃を受け、輻輳ウィンドウを縮小し、損失が止まれば着実に増加させ、タイムアウト内で十分にダウンロードを完了させるはずです。しかし、私たちは 100 回の反復テストで複数のケースを観測しました：約 60% のテストでは、寛容な 10 秒のタイムアウト内にダウンロードを完了できませんでした。 異常現象：損失ゼロで 999 回の状態遷移 コンジェッションコントローラー内部で何が起きているかを理解するため、quiche の qlog 出力にパケット損失イベントを計測し、可視化を行いました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1Lz0AbFsNqMz1c1HrB1n31/ecc425a25ab953bccbc3095768a38cc5/BLOG-3273_image10.png) 失敗したテストの接続概要。T=2 秒以降、パケット損失は完全に停止しますが、cwnd（輻輳ウィンドウ）は最小値に固定されたままとなり、約 14ms の間隔で回復状態と輻輳回避状態を振動し続けています。 2 秒（2000 ミリ秒）の時点以降、パケット損失は完全に停止します。しかし、飛行中のバイト数は横ばいのままであり、これは CUBIC アルゴリズムのコアロジックに矛盾しています：損失がない場合は、より多くのガス（私たちの世界ではより多くのバイト）を投入してスロットルを増やすべきです。これにより疑問が生じます：ネットワークがもはやパケットをドロップしていないのに、なぜ輻輳ウィンドウが増大しないのでしょうか？ その領域にズームインして分析すると、CUBIC が輻輳回避状態（運用レジームフェーズ）と回復状態（パケット損失回復状態）の間で急速な振動を起こすことが示されました。これはプロットでは拡張された回復フェーズとして表されており、約 6.7 秒間に 999 回の遷移が発生しています。つまり、約 14ms に 1 回の割合です。これは接続の RTT（10ms）と不審なほど近い値です。この期間中、cwnd は最小フロアである 2700 バイト（フルサイズの 2 パケット分）に固定されたままです。 明らかに CUBIC のロジック内の何かが接続の状態を誤解釈しています。鍵となる手がかりは振動周期で、約 14ms という値が RTT と一致します。回復と回避の切り替えを引き起こしているものは、接続の ACK クロックに同期してラウンドトリップごとに一度発生しています。これはクライアントからの各ラウンドトリップの ACK がサーバーの次の送信をトリガーする自己クロッキングリズムです。今回はダウンロード（サーバーからクライアント）であるため、問題となる ACK はクライアントからサーバーへ移動し、CUBIC の状態機械はサーバー側で動作します。これらの ACK が入力されるたびに bytes_in_flight がゼロになり、サーバーが次の 2 パケットバーストを送信しますが、これがバグを引き起こす原因となっています。 この挙動が CUBIC に固有であることを確認するため、同じテストを Reno でも実行しました。Reno は損失ベースファミリーの別のメンバーですが、成長率が異なります。結果は決定的で、100% の合格率を示し、Reno は損失フェーズ後にきれいに回復したことがわかりました。これにより、この問題は CUBIC に起因するバグであることが明らかになりました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1p8xXGkZZaRL2DxTqmpGEb/6aab5696040c957caa790642101a8ac7/BLOG-3273_image8.png) Reno は T=2 秒で損失フェーズが終了した後、きれいに回復し、約 5 秒までにダウンロードを完了します 根本原因の追跡 損失ベースのアルゴリズムには、加速方法に違いがある「ガス（アクセル）」と「ブレーキ」の 2 つのペダルがあります。もちろん、CUBIC はいくつかの追加機能も備えています。ここでは、bytes_in_flight == 0 の状況に焦点を当てます。 アイドル状態後の TCP CUBIC (Linux, 2017) このバグを理解するには、まずそのバグの元となった最適化について理解する必要があります。2017 年、Linux カーネルの実装における CUBIC の問題が発見されました。コミットメッセージには以下のように説明されています。 エポックは初期時および損失が発生した時のみ更新またはリセットされます。アプリがアイドル状態になった後、現在時刻と epoch_start の差分「t」は任意に大きくなり得るため、bic_target も同様に大きくなります。その結果、傾斜（ca->cnt の逆数）は非常に大きくなり、最終的に ca->cnt は遅延 ACK のスロースタート動作を確保するために 2 に下限値が設定されます。 これは slow_start_after_idle が無効化されている場合に特に顕著に現れ、数秒間のアイドル時間の後に危険な cwnd の膨張（1.5 x RTT）が発生します。 EPOCH は、CUBIC が成長曲線の基準点として使用する参照タイムスタンプです。W_cubic(delta_t) は delta_t = now - epoch_start によってパラメータ化されており、CUBIC が成長関数を再開始するたびに EPOCH はリセットされます。最も顕著な例は、損失イベントにより cwnd（送信ウィンドウサイズ）が減少した直後です。リセットの間隔では、delta_t は壁時計時間とともに単調に増加します。 アプリケーションが一時的にアイドル状態（送信停止）となり、その後再開した場合、CUBIC の成長関数 W_cubic(delta_t) は、図に示すように delta_t を now - epoch_start として計算します。アイドル期間中に EPOCH が更新されていないため、delta_t は非常に大きな値となり、結果として膨大なターゲットウィンドウが生成されます。これにより、CUBIC は直ちに cwnd を不合理な値まで膨張させようとしてしまいます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2zu6eD7MlJOqjZlEUiGhcj/09e84f66dc8a61f65e310f2e3071dafe/BLOG-3273_image7.png) Jana Iyengar による初期の修正は、アプリケーションが送信を再開した際に epoch_start をリセットするというものでした。しかし Neal Cardwell は、このアプローチに欠陥があることを指摘しました。 …それは CUBIC アルゴリズムに対して、cwnd が現在の位置から再び急激に上昇するように曲線を再計算させることになります（これは損失発生直後の CUBIC の動作と同じです）。理想的には、cwnd の成長曲線の形状はそのまま保ちつつ、アイドル期間の長さだけ時間軸上で後方にシフトした形であるべきなのです。 Eric Dumazet、Yuchung Cheng、Neal Cardwell が執筆したエレガントな解決策は、エポックをリセットするのではなく、アイドル期間分だけ前方へシフトさせることでした。これにより CUBIC 成長曲線の形状が保たれ、単に時間軸上でスライドさせられることで、アルゴリズムが中断された地点から再開されます。 quiche への移植（2020 年） CUBIC が quiche に初めて実装された際、このアイドル期間調整も移植されました。しかし、ユーザー空間で動作する QUIC は、TCP のカーネルレベルの CA_EVENT_TX_START コールバックを持っていません。代わりに、quiche の実装では on_packet_sent() 内でアイドル状態をチェックします。 // cubic.rs — on_packet_sent()（簡略化版） /// パケット送信時の状態を更新する。 fn on_packet_sent(&mut self, bytes_in_flight: usize, now: Instant, ...) { // 送信バーストが再開された場合（つまり、この送信前に bytes_in_flight がゼロだった場合）、 // 送信のギャップを考慮して混雑回復開始時間を調整する。 if bytes_in_flight == 0 { let delta = now - self.last_sent_time; self.congestion_recovery_start_time += delta; } // この送信イベントの時刻を記録する。 self.last_sent_time = now; } どこで破綻するか：QUIC の違い quiche に移植された修正には、カーネルの CUBIC モジュールに対する後続の変更によって約 1 週間後に修正された、元のカーネル変更におけるバグが含まれていました。2 つ目の修正に関するコミットメッセージは次のように説明しています： tcp_cubic: 未来に epoch_start を設定しない bictcp_cwnd_event() におけるアイドル時間の追跡は不正確である。なぜなら、epoch_start は通常、送信時ではなく ACK 処理時に設定されるからである。 適切な修正を行うには追加の状態変数を導入する必要があるが、Jana 氏によって指摘されるまで CUBIC バグが長年存在し続けていたことを考慮すれば、その手間をかける価値はなさそうだ。 単に epoch_start を未来に設定しないようにしよう。そうしなければ、bictcp_update() がオーバーフローしてしまい、CUBIC が再び cwnd（送信ウィンドウサイズ）を速すぎると成長させてしまうことになる。 コミットメッセージで言及されている通り、回復開始時刻は ACK 処理時に設定されるが、送信時刻に基づく調整計算により、その回復開始時刻が未来に押しやられてしまうことがある。これがテストで見られた回復と輻輳回避の間での振動現象の説明となる。この罠が確実に作動するのは、到着するすべての ACK が bytes_in_flight（飛行中のバイト数）をゼロまで引き下げる場合に限られる — 実際には、cwnd が最小値（2 パケット）に崩壊し、アプリケーションが ACK の到着と同時に次のウィンドウ全体を送信できるデータを持っている状態を意味する。この状態以外では、送信のたびに bytes_in_flight == 0 が成立することは稀であり、バグがトリガーされる可能性も低くなる。 なぜ接続開始時にも同様の現象が起こらないのでしょうか？このバグは、接続がスロースタートから脱出して輻輳回避（congestion avoidance）モードに切り替わった際にのみトリガーされます。スロースタートを抜ける前には congestion_recovery_start_time が設定されていないため、on_packet_sent 内のバグのある分岐には進化する回復境界が存在しません。スロースタート中、CUBIC の cwnd はすべての損失ベースの CCAs（輻輳制御アルゴリズム）が共有する Reno スタイルの ACK ベースルールに従って増加します。CUBIC の曲線と congestion_recovery_start_time に対する感度が関与するのは、接続が輻輳回避状態に入った後だけです。つまり、この罠には同時に三つの条件が必要です：回復境界を設定するための実際の損失イベント、実行中の輻輳回避モード、そして cwnd が 2 パケットの下限まで縮小することです。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3ACAQF0nWRiZv8sFbCiAnE/a45b5ca6cd9322176c91e09c90600c2c/BLOG-3273_image3.png) 自己完結型の回復トラップ。cwnd が最小値（2 パケット）のとき、すべての ACK サイクルでインフレしたデルタを伴うアイドル期間調整がトリガーされます。 cwnd が最小値（2 パケット）の場合、接続のダイナミクスは「デススパイラル」に陥り、アイドル期間最適化が自己成就予言となります。このトラップは以下の連続ループで動作します： パケット送信と ACK: 送信側は 2 パケット分のウィンドウ全体を送信します。1 RTT（約 14ms）後、両方のパケットが ACK され、bytes_in_flight がゼロに低下します。 誤ったアイドル検出：次のバーストが送信される際、on_packet_sent() が bytes_in_flight == 0 を確認し、接続がアイドル状態だったと判断しますが、実際には輻輳制御によって制限されていました。 過大評価されたデルタ値：計算では now - last_sent_time を用いてアイドル継続時間を決定します。輻輳ウィンドウ (cwnd) が最小値にある場合、last_sent_time は前回の RTT サイクル開始時のタイムスタンプとなります。その結果生じるデルタは約 14ms（接続の RTT に追加的な丸め誤差を加えたもの）になります。この RTT サイズのデルタが誤って「アイドル時間」として適用されます。実際には、接続がアイドルだった時間（最後の ACK が到着してから次のパケットが送信されるまでの処理ギャップ）は実質的に 0 です。真のギャップではなく全体の RTT を測定することで、デルタ値は著しく過大評価され、回復開始時刻を強制的に前方へシフトさせ、場合によっては未来へと押しやります。 認識された回復：回復開始時刻が未来となったため、in_congestion_recovery() のチェックが入ってくるすべての ACK に対して true を返します。次の ACK の処理は回復を終了し、回復開始時刻を last_sent_time よりも大きい ACK 時間に設定します。これにより、次回の送信時に輻輳コントローラが回復時間を未来へ押しやる可能性が高まります。 停滞：CUBIC アルゴリズムでは、回復期間中と認識されたパケットに対して cwnd の成長をスキップするため、ウィンドウは 2 パケットに固定されたままとなり、次の ACK でパイプが完全に空になり、サイクルが再開されます。 このループは数千回繰り返され、スケジューラのジッターや ACK 処理のばらつきによる小さな誤差が蓄積することで、in_congestion_recovery() 内の <= バウンダリが次のパケットの送信時刻よりも遅れ、サイクルが破綻します。 修正：適切な時点からのアイドル時間の計測 デススパイラルを解消するには、バイト数（bytes_in_flight）が実際にゼロに遷移した時点（最後に処理された ACK の時刻）からアイドル時間を測定する必要があります。これは最後の送信パケットの時刻ではなく、その時点に基づきます。 コードの変更点 CUBIC 状態に last_ack_time タイムスタンプを追加します。 ACK が到着した際にこのタイムスタンプを更新します。 アイドルデルタ計算にこれを使用します： // cubic.rs — on_packet_sent() 関数内 fn on_packet_sent(&mut self, bytes_in_flight: usize, now: Instant, ...) { // このパケット送信前に接続がアイドル状態だったかを確認する。 if bytes_in_flight == 0 { if let Some(recovery_start_time) = r.congestion_recovery_start_time { // 最新のアクティビティからアイドル時間を測定します：直近の ACK（bytes_in_flight がゼロになった時刻を近似）または最後のデータ送信、どちらか遅い方です。last_sent_time のみを単独で使用すると、cwnd が小さく ACK と送信の間で bytes_in_flight が一時的にゼロになる場合に、デルタが RTT 分過大評価されてしまいます。 let idle_start = cmp::max(cubic.last_ack_time, cubic.last_sent_time); if let Some(idle_start) = idle_start { if idle_start < now { let delta = now - idle_start; r.congestion_recovery_start_time = Some(recovery_start_time + delta); } } } } 現在、delta は最後の ACK 以降の実際のギャップを反映しているため、回復境界は送信時刻を追いかけることをやめました: ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6iJxCyk6eHvhxg13Z1XqQT/835dfb9b2b545362b39ec95041549333/BLOG-3273_image2.png) 旧コード：境界はサイクルごとに RTT (Round-Trip Time: 往復遅延時間) だけ前進し、常に次の送信時刻以降に位置します。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3c3v2ZqsyLXzaoEJewZ8hj/c38dc57aa604c1a1dea1bcf2fdba1ed5/BLOG-3273_image1.png) 修正：境界はほとんど移動せず、次の送信はこの境界より先に行われ、cwnd (Congestion Window: 輻輳ウィンドウ) が成長します。 真にアイドル状態の接続では、last_ack_time は過去にあり、同じ式によって完全なアイドル時間が捉えられるため、元のエポックシフト動作が維持されます。 検証 修正を適用した結果、quiche テストスイートの 100% のパス率が回復しました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/75Inh0VXIcfrw4Z7GbcAyw/64de17e59bda183dd65078c90d7e123d/BLOG-3273_image11.png) 修正後、cwnd（送信ウィンドウサイズ）は期待される CUBIC 曲線に沿って成長し、ダウンロードは約 4〜5 秒で完了します。 接続の末尾でのパケット損失については心配していません。これはルーターに割り当てられたバッファを完全に活用した結果として予想される現象です。つまり、このテストケースでは利用可能な帯域幅を最大限に活用していることになります。 教訓 「アイドル状態」とは、言葉ほど単純には定義できないものです。小さなウィンドウサイズにおける通常のパイプライン遅延は、簡易なチェックではアイドル状態と誤認されることがあります。 最小 cwnd の動的挙動は、ユニークなコーナーケースです。このバグは高速環境では検出できず、深刻なパケット損失が発生した後にのみトリガーされました。 この動作の複雑さに比べれば、修正内容は驚くほど小さかったものです。根本原因を特定するために数週間にわたり qlogs（QUIC ログ）の計測と可視化データの分析を重ねた結果、解決策はたった 3 行のコード変更で済みました。調査中に私たちが指摘した通り、バグを発見するための労力は膨大でしたが、修正自体は実質的に論理を 1 行追加するだけの作業でした。 本記事で説明した修正は、Cloudflare が提供する QUIC および HTTP/3 のオープンソース実装である cloudflare/quiche に貢献されました。当社の CCA（Congestion Control Algorithm）の取り組みは損失ベースのアルゴリズムに留まらず、quiche のモジュラー型輻輳制御設計を活用して、モデルベースの BBRv3 実装の実験と調整を行っています。現在、この BBRv3 は増加し続ける QUIC デプロイメントの一部で有効化されています。QUIC 輻輳制御の実装およびパフォーマンスに関する今後の更新にもご注目ください。 輻輳制御やトランスポートプロトコルに興味がある方、あるいはオープンソースのネットワークコードへの貢献を検討されている方は、quiche リポジトリをご覧ください。このような課題に深く取り組むことを愛する優秀なエンジニアを常に募集していますので、ぜひ当社の求人ページもご参照ください。

"アイドル"状態ではない：Linux カーネルの最適化が QUIC のバグに

背景や根拠まで確認しますか？

調べる

選ぶ

サイト