CCWG @ IETF 126 セッションまとめ

2026年7月21日（火）14:00–16:00 CEST、ウィーン。Chairs: Reese Enghardt / Eric Kinnear。
出典：公開スライドおよび録画の文字起こし。

1. Hackathon報告：輻輳制御とキュー管理の評価

Mohit P. Tahiliani / Abhyuday Hegde（NITK Surathkal）、Vishal Kamath（リモート）

短縮開催となったHackathonで、修正後の3目標すべてを完了。

• FQ-CoDel vs FQ-PIE の性能評価：モバイルホットスポット経由（クライアント→ホットスポット→IETF AP→バックボーン→Netperf EU Bufferbloatサーバ）と、OpenWrt動作のWi-Fi AP（QQ-IW-235）の2構成で、Flent（RRUL、TCP/UDP多ストリーム）を実施。egressキューに両qdiscを設定して比較した結果、FQ-PIEの方がテールレイテンシが一貫して良好、ジッタも小さめ。ただし中央値はほぼ同等で、追加検証が必要との位置づけ。
• picoquic の ns-3 統合：ns-3にはQUICのネイティブモデルがないため、QUICを一から実装せずpicoquic（RFC 9000/9001/9002準拠、MPQUIC対応）に薄いラッパーを被せ、contribディレクトリに配置。マルチパスQUICのサンプルや、C4 vs Cubicを比較する例も同梱。コードは公開済み。
• IETF 125以降の成果：FreeBSDのPRR実装をRFC 9937に整合させるパッチが（Hackathon当日に）マージ。ns-3向けのLEDBAT++／rLEDBATモデルのMR提出（LEDBAT++はレビュー進行中、rLEDBATはフィードバック募集中）。GSoC 2026の成果としてns-3上でFlent相当のテストを再現できるアプリケーション、NeSTにマルチボトルネックのトポロジヘルパを追加。

議論

• Raffaello Secchi（Aberdeen）：picoquicやQUICの進化に対する保守コストは? → ラッパーは非常に薄く、picoquic側/ns-3側は独立に進化可能。APIシグネチャが変わった場合のみ追随が必要。
• Alessandro Ghedini（Cloudflare）：他のQUIC実装を追加する労力は? → picoquicで約2ヶ月。ライブラリ側がI/O（送受信）まで抱えるか、データを渡すだけで済むかに大きく依存する。msquicはマルチスレッド構造のため統合に難があった。

2. Hackathon報告：L4S Interop

Greg White（CableLabs） ※TSVWGと同一スライド

• IETF Hackathonでの L4S Interop は2022年7月〜2026年7月で通算9回目。今回は libwebrtc/SCReAM、Netflix NDTC、Apple Responsivenessツール（L4Sモード）、SRM（TSVWGで検討中のL4Sサポート用ネットワーク構成）、Androidクライアントを持つiperf2最新版などを対象。
• CableLabs（デンバー）でも2022年10月以降14回開催。Low Latency DOCSIS機器や複数のXGS-PON OLTが利用可能で、リモート参加も可。
• 累計20超の組織が参加し、L4S輻輳制御11種、レシーバ14種（QUIC/TCP/RTCP等）、ネットワークボトルネック11種。
• 次回：CableLabs（10月19–22日、デンバー）、IETF 127（2026年11月、サンフランシスコ）。

3. BBR（WG文書）

Ian Swett — draft-ietf-ccwg-bbr-06

2024年10月にWG採択、Experimental RFCを目標。

-05→-06の変更

• QUIC拡張 ACK_FREQUENCY / ACK_RECEIVE_TIMESTAMPS に関する考慮の追加（#105）
• 疑似コードの欠落した状態定義・初期化の修正（#114）、Undoロジックの定義・疑似コード・本文の修正（#117）。Undoは特にTCP実装で複雑だが、Neal Cardwellによれば正しく実装することで実測の性能改善があり、理論上の話ではないとのこと。
• Precautionary Bandwidth Probing の本文・状態定義・疑似コードを追加（#115）
• 付録として例示テストケース（約15件）を追加（#103, #119）。application-limited挙動なども含み、実装のサニティチェック用の出発点という位置づけ。
• 編集上の整理（疑似コードのメソッド名から BBR を除去、パラメータ名の統一など）。round trip/round-trip の表記統一は -07 に反映。

Precautionary Bandwidth Probing の要点

• 目的はキュー圧とパケットロスの低減。ProbeBW_UP突入時、「安全」と示されない限り C.inflight を BBR.inflight_longterm に1 ACK以上留めない。
  • (D) Deceleration：ロスでProbeBW_UPを抜けた場合、次のProbeBW_UPは inflight_longterm に到達するまでの短いフェーズにとどめ、直ちにProbeBW_DOWNでキューを吐かせる。
  • (A) Acceleration：この慎重フェーズで過剰ロスがなければ、REFILL→UPに戻り、通常どおりUPを継続する。
• Linux TCP BBRv2/v3 のオープンソース版に2019年から存在し、Google/YouTubeのTCP WANトラフィック（社内WAN 2020年〜、公衆インターネット 2023年〜）で運用実績あり。ドラフトに書かれていないことにNealが気づいて追加した形。

実装状況

未解決の課題

• #109：PROBE_RTT中のmin_rtt膨張リスク。ProbeRTTInterval を5秒→10秒にすると MinRTTFilterLen（10秒）と一致し、PROBE_RTT突入と同時にmin_rttが期限切れになって、膨張したRTTでBDP／cwndを算出しかねない（例：真のmin_rtt 10ms、直近のRTT 50msなら目標inflightが5倍に）。緩和策は (a) サンプル有効期限を MinRTTFilterLen + ProbeRTTDuration に延長、(b) PROBE_RTT開始時に probe_rtt_cwnd を保存、の2案。Nealは本番では5秒で運用中。両案をPRとして書き起こして比較する可能性。
• #5：BBR.ack_phase の削除。実装はmvfstのみ。2つ目の実装とインターネット規模の性能データ（リグレッションなし）を待っている。
• #56：idleからの再開判定。TCP依存の SND.NXT == SND.UNA をトランスポート非依存にしたいが、C.inflight == 0 では不十分（誤ってロスと判定された後に届いたパケットのタイムスタンプが帯域を大幅に過大評価しうる）。UnacknowledgedBytes() == 0 が提案。

出版の基準（Experimental想定）：QUIC/TCP双方での大規模デプロイ複数、両方の実装が従える記述、BBR同士の公平共有とReno/Cubicとの共存。「BBRを無限に進化させ続けるより、デプロイ経験を伴う良いドラフトを妥当な時期に出す方がよい」との方針が示された。

議論

• Altanai Bisht（Cisco Meraki）：PBPは最適化なのか必須なのか、未実装だとBBRv3非準拠か? → 必須の意図。ただし現状はLinux TCPのみ実装。Nealも「キューの健全性や、同一ボトルネックを共有する他フローが被るRTT・ロス率への友好性が大きく改善するので必須のつもり。概念的にはやや複雑だがコードの複雑さは大きくない」と補足。
• Roland Bless（KIT）：これは2023年頃に実装済みのものを文書化しただけか? → Linuxでは2019年から。昨年の計測でBDP相当のキューができていた件も、既に実装済みの版（BBR v3、オープンソース版）での挙動だと確認。
• Alessandro Ghedini（Cloudflare）：QUIC向けBBRを断続的に開発中で、本番トラフィックの一部で有効化を始めている。まだ作業中で、やや遅れ気味との自己評価。

4. SCReAM v2（WG文書）

Magnus Westerlund（Ingemar Johansson代理）— draft-ietf-ccwg-rfc8298bis-screamv2-01

復習：cwndではなく ref_wnd を使い、bytes in flightが ref_wnd を上回ることを許す（大きなビデオフレームの送信側キューイングを避けるため）。輻輳から時間が経てば乗算的増加、ロス・ECN/L4S・推定キュー遅延増加のいずれでも減少。パケットペーシングは target_bitrate の約150%（非輻輳時はさらに引き上げ）。

Individual-07 → WG-01 の変更

• qdelay_dev_avg の導入（qdelay_dev_norm を置換）：キュー遅延の最小値と最大値の差を用いる。クロックドリフトやスケジューリングジッタに対して頑健。ref_wnd_delay_scale = max(0.0, 1.0 - qdelay_dev_avg / QDELAY_DEV_THRESHOLD)（閾値10ms）として、ref_wnd_overhead と ref_wnd 成長の制限に使う。
• 適応的 ref_wnd_overhead：輻輳時（qdelay_dev_avg が大）はbytes in flightを抑制、非輻輳時は ref_wnd 超過を許容。25ms RTT・帯域が5秒ごとに10→5→10Mbpsと変動するシミュレーションで、ビットレートがより安定しキュー遅延の増大も抑制。
• ref_wnd アンダーシュートの緩和：ACKされたビットレートが目標ビットレートを上回っている場合は ref_wnd の減少を制限する（RTT増加が既に目標ビットレートを下げているため）。帯域急減時の回復が速くなる代わりに、その後キュー遅延が上限付近を上下しながら探る挙動になる。
• リンク層ロス（非輻輳性ロス）への頑健性：ロス検出時に ref_wnd を減らすのは、平均ロス率が LOSS_RATE_THRESHOLD（既定1%）を超えるか、qdelay > qdelay_target/4 の場合のみ。100Mbpsリンク・最大10Mbpsのビデオ・ランダムロス0.5%というdata-limitedなシナリオで、従来は帯域が不当に制限されていたのに対し、ほぼ10Mbpsを維持できるようになった。
• L4Sの効果：5G上りリンク（2.6GHz、20MHz、3セクタ、20km/h移動）のシミュレーションで、L4S有効時はキュー遅延が大幅に低下しレート安定性が向上（ビットレートはわずかに低下）。付録のWebRTC実験（jitsi + H264 + Chrome、fq_codel／CE閾値8ms）やAndroid上りストリーミングでも同様の傾向。

オープンな論点：RFC 9743に基づく評価は別文書か本文の付録か／全ケースで評価が必要か（アルゴリズム設計から理論的に論じられる部分もある）、レートポリサーの検出と対処を続けるべきか、L4S非対応時にSCReAMをより保守的にすべきか。GoogleがSCReAM + L4SのWebRTC評価に協力中で、年内に結果が出る見込み。

議論

• Christian Huitema（Private Octopus）：ロス率の平均で反応するのは多くの実装（C4、BBR、Cubicでも可能）が採っているが、閾値が1%／2%／20%とばらつくと競合フロー間の公平性の問題になる。WGでこの点を扱うドラフトを検討してはどうか。さらに、L4Sの「非ECNフローのドロップ率 ≒ ECNフローのマーキング率の2乗」という関係はTCPの漸近挙動の古いモデルに基づき、個々のパケットロスごとにcwndを下げる前提に立っている。平均で判断する方式が広がると、これらの式は成り立たなくなる。IETFで議論して推奨値に収斂させ、モデリングのコミュニティにも伝えるべき。
• Mirja Kühlewind（Ericsson）：SCReAMはL4Sを既定で有効にしており、L4Sマーキングがあれば別の反応をする。ロス閾値の話は非ECNキューの場合のみ。BBRも同様のロス閾値を持つので、同じ閾値を使うのは悪くない考えだし、一般論として整理する価値はある。
• Martin Duke（Google）：Christianの提起は興味深く、誰かが議論を始めてほしい。ただし、ロスを無視する条件はキュー遅延の増加（あるいは非増加）と結び付いており、それはまさにキューが立ち上がってCEマークが付き始める領域なので、当該の式がこれで陳腐化するとは思わない。
• Neal Cardwell（Google）：ポリサーについては、明示的な検出器／推定器を作る道は勧めない。BBRv1では実際にポリサー検出と専用応答を作り込み、実用上はうまく動いたが複雑で、v2への移行時に削除した。一般的なロス応答が妥当に振る舞うようにする方が良い。
• Gorry Fairhurst（Aberdeen）：RFC 9743を書いた際の意図は「IETFのプロセスのどこかに記録が残ること」。ICCRGでの技術発表でも論文でも文書でもよく、各輻輳制御文書に巨大な付録を付ける想定ではなかった。公開の有無を問わず別文書が念頭にあった。
• Martin Duke：Gorryに同意。大量の記述も別RFCも不要で、WGの議事録・資料に報告があれば十分。Experimental狙いなのも助けになる。適用範囲がインターネット全体なら、衛星などインターネットでは捉えにくいが重要なシナリオはシミュレーションが必要。データが理想だが、適用ユースケースのシミュレーションがあればおそらく十分。
• Stuart Cheshire（Apple）：ポリサー向けの特別なコードを入れるのは生産的でない。ポリサーは「送信側に速度を伝える」ためにパケットロスという単一の二値信号しか持たない。キューなら遅延の増加から事前に推測して手前で退けるが、ポリサーは超過の予兆がなく突然落とすため厄介。いつかECNを使うポリサーが現れることに期待したい——再送を強いずにレート調整のフィードバックを返せるので、今日のポリサーへの回避策を作るより、そちらを目標にすべき。

5. SEARCH

Jae Chung — draft-chung-ccwg-search（SEARCH = Slow start Exit At Right CHoke point）

前回のMirjaの質問（なぜRTTではなくgoodputを使うのか）への回答としての信号品質の分析と、exit時のドレイン導入の2点が更新内容。

スロースタート終了信号の品質

• 従来のTCPはロス／AQMのECNで終了 → オーバーフローしやすい。HyStart/HyStart++はRTT膨張、BBR/SEARCHは配送レートの頭打ちを使う。問題は「どの信号か」ではなく利用可能帯域付近で信号がどれだけ明瞭か。
• RTTは輻輳点の手前では変化せず、ノイズ（標準偏差）は前後で変わらない。一方、配送レートはパイプが埋まるほど測定精度が上がるため、輻輳点付近で最も正確になる。
• SNR（20 log10(直近ラウンド平均 / 直近ラウンド標準偏差)）で比較すると、正規化差分 Norm-diff = (sent_rtt_ago − delivered) / sent_rtt_ago のSNRはBDP付近およびその後で強くなるのに対し、直近ラウンドの最小RTTをベースにしたRTT膨張のSNRはBDP付近で弱く、大きく揺れる（ベース自体がノイズを含むため）。

Exit時のドレインフェーズ（新規）

• 従来：SEARCHが終了を検出した時点で ssthresh = cwnd として抜けるだけ → キューに滞留したパケットが残る。
• 変更後：直近RTT分の配送バイト（SEARCHの直近3ビン）から target_cwnd を算出し、cwnd = max(inflight − Δ, target_cwnd) として3パケット相当のバイトごとに1減らす形で緩やかにドレイン。一気に絞ると、exit直後にロスが起きた際にfast retransmitに必要なウィンドウが残らないため。ドレイン完了後に輻輳回避へ引き渡す。例（100Mb/s、RTT 100ms、キュー4×BDP、ジッタ26ms）では約4 BDP相当で検出→ドレインする様子が示された。

進行中の作業：SNRに基づくcwnd成長率の適応化。SNRが低い＝パスがまだ埋まっていないので2倍より速く増やしてよく、SNRが良い＝輻輳点に近いのでHyStart++のように緩やかにする。

議論

• Ian Swett（Google）：グラフの読み方の確認（左下がwindowed min RTT、右下が期待帯域からの偏差、赤線がBDP）。スロースタートでは1 ACKあたり2パケット送るため正規化差分は0.5に収束する、との説明。
• Gorry Fairhurst：何を測っているのか、パスは何か? → エミュレートしたネットワーク（実ネットワークのWi-Fiや自社のGEO衛星でも同じ計測はしている）。「エミュレーションだけのデータをWGで見る意義には疑問がある」「実ネットワークのデータを見せてほしい」と指摘。
• Altanai Bisht：アプリ側が送信を絞っている場合、計算が狂わないか? → app-limitedならそもそもスロースタートを抜けない想定であり、SEARCHが誤って抜けさせないようにしたい。
• Neal Cardwell：app-limitedフローで早期終了を防ぐ具体的な機構は? 例えばBDPが200パケットでアプリが毎RTT 100パケットしか送らない場合はどうなるか。 → 現在検討中で、SNRが低ければ測定を信頼せず終了判断をしない方向。ビン幅はRTTの約1/3で、そもそも判断に十分なビン数が集まらないケースも多い。
• Christian Huitema：レート測定はRTT測定に依存する。測定区間にRTTが含まれる以上、RTTのジッタが除数に効いてレート精度を大きく損なう。「レートは一定」「遅延は一定」という前提はWi-Fiでは特に成り立たない。どちらを使うべきという話ではなく、レート測定の確からしさを過信しないよう注意すべき。→ RTTは1次元、配送レートは「どれだけ／いつ」の2次元情報であり、輻輳点に近づくほど誤差は縮む、と応答。
• Martin Duke：fast retransmitを根拠に3を選ぶのは出発点としては良いが、RACK等がある今、そこに寄りかかりすぎないように。一般化の際にはより汎用的な扱いが必要。

Poll：「この文書を読んだか」「実装した／実装に関心があるか（この変更が入れば実装する、も含む）」の2問を実施。Chairsは複数あるスロースタート提案の著者と調整を続ける方針で、この場での採択を諮るものではないと明言。

スロースタートをWGで扱うことへの疑問（Huitema）：SEARCHが取り組んでいる本質的な問題は、スロースタートと輻輳回避の間の不連続。高BDPパスでは輻輳回避が極めて非応答的で、一度ウィンドウを割ると回復に膨大なRTTがかかる。だから「早く抜けすぎること」の代償が大きくなる。初期フェーズで発見を済ませ、その後はほとんど変えないという設計自体が根本的に良くない——ネットワーク状況は常に変わる前提を置くべき。Chairが「輻輳回避がもっと応答的なら、抜ける地点はそこまで重要でなくなる、ということか」と確認し、Huitemaも同意。一方で、そもそも終了前に終わる接続が相当数あること、過去のIETFで「適切なレートへの到達を改善するとユーザ体験が有意に改善する」データが示されたことも指摘された。

Martin Dukeからは、標準化トラック文書としての採択を議論するなら「インターネット規模の実験を行っている者がいるか」を問うべき、とのコメント。

6. Firefox（neqo）でのQUICスロースタート評価

Oskar Mansfeld（Mozilla）

Firefox の QUIC スタック neqo に、既定の輻輳イベントベース方式（Classic/Control）に加えて SEARCH と HyStart++ を実行時切替可能な枠組みで実装し、Desktop Nightly / Beta、そして Release で 2026年7月2日〜19日にA/B/C実験を実施。直前のDukeのコメントに対する、まさにインターネット規模の実験にあたる。

データセットの構成

• 大多数の接続はcwndを一度も成長させない（app-limited）。成長したのは 8.61%、そのうちスロースタートを抜けたのは 4.42%。
• SEARCHはClassic/HyStart++よりスロースタート終了がやや多い（+約0.5ポイント）。
• ヒューリスティックによる終了の割合：Classic 0%（想定通り）、HyStart++ 約2.5%、SEARCH 12.6%。つまり終了の大半は依然として輻輳イベント起因。

なぜヒューリスティックが効かないのか

Release全体（ヒューリスティックなし）の終了時ssthreshは p50 = 20,000、p25 = 14,000、p5 = 8,600バイト。IW10 なら初期ウィンドウで既に輻輳を観測していることになり、ヒューリスティックが働く余地がない。

メトリクス

• パケットロス率（p95・p99）：SEARCH < HyStart++ < Classic。日次でも一貫してSEARCHが最良。
• アップロードスループット（10MB以上、p95）：日によって勝者が変わり結論が出ない。
• 終了時ssthreshのClassicとの差分：上位パーセンタイルではSEARCHがClassicより高い（Mozillaはドレインフェーズを未実装で、検出即終了である点に注意）。HyStart++は低めで、早期終了の疑い。一方、下位パーセンタイルでもSEARCHに差が出ており、これはブラウザ特有のapp-limitedなトラフィックパターンが連続送信の前提を崩し、バイト追跡ロジックを狂わせて早期終了させている可能性が高い。既定にできない障害要因であり、Jaeが示した緩和策に期待。
• 低ssthreshの理由の仮説：ボトルネックは家庭用ルータで、輻輳イベントの10〜20%がECN CE。つまりAQMが動いており、大バッファ+tail dropの環境より早く輻輳イベントを観測しているのではないか。

コミュニティへの質問：他者の接続パターン（cwndを成長させない割合、スロースタート終了率）と一致するか。8,600〜20,000バイトという低ssthreshの輻輳イベントが多いのはなぜか。

議論

• Martin Duke：SEARCHの方がヒューリスティック発動率が高いことと、HyStart++の終了ssthreshが低いことをどう整合させるか。HyStart++は低すぎるレートで発動しているのでは? → 発動時が上位パーセンタイル側に現れ、Classicが0.7倍した後の値より低いのは事実だが、解釈は未確定。
• Antonio Vicente（Cloudflare）：SEARCHの誤った早期終了が上位パーセンタイルを押し上げている可能性もある。最終ウィンドウの分布全体との比較も有用。
• Matt Joras（Meta）：接続メトリクスだけでは判断が難しい。ページロード時間やHTTPリクエストなどブラウザ側のメトリクスは取っていないか。スロースタートを変えるとGET/POSTやページロードに影響が出ることは経験的にある。→ ブラウザのメトリクスは主に受信側の話で、こちらの輻輳制御ではなくサーバ側に依存する、と応答。後で実ダッシュボードを見ながら相談することに。
• Mirja Kühlewind：時間ベースのメトリクスが有用。スロースタート終了までにかかったRTT数（RTTで正規化）を見れば差が出るはず。スロースタートを抜けない場合の改善も捉えられる。→ 後知恵では有用だが、メトリクスが集約済みのため遡って見ることができず、測るには実験のやり直しが必要。
• Kazuho Oku（Fastly）：ロスを経験した接続だけを見ているため結果が歪む可能性がある。BDPが大きい接続はよほど圧力をかけない限りロスを観測しないので、低BDPの接続が過剰に反映される。サーバ側のデータでも、200K超と1Mとでssthresh分布は2倍程度変わる。Mattの指摘どおりTTFBやアップロード完了時間を見るのがよい。
• Jae Chung：低ssthresh終了は自社ネットワークでも問題になっており、AQM（特にRED）の設定がネットワーク条件に合っていないことが一因。バースト的なドロップが起き、原因となったフロー以外の細いフローまで巻き添えにする。
• Martin Duke：メトリクスの解釈自体に悩んでいる。低い終了点が良いのか悪いのかはリンク条件次第で、この種の実験では知りようがない。終了後の輻輳回避の挙動を見てはどうか——直線的に伸び続けるなら早く抜けすぎ、ssthresh付近でのこぎり波を描いていればおおむね適切、という判断ができる。→ 最終cwndのメトリクスはあるが、多数の低ssthreshロスに引っ張られており信頼していない。

会場からは、Firefoxが送るのは少数のGETリクエストが中心なので大半の接続がスロースタートを抜けないのは自然、との確認もあった。Mozillaからは他ブラウザベンダの数値との比較を見たいとの希望が示された。

7. C4（Christian's Congestion Control Code）

Christian Huitema — draft-huitema-ccwg-c4-spec / -design / -test（いずれも -04）

目的は、特にメディアアプリケーションに適した高応答性の輻輳制御。帯域推定が小さすぎればフレームを十分速く送れず応答が悪化し、大きすぎればフレームを過剰に送って優先度逆転を招くため、その均衡を狙う。

テスト結果の提示方法の改善（前回のフィードバックへの対応）：3,000シナリオ×各100回の実行について、平均と最悪側90パーセンタイルの実行時間／レイテンシ（マイクロ秒、小さいほど良い）を併記し、同一テストをBBRやCubicで実行した結果と比較する形式に変更。ドラフト間の比較も可能。100回試行のため90%であり、将来1,000回に増やせば99%も出せる。結果としてC4はごく一部を除きほぼ全テストで既存手法を上回っているとの報告。

状態機械の変更

• Resuming状態の新設：careful resume（RFC 9959）の実装。以前は起動時の特殊条件として扱っていたが、独立した状態にした方がデバッグしやすい。記憶したデータレートで2 RTT送信し、輻輳を検出したら即座に離脱。2 RTT留まるのは、早く抜けると衛星回線などで性能への影響が大きいため。
• ProbingとPushingの分離：C4は元来「1 RTTだけ高いレートを試し、直後に1 RTT観測に戻る」という慎重な探索のみを行っていた（BBRのprecautionary probingの発想と近いが、C4はその逆方向の変更）。これは安全だが遅く、2 RTTに1回しか探索しないと帯域低下からの回復に倍の時間がかかる。そこで、+6.25%で1 RTT探索し成功が見込めればPushing状態に入り、+25%で伸びが止まるまで押す（BBR同様の指数的増加）ようにした。
• 持続的輻輳への高速応答：従来は輻輳検出のたびにbeta（25%）ずつ下げるため、経路変更などで帯域が落ちた際に階段状に何RTTもかけて追随していた。変更後は、最初の輻輳ではbeta減少、2回連続で輻輳サイクルが起きたら「何かが変わった」と判断して直近の測定値にnominal rateを合わせる。3〜5 RTTかかっていた追随が2 RTTで済む。
• 初期起動時のペーシング下限：起動時に公称レートの2倍でペーシングしていたが、そのレートが低すぎると送出が不足して測定が伸びず「詰まる」シナリオが多発した。ペーシングに**下限（1Mbps）**を設け、それ以下ではcwndのみが制限となるようにしたところ、詰まりが解消し全体の性能も改善。

次のステップ：セルラー網（帯域が常時変動する条件）、RED および RED+ECN のシミュレーション追加。バッファは現在2〜4×BDPで設定しており、bufferbloatを試すには20×BDP程度のケースが必要。C4同士／C4対BBRの競合シナリオでレイテンシを下げること——現状の公平性は輻輳時のバックオフで達成されており、少なくとも1 BDP分の遅延を伴う状態で均衡してしまう。Cubic相手には原理的に困難だが、レートを測るタイプの輻輳制御が相手なら改善できるはず。加えて、シミュレーションだけでなく実ネットワークでのテスト展開へ。

時間切れのため、Neal Cardwellのコメントはチャットに回された。

8. NDTC（時間切れで未実施）

Paul-Louis Ageneau ほか（Netflix）— draft-ageneau-ccwg-ndtc-02

アジェンダには5分枠があったがセッション時間内に発表されず、スライドのみ公開。内容は、高ビットレート・リアルタイム・インタラクティブ映像向けのレート適応／輻輳制御で、高速な立ち上がり・低遅延・低ロスが特徴。中核のヒューリスティック FDACE（Frame Dithering Available Capacity Estimation） はペーシングされたフレーム自体をプローブとして利用可能帯域を推定し、フレームの適時到着を確保しつつ自己誘発輻輳を先回りして抑える。AIMDロジックと組み合わせて従来のロス信号にも反応し、L4Sとも互換。Netflixのクラウドゲーミングサービスで実際に使用されている。-02では ecn_average の誤記、SLOPE計算での共分散チェック欠落、ECN条件でのAIMD減少抑止の誤り、MIN_LENGTH = MIN_TARGET/2 と比較すべき箇所の記述誤りを修正。Hackathonでも L4S 検証を継続し、パケット遅延変動約2msという結果が示されている。

セッション全体を通した論点

いくつかのテーマが発表をまたいで繰り返し現れた。

• 平均ロス率に基づく反応の広がりと、その副作用。SCReAM（1%）もBBRも同様の閾値を持ち、C4やCubicにも適用可能。閾値がばらつけば競合フロー間の公平性に影響し、さらにL4Sが前提とする「非ECNフローのドロップ率＝ECNのマーキング率の2乗」といったモデル式の妥当性にも波及する。IETFとして議論して収斂させるべき、という提案が出た。
• ポリサーへの対処は専用機構を作らない。Cardwell（BBRv1での実体験）とCheshireが揃って、一般的なロス応答を妥当にする方向を推奨。長期的にはECNを使うポリサーの実現を目標に置くべきという意見。
• スロースタート研究の評価軸そのものが未確立。Mozillaの実データで「終了ssthreshが高い／低いのどちらが良いのか」を判定できず、時間ベースのメトリクス（終了までのRTT数、TTFB、アップロード完了時間）や、終了後の輻輳回避の形状を見る、といった代替案が複数出た。またapp-limitedフロー（ブラウザ接続の大多数）でSEARCHが誤って早期終了する問題は、実装採用の実質的な障害として明確に指摘された。
• エミュレーション／シミュレーションと実測データのバランス。SEARCHにはFairhurstから実ネットワークデータの要求が出た一方、C4は3,000シナリオのシミュレーションを整備しつつ実網テストへ移行しようとしており、SCReAMもRFC 9743評価の「どこまで理論で、どこから実験で」という線引きが未解決の論点として残った。