コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第22回　パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（前編）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第22回　パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（前編） (中井悦司) 2017年8月

はじめに

　今回は、2016年に公開された学術記事「BBR: Congestion-Based Congestion Control」をもとにして、Googleが開発した、ネットワーク通信における新しい輻輳制御の仕組みを解説します。TCP/IPネットワークで伝統的に用いられてきた輻輳制御では、ネットワーク上でのパケットロスを検知した際にパケットの送出頻度をおさえるという仕組みが利用されています。しかしながら、この仕組みには、現代の高性能なネットワーク機器には最適化されていないという課題がありました。ネットワークの帯域を十分に活用しながら、パケット転送の遅延を最小限におさえることが、BBRと呼ばれる新しい仕組みの目標となります。

ネットワーク通信経路のモデル

　BBRでは、RTprop（round-trip propagation time）とBtlBw（bottleneck bandwidth）という2つの指標にあわせて通信量を最適化します。冒頭の記事では、この仕組みを説明するために、ネットワーク通信経路を水道管にたとえています。まず、BtlBwは単位時間に通過できるパケットの量で、いわば、水道管の太さに対応します。RTpropは、パケットが相手側のサーバーに到達するまでの時間で、いわば、水道管の長さに対応します。そして、この水道管の所々には、水道管からあふれそうになった水を一時的に迂回する経路が用意されています（図1）。これは、ネットワークスイッチなどの機器に内蔵されたパケットバッファに対応するもので、機器の処理能力を超えてパケットが到着した場合、そのパケットをバッファにキューイングする仕組みになります。このバッファがいっぱいになった状態で、さらにパケットが到着すると、そのパケットは破棄されて、いわゆるパケットロスが発生することになります。

fig01

図1 ネットワーク通信経路の水道管による模式図

　それでは、従来のパケットロスに基づいた輻輳制御には、どのような課題があるのでしょうか？　水道管のたとえで説明すると、この仕組み場合、水道管の迂回路に水がまわりはじめて、さらにその迂回路も一杯になった状態で、はじめて流量の制御が行われます。この仕組みが理想的に働いた場合、パケットロスが発生し始めるぎりぎりの状態を保って、水が流れ続けることになります。この場合、単位時間あたりに送られる水の量という意味では、水道管の容量をフルに活用した理想的な状況になります。しかしながら、実質的な水道管の長さは、迂回路の分だけ長くなります。つまり、パケットが相手のサーバーに到達するまでの時間は、その分だけ長くなってしまうのです。特に、現代のネットワーク機器では、メモリチップの価格低下もあり、以前よりも大きなバッファが搭載されるようになり、バッファを経由することによるパケット遅延の影響もより大きくなります。
　そこで、BBRでは、ネットワーク機器のバッファにパケットが蓄積されはじめる直前の状態を保つように、パケットの送出頻度を調節していきます。つまり、水道管の迂回路に水がまわりはじめる直前の状態を保つことで、水道管の容量をフルに活用しつつ、相手側への到達時間も最小限にしようというわけです。ただし、現実には、パケットを送信するサーバー側で、ネットワーク経路の途中にあるネットワーク機器のバッファの状態を測定することはできません。BBRは、どのようにして、最適な送出頻度を見つけ出すのでしょうか？

BBRの輻輳制御の仕組み

　BBRの仕組みを理解する上でポイントになるのが、図2のグラフです。これは、サーバーからのパケット送出頻度を上げていった際に、パケット到達時間（上図）と単位時間あたりの送信量（下図）がどのように変化するかを示したものです。

fig02

図2 ネットワーク性能の変化の様子（記事より抜粋）

　このグラフもまた、水道管のたとえで理解することができます。水道管に水がまったく流れていない状態から徐々に流量を増やしていくと、はじめのうちは、パケット到達時間は一定のままになります。水道管を流れる水の総量とは関係なく、水が流れる速度そのものは一定だと考えてください。これが、この水道管の（迂回路を含まない）本来の長さを表わすRTpropに相当します。その一方で、単位時間あたりの送信量は一定の割合で増えていきます。これは、水道管を流れる水の総量が徐々に増えている状態に対応します。その後、水道管いっぱいに水がつまると、いよいよ迂回路に水が流れ始めます。この時点の単位時間あたりの送信量が、この水道管の太さ、すなわち、BtlBwに対応します。
　この後は、迂回路、すなわち、バッファがいっぱいになるまでは、単位時間あたりの送信量は一定のままに保たれますが、その代わりに、迂回路を通る分だけ、パケット到達時間は長くなっていきます。最後に、バッファからパケットがあふれ出すと、パケット到達時間も頭打ちになってそれ以上は変化しなくなります。前述のように、パケットロスに基づいた輻輳制御においては、この頭打ちの状態を保ってパケットが流れ続けることになります。
　一方、BBRが目指すのは、パケット到達時間が増えだすぎりぎり手前の状態です。この状態は、ネットワーク上に送信中のパケット量が、ちょうど、迂回路を除いた水道管全体の容量、すなわち、RTprop✕BtlBwに一致する状態と言えます。RTprop✕BtlBwの値は、BDP（bandwidth-delay product）とも呼ばれます。BBRでは、サーバーから送信したパケットに対して、それに対応するACK（受信確認）パケットが戻ってくるまでの時間、あるいは、それぞれのパケットの容量などのデータを利用して、RTpropとBtlBwの値を推測します。そして、ネットワーク上に送信中のパケット量（送信後にまだACKを受け取っていないパケットの総容量）がちょうど、RTprop✕BtlBwに一致するようにパケットの送信頻度を調整していきます。

次回予告

　今回は、水道管のたとえを用いて、BBRの基本的な考え方を説明しました。次回は、引き続いて、BBRのより詳細な動作の仕組みを解説します。特に、ネットワークの帯域、すなわち、BtlBwは常に一定とは限りません。あるいは、ネットワーク経路の変化により、RTpropの値が変化することもあり得ます。このようなネットワークの特性の変化を検出して、パケットの送信頻度を動的に調整する仕組みなどを紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡