バッファブロートと AQM（CoDel・FQ-CoDel・PIE）

バッファブロートとは何か

バッファブロート（bufferbloat）は、ルータやモデムが過大なバッファを持つために、輻輳時にパケットがそこへ大量に溜まり、パケットロスは起きないのに遅延が肥大する現象です。直感に反するのは「ロスがない＝健全」ではない点です。むしろロスが出ないほどキューが深く埋まり、その分の滞留時間がそのまま往復遅延（RTT）に上乗せされます。

なぜ過大バッファが生まれたか。メモリが安くなり、設計者が「捨てるより貯めるほうが良い」と考えてバッファを大きく取ったためです。ところがエンド間の輻輳制御は損失を輻輳のシグナルとして使います（AIMD と輻輳制御の数理 参照）。バッファが深いと送信側は損失を観測できず、cwnd を増やし続け、バッファを満杯近くまで埋めてしまいます。この「常に満杯近くで動く」状態が標準になることが問題の本質です。

なぜ「キュー長」での制御は破綻するか

古典的な対策は RED（Random Early Detection）で、平均キュー長がしきい値を超えると確率的にパケットを落として送信側を早めに減速させます。考え方は正しいのですが、運用が破綻しました。

RED のしきい値はパケット数（またはバイト数）で指定します。しかし「何パケット溜まったら困るか」はリンク速度・RTT・フロー数に依存し、固定値で適切に設定するのは事実上不可能です。min_th・max_th・max_p を手で調整する必要があり、ほとんどの現場で無効化されました。

ここで Kathleen Nichols と Van Jacobson の洞察が効きます。問題なのはキューが長いことそのものではなく、キューが長く居座ることです。バースト的なトラフィックを吸収する一時的なキュー（good queue）は有益で、これを落としてはいけません。落とすべきは、いつまでも掃けない定常的なキュー（bad queue）だけです。両者を見分ける指標がキュー長ではなく、パケットの**滞留時間（sojourn time）**である、というのが AQM 第二世代の出発点です。

CoDel の内部動作

CoDel（Controlled Delay, RFC 8289）は、各パケットがデキューされる瞬間に滞留時間を計測し、それが一定以上に居座り続けるかどうかだけを見ます。パラメータは実質 2 つで、リンク速度に依存しません。

• target（目標遅延）: 既定 5ms。許容するキュー遅延の下限。
• interval（観測窓）: 既定 100ms。おおむね最悪 RTT に相当する時間。

アルゴリズムの骨子はこうです。デキュー時の滞留時間が target 未満なら、キューは健全とみなしドロップしません。滞留時間が target 以上の状態が interval の間継続したら、ドロップ状態に入り 1 個落とします。ドロップ状態の間は、落とすたびに次のドロップまでの間隔を詰めていきます。

# CoDel デキュー時の擬似コード（要点）
sojourn = now - packet.enqueue_time
if sojourn < target or queue_bytes < MTU:
    dropping = false            # キューは健全。一時バーストは許す
else:
    if not dropping:
        dropping = true
        count = 1
        drop_next = now + interval / sqrt(count)
    while dropping and now >= drop_next:
        drop(packet); packet = dequeue()
        count += 1
        drop_next = drop_next + interval / sqrt(count)

核心は interval / sqrt(count) というドロップ間隔の縮め方です。輻輳が続くほど count が増え、次のドロップまでの間隔が逆数平方根で短くなります。これは TCP のスループットが損失率 p の平方根に反比例する（1/sqrt(p) 則）ことと整合します。スループットを線形に下げるには、ドロップ頻度を平方根のペースで上げる必要があるからです。逆にキューが捌けて滞留時間が target を下回れば dropping を解除し、次に輻輳が再発したときは前回の count を引き継いで素早く反応します（控えめにデクリメントして再利用）。

FQ-CoDel — フロー分離との合わせ技

CoDel 単体は 1 本のキューを制御しますが、実運用で広く使われるのは FQ-CoDel（Flow Queueing + CoDel, RFC 8290）です。これは入ってきたパケットを 5-タプルのハッシュで多数のサブキュー（既定 1024 本）に分け、各サブキューを CoDel で個別に管理したうえで、サブキュー間を**改良版 DRR（Deficit Round Robin）**で公平に取り出します。

効果は二重です。第一に、各フローが独立した CoDel インスタンスを持つため、1 本の大量転送（エレファントフロー）が自分のキューだけを埋め、他のフローの遅延を巻き込みません。第二に、新規・低レートのフロー（DNS 問い合わせ、対話的な ACK、Web の最初の数パケット）を優先する仕組みを持ち、これらが大量転送の後ろで待たされません。結果として、ダウンロード中でも音声通話や SSH の応答性が保たれます。FQ-CoDel はホームルータや Linux の既定キューイング規律として事実上の標準になっています。

PIE — 比例積分による遅延制御

PIE（Proportional Integral controller Enhanced, RFC 8033）は、CoDel と同じくキュー遅延を制御目標にしますが、手法が制御理論的です。CoDel がデキュー時に滞留時間を直接測るのに対し、PIE は定期的（既定 15ms ごと）に現在のキュー遅延を推定し、目標遅延 target（既定 15ms）との誤差からドロップ確率 p を更新します。

# PIE のドロップ確率更新（周期 Tupdate ごと）
err   = cur_delay - target
p += alpha * err + beta * (cur_delay - old_delay)
#        └比例項(P)         └微分的な傾向項(I相当)
old_delay = cur_delay

alpha は現在の遅延誤差に比例して p を動かす項（比例制御）、beta は遅延の変化の向きを見て先回りする項です。遅延が目標より大きく、しかも増え続けているなら p を強めに上げ、目標に近づいて減少傾向なら緩める。これにより遅延を target 付近へ滑らかに収束させます。キュー遅延の推定は、現在のキュー長 Q をデキュー実測レートで割る（Q / drain_rate）リトルの法則的な近似で行います。エンキュー時に確率 p でドロップするため、デキュー経路の計算負荷が軽く、ハードウェア実装（DOCSIS ケーブルモデムなど）に向くのが PIE が採用された理由です。

ECN との連携と実務上の含意

AQM は「落とす」代わりに ECN（明示的輻輳通知） でパケットに輻輳マークを付けられます。落とさずに減速シグナルだけ送れるため、再送遅延を避けつつキューを浅く保てます。CoDel・PIE とも、ドロップする代わりに ECN マークする変種を持ちます。

実務上の急所は、AQM がエンド間の輻輳制御と役割分担している点です。AQM はボトルネックのキューを浅く保ち、損失や遅延のシグナルを早く送信側へ返します。送信側はそれを受けて減速します。BBR の帯域・RTT推定モデル のように損失を待たず帯域と RTT を直接推定する方式は、深いバッファ自体を埋めにくくする別アプローチで、AQM と補完関係にあります。輻輳制御方式の全体像は TCP輻輳制御の系譜 を、遅延とスループットの基礎関係は 帯域・レイテンシ・スループット を参照してください。