Skip to main content
QUICK REVIEW

[論文レビュー] Fairness of Congestion-Based Congestion Control: Experimental Evaluation and Analysis

Shiyao Ma, Jingjie Jiang|arXiv (Cornell University)|Jun 28, 2017
Network Traffic and Congestion Control参考文献 15被引用数 32
ひとこと要約

この論文は、長時間遅延(RTT)のフローが短時間遅延のフローを圧倒するという深刻なRTT公平性の問題を特定し、解決する。長時間遅延のフローが過剰にプローブするための原因である。著者らは、キーボードに実装されたBBQを提案する。BBQは、キューの蓄積を防ぐためにプローブ時間の上限を設定し、スループットや遅延に影響を与えることなく、公平性を最大6.1倍まで向上させる。

ABSTRACT

BBR is a new congestion-based congestion control algorithm proposed by Google. A BBR flow sequentially measures the bottleneck bandwidth and round-trip delay of the network pipe, and uses the measured results to govern its sending behavior, maximizing the delivery bandwidth while minimizing the delay. However, our deployment in geo-distributed cloud servers reveals a severe RTT fairness problem: a BBR flow with longer RTT dominates a competing flow with shorter RTT. Somewhat surprisingly, our deployment of BBR on the Internet and an in-house cluster unearthed a consistent bandwidth disparity among competing flows. Long BBR flows are bound to seize bandwidth from short ones. Intrigued by this unexpected behavior, we ask, is the phenomenon intrinsic to BBR? how's the severity? and what's the root cause? To this end, we conduct thorough measurements and develop a theoretical model on bandwidth dynamics. We find, as long as the competing flows are of different RTTs, bandwidth disparities will arise. With an RTT ratio of 10, even flow starvation can happen. We blame it on BBR's connivance at sending an excessive amount of data when probing bandwidth. Specifically, the amount of data is in proportion to RTT, making long RTT flows overwhelming short ones. Based on this observation, we design a derivative of BBR that achieves guaranteed flow fairness, at the meantime without losing any merits. We have implemented our proposed solution in Linux kernel and evaluated it through extensive experiments.

研究の動機と目的

  • 異なるRound-Trip Time(RTT)を持つ競合するフローが存在する際、BBRのRTT公平性の不均衡の深刻さとその根本原因を調査すること。
  • BBRが帯域幅を最大化し遅延を最小化することを目的としているにもかかわらず、なぜ長RTTフローが短RTTフローを優遇するのかを分析すること。
  • BBRの性能優位性を損なわず、実用的でエンドホストベースの解決策を設計・実装すること。
  • 多様なネットワーク環境やフロー設定において、解決策のスケーラビリティと頑健性を評価すること。

提案手法

  • キュー状態の検出に基づいてプローブ期間を動的に調整する、BBRの誘導的変種であるBBQを提案する。
  • 過剰なキューが検出された場合には短いプローブ期間(α = 3 ms)を強制することで、長RTTフローの帯域幅プローブを制限する。
  • キューが解消された場合には、より長いプローブ期間に切り替えることで、効率的な帯域幅の特定を可能にする。
  • Linuxカーネル4.9.18にBBQを実装し、実世界での評価を可能にする。
  • 自社クラスタおよびインターネット上の展開を用いて、帯域幅の割合、RTT公平性、リンク利用率を測定する。
  • 異なるRTT比、フロー数、AQM設定において、BBQとBBRを比較する。

実験結果

リサーチクエスチョン

  • RQ1競合するフローが異なるRound-Trip Time(RTT)を持つ場合、BBRにおけるRTT公平性の問題はどの程度深刻か?
  • RQ2BBRが短RTTフローを偏向する根本的原因は何か?
  • RQ3単純でエンドホストベースの修正により、性能の犠牲を払わず公平性を回復できるか?
  • RQ4増加する競合フロー数に伴って、提案された解決策はどのようにスケーリングするか?
  • RQ5一様な固定プローブ上限(α)は、多様なRTT範囲においても有効か?

主な発見

  • 50 msのRTTフローと競合する10 msのRTTフローがBBRを使用した場合、帯域幅はわずか6.3 Mbpsにとどまり、ボトルネック帯域幅の7.2%にとどまる。
  • RTT比が10(10 ms 対 100 ms)の場合、短RTTフローはBBQでは帯域幅の37.1%を確保し、BBRと比較して4.62倍の改善を達成する。
  • 1つの50 ms RTTフローと20個の10 ms RTTフローが存在する状況では、BBQはBBRと比較して公平性を最大6.1倍まで向上させる。
  • 5 msから300 msのRTT範囲にわたり、短RTTフローの帯域幅割合は最低84.12%以上向上する。
  • 一様なプローブ上限α = 3 msにより、多様なインターネットRTT環境において一貫した公平性の向上が保証される。
  • BBQは完全なリンク利用率と低エンドツーエンド遅延を維持し、これらの指標においてBBRと同等の性能を発揮する。

より良い研究を、今すぐ始めましょう

論文設計から論文執筆まで、研究時間を劇的に削減しましょう。

クレジットカード登録不要

このレビューはAIが作成し、人間の編集者が確認しました。