IT業界でベンチャービジネスの支援をしている執筆者が日々の活動ログと感じたことを、徒然なるままに書き綴っていきます。

グーグルのクラウドを支えるテクノロジー > 第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

Comment(0)

コメント

コメントを投稿する