インターステラの阿形です。
GCPのブログに以下のような記事が投稿されていました。
TCP BBR congestion control comes to GCP – your Internet just got faster
GCPのサービスでTCP BBR輻輳制御アルゴリズムを使うようになったよ、というお知らせです。
ネットワーク、特にTCP/IPについての知識がないとなんのこっちゃだと思いますが、ちょっと気になったのでざっくりと読んでみました。
TCP BBR輻輳制御アルゴリズムについては、ざっと見たところ、旧来のパケットロスを検出しての輻輳制御ではなく、転送速度の計測とRTTをベースにし、なるべく途中経路のバッファ溢れを引き起こさないようにするアルゴリズムのようです。
詳しくは以下のページに詳しく掲載されていますので、興味のある方はこちらを読んでみてください。
BBR: Congestion-Based Congestion Control
記事によると、GCPにBBRが導入されることで、より高いスループットと低いレイテンシーが実現できるとされています。
Youtubeの実験によると、スループットが4%向上し、バッファの使用率を低下させることによって、RTTを33%改善したとのことです。
「えー?たった4%?」と思う方もいらっしゃるかもしれませんが、たかが4%されど4%。
それにRTTの改善効果のほうが重要かもしれません。一方的にデータを流し続けるようなダウンロード型サービスよりも、インタラクティブなWebやゲームなどにかなり効果がある可能性があります。
なお、この実験の結果として記事中に掲載されているグラフがちょっと気になったので、ここに引用します。
こちらのグラフを見ると、JP、つまり日本のスループット改善率が突出して高いです。この点について記事中では何も触れていないので、原因はよくわかりません。
一方、以下のRTTの改善率はそれほど高くありません。(USについで2番めに低い)
このスループットの改善率が高く、RTTの改善率が低い状況の原因ですが、以下のような仮説を考えてみました。
順番が前後しますが、まずRTTから。
アルゴリズムの特性として、バッファの使用率を低く抑え、ネットワーク機器のバッファに溜め込む時間を減らすことでRTTを改善しています。
だとすると、これの改善率が低いということは、元々バッファの使用率が低いことが考えられます。
バッファの使用率が低いということは、パケットの送信を待つ必要がない、つまり帯域に余裕があってどんどんパケットの送信ができる、またそれを行えるだけネットワーク機器の性能も高いということが考えられます。
つまり、日本国内のネットワーク帯域に余裕があり、ネットワーク機器の性能が高いため、RTTはあまり効果が出なかったと考えられます。
一方スループットの方は今ひとつはっきりしませんが、上記のようにネットワーク帯域に余裕があるのがよりプラスに働いたのかもしれません。
さて、実際のところはどうしてなんでしょうか?
中の人に聞いてみたいところです。
ただ、このデータのとおりだとすれば、日本国内だとかなり使用するメリットはありそうです。