グーグルのクラウドを支えるテクノロジー　＞　第23回　パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（後編）

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー　＞　第23回　パケットロスに基づかない新しい輻輳制御の仕組み ― BBR（後編） 」を公開しました。

Google　Cloudを支えるテクノロジーの後半です！

今回もエバンジェリストの中井さんの筆は好調です。わかりやすい解説なので、技術者でない方でも理解できる良い文章だと思います。興味がある方は是非チェックしてください。

＃＃＃

はじめに

　前回に続いて、2016年に公開された学術記事「BBR: Congestion-Based Congestion Control」をもとにして、Googleが開発した、ネットワーク通信における新しい輻輳制御の仕組みを解説します。前回は、ネットワーク経路を水道管にたとえる方法で、BBRの考え方を説明しました。水道管の長さに相当するRTpropと太さに相当するBtlBwの値を推定して、送信中のパケットの総量がちょうど水道管の容量である「RTprop✕BtlBw」に一致するように、パケットの送信頻度を調整するという考え方でした。
　今回は、RTprotとBtlBwを推定する方法について、より具体的な解説をすすめます。

RTpropの推定方法
　冒頭の記事では、TCP通信において、RTpropとBtlBwを推定するコードの例が紹介されています。まず、RTpropの方は単純です。あるパケットを送信した後、そのパケットに対する受信確認（ACK）パケットを受け取るまでの時間であるRTT（Round Trip Time）を計測します。そして、過去数十秒間に計測された、複数のパケットに対するRTTの中で、最小の値をRTpropの推定値とします。ここで最小値を選択するのは、受信側の理由でACKの送信が遅れるなどの可能性があるためで、そのような、RTpropと無関係な遅延を含む場合を除外することが目的です。前回の図2のグラフから分かるように、一切の遅延がなく、最速でパケットが戻ってきた場合の時間がRTpropになるので、それを過去数十秒間における最小値で代替しているわけです。

この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai223.html