回線遅延シミュレータEthdelay：バッファサイズ設定可能に

細かい話題なのですが、先日、回線遅延シミュレータのEthdelay・EthdelayProにジッター機能を追加しましたが、他にもご要望をいただき、機能追加しました。サポートサイトで最新スタートアップガイドがダウンロードできます。サポート契約ユーザ様（EthdelayProは初年度サポート込み）は更新ファームも取得できます。

バッファサイズを設定可能にしたのですが、バッファサイズは遅延と帯域制限に関係します。

遅延の場合は、受信したパケットを送出するまでに指定時間待つことになりますが、当然ためておくための領域が必要で、この大きさを溢れるとパケットが破棄されます。大きい方が破棄される可能性は減りますが、どんどん遅延するデータがたまります。リアルタイム性の面では遅延するより破棄される方が良い場合もあるものです。

帯域制限の場合、影響が大きいのはリーキーバケツ方式で、リーキーバケツでは指定帯域を越えそうな場合に送出を遅延させます。バッファに入る間は受信データを受け付けますが、溢れたら破棄します。

Ethdelay・EthdelayProでは、もともとバッファサイズを内部的には設定可能にしてあったのですが、むやみに変更すると破棄されるパケットが増える点などがわかりにくいかと考え、ユーザインターフェースから設定を変更できないようにしていました。1メガバイトとかなり大きなバッファサイズで固定にしていました。

あるお客さんが、比較的小さく帯域制限をかけたところ、TCPの体感速度が、実際の回線とEthdelayでかなり違うという指摘をくださり、まず間違いなくバッファサイズの問題だろうとわかりましたので、バッファサイズも調整可能に変更したのでした。TCPの場合、大きく遅延してパケットが届いても、TCP自体が再送の仕組みを持っているので、単に混雑するだけということがあります。

リーキーバケツでのバッファサイズの影響をグラフで見てみましょう。第一パケットを受信してからの遅延時間が縦軸です。1メガバイトでは10000パケット目が届くまで22秒以上かかっていますが、ほとんど破棄されていません。バッファサイズを減らしていくとロスパケットがどんどん増えますが、後の方のパケットもそれほど遅延せずに届きます。

トークンバケツでは一定時間で通せるだけ通して、閾値を越えたところでしばらく通さない、という感じの動きになるので、バッファサイズに関係なく、最終パケット付近は同じくらいの遅延で届きます。ただし、届くパケットの数はもちろんかなり差が出ます。

かなりマニアックな話になりましたが、製品はユーザが増えれば増えるだけ品質が上がると共に機能も増えていくものです。不正接続検知／排除システムのIntraGuardian2も当初に比べると驚くほど機能が増えましたし、性能もUPしています。先日のLBIサロンで講師の方が語っていた内容で、「まずは絶対に必要な機能だけに絞ってリリースするのがポイント」というのがありました。最初から盛りだくさんにしても、市場のニーズとあっていない可能性があります。製品は市場に育ててもらうのが一番なのです。もちろん、要望がきたものを何でもかんでも盛り込めば良いというものでもありません。製品のポリシーやバランスも大切です。しかし、何よりも大切なことは、まずリリースしてたくさんのユーザに使ってもらうことです。