輻輳制御の新アルゴリズム TCP BBR を GCP に導入

私たちはこのほど、インターネット トラフィックの帯域幅を広げ、レイテンシを低減する最先端の輻輳制御アルゴリズム、TCP BBR を Google Cloud Platform（GCP）に導入しました。TCP BBR は、google.com からの TCP トラフィックで使われ、YouTube ネットワークのスループットを全世界平均で 4 %、一部の国では 14 % 以上引き上げたのと同じ BBR です。

WP Engine のような GCP のお客様は、BBR 導入によって自動的に 2 つのメリットを手にします。

• GCP サービスからクラウド ユーザーへ : GCP のお客様が Cloud Bigtable や Cloud Spanner、Cloud Storage などの GCP サービスとやり取りするとき、GCP サービスからアプリケーションへのトラフィックは BBR を使って送られます。これは、データ アクセスの高速化を意味します。
  
• Google Cloud からインターネット ユーザーへ : GCP のお客様がウェブ サイトのサービス提供や負荷分散のために Google Cloud Load Balancing や Google Cloud CDN を使うとき、コンテンツは BBR を使ってユーザーのブラウザに送られます。これは、ウェブ ページがサイトのユーザーのもとに速くダウンロードされることを意味します。

BBR とは何か

では、輻輳制御アルゴリズムが送信速度を左右するというのはどういうことでしょうか。

1980 年代の後半から、インターネットではスローダウンの兆候としてパケット ロスだけを頼りとする loss-based 輻輳制御が主として使われてきました。インターネット スイッチやルータの小さなバッファはインターネット リンクの低帯域幅にちょうど見合ったものだったので、この方法は長年にわたってうまく機能したのです。これらのバッファは、送信側のデータ送信速度が速くなりすぎた途端にいっぱいになってパケットを消失してしまう傾向がありました。

しかし、このような loss-based 輻輳制御は、今日の多種多様なネットワークでは問題があります。

• バッファが浅い場合、パケット ロスは輻輳が起きる前に発生します。バッファが浅いコモディティ スイッチを使っている現代の高速長距離リンクで loss-based 輻輳制御を行うと、過剰反応を起こしてスループットがひどく落ちてしまうことがあります。一時的なトラフィックのバーストによりパケットが消失しているときでも（この種のパケット ロスは、リンクがほとんどアイドル状態でもよく起きます）、送信速度が半分になってしまうのです。
  
• バッファが深い場合、輻輳はパケット ロスが起きる前に発生します。インターネットの末端では、loss-based 輻輳制御は悪名高いバッファブロート問題を引き起こします。多くのラスト ワンマイル リンクで使われている深いバッファを繰り返しいっぱいにしては、無駄に数秒間のキューイング遅延を発生させるのです。

BBR は、どのくらいのペースでネットワークにデータを送り出すかを決めるにあたって、そのネットワークがどれくらいの速さでデータを送り届けているかを考慮します。一定のネットワーク接続におけるネットワークの転送速度とラウンドトリップ時間の最近の測定値を用いて、その接続の帯域幅の上限と最小のラウンドトリップ遅延の両方を含むモデルを構築します。BBR はこのモデルを用いて、データの送信速度とネットワークに流し込むデータ量の上限を常に制御します。

Google Cloud のお客様にとってのメリット

たとえば YouTube の場合、BBR でネットワークの帯域幅をより効果的に判定、利用するようになったことから、ネットワーク スループットが 4 % も向上しました。また、BBR はネットワーク キューを短く保つので、ラウンドトリップ時間が 33 % も短縮しています。これは、レイテンシに敏感なウェブ ブラウズやチャット、ゲームなどのアプリケーションでは応答が速くなり、遅延が短縮されることを意味します。さらに、パケット ロスに過剰反応しなくなったことで、再バッファリングまでの平均時間が 11 % 長くなっています。これらは全体として、デスクトップやモバイルを問わず、世界中のあらゆるユーザーに大幅な改善をもたらします。

Google は動画再生のユーザー エクスペリエンスを向上させることに長い間こだわり続けてきました。YouTube はすでに高度に最適化されているだけに、こうした数字は特に注目すべきものです。しかも、イテレーションとチューニングを継続して行えばさらに良い結果が得られることが、実験から明らかになっています。

BBR は根本的な部分の改善であり、そのメリットは Google や YouTube にとどまりません。いくつかの合成マイクロベンチマークから、BBR から得られるメリット（必ずしも一般的に注目されるほどの規模ではない）の本質が明らかになっています。

• スループットの向上 : BBR は、高速長距離リンクでは大幅なスループットの向上を実現します。10 ギガビット イーサネット リンクを備え、パケット ロス率 1 % でラウンドトリップ時間が 100m 秒のパス（たとえばシカゴとベルリン間）にデータを送出するサーバー クラスのコンピュータについて考えてみましょう。この場合、BBR のスループットは、現時点でベストの loss-based 輻輳制御である CUBIC の 2,700 倍になります（CUBIC の 3.3 Mbps に対し、BBR は 9,100 Mbps を超えます）。このようにパケット ロスに強いため、単一の BBR 接続だけでパケット ロスのあるパスをフルに活用できます。この特徴は、単一の接続を使い、使用率の上限を使い切るために複数の TCP 接続を開設するような策を弄する必要がない HTTP/2 には特に合っています。最終的には、高速バックボーンのトラフィックがさらに速くなり、帯域幅が大幅に広がるため、ウェブ ページ、動画、その他のデータのダウンロード時間が短縮されます。
  
• レイテンシの低減 : BBR は、ユーザーとインターネットを結ぶラスト ワンマイル ネットワークのレイテンシを大幅に低減します。帯域幅が 10M ビット、ラウンドトリップ時間が 40m 秒の典型的なラスト ワンマイル リンクと、1,000 パケットの典型的なボトルネック バッファについて考えてみましょう。このような環境では、BBR のキューイング遅延は CUBIC の 25 分の 1 に短縮されます（CUBIC の平均ラウンドトリップ時間が 1,090m 秒なのに対し、BBR ではわずか 43m 秒です）。BBR はキューを短縮し、動画閲覧やソフトウェア ダウンロード時のラスト ワンマイル リンクのキューイング遅延を短縮します。そのぶん、ウェブ サーフィン、ビデオ会議、ゲームの応答性は良くなります。このようなバッファブロート抑制能力を考えると、BBR という名前は、“Bottleneck Bandwidth and Round-trip propagation time” だけでなく “BufferBloat Resillience” の略だと言うこともできるでしょう。

ディスカッションに参加したり、最新の BBR 関連ニュースをフォローしたり、BBR に関するトークの動画を見たり、オープンソース BBR の開発やテストに協力したい方は、bbr-dev の公開メール グループにぜひご参加ください。

* この投稿は米国時間 7 月 20 日、Neal Cardwell（Senior Staff Software Engineer）、Yuchung Cheng（Senior Staff Software Engineer）、C. Stephen Gunn（Senior Staff Site Reliability Engineer）、Soheil Hassas Yeganeh（Senior Software Engineer）、Van Jacobson（Research Scientist）、Amin Vahdat（Google Fellow）によって投稿されたもの（投稿はこちら）の抄訳です。