LiteSpeedのLiteSpeed Web Server 5.4.2、Web ADC 2.6.0、OpenLiteSpeed 1.6.1でQUICの接続にBBRを使うようになったらしいです。

BBRは、Googleが開発した、Bottleneck Bandwidth and RTTという新しい輻輳制御のアルゴリズムです。BBRの解説は、こちらで読むことができます。ちなみに、BBRv2 もgoogleによって開発が進んでいるようです。

LiteSpeedの記事は、BBRの特徴、欠点、特徴を確認するためのテストを行った結果などが書かれている記事です。

特徴は、輻輳に起因しないロスに反応しにくいことと、レイテンシーが小さいことの2つです。

欠点は、shallow bufferの時に性能が低い点と、他のフローに対して公平ではない点が挙げられていました。

記事ではcubicとBBRを比較しBBRの特徴を確認するために2つのテストを行っています。一つ目は、パケットロスの値を変化させた時の、10MByteのファイルのダウンロードスピードの変化を見ます。二つ目は、大きいファイルと小さいファイルを同時にダウンロードさせたときのBBRとcubicの振る舞いの違いを見ています。前者の実験ではパケットロス率を0, 0.5, 1, 2, 3 と上げていくごとにファイルのダウンロード時間が長くなっていくことが分かります。後者の実験では、BBRを使用したときはネットワーク上のバッファをちょうどよい使い方をするので小さいファイルのダウンロード時間がRTTとほぼ同じ時間で終わっていることを示しています。

特徴

Resistance to Loss

BBRの主なアイディアは、パケットロスが発生していることが、輻輳が起きていることを意味しないかもしれないと考えることです。例えば、パケットは、一時的な電波の干渉によって発生することも考えられます。 cubicや他の輻輳制御のアルゴリズムは、輻輳が原因ではないパケットロスと実際の輻輳を区別せずに、両方の場合に送信レートを下げます。

BBRは簡単にはその影響を受けません。結果、BBRはネットワークの状態が準最適の場合でもスループットを保つことができます。

Minimal Latency

BufferbloatがUXにとって良くないと何年も言われています。インフラでもbufferbloatを避けるために大量のデータをバッファリングすることを避けるように変更が進められていました。

それにもかかわらず、cubicは、ネットワークのパス上に存在するbottleneck bufferを埋めようとしてしまい、その結果接続のレイテンシーが増加してしまいます。

An in-depth study of LTE: effect of network protocol and application behavior on performanceでは、パケットロスをマスクするために、バッファーが広範囲に使用され、それによりRTTが増大することが明らかになりました。

BBRは、bottleneck bandwidthを追跡し、定期的に最小のRTTをテストします。これらの評価は送信者によって、bottleneck bufferを埋め尽くさないようにするために使われています。BBRを使うことで、ウェブアプリケーションはより、responsiveになる可能性が高いです。