Top Trends in Cybersecurity for 2024 | 
Transmission Control Protocol (TCP)輻輳制御アルゴリズム(CCA)は、利用可能な帯域幅を最大限に活用し輻輳を回避するために、クライアントとサーバの間で送信するデータ量を制御する。 創業以来、ボトルネック帯域幅、ラウンドトリップ伝播時間(TCP BBR)、キュービックといった他のCCAが開発されてきた。 TCP BBRとキュービックは輻輳回避を目指しているが、その有効性を理解することは、我々のエンジニアリングチームと研究チームにとって継続的な使命である。
TCP BBRは、パケット損失の代わりにパケット遅延を指標として使用することで、より高いスループットを達成することを目的としている。 しかし、我々の以前の研究では、BBRはすべてのケースで低パフォーマンスであることが報告されていた。 具体的には、小容量ファイル(100KB)のスループットにはほとんどメリットがない、またはまったくないと結論付けた。< さらに,ラウンドトリップ時間(RTT)が低く,再送回数が少ないフローでは,3次よりもBBR性能が悪いことを観測した。 最後に、BBRの利点はクライアント側のトラフィックにのみ見られ、バックオフィス接続（RTTが低く、再送信は無視できる）はcubicでより良いパフォーマンスを示した。
Edgecast（現Edgio）は、世界的なマルチテナントCDNであり、多くの大規模な（VODおよびライブ）ビデオストリーミング顧客にウェブトラフィックを配信している。 一方の顧客に対してBBRを使用した輻輳制御チューニングは、他の顧客のパフォーマンスに悪影響を及ぼす可能性があり、ブランケット有効化によってパフォーマンスが低下する可能性があることを考慮して、BBRがパフォーマンスを向上させ、すべてのCDN顧客に対して動的に有効化できるケースを検出するメカニズムを実装した。 その結果、すべてのお客様が利用できるようにした新しい動的な輻輳制御チューニング機能が実現した。
方法論に関する洞察
そのような動的システムへの最も重要な入力は、それを動かすデータであろう。 我々の動的輻輳制御チューニングメカニズムは、我々の大規模なソケットデータ収集の上に位置し、すべてのエッジキャッシュからTCP (xTCP)ソケットパフォーマンスデータをエクスポートする。 具体的には、NetLinkを介してLinuxカーネルのtcp_info構造体から情報を抽出し、Kafkaを介してClickHouseクラスタにストリーミングする。 このソケットパフォーマンスデータを大規模に持つことで、キャッシュサーバへの接続のパフォーマンスを非常に高い粒度で監視することができる。 xTCPは多くのCDN最適化のための強力なツールであることが証明されている。 例えば、最近IPv6の初期輻輳ウィンドウを変更し、xTCPを使用してパフォーマンスを監視した。
xTCPはGoogle Measurement lab (M-Lab)のTCP-infoツールによる作業と似ているが、我々のエッジキャッシュで見られる大量のソケットを管理するために必要な最適化と、データをprotobuf形式でエクスポートする機能に大きな違いがある。 xTCPをオープンソース化する予定だ。
以下の図に本システムの概要を示す。 xTCPデータは、Kafkaにストリーミングされるすべてのエッジキャッシュから大規模に収集される。 xTCPデータはClickHouseクラスタに収集され、BBRコントローラなどのネットワークデータ分析機能が強化される。このクラスタは、各エッジポップでパフォーマンスの低いプレフィックスを検出する。
図1。 xTCPおよびBBR設定プッシュを使用したデータ収集の概要。
ワークフローの動的な性質を維持する一方で、立方体とBBRの間のフリップフロップを短時間で回避するために、各エッジポイントオブプレゼンス（PoP）で一貫してパフォーマンスの低いプレフィックスを選択する必要もある。 また、前述したように、ファイルサイズが100KBを超えるリクエストに対して選択的にBBRをアクティブ化する。 微調整された3次フローは、小さなファイルに対してより良いパフォーマンスを発揮する。
BBRコントローラは、2つのメトリックを使用して、監視されるすべてのクライアントプレフィックスのヘルスを評価する。
- デューティサイクル:下位20パーセンタイルのパフォーマンスグループのプレフィックス(/24または/56)はどのくらいの長さだったか?
- フラップレート:下位20パーセンタイルパフォーマンスグループから接頭辞が出現したり消えたりする頻度、つまり状態の変化。
このアルゴリズムは、過去数時間のパフォーマンスの悪いプレフィックスを一貫して検出する。 この検出は5分ごとに実行される。 エッジポップごとに選択されたプレフィックスの総数は数百になる可能性があるが、プレフィックスのパフォーマンスは比較的一貫していることが観察された。 同じ接頭辞が定期的に選択され、各ラウンドでの新たな追加（以下のシカゴ・ポップの図に示すように）は非常に少ない。
図2。 コンフィギュレーション生成ラウンドごとに選択される新しいプレフィックスの数が少ない。
存在する場合、BBRを有効にするために新しいプレフィックスが選択され、設定が生成され、検証ステップを通過して、グローバルにエッジキャッシュにプッシュされる。
パフォーマンスの向上
世界中のエッジ全体でBBRを有効にすることで、パフォーマンスが大幅に向上したことを報告できることを嬉しく思っている。 xTCPソケットデータから追跡する重要なメトリックは、TCP_INFOで報告される配信レートである。 最もパフォーマンスの低いプレフィックスに対して動的にBBRを有効にするため、低いパーセンタイル（最悪の場合）の配信率が向上すると予想される。
次の図は、BBR変更が有効になった時点で、ロサンゼルス・ポップでの5パーセンタイルと10パーセンタイルの配信率の改善を示している。
図3。 BBR変更後の5パーセンタイルおよび10パーセンタイルの照射率の改善が観察された。
同様に、次の図では、北米のPOPすべてで動的にBBRを有効にした直後に、米国の大規模な住宅ISPの低いパーセンタイル配信率が大幅に改善(〜2倍)したことを示している。
図4。 BBRを動的にイネーブルにした後、大規模な住宅用ISPで改善が見られた。
tcp-infoから抽出された配信レートは、クライアントが見たパフォーマンスの良い推定値を提供する。 しかし、最も正確なパフォーマンスインジケータは、クライアント接続のHTTPアクセスログに見られるスループット、つまりgoodputである。
エッジキャッシュサーバーからのグッドプットを測定する。 下図に示すように、この変更により、のれん発生量が増加した。 全体として、10パーセンタイルのグッドプットは12%増加した。
図5。 10パーセンタイルのグッドプットは12%増加した。
BBRv1の素晴らしい仕事とBBRv2の継続的な努力のためのGoogleのBBR開発チームに特別な感謝。 BBRv2を楽しみにしており、今後も関連する変更をプラットフォームにプッシュしていく予定である。 EdgecastのSergio Ruiz、Joseph Korkames、Joe Lahoud、Juan Bran、Daniel Lockhart、Ben Lovett、Colin Rasor、Mohnish Lad、Muhammad Bashir、Zach Jones、Dave Andrewsに、開発、テスト、ロールアウト中にこの変更をサポートしてくれた。 Edgioエンジニアリングチームは、分析の多くを支えたxTCPツールの開発に貢献してくれたDave Seddonに特に感謝したい。
動的な輻輳制御チューニングにより、Edgioの顧客はパフォーマンスが低いクライアントのパフォーマンスを自動的に改善し、最終的なパフォーマンスを向上させて、ウェブ配信の高速化とビデオストリーミングの再バッファの削減を実現した。
