6/04/2017

新しいTCPフロー制御アルゴリズムBBR

ジェフ・ヒューストンがTCPフロー制御プロトコルについて書いたエッセイ

インターネットは、シンプルなネットワークとアジャイル・エッジのアーキテクチャ原則に基づいて構成された。基本的なアプローチは、ネットワークはバッファリングを持つスイッチや回線のシンプルな集合だと想定することだった。パケットがネットワークを通過する際、スイッチからスイッチへと効率的に渡される。スイッチは、パケットを意図する宛先により近い場所に転送しようと次の回線を選択する。回線がビジーなら、パケットはキューに入れられ、回線が利用可能になった後で処理される。キューが一杯なら、パケットは破棄される。

信頼できるデータストリームをネットワークを使って通過させることが望みなら、このネットワークの挙動は完全に役立たない。IPアーキテクチャが採用したアプローチは、パケット損失の検知と修復、データ流量の管理を含むデータの流れの管理責任をエンドツーエンドのトランスポート・プロトコルに取らせることである。

一般に、我々はこの目的にTransmission Control Protocol(TCP)を使う。TCPの意図する動作形態は、データをできるだけ早く送るために、データストリームを調整することだが、バッファキューを頻繁に飽和状態にしたり、パケット損失する(損失を検知して、再転送するオーバーヘッドが発生する)ことで、それほど早くなくなってしまう。2つの目的の間で進路を決め、最適なスピードで実行することがTCPに求められる。第一に、利用可能な全てのネットワーク配送リソースを使う事、そして第二に、ネットワーク・リソースを同時並行のTCPデータフローで公平に共有する事である。

しかし、TCPが単一のプロトコルのように見えるが、実際にはそうではない。TCPは一般的なトランスポート・プロトコル・ヘッダ形式で、全てのTCPパケットはこの形式を使用し、このプロトコル・ヘッダ(図1)のフィールドに同じ解釈を適用する。しかし、この背後には雲泥の差がある。TCPがデータフロー速度を管理する方法、パケット損失を検出してそれに反応する方法は、実際には変動を受けやすく、様々なネットワーク環境で見られる要件や制限に対処するため、長年に渡り、様々な方法でTCPを最適化しようと試みてきた。

Bbr fig1

図1 - IPv4/TCPパケットのヘッダ

AIMDとTCP Reno

おそらく4.3BSD-Reno Unixディストリビューションのリソースが原因で、長年いわゆる"Reno"のフロー制御アルゴリズムがTCPデータのフロー制御の中心になっていると思われる。

RenoはAIMDフロー・アルゴリズムの実例であり、"AIMD (Additive Increase, Multiplicative Decrease) (加算的に、乗算的に)"を意味する。簡単に説明すると、Renoは"ACK-pacing"フロー制御プロトコルで、新しいデータ・セグメントは受信側で古いデータ・セグメントの到着が成功したことを示すACKセグメントが送信側によって受診される速度に基づきネットワークに渡る。データ送信速度が正確にACK到着速度に一定化され、利用可能な回線容量がこの送信速度より小さくなければ、上記フロー制御プロトコルは一定の送信速度をいつまでも維持する。(図2)

Bbr fig2 1

図2 - ACK-pacingフロー制御

しかし、Renoはこれを全く行わない。定常状態(輻輳回避と呼ばれる)で、Renoはパケットを送って対応するACKを受信する時間(往復時間、RTT)の推定値を保持し、ACKストリームが通信中に失われたパケットが無いことを示している場合、RenoはRTT間隔で1つのセグメントを追加して、通信速度を上げる。

明らかに、このように一定に増加するフロー速度量は不安定であり、フローが増え続けると最も制約のある通信コストを飽和させるだろう。そして、このリンクを駆動するバッファが余計なデータで一杯になってしまい、必然的な結果として回線のパケットキューのオーバーフローとパケットドロップが発生する。TCPがドロップしたパケットを伝える方法は、応答ACKを送ることによって、適切では無いパケットであることを確認し、ACKは適切に受信したデータは最後に受信したデータ・セグメントであることを伝える。この挙動は、送信者が受信者のデータ受信率を認識し、同時にデータ損失を通知することを保証する。

この通知されたデータ損失の形態へのRenoの送信者の応答は、データ損失を修復しようとして、送信速度を半減させる。損失が修復されると、Renoは以前のこの新しい基本速度から送信速度を加算値に増やして再開する。輻輳回避モードでのTCP Renoの理想的な動作モデルは鋸歯状パターンである。それは、ネットワークのキュー内のパケット損失による輻輳レベルに達するまで送信速度が徐々に直線的に増加し、Renoが損失を修復すると、送信速度を半減させ、もう一度やり直す。(図3)

Bbr fig3 1

図3 - 理想のTCP Renoフロー制御の挙動

Renoの背後にある前提は、パケット損失がネットワークの輻輳が原因でのみ発生し、そのネットワーク輻輳はバッファが溢れた結果である。RenoはリンクのRTTが安定し、利用可能な帯域の上限が比較的安定していることも前提にしている。Renoはネットワークのキューバッファの合図に関していくつかの前提(憶測)を立てており、その速度を半分にすることはキューの増大を止めるだけなく、バッファのドレイン(空にする)も可能になる。

総パケットキュー容量(バイト)は、このバッファが駆動するリンクの遅延帯域幅積よりも大きくならないようにすべきである。バッファが小さいと、Renoは利用可能なネットワーク容量を非効率にするレベルに戻ってしまう。バッファが大きいと、Renoはバッファを決してドレインしないバッファブロート状態に繋がる可能性がある。キューサイズの一定の下限の残りのキュー占有時間は、セッション全体に負わされる遅延オーバーヘッドとなる。

これらの前提が有効であっても、Renoには不十分な点がある。これらは高速ネットワークで特に顕著である。RTTあたりの1セグメントで通信速度を増加させると、通常はRTT毎のデータ・ストリームに、1500オクテットが加わる。今、30msのRTTネットワークパス上に10Gbpsの回線があると、TCPセッションが各RTTで1500オクテットずつ速度を加速していき、TCPセッションは5Gbpsフロー速度から10Gbpsに引き上げるのに約3.5時間掛かる。

この3.5時間で、パケットドロップが起きない可能性があり、パケット破棄率は78億分の1未満、基礎となるビットエラー率は1014分の1未満になることを意味する。実験的な事情でのエンドツーエンドのチャンネルを完全にクリアにするため、これは実現可能かも知れない。しかし、同時フローが課せられたクロストラフィックや一過性の負荷を伴う通常の状況では、これは完全に非現実な期待である。

上記にあるように、ネットワークバッファが関連するリンクの遅延帯域幅積よりも大きいと、Renoはパフォーマンスが低下する場合がある。そして、ACKペーシング・プロトコルのように、ACK信号が失われるとRenoは破綻するため、Renoはバースト・パケットの末尾を取り除く損失条件に遭遇すると、ACKペーシング信号を失い、Renoは現在のデータフローを停止し、セッションのフロー状態の再起動を実行する必要がある。

このTCPの動作を改善するための提案は数多くある。これらの提案の多くは、RTTあたりの増減レベルを調整するが、減らすよりはゆっくりと送信速度を増やすような基本動作パラメータにとどある。言い換えると、これらの亜種全てがパケット損失の兆候に対して高い反応を取ろうとする一方、送信速度を高める努力は控えめである。

しかし、長年Renoが唯一のTCPプロトコルと思われてきたが、これは徐々に変化し、多くのLinuxプラットフォームでデフォルトのフロー制御プロトコルとして使われたおかげもあり(2.6.19から)、Renoもさることながら、今ではCUBICが広く使われている。

CUBIC

基礎アイデアはBIC(Binary Increase Congestion Control)で規定され、BICは制御アルゴリズムが実際にパケット損失を引き起こす閾値を抑え付けるパケット送信速度を探索することを担うプロトコルで、効率的にこれを達成するためにバイナリ探索アルゴリズムを利用する。BICはパケットドロップに応じてウィンドウサイズの縮小を実行する際、以前の最大ウィンドウサイズと現在のウィンドウ設定を記憶する。

各無損失のRTT間隔で、BICは現在のウィンドウサイズと以前の最大ウィンドウサイズとの差分の1/2に輻輳ウィンドウを膨らませようとする。このようにして、BICは以前のウィンドウ縮小から速やかに回復しようと試みる。そして、BICは以前の最大値に近づくにつれ、ウィンドウの膨張率を低下させ、RTTの度にウィンドウ膨張率を半減させる。

BICは一度のRTT間隔での率の変化量を制限するため、最大膨張定数を定めているという点で、それほど過激ではない。この値は通常、Renoが使うRTT毎の1セグメントよりも大きい。結果として得られる挙動は、線形応答と非線形応答のハイブリッドで、ウィンドウ削減後の最初のウィンドウ膨張は急激な線形増となるが、ウィンドウが以前パケット損失を起こしたポイントに近づくにつれ、ウィンドウ増加率は減速する。BICは現在のウィンドウサイズが前回の損失ポイントを超えた時、ウィンドウ膨張に補完的アプローチを使う。当初は、追加的なウィンドウ膨張が小さく、ウィンドウ膨張値は制限値までRTT毎にサイズが2倍になり、ウィンドウ膨張を越えるともう一度扇形になる。

BICは低RTTネットワークで、より低速な状況ではとてもアグレッシブで、BICの改良版つまりCUBICに繋がっている。CUBICは、BICが使っていた指数関数よりも、ウィンドウ膨張アルゴリズムを抑制するため三次多項式関数を使用する。三次関数は以前のウィンドウ縮小からの経過時間の関数であるため、BICがRTTカウンタを暗黙的に使うのに比べ、CUBICは様々なRTTを持つ多数のフローの状況でより公平な結果を生じさせる。

CUBICは一度のRTT間隔でウィンドウ調整を最大値に制限するため、縮小後の初期のウィンドウ調整は線形である。この関数は、ウィンドウサイズが以前のウィンドウサイズに近づいた時、より安定する。ウィンドウサイズ調整にRTTカウンタではなく、時間感覚を使うことは、CUBICが同時TCPセッション、特に短いRTT環境に対してより敏感にすることを目的としている。

RenoとCUBICの理論的な比較を図4に示す。

Bbr fig4 1

図4 - RENOとCUBICのウィンドウ管理の挙動の比較

CUBICは高速フローにとってはるかに効率的なプロトコルである。パケット損失の反応はRenoほど厳しくなく、できるだけ迅速に損失前のフロー速度で再開しようと試みる。その後、前回の損失発生時点に近づくにつれ、そして時間とともに調整は損失状態をプローブするにつれてより不確かになっていく。

CUBICが行なっていると思われることは、パケット損失が起こる直前まで、できるだけ長くフローを動作させることである。言い換えれば、キュート転送要素を組み合わせたリンクのモデルで、CUBICトラフィックを可能な限り長い間、最大限大きなキューを埋めるよう試み、その後により少ない速度に落とし、キュー充填操作を再開する。高速リンクでは、CUBCは高速上方検索を実行するため、非常に効果的に動作する。そして、これはそのようなリンクにうまく適していることを意味する。

フロー管理された挙動に対する一般的な考えは、パケット損失が主にネットワークの輻輳によって引き起こされ、輻輳回避はパケット損失に迅速に対処することで達成できるということである。

リンクとキューの単純モデル

この構造を通過する単一のデータフローで、固定容量のリンクを駆動する固定サイズのキューの非常に単純なモデルについて考えることで、ネットワークの動作の洞察を深めることができる。このデータフローは、3つの異なるリンクとキューの状態に直面する。

Bbr fig5 1

図5 - キューとリンクの状態

  • 第1の状態は、送信速度がリンク容量よりも低い場合である。この状態では、キューは常に空で、到着するフローパケットが受信されると速やかにリンクに渡される
  • 第2の状態は、送信速度がリンク容量よりも大きい場合である。この状態では、到着するフローパケットはリンクにアクセスする前に、常にキューの中に保持されている。徐々にキューがフローデータ速度とリンク容量の間の差異によって大きくなるという点で、これは不安定な状態である
  • 第3の状態は、送信速度がリンク容量よりも大きく、キューが完全に占有され、後で通信のデータキューに格納できず破棄される。徐々に破棄率はフローデータ速度とリンク容量の間の差分になる

データフローに最適な状態は何だろうか?

直感的には、再転送を引き起こし、リンクの効率性を低下させるため、データ損失を避けたいと考える。また、ACKペーシング制御アルゴリズムは、障害を引き起こすイベントと元のデータ送信者がACKストリームを通じて状態を通知される間の時間が長くなるのに伴い、反応が低下するため、エンドツーエンドの遅延を最小限に抑えたい。簡単に言うと、最適性は容量を最大にして、遅延を最小に抑えることである。

前述の3つの状態に関連付けるなら、TCPセッションにとっての最適なポイントはバッファリングの直前か、第1の状態から第2の状態に移行する直前の状態である。この時点で、エンドツーエンドの遅延がキュー占有コンポーネントなしのもっぱら伝送遅延からなる限りは、利用可能なネットワーク伝送能力全てが利用されている。

Renoはそのフローの様々な対象を使用する。Renoの目的は第2の状態を維持することだが、状態の全範囲で揺れ動く。パケットドロップ(状態3)は、フローが状態2を通って状態1になる(これはキューが溢れている)ため、送信速度の低下を引き起こす。パケットドロップが発生しないRTT間隔は、TCPフローに送信中のデータのボリュームの増加を引き起こし、状態2を通じてTCPフロー状態を動作させるべきである。CUBICはパケット損失あるいは状態2と3の間の移行時点にあり、フローを判別することは難しい。パスのフロー圧力を判別してフローの能力を最大にするには、CUBICは無期限キュー占有状態を形成する可能性が高いため、遅延増大を招いてしまう。

問題はパケットドロップ発生時というより、キューの形成時点での最適な時点に向かおうと試みるTCPフロー制御アルゴズムを考案できるかである。

理論的には、データパケットのRTT測定値とACK応答に十分配慮すれば、最適な時点が得られる時間を知ることができる。第1状態では、送信速度がボトルネックとなる容量より小さい場合、送信速度の増加は測定されたRTT値に影響を与えない。第2の状態では、追加トラフィックがある期間キューに保持され、結果としてデータ測定されたRTTが増加する。もちろん、第3状態はパケットドロップと識別される(図6)。

Bbr fig6 1

図6 - 単純なリンクモデルの遅延と配送特性

データ配信速度が最大で往復遅延が最小に抑えられる最適ポイントは、状態1から状態2への遷移点で、キュー形成時点である。この時点で、パケットはキューイングによってこれ以上遅延は起きず、配信速度はリンク容量と一致する。従って、我々が後でやろうとすることは、状態1と状態2の間で不安定になる時点で、フローを位置付けようと試みるTCPフロー制御アルゴリズムである。

これを実行するための初期の試みの一つがTCP Vegasだった。

TCP Vegas

TCP Vegasは、送信データの時間を記録し、対応する受信ACKの時間を照合することでフローのRTTの慎重な測定を行う。端的にいうと、Vegasの制御アルゴリズムはRTTやパケットドロップが増大すると、パケットの送信速度低下を引き起こす。RTTが安定すると、RTT増大の新しいポイントを見付け、送信速度の増加につながる。

TCP Vegasは問題がないわけではない。そのフロー調整メカニズムは時間と共に線形であるため、Vegasのセッションがボトルネックとなる帯域の大きな変化に適応するには時間を要することがある。また、Renoや同じような損失減速型のTCPフロー制御アルゴリズムと一緒にリンクを共有する場合、利点は失われる。

損失減速型のTCP送信者は、損失が発生(状態3)するまでは送信速度を調整しないが、Vegasはキューイング(状態2)開始時に調整を始める。これはVegasセッションが送信速度の減速調整を始めると、キューイング開始時の応答で、同時に損失減速型TCPセッションがフロースペースを占有し、Vegasのフローへさらなる信号が送信速度を低下させる等を引き起こすことを意味する。

このシナリオでは、Vegasは効果的にリンクの混雑を解消する。もし、セッションの途中でパスが変化してRTTが縮まれば、Vegasはより小さなRTTを確認してうまく調整するだろう。一方、長いRTTへのパス変更はキューイベントと解釈され、Vegasは誤って送信速度を落とすだろう。

この遅延に敏感なアルゴリズムを採用して、いい仕事ができるだろうか?

BBR

GoogleのTCPフロー制御アルゴリズムで、遅延制御する最新のTCPを組み込み、BBRと呼んでいる。

BBRは、パスボトルネックでのキュー生成時でのTCPセッションを操作しようとする点で、TCP Vegasに非常によく似ている。BBRが取り組んでいる具体的な問題は、利用可能な帯域の内在するボトルネックとパスRTTの決定が、この特定のフローにネットワークを通過するデータに加えて多数の要因の影響を受ける点で、BBRはフローの持続可能な容量を決定した時点で、従来のAIMDプロトコルの同時動作によって混雑することを避けるため積極的に防御しようとする。

TCP Vegasのように、BBRはフローのRTTやフローの持続可能なボトルネック容量の一連の見積もりを計算する。RTTはある時間のウィンドウでの全RTT測定値の最小値であり、数十秒から数分と説明されている。ボトルネック容量は受信者への最大データ配送速度で最新の6から10 RTT間隔のスライディング時間ウィンドウで、ACKストリームへのデータストリームの相関によって測定される。これらのRTTの値とボトルネック帯域幅は独立に管理され、どちらも他に影響を与えることなく変更できる。

全ての送信パケットに、BBRはデータパケットがストリームの一部であるか、アプリケーションストリームが一時停止(paused)されているかどうかをマークする。この場合、データは"アプリケーション制限"としてマークされる。重要なことに、送信されるパケットは、ネットワークがボトルネックポイントで可変速度方式(rate adaptation)を実行する際に遭遇するであろうネットワークキューイングを回避することを意図して、見積もられたボトルネックの流量で一定に調整される。

ここで意図した運用モデルは、送信者は全体のパスの中でキューイングされないと予想される流量で、ネットワークにパケットを渡すことである。RTTのエポックでバースト的にパケットを送る傾向があり、バースト送信速度がボトルネック容量よりも高い場合、ネットワークの内部で可変速度を実行するためのネットワークのキューに依存するRenoのようなプロトコルとは著しく対象的である。

受信したACK全てに、BBR送信者は元の送信データがアプリケーション制限になったかどうかをチェックする。もし、そうでなければ、送信者はパスRTTとパス帯域幅の計算を現在のフロー見積もりを組み込む。

BBRのフロー適応(可変長フロー)動作は、TCP Vegasとは著しく異なる。BBRはネットワークパスの帯域幅遅延積の倍数である速度で慎重に送ることで、周期的に1回のRTT間隔を費やすだろう。この倍数は、1.25であり、より高い速度は積極的にそうではないが、完全に占有されたリンクをキューイング状態にするにはRTT間隔で十分である。

使用可能なボトルネック帯域幅が変更されない場合、増加した送信速度がボトルネックでキューが形成される。これが増大したRTTを明かすACK通知を引き起こすが、ボトルネック帯域幅の推定地は変更されてはならない。この場合には、送信者はそれ以降、RTT間隔で送信速度を補正低下しながら送り、ボトルネックキューを排除することができるだろう。もし、このプローブのために、利用可能なボトルネック帯域幅推定値が増大するなら、送信者は新しいボトルネック帯域幅推定値に従って動作するだろう。

一連のプローブ動作はこれらのプローブのために推定されたボトルネック帯域幅が変わらなくなるまで、同じゲイン係数で送信速度が増大す続けるだろう。このプローブのゲイン係数は帯域幅遅延積の倍数なので、パスへの帯域幅増大のためのBBRの全体的適応はTCP Vegasが使う線形適応ではなく、指数関数的である。

パスの特性の変化を明らかにする定期的なプロービングは、ドロップベースのフロー制御アルゴリズムから借用されたテクニックである。非公式には、制御アルゴリズムは8つのRTT間隔毎に25%の係数でデータ送信速度を上げることで、RTT間隔のパス上で増加したフロー圧力をセットしている。この結果が増大するRTT推定値によって示されるキューイングの負荷と一致するなら、アルゴリズムはキューが空になるよう速度を落とし、推定されたパス帯域幅と遅延特性のレベル、すなわち定常状態で再開する。

この増加したフロー圧力が他の同時(concurrent)フローの速度を落とす原因となる可能性もある。その場合、BBRは新しいボトルネック帯域幅の見積もりに等しい一定速度のパケットを送信することで、リソースを速やかに占有するよう反応するだろう。

セッションの始動は比較的チャレンジングで、帯域幅は12桁大きくなった今日のインターネットリンクでの関連のある観測結果から、始動手続きはその容量に関係なく利用可能な帯域幅に素早く収束しなければならない。BBRでは、送信速度が各RTTで2倍になり、ボトルネック帯域幅はRTT間隔のlog2以内に発生することを示唆する。これは、Renoで使われている速度倍化に似ているが、アルゴリズムのこのフェーズの終了は、キューの飽和時やパケットドロップ時点のRTT以内がRenoの条件ではなく、キューイング時点のRTT以内である。

推定されたRTTが増大し始めた時点で、BBRは今時点でネットワークキューが一杯になっていると見なし、この帯域幅推定値を維持するために、RTTに同じゲイン係数によって送信速度を増やすことでネットワークキューを吐き出す。今、送信者がRTTとボトルネック帯域幅を見積もったとすると、帯域幅遅延積(BPD)も関連付けされる。サーバは大量のデータが未確認状態になると、推定ボトルネック帯域幅で送信を再開するだろう。

RenoとCUBICを比較したBBRの動作全体のプロファイルを図7に示す。

Bbr fig7 1

図7 - Reno、CUBIC、BBRのモデル挙動の比較

共有(Sharing)

TCP Vegasのよく知られている問題は、ドロップベースのTCPフロー制御アルゴリズムが同時にあると、フロー空間を譲ってしまう事である。別のセッションが同じボトルネック回線を使った時、Vegasが送信速度を落とすと、ドロップベースのTCPは事実上、開放したスペースを占有してしまう。ドロップベースのTCPセッションはボトルネックキューを半分以上の時間占有してしまうため、Vegasは送信速度をドロップし続け、フリーになった帯域幅にドロップベースのTCPセッションを渡す。

BBRはこの動作形態を避けるよう設計されているようだ。BBRがその"公平な分配"を主張する理由は高い送信速度で定期的にプロービングを行うためである。この動作は同時にドロップベースTCPセッションに対してプッシュし、BBRはボトルネック帯域幅推定値を公平な分配で安定化できる。しかし、内部ネットワークバッファはそれらが運んでいる回線の遅延帯域幅積に関連してサイズが決められる時、これは効果的に機能する。

キューがオーバープロビジョンされているなら、BBRのプローブ・フェーズはキューを占有するドロップベースのTCPセッションに対して十分な圧力を生み出さないかも知れない。そして、BBRはこれらのセッションに影響を与えることができないかも知れない。そして、ボトルネック帯域幅の公平な分配を失うリスクがあるかも知れない。一方、BBRがRTTを過大に見積もると、パーマネントキュー占有があるレベルで安定するという確かなリスクがある。この場合、ドロップベースのフローアルゴリズムを破綻させ、それらを締め出すかも知れない。

Googleは、CUBICが利用可能なリソースの幾分大きなシェアを獲得しつつ、同時にBBRとCUBICのフローがほぼ均等であることを示す実験を報告している。しかし、それほどでもない。BBRは他のTCPフローを失うことなく、完全に影響を及ぼすことなくRENO/CUBIC TCPの世界に共存できるという合理的な結論を指摘している。

我々の限られた実験では、若干異なる結論を示している。実験は、1つのCUBICとRenoのフローが15.2msのRTTで輻輳していない10Gbps回線に同時に渡される1:1形式のテストで行った(図8)。CUBICが最初に開始され、20秒経ってBBRセッションが同じ2つのエンドポイント間で開始された。BBRの初期始動アルゴリズムは、CUBICをBBRに対して公平な分配を再確立できないように見えるポイントにプッシュバックする。これは少々予期せぬ結果ではあるが、内部バッファサイズがボトルネック回路の遅延帯域積よりも大幅に小さい場合の結果の説明に役立つかも知れない。

Bbr fig8 1

図8 - CUBIC対BBRのテスト

2回目の実験では、ドイツとオーストラリアにあるエンドノード間でインターネットの大きな距離を横断する298msのRTTパスを使った。これはインターネットで遭遇すると予想される商用ISPを横断する標準的なインターネットパスである。これらは、2つだけのストリームではなく、この拡張パス内で16の順方向と21の逆方向のコンポーネントリンク上に存在する。そして、2つのTCPセッションはこれら全てのリンク上のネットワーク・リソースに対して互いに奪い合うだけでなく、各コンポーネントのリンク上のトラフィックが交わり、様々競い合う。更に、BBRはパスリソースを要求することに成功しているように見え、BBRセッションの期間に他のフローに対して防御している(defending)ように見える(図9)。

Bbr fig9 1

図9 - CUBIC対BBRの2回目のテスト

拡張RTTは明らかにCUBICの問題を提起したが、BBRはこの期間にパス帯域幅推定値を保持できたという点で、これはおそらくあまり驚くべき結果ではない。この結果は、BBRとCUBIC間にあるレベルの共存を示しているが、結果はBBRに偏っており、パス容量の大きな割合を勝ち取っているように見える。

輻輳制御とアクティブ・ネットワーク・プロファイリング

Googleのレポートのもう一つの側面は注目に値する:

「トークン・パケット・ポリサー。BBRの初期のYoutubeデプロイは世界のISPのほとんどがトークン・パケット・ポリサーでトラフィックをダメにしている事が判明した。通常、パケットは接続開始時に一杯になり、BBRは内在するネットワークのBtlBw[ボトルネック帯域幅]を学習する。しかし、パケットが空の時、(BtlBwよりもはるかに低い)パケット充填速度より高速に送信された全パケットはドロップされる。BBRは結局は新しい配送速度を学習するが、ProbeBWのゲインサイクルが連続的なわずかな損失をもたらす。これらの損失から上流帯域幅の浪費とアプリケーション遅延の増大を最小限にするには、BBRにポリサー検知と明示的なポリサーモデルを追加した。我々はポリサーのダメージを軽減する良い方法を現在研究中である。」[1]

ここでの観測はトラフィック調整法が今日のインターネットで普及しているように見える事だ。トークン・パケット・ポリサーは平均帯域幅フィルタとして動作するが、強制的な平均帯域幅速度よりも短いトラフィック期間では、これらのトークンは"帯域幅クレジット"として蓄積され、このクレジットが蓄積されたトークン・カウントと同じ短いバースト・トラフィックを許可するために使う事ができる。調整のパケット部分は蓄積された帯域幅クレジットが固定の上限を持つ事、そしてトラフィックのバーストがこの上限容量を超える事がないことをポリシーに強制する。

ここでの目的は、速度制御TCPプロトコルがトークン・パケット・ポリサーによって強制される平均帯域幅速度を見付ける事である。そして、可能ならトラフィック調整によって強制されるバースト・プロファイルを発見する事である。トークン・パケット・ポリサーがフロー制御アルゴリズムに影響を与えるフィードバックは、通信中のデータ量の増加が必ずしもより大きな測定RTT値の応答を生成するとは限らないが、その代わりに、発生するパケットドロップは通信中のデータ量の増加と等しい。

こうした状況下では、送信速度が一定の短期間で一定の上限フロー速度境界を超える一致するパケット損失イベントの兆候は、トークン・パケット・アプリケーション・ポイントによって強制される平均トラフィックのフロー速度を明らかにすることを意味する。

参考文献

[1] Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, Van Jacobson, “BBR: Congestion Based Congestion Control,” Communications of the ACM, Vol. 60 No. 2, Pages 58-66. (https://cacm.acm.org/magazines/2017/2/212428-bbr-congestion-based-congestion-control/fulltext)
[2] BBR Congestion Control – Presentation to the IETF Congestion Control Research Group, IETF 97, November 2016. (https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf)
[3] Google Forum for BBR Development (https://groups.google.com/forum/#!forum/bbr-dev)

Hacker News