Top Trends in Cybersecurity for 2024 | 
ボトルネック帯域幅とラウンドトリップ伝播時間(BBR)はTCP輻輳制御アルゴリズムであり、多くのコンテンツプロバイダによって報告されているように、より高いスループットを提供できるため、市場で大きな注目を集めている。 本記事では、大量のソフトウェアアップデートとストリーミングビデオを提供するVerizon Media (現Edgio )のコンテンツ・デリバリー・ネットワーク(CDN)ワークロードのコンテキストでBBR(バージョン1)を評価し、トラフィックへの利点と影響を定量化する。 大規模なCDNでのこのような評価が、他のコンテンツプロバイダがトラフィックに適した輻輳制御プロトコルを選択するのに役立つことを願っている。
背景
多くのコンテンツプロバイダや学術研究者は、BBRはTCP-Cubicのような他のプロトコルよりもスループットが高いことを発見している。 ユビキタスなTCP-Cubicのような損失ベースの輻輳制御アルゴリズムとは異なり、BBRは異なる動作パラダイムを持っており、バッファブロートを避けるためにセッションがこれまでに見た最小RTTに基づいて、どのくらいのデータが送信中であるかを継続的に更新する。 BBRの運用についての詳細は、Googleからのオリジナルの出版物をここで見て。
測定と分析
CDNにおけるBBRの可能性を理解するために、いくつかのプレゼンスポイント(POPS)からのTCPフローへの影響を測定し、複数の段階でBBRを評価した。 PoPは、大都市圏にあるキャッシングサーバの集中を表す。 最初に、PoPで小規模なBBRテストを実行し、また、すべてのフローがBBRを実行しているクライアントへのフルPoPテストを実行した。 クライアントが経験する利点を特定するために、テスト中の社内プロキシウェブサーバログからのスループットとソケットレベル分析を測定した。
評価する指標
当社のマルチテナントCDNは、多種多様なクライアントトラフィックを認識している。 多くの顧客は小さなオブジェクトをたくさん持っているが、他の顧客ははるかに大きなマルチギガバイトのオブジェクトを持っている。 したがって、異なるトラフィックパターンにわたって実際のパフォーマンスの向上を捉える成功指標を特定することが重要である。 特に、この評価のために、成功パラメータとしてスループットとTCPフロー完了時間を特定した。 図1では、CDNから要求された共通オブジェクトサイズと、それらを提供するのにかかった時間のヒートマップを示す。 色のグラデーションは、各カテゴリのリクエスト数を示す。 これらは、共通の動作のみを捉えるのに十分な、少数のサーバのセットからの代表的な番号である。
図1。 共通のオブジェクトサイズを示すヒートマップ。
ヒートマップは、異なる要求パターンを理解することを可能にする。 一般的に、スループットを上げることが性能向上の最良の指標である。 しかし、測定としてのスループットは、特にオブジェクトサイズが小さい（数MB未満）場合には非常にノイズが多い。 そのため、スループット評価にはどのサイズが最も信頼性の高いものかを別々に評価し、3MB以上のオブジェクトサイズのみを使用する。 オブジェクトサイズが3MB未満の場合は、フロー完了時間の追跡が良いメトリックである。
評価の最初のステップとして、ロサンゼルスのPoPにあるいくつかのサーバでBBRを有効にし、すべてのTCPフローのスループットとフロー完了時間を監視した。 以下の結果は、いくつかのインターネットサービスプロバイダ固有のケーススタディを検証した。
大規模なワイヤレスプロバイダー
図2は、BBRをオンにしたときの違いを示す。
図2。 BBRがオン（テスト）になったときの大規模な通信事業者のクライアントのスループットへの影響と、キュービックフロー（制御）の比較。 左：2日間のスループット測定。 青色の縦線は、BBRがアクティブになったことを示す。 ここでは、BBRの全体的な改善が約6-8%見られる。 右：5パーセンタイルスループットのCDF。 BBRフローは大幅な改善を示している。
このワイヤレスプロバイダでは、BBRを有効にするとすぐに、平均で6～8%のスループット改善が見られた。 TCPフロー完了時間も全体的に低下した。 この発見は、Spotify、Dropbox、YouTubeの他のレポートとも一致しており、パケットロスが一般的なワイヤレスネットワークではスループットが明らかに向上しているが、それは必ずしも輻輳の指標ではない。
大規模な有線プロバイダー
次に、大規模な有線プロバイダーのパフォーマンスを調べた。 ここでも、BBRを使用したスループット(大きなオブジェクトの場合)とフロー完了時間(図3参照)の両方の改善が見られた。
図3。 大規模な有線プロバイダーのフローを完了するのにかかった平均時間。 BBR（テスト）フローのジッタが少なくなり、データ転送の完了にかかる時間が短縮される。 利点はより大きい目的のためにより影響を与える。 しかし、CubicとBBRの両方で大きなファイルサイズについては、同様のジッタが見られる。
これらのテストから報告された利益は、クライアント側トラフィックについて非常に有望な結果を示している。
これらの利益は集約されたビューにあるため、PoPでのすべてのTCPフローがBBRを使用する利点を見たかどうかを確認するために、もう少し掘り下げることにした。
CDNエッジでは、次の4種類のTCPセッションを実行する。
- Pop-to-Client（上図のように）
- ポップツーポップ（データセンター間）
- ポップ内通信（同じポップのキャッシュ間）
- Pop-to-Origin（顧客のオリジンデータセンターへのポップ）
エッジからオリジンまでの量は他の3つほどではないため、本研究ではpop-to-client、pop-pop、およびintra-popフローを検討した。
ポップツーポップおよびポップ内トラフィック
これらのTCPフローへの影響も評価することが重要である。多くの場合、これらのフローは動的コンテンツなどのクライアント配信のブロッカーであるためである。
Pop間およびIntra-Popトラフィックのスループットでは、パフォーマンスの大きな回帰が見られた。 図4は、同一期間におけるPop内トラフィックとPop間トラフィックへの影響を示す。
図4。 BBRがオン（テスト）の場合のポップ内およびポップツーポップトラフィックのスループットへの影響と、キュービックフロー（制御）の比較。 2日間のスループット測定。 青色の縦線は、BBRがアクティブになったことを示す。 スループットはBBRで約半分減少した。
エンドユーザーへのフロー間およびデータセンター間の明確なパフォーマンスの違いは、これまでの調査結果では報告されていない。 これらの特定のTCPフローが発生した理由、これがハードウェアまたはCDNの構成によるアーチファクトである場合、およびその場合、どのチューニングを変更する必要があるかを評価する必要がある。
Webサーバのアクセスログを用いたさらなる調査とサーバ側ソケットデータからの評価から、RTTの高さと低さの両方のフローが存在する場合、RTTの低いTCPフローがBBRを使用することに悩まされていることが明らかになった。 さらに0.5KB未満のデータを転送した場合を評価した結果、ほとんどの場合、BBRはキュービックと同様の機能を持つことがわかった。
これらの結果から、我々のトラフィックパターンについては、RTTと損失が低いPop内およびPop間通信にCubicを使用する方が良いと結論付けた。 クライアント側のトラフィックの場合は、BBRを使用する価値がある。
フルポップテスト
BBRのパフォーマンス上の利点を大規模に評価するために、リオデジャネイロのPOPで、当社のネットワークからのすべてのクライアント側トラフィックについて、POPテストを実行した。 このPoPは、リージョン内のロケーションとピアリング制約により、クライアントが経験するRTTの中央値が他のリージョンよりも高くなるため、興味深いケーススタディとなった。
図5。 高再送信（ASN1）を示すクライアント用のBBRを使用したスループットの向上。
輻輳制御アルゴリズムの変更を導入し、パフォーマンスを監視した。 RIOの上位2つのASE(Autonomous Systems)についてBBR vs. Cubicを用いて観察されたスループットのCDFを示した。 図5に見られるように、全体的に1つはBBRの利点を見ていたが、別のものはそうではなかった。
その背後にある理由を調査するために、ssユーティリティを使用してテスト中に収集された他のTCPメトリクスを探した。 これら2つのASの再送信速度には明確な違いが見られる。 RTTが高いASでも、BBRは再送信回数が多い場合にのみうまく機能する。つまり、損失の少ないASでは、キュービックはバックオフする理由がなく、BBRよりも優れたパフォーマンスを発揮する。 しかし、TCP Cubicのパラメータの多くは、我々のCDNで注意深く調整されていることに注意することが重要である。
次に、図5に示すASN1からのすべての接続がスループットの改善を示しているかどうかを調査した。 図6は、さまざまなオブジェクトサイズのBBR接続とキュービック接続にかかった時間のプロットである（低いほどスループットが向上する）。 ここで、BBRはMBのオーダーで、より大きなオブジェクトに対して顕著な利点を示し始めただけであることがわかる。 BBRを使用した異常なインスタンスが1つ見られたが、特定の輻輳制御プロトコル関連の問題に起因するとは言えなかった。
図6。 改善を示すASEでは、BBRの利点は、大きなファイルを持つ長時間実行されるフローに見られる。
なぜこれが起こるのか?
これらの結果には2つの次元があり、キュービックvs. BBRとBBRである。
キュービックvs. BBR
BBRは、ボトルネック帯域幅を見積もるときに、バッファサイズとRTTに非常に反応する。 ミドルボックスがキューを構築する可能性のある大きなバッファの場合、BBRの推定RTTは増加する。 パケットロスがないため、Cubicはそのような場合、つまりポップツーポップ型のトラフィックをバックオフしないため、Cubicはより高いスループットを達成する。 無線クライアントのような小さなバッファの場合、バッファは急速にいっぱいになり、損失をもたらす。したがって、キュービックフローはオフに戻り、BBRフローのパフォーマンスが向上する。
BBR vs. BBR
このシナリオでは、損失が発生してもフローバックが発生しない。 しかし、異なるRTTを持つ2つのフローが帯域幅の共有を求めて競合する場合、より高いRTTを持つフローもより大きな最小RTTを持ち、したがってより高い帯域遅延積を持つ。 したがって、このフローは、RTTが低いフローよりもはるかに速い速度で機内データを増加させる。 これにより、RTTの降順でフローに帯域幅が再割り当てされ、RTTが大きいフローは、RTTが小さいフローよりも早くバッファを埋める。
ラボ環境での結果の再現
フロー間の相互作用の理解を深めるために、本番環境で見た動作をキャプチャするテストベッド環境を仮想マシンに作成した。 エッジサーバでさまざまなトラフィッククラスをシミュレートする方法を次のように特定した。
クライアントトラフィック遅延は、損失が0.001～0.1の範囲で、ボトルネック帯域幅が50Mbpsの50ミリ秒に設定されている。 同様に、Pop-to-Popのみの損失と遅延は~15msと0.0001から0.01に設定されている。 PoP内トラフィックについては、VMが使用可能な容量を最大にする。 最後に、さまざまなオブジェクトサイズを使用してシミュレーションを実行し、トラフィックのマルチテナント特性をキャプチャした。 3つのトラフィックパターンすべてをフローの指数的到着と並行して実行し、Poissonスタイルのフロー到着分布をキャプチャする。 図7にテストベッドのセットアップを示す。
このテストの目標は、実稼働テストで見られる問題、特にPop内トラフィックとPop間トラフィックの小さなRTTフローのスループット低下を再現することであった。
図7。 KVM、iperf、netem、およびtcユーティリティを使用したラボセットアップ。
この設定を使用して、CubicとBBRの両方のバックグラウンドトラフィックをシミュレートしてシミュレーションを数百回実行し、フローを完了するのにかかる時間を測定した。 バックグラウンドトラフィックの目的は、本番環境のような環境をシミュレートすることである。 多くの既存の研究は、キュービック法とBBR法のいくつかのフローを実行し、それらの挙動を評価することに焦点を当てていた。 このような場合、フローごとの動作を理解することは有用であるが、大規模なCDNの複雑さを十分に表していない。 ファイルサイズが小さいとスループットがノイズになる可能性があるため、信頼できる指標としてクライアント側フロー完了時間を使用した。
図8。 iperfフローによる時間の流れ。 左：クライアントフロー。 右：ポップツーポップフロー。 オブジェクトサイズ：3MB。 シミュレートされたクライアントフローでは、BBRはCubicよりも優れていた。
テストベッドにもパターンが現れた 図8では、クライアントトラフィックと3MB（中規模）ファイルのポップツーポップトラフィックの2つのシナリオで、BBRフローとキュービックイパーフフローが取る時間のCDFを示す。 低損失の高帯域幅設定では、BBRフローがキュービックに追いつくことができない。 クライアントトラフィック（低帯域幅）が改善された、つまり、BBRフローにかかる時間が短縮された。 しかし、小さなファイルの改善はわずかである。 テスト環境でこれらの挙動を再現することで,異なるフロータイプ間の相互作用の結果であることを確信できる。 その結果、CDN上でのBBRの展開は、それがさまざまなフロータイプに与える可能性のあるより広範な影響を認識しなければならない。
結論
評価の結果、BBRフローはすべてのシナリオでうまく機能しないことがわかった。 具体的には、BBR使用時に、データセンター/ Point-of-Presence（PoP）内のトラフィックとデータセンター間のトラフィック（PoP間）が発生する。 極端な場合には、スループットが半分に低下する。 しかし、Pop-to-Clientトラフィックのスループットは6-8%改善した。
本稿では、CDNの観点からのBBR(バージョン1)の評価について概説した。 我々は、単一のPoP内のいくつかのサーバーの小さなテストから始めて、大規模なコンテンツプロバイダとして私たちに興味があるさまざまな変数を評価した。 大規模なフルポップテストでは、再送信が多いASEではBBRが最も役立つことに気づき、大きなファイルではBBRを使用する価値があることを示唆している。
ここからどこへ行くのか。
システムレベル（すべてのフロー）でBBRをイネーブルにすると、PoP内およびPoP間トラフィックのスループットが低下するリスクがある。
しかし、BBRは潜在的な可能性を示しており、クライアント側のトラフィックでは良好に機能している。 これは、クライアントに対して選択的にBBRを有効にする動機となり、無線プロバイダーから始める可能性がある。 さらに、これらの経路は浅いバッファと無線損失を持ち、BBRが他のキュービックフローよりも優れた性能を発揮する理想的な状況である。
このアウトラインが、大規模なコンテンツプロバイダでのBBRの使用と、ボトルネックを共有する可能性のあるさまざまなタイプのトラフィックへの影響についてある程度明確になることを願っている。 BBRv2のアルファ版が利用可能になり、これらの問題のいくつかに対処する必要がある。 我々は、BBRの新しいバージョンの評価を継続し、適切な種類のフローに対して適切な輻輳制御を選択するインテリジェントトランスポートコントローラを使用する予定である。 これについては、今後詳細を共有する。
この分析を可能にした組織全体のさまざまなチームからの貢献のおかげで!
