Loading article…
バッファブロートとは、ルータやその他のネットワーク機器が大量のデータパケットをバッファリングすることで発生する望ましくない遅延のことです。バッファブロートは、パケット遅延の変動(ジッターとも呼ばれる)を引き起こしたり、ネットワーク全体のスループットを低下させたりします。ルータやスイッチが過度に大きなバッファを使用するように構成されている場合、非常に高速なネットワークであっても、VoIP ( Voice over IP )、オーディオ ストリーミング、オンライン ゲーム、さらには通常のWeb ブラウジングなどの多くのインタラクティブ アプリケーションでは実質的に使用できなくなります。
通信機器メーカーの中には、ネットワーク製品の一部に不必要に大きなバッファを設計しているところもあります。このような機器では、ネットワーク リンクが混雑するとバッファブロートが発生し、パケットがこれらの大きすぎるバッファに長時間キューイングされることになります。先入れ先出しのキューイング システムでは、バッファが大きすぎるとキューが長くなり、待ち時間が長くなり、ネットワーク スループットは向上しません。また、特定の低速接続によって他のパケットが時間どおりに配信されなくなることでもバッファブロートが発生することがあります。
バッファブロート現象は1985年にすでに説明されていました。[1] 2009年からはより広く注目を集めるようになりました。[2]
いくつかの情報源によると、オンラインビデオゲームにおける高レイテンシ（「ラグ」）の最も一般的な原因は、ローカルホームネットワークのバッファブロートです。高レイテンシは、現代のオンラインゲームを不可能にする可能性があります。[3]
バッファリング
ネットワーク機器メーカーの 経験則では、デバイスを通過するトラフィック ストリームに対して少なくとも 250ミリ秒のバッファリングに対応できる大きさのバッファを用意することが定められていました。たとえば、ルーターのギガビット イーサネットインターフェイスには、比較的大きな 32 MB のバッファが必要です 。[4] このようなバッファ サイズは、TCP 輻輳制御アルゴリズムの障害につながる可能性があります。バッファが空になるまでにしばらく時間がかかり、その後輻輳制御がリセットされて TCP 接続が速度を上げてバッファが再びいっぱいになります。[5]このように、バッファブロートは、1 つの TCP ストリームのパケットでバッファがいっぱいになり、他のパケットがドロップされるため、他のすべてのフローのネットワーク ボトルネックが詰まるなど、高いレイテンシと変動するレイテンシなどの問題を引き起こします。[6]
バッファが肥大化した場合、実際にバッファが使用される場合にのみ影響があります。言い換えると、バッファリングするリンクがボトルネックになった場合にのみ、バッファサイズが大きすぎると悪影響があります。ボトルネックとなるバッファのサイズは、ほとんどのオペレーティング システムで提供されているpingユーティリティを使用して測定できます。まず、他のホストに継続的に ping を送信し、次にそこから数秒間のダウンロードを開始して数回停止します。設計上、TCP 輻輳回避アルゴリズムは、ルート上のボトルネックを急速に埋めます。ダウンロード (およびアップロード) が、ping によって報告されるラウンド トリップ時間の直接的で重要な増加と相関している場合は、ダウンロード (およびアップロード) 方向の現在のボトルネックのバッファが肥大化していることを示しています。ラウンド トリップ時間の増加はボトルネックのバッファによって引き起こされるため、最大増加から、そのサイズをミリ秒単位で概算できます。[引用が必要]
前の例では、単純な ping の代わりに高度なtracerouteツール (たとえば、MTR ) を使用すると、ボトルネックの肥大化したバッファの存在が示されるだけでなく、ネットワーク内のその場所も特定されます。traceroute は、ルート (パス) を表示し、ネットワーク全体のパケットの転送遅延を測定することでこれを実現します。ルートの履歴は、ルート (パス) 内の各連続ホスト (リモート ノード) から受信したパケットの往復時間として記録されます。[7]
機構
TCP 輻輳制御アルゴリズムのほとんどは、パケット ドロップの発生を測定して、接続の両端間で利用可能な帯域幅を決定します。アルゴリズムは、パケットがドロップし始めるまでデータ転送を高速化し、その後、伝送速度を低下させます。理想的には、リンクの平衡速度に達するまで伝送速度を調整し続けます。アルゴリズムが適切な転送速度を選択できるように、パケット ドロップに関するフィードバックがタイムリーに発生する必要があります。大きなバッファーがいっぱいになると、パケットは宛先に到着しますが、遅延が大きくなります。パケットはドロップされないため、アップリンクが飽和してバッファーがさらにいっぱいになっても TCP は速度を低下させません。新しく到着するパケットは、バッファーが完全に飽和したときにのみドロップされます。これが発生すると、TCP は接続のパスが変更されたと判断し、新しい動作ポイントをより積極的に検索し直すこともあります。[8]
パケットは、送信される前にネットワーク バッファ内でキューに入れられます。問題のある状況では、バッファがいっぱいになった場合にのみパケットがドロップされます。古いルータでは、バッファがかなり小さかったためすぐにいっぱいになり、リンクが飽和状態になるとすぐにパケットがドロップし始めました。そのため、TCP プロトコルは調整でき、問題は明らかになりませんでした。新しいルータでは、バッファは数秒間のバッファ データを保持できるほど大きくなっています。TCP にとっては、バッファがいっぱいになると、輻輳したリンクが正常に動作しているように見えることがあります。TCP アルゴリズムはリンクが輻輳していることを認識せず、バッファが最終的にオーバーフローしてパケットがドロップされるまで修正アクションを開始しません。
単一のキューとして実装された単純なバッファを通過するすべてのパケットは同様の遅延を経験するため、いっぱいになったバッファを通過する接続の遅延は影響を受けます。また、低速の宛先への配信を待機しているデータでバッファが詰まっているため、一部の高速の宛先にすぐに到達できない可能性があるため、利用可能なチャネル帯域幅が使用されなくなる可能性もあります。これらの影響により、 VoIPやオンラインゲームなどの遅延に敏感なアプリケーションで使用されるUDPを含む、他のネットワークプロトコルを使用するアプリケーションの対話性が損なわれます。[9] [自己出版ソース]
アプリケーションへの影響
帯域幅の要件に関係なく、一貫して低遅延またはジッターのない伝送を必要とするあらゆる種類のサービスは、バッファブロートの影響を受ける可能性があります。このようなサービスには、デジタル音声通話 (VOIP)、オンライン ゲーム、ビデオ チャット、およびラジオ ストリーミング、ビデオ オン デマンド、リモート ログインなどのその他のインタラクティブ アプリケーションが含まれます。
バッファブロート現象が発生し、ネットワークに負荷がかかっている場合、通常のWebページの読み込みでさえ完了するまでに数秒かかることがあり、単純なDNSクエリがタイムアウトのために失敗することがあります。[10]実際には、どのTCP接続もタイムアウトして切断され、UDPパケットが破棄される可能性があります。TCPダウンロードストリームの継続はアップロードストリームの確認応答（ACK）パケットに依存するため、アップロードでのバッファブロートの問題により、クライアントACKパケットがインターネットサーバーにタイムリーに到達しないため、他の無関係なダウンロードアプリケーションが失敗する可能性があります。
検出
DSL Reports Speedtest [11]は、バッファブロートのスコアを含む使いやすいテストです。ICSI Netalyzr [12]は、ネットワークのバッファブロートの有無をチェックし、他の多くの一般的な構成の問題をチェックするために使用できる別のオンラインツールでした。[13] このサービスは2019年3月に停止されました。bufferbloat.net Webサイトには、接続に過剰なバッファリングがあり、速度が低下しているかどうかを判断するためのツールと手順が記載されています。[14] [15]
解決策と緩和策
いくつかの技術的ソリューションが存在し、それらはネットワークをターゲットとするソリューションとエンドポイントをターゲットとするソリューションの 2 つのカテゴリに大まかに分類できます。この 2 種類のソリューションは、多くの場合、相互に補完し合っています。問題は、高速ネットワーク パスと低速ネットワーク パスの組み合わせで発生することがあります。
ネットワークソリューションは一般的にキュー管理アルゴリズムの形をとります。このタイプのソリューションはIETF AQMワーキンググループの焦点となっています。[16]注目すべき例としては次のようなものがあります。
- IPキューの長さを制限するには、TCPチューニングを参照してください。
- CoDelやPIEなどのAQMアルゴリズム。 [17]
- ハイブリッドAQMとFQ-CoDelなどのパケットスケジューリングアルゴリズム。[18]
- ケーブルモデムにおけるよりスマートなバッファ制御を可能にするためにDOCSIS規格[19]を改正したもの。[10]
- Linuxは無線アクセスポイントでよく使用されているため、LinuxオペレーティングシステムのWi-Fiサブシステムにキュー管理（FQ-CoDel）を統合しました。[20]
エンドポイントをターゲットとするソリューションの注目すべき例は次のとおりです。
- TCPの BBR 輻輳制御アルゴリズム。
- 多くのBitTorrentクライアントで採用されているマイクロ トランスポートプロトコル。
- 単純なHTTPプロトコルの代わりにHTTPパイプラインやHTTP/2など、より少ない接続を使用するテクニック。 [10]
この問題は、OS [10]とネットワークハードウェアのバッファサイズを減らすことでも軽減できますが、これは多くの場合構成可能ではなく、最適なバッファサイズは回線速度に依存し、回線速度は宛先によって異なる場合があります。
DiffServを利用すること（および複数の優先度ベースのキューを採用すること）は、低遅延トラフィック（VoIP、ビデオ会議、ゲームなど）の送信を優先し、輻輳やバッファブロートの処理を非優先トラフィックに委ねるのに役立ちます。[21]
最適なバッファサイズ
最も遅延の大きいTCP接続でも帯域幅を公平に確保するには、バッファサイズを少なくとも同時ストリーム数の平方根で割った帯域幅遅延積以上にする必要があります。 [22] [4]一般的な目安はラインレートデータで50msですが、[23]一部の一般的なコンシューマグレードのスイッチでは1msしかありません。[24]そのため、他の接続とのローカル競合が発生した場合、遅延の大きい接続で余分な帯域幅の損失が発生する可能性があります。
参照
参考文献
- ^ 「無限ストレージを備えたパケットスイッチについて」1985 年 12 月 31 日。
- ^ van Beijnum、Iljitsch (2011 年 1 月 7 日)。「バッファブロートとネットワーク バッファの軍拡競争を理解する」。Ars Technica。2011年11 月 12 日閲覧。
- ^ 「バッファブロート：インターネットのダークバッファ：効果的な AQM のないネットワークは、再び輻輳崩壊の危険にさらされる可能性がある」。キュー。doi：10.1145 /2063166.2071893。S2CID 18820360 。
- ^ ab Guido Appenzeller、Isaac Keslassy、Nick McKeown (2004)。「ルーター バッファーのサイズ設定」( PDF)。ACM SIGCOMM。ACM。2013年10 月 15 日閲覧。
- ^ Nichols, Kathleen ; Jacobson, Van (2012 年 5 月 6 日)。「キュー遅延の制御」。ACM Queue。ACM Publishing。2013年9 月 27 日閲覧。
- ^ Gettys, Jim (2011 年 5 月～6 月)、「Bufferbloat: Dark Buffers in the Internet」、IEEE Internet Computing、vol. 15、IEEE、pp. 95～96、doi :10.1109/MIC.2011.56、2012 年 10 月 12 日時点のオリジナルよりアーカイブ、2012年2 月 20 日取得
- ^ "traceroute(8) – Linux manページ". die.net . 2013年9月27日閲覧。
- ^ Jacobson, Van; Karels, MJ (1988). 「輻輳回避と制御」(PDF) . ACM SIGCOMM Computer Communication Review . 18 (4): 314–329. doi :10.1145/52325.52356. 2004年6月22日時点のオリジナル(PDF)からのアーカイブ。
- ^ 「Bufferbloat の技術紹介」。Bufferbloat.net。2013年9月 27 日閲覧。
- ^ abcd Gettys, Jim; Nichols, Kathleen (2012年1月). 「バッファブロート：インターネットのダークバッファ」Communications of the ACM . 55 (1). ACM: 57–65. doi : 10.1145/2063176.2063196 .
- ^ 「スピードテスト - あなたのインターネットの速度はどれくらいですか？」dslreports.com 。 2017年10月26日閲覧。
- ^ “ICSI Netalyzr”. berkeley.edu . 2019年4月7日時点のオリジナルよりアーカイブ。2015年1月30日閲覧。
- ^ 「Netalyzr の結果を理解する」 。2017年10 月 26 日閲覧。
- ^ 「Bufferbloat のテスト」。bufferbloat.net 。2017年10 月 26 日閲覧。[自費出版ソース]
- ^ 「Bufferbloat の紹介」. bufferbloat.net . 2023 年5 月 8 日閲覧。
- ^ 「IETF AQMワーキンググループ」。ietf.org 。 2017年10月26日閲覧。
- ^ Pan, Rong; Natarajan, Preethi; Piglione, Chiara; Prabhu, Mythili; Subramanian, Vijay; Baker, Fred; VerSteeg, Bill (2013). 「PIE: バッファブロート問題に対処するための軽量制御スキーム」。2013 IEEE第14 回国際高性能スイッチングおよびルーティング会議 (HPSR)。2013 IEEE 第 14 回国際高性能スイッチングおよびルーティング会議 ( HPSR)。IEEE。pp. 148–155。doi :10.1109/HPSR.2013.6602305。ISBN 978-1-4673-4620-7。
- ^ Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric. FlowQueue-CoDel パケット スケジューラとアクティブ キュー管理アルゴリズム。doi : 10.17487 / RFC8290。RFC 8290 。
- ^ 「DOCSIS「アップストリームバッファ制御」機能」。CableLabs。pp. 554–556 。 2012年8月9日閲覧。
- ^ Høiland-Jørgensen, Toke; Kazior, Michał; Täht, Dave; Hurtig, Per; Brunstrom, Anna (2017). 異常の終焉: WiFi における低遅延とエアタイム公平性の実現。2017 USENIX 年次技術会議 (USENIX ATC 17)。USENIX - 高度コンピューティング システム協会。pp. 139–151。ISBN 978-1-931971-38-6. 2017年9月28日閲覧。ソースコード。
- ^ Hein, Mathias. 「Bufferbloat » ADMIN Magazine」。ADMIN Magazine 。 2020年6月11日閲覧。
- ^ Huston, Geoff (2019 年 12 月 12 日)。「バッファのサイズ設定」。APNIC ブログ。2022 年10 月 16 日閲覧。
- ^ 「ルーター/スイッチのバッファサイズの問題」。fasterdata.es.net 。2022年10月16日閲覧。
- ^ “BCM53115”. www.broadcom.com . 2022年10月16日閲覧。
外部リンク
- BufferBloat: インターネットの何が問題なのか? Vint Cerf、Van Jacobson、Nick Weaver、Jim Gettysとのディスカッション
- 2011 年 4 月のYouTubeでの Google Tech Talk 、Jim Gettys 著、Vint Cerf による紹介
- バッファブロート: インターネットのダークバッファ — デモはYouTubeのみで公開2011 年 4 月、Jim Gettys著、 Vint Cerfによる序文
- バッファブロート: インターネットのダークバッファ - YouTubeでのデモとディスカッション典型的なブロードバンド バッファブロートの 21 分間のデモと説明
- LACNIC - BufferBloat on YouTube 2012年5月、Fred Baker (IETF 議長)によるスペイン語版、英語版スライドあり [1]
- TSO のサイズ設定と FQ スケジューラ (Jonathan Corbet、LWN.net )