ECN（明示的輻輳通知）の仕組みと L4S

ECN は何を解決するのか

輻輳制御の古典的な前提は「パケット損失こそが輻輳のシグナル」です（AIMD と輻輳制御の数理 参照）。しかしこの設計には根本的な無駄があります。輻輳を送信側に伝えるために、わざわざパケットを捨てる必要があるのです。捨てられたパケットは再送され、再送には最低 1 RTT、場合によっては再送タイムアウト（RTO）相当の遅延が乗ります。

ECN（Explicit Congestion Notification, RFC 3168）はこの無駄を断ちます。ボトルネックのルータが、パケットを落とす代わりにパケット自身に輻輳マークを付け、受信側経由で送信側へ「混んでいる、減速せよ」と明示的に通知します。パケットは破棄されないので再送が要らず、損失による遅延を避けつつ送信側を減速させられます。AQM（バッファブロートと AQM 参照）が「いつ合図を出すか」を決め、ECN が「どう合図を運ぶか」を担う、という役割分担です。

IP と TCP のビット連携

ECN は IP ヘッダの ToS/Traffic Class フィールド下位 2 ビット（ECN フィールド）を使います。取りうる 4 つの符号点（codepoint）の意味はこう定義されています。

動作の流れはこうです。ECN 対応の送信側は IP パケットを ECT（ECT(0) または ECT(1)）で送り出します。経路上のルータが輻輳を検知し、かつそのパケットが ECT であれば、破棄する代わりに ECN フィールドを CE（11） に書き換えます。Not-ECT のパケットしか扱えないルータ、あるいは ECT でないパケットは、従来どおり破棄するしかありません。

受信側はこの CE を見ても、その場で何かできるわけではありません。減速すべきは送信側だからです。そこで TCP は CE を送信側へ折り返すために、ヘッダに 2 つのフラグを持ちます。

• ECE（ECN-Echo）: 受信側が「CE 付きパケットを受け取った」ことを送信側へ伝えるフラグ。一度受け取ると、送信側が応答するまで以後の ACK で ECE を立て続けます（確実に届けるため）。
• CWR（Congestion Window Reduced）: 送信側が「ECE を受け取り、輻輳ウィンドウを減らした」ことを受信側へ伝えるフラグ。これを見た受信側は ECE を下ろします。

古典 ECN（RFC 3168）の限界

ここまでは一見うまくできた仕組みに見えますが、RFC 3168 の ECN には決定的な制約があります。CE マークを 1 個受け取ったときの送信側の反応が、パケット損失 1 個と完全に等価である、と定義されている点です。つまり ECE を受け取った Reno/CUBIC は、損失時とまったく同じ乗法減少（cwnd を半分、CUBIC なら約 0.7 倍）を行います。

これが低遅延の妨げになります。マークが損失と等価なら、ルータはマークを滅多に付けてはいけません。頻繁にマークすれば送信側が過剰に減速し、スループットが崩れるからです。結果として AQM はキューがかなり深くなってからようやくマークを出すことになり、せっかく損失を避けてもキューイング遅延そのものは大きいままです。ECN は「損失による再送遅延」は消せても、「キューに溜まることによる遅延」は消せなかったのです。

L4S — マークの意味を作り替える

L4S（Low Latency, Low Loss, Scalable throughput, RFC 9330）は、CE マークの解釈を根本から変えます。マークを「損失と等価な 1 回の大減速イベント」ではなく、輻輳の度合いを表す確率的シグナルとして扱うのです。キューが少しでも深くなり始めたら高い頻度で（場合によっては毎 RTT 多数の）マークを付け、送信側はマーク率に比例して細かく cwnd を調整します。荒い半減ではなく、連続的な微調整に変わります。

この「頻繁にマークして比例的に反応する」輻輳制御を Scalable（スケーラブル）と呼びます。代表が DCTCP（Data Center TCP）と、インターネット向けの TCP Prague や QUIC 版の実装です。スケーラブルな制御では、1 RTT あたりのマーク数が cwnd の大きさによらずおおむね一定に保たれ、帯域が増えてもキューを浅いまま運用できます。

ECT(1) と DualQ による分離

L4S 最大の設計課題は共存です。同じボトルネックに、毎 RTT 多数マークを期待する L4S フローと、1 マーク＝大減速の古典フローが混在したらどうなるか。古典フローを L4S 流の頻度でマークすれば過剰減速で潰れ、L4S フローを古典流の頻度でマークすれば低遅延になりません。同一キューでは両者を満足させられないのです。

解決策が ECT(1) を識別子に転用することです。L4S 対応の送信側は ECT(0) ではなく ECT(1) でパケットを送ります。ボトルネックの DualQ Coupled AQM（RFC 9332）はこのビットを見て、トラフィックを 2 本のキューへ振り分けます。

• L キュー（Low Latency）: ECT(1) のスケーラブルなフロー用。ごく浅い遅延しきい値（例: 1ms 程度）で頻繁に CE マークする。
• C キュー（Classic）: それ以外（Not-ECT / ECT(0) / 古典 ECN）用。従来型の AQM（PI2 など）で制御する。

両キューは独立ではなく結合（coupled）されています。C キューの輻輳水準を L キューのマーク率へ換算して反映させることで、L4S フローと古典フローがおおむね公平に帯域を分け合えるよう調整します。これにより L キューを浅く保ったまま、古典フローを過剰に締め付けずに共存できます。

# DualQ Coupled AQM の分類と処理（要点）
on enqueue(pkt):
    if pkt.ecn == ECT(1) or pkt is scalable:
        put pkt -> L_queue        # 低遅延キュー
    else:
        put pkt -> C_queue        # 古典キュー

# L キューは浅いしきい値で高頻度に CE マーク
# C キューのドロップ/マーク確率 p_C から
# 結合して L キューのマーク確率を導く:
#   p_L = k * sqrt(p_C) など（実装依存の結合式）
#   ＝ 古典側 p_C は L 側 p_L の二乗に対応（p_C = (p_L / k)^2）
# 2 本から取り出す際は L キューを優先しつつ
# C キューが飢餓に陥らないようスケジュールする

実務上の含意

L4S が狙うのは、回線を使い切りながらキュー遅延をほぼゼロに保つことです。動画会議・クラウドゲーミング・XR のように、スループットと低遅延を同時に求める用途で効きます。バッファブロート対策が「定常キューを早く崩す」アプローチだったのに対し、L4S は「そもそもキューを深くさせない」ことを輻輳制御側と AQM 側の両方から実現します。

エンド側では QUIC が ECN を扱いやすい点も追い風です。QUIC は ACK フレームで CE/ECT(0)/ECT(1) の受信カウントをそのまま運べるため（QUIC の内部構造 参照）、TCP の ECE/CWR より精密なマークフィードバックを送れます。輻輳制御方式全体の中での位置づけは TCP輻輳制御の系譜 を参照してください。