回線遅延のTCPスループットへの影響：回線遅延シミュレーターEthdelayProと理論値

いきなりマニアックな話題ですが、回線遅延がTCP/IPのスループットに与える影響を、回線遅延シミュレータ：EthdelayProでの測定結果と、理論値を比較してみます。

測定はnetperfを使い、EthdelayProを経由して2台のLinuxマシンで測定しました。遅延時間を2msecから100msecに変化させ、スループットを測定します。
TCPのスループットにはウインドウサイズが大きな影響を与えますが、今回はnetperfを動かす2台のLinuxマシンのウインドウサイズを送信側・受信側ともに262144バイトにして測定しました。
帯域制限も、1000Mbpsから10Mbpsで測定して、EthdelayProが正しくシミュレートしているかどうかを見てみました。

まずはEthdelayProでの実測値です。帯域制限はリーキーバケツを指定したときのデータですが、トークンバケツでもほぼ同じになります。

まずは、帯域制限がきちんと動いていることがわかります。なお、対数グラフにした関係で、回線遅延無指定（実測で往復遅延が0.33msec）は、見やすくするために1msecとしてプロットしています。

続いて、理論値です。ウインドウサイズと回線遅延を元にスループットは、
ウインドウサイズ(byte)×8/往復遅延(sec)＝スループット(bps)
で求められます。グラフにすると、次のようになります。

傾きが実測と少しずれてしまっていますが、測定自体のオーバーヘッドもありますので、まあこのくらいでしょうか。いずれにしても、傾向は再現できていますので、後は遅延の設定値を調整するなどで、目的に合わせていく感じで使うことになります。

ちなみに、測定環境のLinuxでは、ウインドウサイズは、
最小　デフォルト　最大
4096    16384   2031616
となっていました。
最小・最大・262144バイトの理論値をグラフにしてみると、こんなに違うのです。TCPでのウインドウサイズの影響は非常に大きいということがよく理解できると思います。受信確認応答（ACK）が回線遅延の影響を受けるためで、ウインドウサイズが小さいと応答確認を受け取るまで次のパケットの送信ができなくなり、回線使用率が低下してしまいます。上記EthdelayProでの測定ではウインドウサイズを262144バイトにしていますが、OSのデフォルトのままの方がはるかにスループットは上がります。

TCPの仕組みに興味が湧いてきたら、是非専門書などの解説を読んでみましょう！