TCP 性能評価システム DBS の構築

(1)
1
特集●インターネット技術
TCP 性能評価システム DBS の構築
村山公保門林雄基山口英
TCP の性能評価に広く用いられている性能測定ツー
ルは，2 点間のホストでデータ転送をしたときの，スルー
プットの平均値を測定することに主眼が置かれている．
TCP の一部の機能しか評価できないという
このため，
TCP の設計思
ターネットがここまで発達できたのは，
想 [2] には，大きな誤りがなかったからだと考えられる．
TCP は，従来から使われてきた低速なネット
ワーク上で発展してきたため，TCP の利用が想定され
しかし，
欠点がある．
ていなかった高速なネットワークでは，さまざまな問題
本稿では，
が起きることが指摘されている．具体的には，データリ
TCP 性能評価システム DBS (Distributed
Benchmark System) を提案する．DBS は，多点間の
ホストで同時にデータ転送を行い，スループットの時間
TCP に備えられる全ての機能
TCP
ンクがどんなに広帯域になっても，限られたスループッ
トでしかデータ転送を行えないことや，帯域に十分な
変化を測定することで，
余裕があっても，間欠的にしかデータが送出されず，ス
を評価するためのツールである．本稿では，まず，
ループットが極端に悪化する場合があることなどである
の性能評価手法について論じ，新たなツールが必要であ
[13][4]．しかしながら，現在までに明らかになっている
ることを明らかにする．次に，
問題以外にも，
DBS を提案し，実装と
評価について論じる．さらに，DBS を利用して実際の
ネットワークで測定した例を示す．
1 TCP の性能評価の重要性
現在，インターネットは世界的な規模で，急速に普及・
発展が進められている．現在のインターネット上のサー
TCP を利用して構築されている．この
ため，インターネットでは，TCP が最も重要なトラン
ビスの大部分は，
スポート・プロトコルということができる．また，イン
TCP には未知の問題が数多く残されて
いると考える研究者は多い．高速化，多様化が進むネッ
トワークを，将来にわたって効率よく利用するためには，
TCP の問題点をできる限り明らかにして，それ
らを克服した次世代の TCP (TCPng) へ発展させるこ
現在の
とが必要である．
2 TCP の性能評価手法
TCP の性能評価手法には，シミュレーションによる
2つ
方法と，実際にデータ転送を行って観測する方法の
がある．実在しないネットワークの評価ならば，シミュ
Design and implementation of DBS:a performance
evaluation system for TCP.
Yukio Murayama, 奈良先端科学技術大学院大学, Nara
Institute of Science and Technology (NAIST).
Youki Kadobayashi, 大阪大学, Osaka University.
Suguru Yamaguchi, 奈良先端科学技術大学院大学, Nara
Institute of Science and Technology (NAIST).
コンピュータソフトウェア, Vol.16, No.6(1997), pp.3{16.
[論文] 1996 年 10 月 2 日受付.
レーションは非常に有効な手法だといえるが，広く利用
TCP の場合には，特に優れた手法
とはいえない．また，TCP の性能は，TCP のプロトコ
されるようになった
ルやアルゴリズムだけで決まるのではなく，その実装や，
OS でのメモリ管理，コンピュータ・アーキテクチャ，
データリンクの特性などが関係することが，最近の研
究から明らかになっている [11]．しかし，既存の
REAL
2
(2)
コンピュータソフトウェア
[10] などのシミュレータでは，データリンクの特性やコ
性能測定ツールは，負荷の低い状態や負荷の高い状
ンピュータ・アーキテクチャなど，実装面の細かい部分
態を作り出せる必要がある．
まではシミュレートできていない．これらのことから，
今後の
TCP の性能評価では，実際にデータ転送を行っ
て測定する評価手法が重要になってくると考えられる．
3 TCP 性能測定ツールに求められる機能
現在のインターネットの利用形態を考慮すると，実際
にデータを転送して測定を行う
は，次の機能が求められる．
1.
TCP 性能測定ツールに
アプリケーションレベルのスループットを測定で
きる．
TCP の性能改善は，終点アプリケーション間での通
信性能の向上が目的である．ネットワーク中をどの
ようにデータが流れようとも，終点アプリケーショ
ンにとって，十分なスループットが得られればよい．
TCP 性能測定ツールは，アプリケーショ
2.
る影響を測定できる．
ネットワークの負荷の変動は，データ転送に影響を
TCP 性能測定ツールは，その
与える．そのため，
影響を測定できる必要がある．具体的には，各々の
データ転送のシーケンス番号の時間推移，スルー
プットの時間変化等を測定できる必要がある．また，
マルチメディア通信の評価にとっては，遅延時間の
時間変化，遅延時間の揺らぎの時間変化等も測定で
きる必要がある．
6. TCP の制御機構の評価ができる．
TCP にはフロー制御，再送制御，そして輻輳回避制
御の 3 つの制御機構がある．これらは TCP の性能
を決定する大きな要素となっている．フロー制御は，
受信ホストが受信可能な最大のスループットに制御
ンレベルのスループットを測定できる必要がある．
する機構である．再送制御は，セグメントが喪失し
通信経路のデータリンクの種類によらずに利用で
たかどうかを予測して，再送処理をするための機構
きる．
である．そして輻輳回避制御は，ネットワークの混
インターネットでは，
み具合に合わせてセグメントの送信量を制御し，セ
能測定ツールは，通信路上のデータリンクの種類に
よらずに利用できる必要がある．
複数のコネクションを同時に確立し，同時にデー
タ転送を行うことができる．
パケット・ネットワークのもっとも重要な役割は，
ネットワークを構成するハードウェアの共有である．
グメントの喪失を防ぐ機構である．これらの
3 つの
制御機構が協調して動作しなければ，ネットワーク
を有効に利用して，最大限のスループットを得るこ
TCP 性能測定ツールは，
TCP の制御機構の評価ができなければならない．
とはできない．そのため，
4 既存の性能測定ツールとその問題点
TCP の性能評価を目的として，ttcp，Netperf [5]，nettest， NetSpec [9] といった性能測定ツー
これまで，
ルが開発されている．
ttcp，Netperf，nettest は，2 点間のホストでデータ
実際に，インターネット上では，たくさんのコネク
転送をしたときに，最大どれぐらいのスループットにな
ションが確立され，複数のデータ転送が同時に行わ
るかを測定できる．得られる結果は，アプリケーション
れている．
レベルのスループットの平均値である．点間のホスト
できる必要がある．
でデータ転送をしただけでは，通常はネットワークの負
TCP 性能測定ツールでは，これを模倣
4.
ネットワークの負荷の変動が，データ転送に与え
そのため，
Ethernet や FDDI，ATM，
X.25，専用回線，ISDN，Frame Relay，Fiber
Channel など，さまざまなデータリンクが利用
される．TCP は IP の上位層のプロトコルであり，
IP データグラムを転送できるあらゆるデータリン
クで利用される可能性がある．そのため，TCP 性
3.
5.
ネットワークの負荷を変化させることができる．
ネットワークの負荷は一定ではない．負荷の低い状
態や，負荷の高い状態，そして輻輳の状態など，ト
ラヒック量は動的に変化する．このため，
TCP の
2
荷は変化せず，セグメントの喪失も起こらない．これら
3
のツールでは，節の
1 と 2 の機能は備えられているが，
3，4，5，および 6 の機能が欠けている．
NetSpec は，2 点間のデータ転送だけでは，高速ネッ
(3)
Vol. 14 No. 6 Nov. 1997
3
トワークの帯域のすべてを使い切ることはできないとい
動を測定していることにはならない．モニタリングやパ
うことに着目し，複数のホストが同じデータリンクで同
ケットの収集は，ネットワークを流れるトラヒックの挙
時にデータ転送をしたときに，データリンクの帯域のす
べてを使い切れるかどうかを測定する目的で作られた．
しかし，この
Netspec では，すべてのコネクションの
データ転送が同時に行われるため，通常，ネットワーク
の負荷は変化しない．また，変化したとしても，得られ
る結果は他のツールと同様にスループットの平均値であ
る．このため，ネットワークの負荷の変化が，データ転
OS やコ
ンピュータのアーキテクチャの評価を含めた，TCP に
動を分析するためには優れた手法といえるが，
よるデータ転送の総合的な性能評価をすることにはなら
ない．
以上のことから，異なる環境下でも同じ実験・測定が
できる単一のシステムが必要だといえる．
送に与える影響を調査することはできない．このツール
5 DBS の提案と実装
では，節の，，の機能は備えられているが，，
5.1
3 1 2 3
および 6 の機能が欠けている．
4 5
これらの性能測定ツールは，スループットは変化せず，
セグメントの喪失もないといった仮定のもとで，特定の
データリンク上で
TCP/IP プロトコルスタックを使用
したときの，平均スループットを測定しているに過ぎな
TCP の性能改善を目指した設計がされておらず，
TCP に潜在している問題点を明らかにするためには機
い．
能が不足している．
ただし，手作業などで，時間間隔を空けてこれらの
ツールを複数起動させれば，ネットワークの負荷を変化
させることができる．また，ネットワーク・アナライザ
によるパケットのモニタリングや，
tcpdump コマンド
によるパケットの収集を行えば，ネットワーク中を流れ
るパケットの挙動の変化を測定することもできる．しか
し，手作業による実験では，測定結果の再現性を調べる
ための再実験や，設定変更前後の比較のための実験が困
DBS
の提案
TCP 性能評価システム DBS (Distributed Benchmark System) を提案する．このシス
テムの目的は，任意の TCP/IP ネットワーク環境下で，
本研究では，
任意のデータ転送トラヒックを生成・測定することで，
TCP が持つ機能のすべてを評価できる基盤を提供する
ことである．そのためには，3節で述べた機能の全てを，
単一のシステムで実現することが必要である．これらの
機能を実装面からまとめると，すべての機能は，次の機
能モデルで実現できる．
i.
複数のホスト間で複数の
TCP コネクションを確立
し，アプリケーションレベルのデータ転送を行う．
ii.
各々のコネクションのデータ転送に関して，アプ
リケーションレベルでのデータ転送開始時刻や，転
送するデータの量を設定できる．
iii. 一つ一つのデータの送受信時刻を記録する．
i と ii により，複数のコネクションのデータ転送の開始
難になる可能性がある．複雑な実験になればなるほど，
時刻や，データの転送量を操作することで，ネットワー
手作業で同一の実験を精度よく複数回繰り返して行うこ
クの負荷を変動させることができる．また，
とは困難である．
から，シーケンス番号の時間推移や，スループットの時
また，パケットのモニタリングや，パケットの収集に
TCP/IP が利用されるあらゆるデー
よる解析手法では，
タリンクに対応できる統一的なシステムを構築するのは
困難である．通常，アナライザは特定のデータリンクに
tcpdump コマンドはブロー
しか対応しておらず，また，
ドキャスト型のネットワーク以外では利用できない．利
用できたとしても，データ送受信を行うホストで別のプ
ロセスとして実行しなければならないため，大きな負荷
iii のデータ
間変化，遅延時間の時間変化，遅延時間の揺らぎの時間
3
変化を計算することができる．これにより，節の要求
3
1 2
と 5 は i と iii の機能で，3 は i と ii の機能で，4 は i の
機能で，6 は i と ii と iii の機能でそれぞれ実現できる．
を全て実現することができる．具体的には，節のと
5.2
DBS
の機能
DBS は，測定に関係するすべてのホスト間で，時刻
となり測定結果に影響することになる．しかも，これら
の同期がとれているという条件の下で動作するように，
の手法では，アプリケーションレベルのデータ転送の挙
設計・開発を行った．時刻の同期は
NTP [3] (Network
4
実験ホスト群
情報収集ホスト
DBSデーモン複数存在する
DBSコントローラ
コマンドファイル
の読み込み
コマンド送信
(1) コマンド送信
(2) 実験準備完了合図
実験ネットワーク
(3) 実験開始時刻通達
設定ファイル
()
O
K
F
i
l
)
o
r
a
(
o
r
(4)
コンピュータソフトウェア
結果受信
データを送受信
する数分のプロ
セスが起動する
実験中止
実験開始時刻
まで待つ
結果ファイル
図1
データの送受信
が行なわれる
DBS のシステム構成図
(4) 結果の送信要求
Time Protocol) を対象にしている．DBS には次の機能
を実装した．
1. TCP および UDP でデータの送受信ができる．
2. 複数のホスト間で，複数のコネクションを確立し，
3.
4.
複数のデータ転送を同時に行うことができる．
一つ一つのデータの送受信時刻を記録し，アプリ
ケーションレベルのスループットの時間変化を測定
できる．
(5) 結果データの送信
結果の書き込み
図2
DBS の処理の流れ
DBS コントローラは，情報収集ホス
ト上で動作させるプログラムで，DBS デーモンへの実
デーモンと呼ぶ．
験内容の指示や，結果を受信してファイルに出力する機
データの転送開始時刻や，トラヒックパターンな
ど，データ転送に関する細かい設定ができる．
5. TCP のバッファサイズの指定や，Nagle アルゴリ
ズム [6] の解除などの，ソケットのオプションを指定
DBS デーモンは，実験ホスト群の各々のホス
ト上で動作させるプログラムで，DBS コントローラの
能を持つ．
指示に従ってデータ転送と測定を行う．なお，一つの実
できる．
験ホストで複数のデータ転送を送受信する場合は，その
数だけ
デーモンが別のプロセスとして動作するy1 ．
コントロールブロックの値を記録することができ，
示す．
6. OS に TCP DEBUG 機能がある場合には，TCP
喪失セグメントの特定や輻輳ウィンドウの大きさの
OS 内部
変化，ラウンドトリップ時間の変化など，
の処理に関するきめ細かな情報を得ることができる．
DBS
DBS は次のように動作する．DBS の動作を図 2にも
(1)
情報収集ホストから各実験ホストへ，実験の内容
を指示する命令が送信される．
(2) DBS デーモンが命令を受信し，データの送受信
時刻を記録するためのメモリ空間などの資源を用意
5.3
DBS
のシステム構成と動作概要
実装したシステムの構成を図 1に示す．DBS は大きく
2 種類の構成要素に分けられる．一つは実際に性能測定
を行う実験ネットワークと実験ホスト群で，もう一つは
測定の制御や測定結果のデータ収集を行う情報収集ホス
する．実験の準備が完了したら
何か問題があったら
する．
(3)
OK の返事をする．
Fail の返事とエラー番号を返送
情報収集ホストにすべての実験ホストから
OK
の返事がきた場合は，実験開始時刻を知らせる命令
トである．情報収集ホストは必ず一つで，実験ホストは
を送信する．その時刻になると実験ホスト群の間で
通常複数台存在する．なお，実験ホストが情報収集ホス
データ転送・測定が行われる．実験ホストから
トを兼ねることも可能である．
の返事が来た場合には実験中止の命令を送信する．
DBS は dbsc と dbsd という 2 つのソフトウェアから
構成される．この二つのソフトウェアは C 言語で開発
した．以降，dbsc を DBS コントローラ，dbsd を DBS
(4)
y1
Fail
実験終了時刻になると，情報収集ホストから結果
fork システムコールを使用した．
(5)
Vol. 14 No. 6 Nov. 1997
トラヒックのパターンを作成しなければならない．
(1) 一つのデータの大きさ
3 (1)∼(4) は，それぞれ次のような意味である．
(1) 一つのデータの大きさ (byte)．アプリケーション
図の
(2) 一回のシステムコール
で送信するデータ
送信するデータ
でのデータの単位．
(4) 送信の時間間隔
(3) 送信開始時刻の間隔
図3
(2)
一回の
send システムコールで送信するデータの
(byte)．
(3)
送受信開始時刻の間隔，送信レートの調節に利用
(4)
送受信の時間間隔，システムや入出力のオーバ
大きさ．メッセージサイズ
時間の経過
(
する精度は
DBS のトラヒックパターン
を要求する命令が送信される．
(5)
5
0.01 秒程度)．
(
送され，ファイルに格納される．
実験ホストがネットワークのインターフェースを
1つ
しか備えていない場合は，命令と結果のトラヒックが実
験ネットワークを通ることになる．このことが結果へ影
響するのを防ぐため，実験のトラヒックと制御のトラ
ヒックが同時に流れないように
0.01 秒程度)．
ヘッドの指定に利用する精度は
測定結果が実験ホスト群から情報収集ホストへ転
DBS を実装した．
また，実験ホストが情報収集ホストを兼ねる場合は，
DBS コントローラの処理が，DBS デーモンの処理に影
響を与える可能性がある．そのため，実験中は DBS コ
ントローラは sleep 状態となり，できるだけ CPU 時間
5.5
DBS
の測定結果の処理
DBS は他の性能測定ツールと比べ，大量の測定結果を
出力する．そのデータを処理してグラフ化する dbs view
というツールを作成した．ツールの本体は perl で記述
したが，グラフの描画には Gnuplot V3.5 [12] を利用す
る．dbs view ではシーケンス番号の時間推移，スルー
プットの時間変化，遅延時間の時間変化，遅延時間の揺
TCP DEBUG を
らぎの時間変化等をグラフ化できる．
利用した場合には喪失セグメントや，輻輳ウィンドウの
時間変化等をグラフ化できる．
を消費しないように実装した．
5.6
5.4
トラヒックパターン
telnet などの遠隔端末や，UDP のデータをネットワー
セキュリティに対する配慮
近年，
LAN とインターネットの間に，防火壁 (Fire
Wall) を置くところが多くなってきた．このような環境
クに流して，それを測定しようと考えた場合には，ト
でも，防火壁を通過する通信の性能を測定したいという
ラヒックパターンの指定が必要である．特に
要求がある．防火壁にはいろいろな形式があるが，
UDP はフ
DBS
ロー制御がなく，トラヒックの制御をアプリケーション
では，外向きへのコネクションは許すが，内向きへのコ
に任せている．
ネクションは許さないという，フィルタリング型の防火
ようなトラヒックを流すことも可能である．しかし，現
壁に対応させた．このような防火壁では，
UDP ではネットワークの帯域を超える
TCP のコネ
実のネットワークではそのようなことは行われない．ビ
クションの確立時に，必ず防火壁の内側から外側へ向け
デオや音声などのマルチメディア情報をリアルタイムに
て接続要求をしなければならない．しかしデータ転送
流す場合には，送信レートや，トラヒックのパターンが
は外側から内側へも，内側から外側へも行われる．そこ
大体決まっている．そこで，
で，コネクションの接続要求の向きとデータ転送の向き
トラヒックパターンを，任意の回数繰り返して送信でき
を別々に指定できるように実装することで，これらの環
るように実装した．この機能により，
境に対応させた．
DBS では図 3に示すような
MPEG などのデー
DBS デーモンは，inetd スーパデーモンから
また，
タ転送を模倣することや，乱数的に送信間隔やパケット
長が変動するデータ転送を作り出すことができる．ただ
自動的に起動できるように作成した．しかし，自動的に
し，
起動できるように設定すると，悪意を持った者が，不正
能を実装しなかった．そのため，利用者が必要に応じて
に
DBS 自体には，トラヒックパターンを生成する機
DBS デーモンにアクセスし，ネットワークに大量の
6
(6)
コンピュータソフトウェア
トラヒックを長時間流すことで，業務や研究活動の妨害
DBS
Ethernet
を企てる可能性がある．この問題に対応するため，
10Mbps
デーモンは，特定の情報収集ホスト以外からはコマンド
を受け付けないように，アクセスに制限を設けられるよ
IP アドレスの
Host1
うに実装した．しかし，ユーザの制限や，
なりすましには対応していない．これらへの対策も必要
図4
DBS デーモンを自動的に起動せずに，
測定実験のたびに DBS デーモンを起動・終了してほし
Host2
2 点間の Ethernet 実験環境
とされる場合は，
いと考えている．
6 DBS の評価
DBS の機能面の評価と，測定結果の妥当性について
検討する．
6.1
表2
CPU
OS
MSS
TCP バッファサイズ
Twinhead Subnote(486 33MHz)
BSD/OS V2.1
1448octet
8196byte
メッセージサイズ
2048byte
送信回数 (DBS，ttcp) 2048 回
送信時間 (Netperf)
10 秒
機能面の評価
DBS と他の性能測定ツールを，トラヒックの生成，測
定実験の設定，測定結果の解析について，機能面で比較
1
した結果を表に示す．
ネットワークの負荷を変動させるためには，複数の
表3
DBS
Netperf
ttcp
8000
できること，各々の転送データの総量を設定できるこ
7000
とが必要である．また，ネットワークの負荷の変動が，
6000
ス番号の時間推移を測定できる必要がある．以上，ここ
DBS では全ての機能が実現
で述べたこれらの機能は，
Throughput(Kbps)
データ転送を行えることや，各々の転送開始時刻を指定
データ転送に与える影響を調査するためには，シーケン
1000
また，
DBS は他のツールと比較して高機能であるが，不足
している機能が 2 つある．しかし，IP を使わないデータ
転送は TCP の性能評価にとっては必要なく，また，送
受信データをリダイレクションで入出力できる機能は，
複雑なトラヒックパターンを設定する機能である程度模
倣することができる．
TCP の性能測定という視点から総合的に判断すると，
DBS は既存の測定ツールよりも高機能なのは明らかで
DBS を 100 としたときの比率
100.0
102.1
99.1
DBS
Netperf
ttcp
0
0
記録できる機能が備えられており，これは他の性能測定
になる．
6223Kbps
6357Kbps
6172Kbps
3000
2000
TCP の挙動のより精密な調査や解析をすることが可能
平均スループット
4000
なかった．
ツールにはない特長といえる．この機能を利用すれば，
それぞれのツールでの測定結果 (平均)
5000
されているが，既存の測定ツール単体では実現されてい
DBS には TCP コントロールブロックの値を
評価に使用した機材と設定
図5
1
2
3
Time(s)
4
5
6
それぞれのツールでの測定結果 (時間変化)
ある．
6.2
測定結果の妥当性
DBS は，データを送受信するたびに，その時刻をメモ
リに記録している．この処理は CPU の負荷となり，測
定結果に影響する可能性がある．この影響の度合いを調
DBS，Netperf，ttcp の測定結果を比較し
た．図 4に示すような Ethernet で接続された 2 つのホ
スト間で，表 2に示す設定でデータ転送を行った．結果
査するため，
(7)
Vol. 14 No. 6 Nov. 1997
表1
性能測定ツールの機能の比較
トラヒックの生成
TCP および UDP によるデータトラヒックの生成
2 点間のホストで複数のデータ転送
多点間のホストでのデータ転送
データリンクを直接使った転送 (IP を使わない)
送信データをリダイレクションで入力できる
トラヒックパターンの設定
測定実験の設定
各々のデータ転送の開始時刻の設定
メッセージサイズの設定
送信データ量の設定
ソケットのバッファサイズの設定
Nagle アルゴリズムの解除の設定
防火壁への対応，セキュリティへの配慮
測定結果の解析
シーケンス番号の時間推移の測定
平均スループットの測定
スループットの時間変化の測定
遅延時間の時間変化の測定
遅延時間の揺らぎの時間変化の測定
コネクション確立のオーバヘッドの測定
TCP コントロールブロックの値を記録
スロースタートの挙動の測定
ラウンドトリップ時間の測定
輻輳ウィンドウの変動の測定
3
5
7
を表と図に示す．
DBS と各ツールとの差は 1∼2%程
この結果をみると，
DBS
O
O
O
X
X
O
Netperf
O
X
X
O
X
X
ttcp
O
X
X
X
O
X
nettest
O
O
X
X
X
X
NetSpec
O
O
O
X
X
O
DBS
O
O
O
O
O
O
Netperf
X
O
O
O
O
X
ttcp
X
O
O
O
O
X
nettest
X
O
O
O
O
X
NetSpec
X
O
O
O
O
X
DBS
O
O
O
O
O
O
O
O
O
O
Netperf
X
O
X
X
X
O
X
X
X
X
ttcp
X
O
X
X
X
X
X
X
X
X
nettest
X
O
X
X
X
X
X
X
X
X
NetSpec
X
O
X
X
X
X
X
X
X
X
るまで続くy2 ．その間スループットは極端に小さくなる．
Ethernet で接続された 2 点間のホス
TCP の
この実験から，
度であり，時刻をメモリに記録する処理の影響は，無視
トという平凡なトポロジーであったとしても，
できないほど大きなものではないといえる．また，図
制御機構のために，スループットが極端に変化する場合
5
DBS の測定結果をみると，約 0.2 秒まではスループッ
があることが明らかになった．また，このことから，ス
トが極端に小さくなっていることがわかる．調査した結
果，この現象は
TCP のスロースタート [14] と遅延確認
ループットの時間変化を測定できる機能は，
能評価にとって，なくてはならない機能だといえる．さ
の
TCP の性
応答 [1] に原因があることが判明した．送信ホストは通信
らに，スループットの時間変化を測定できないツールの
開始直後，スロースタートにより輻輳ウィンドウを
測定結果を，盲目的に無条件で信用することは危険だと
1セ
1
しかし，受信側は 1 セグメントのデータを受信しても，
グメントに設定し，セグメントだけデータを送信する．
更なるデータの到着を待ち，確認応答を送信しない．そ
の結果，最初のセグメントはかならず遅延確認応答とな
る．この状態は，送信ホストの輻輳ウィンドウが，受信
ホストのウィンドウを更新させる大きさより，大きくな
いえる．
7 DBS による性能測定
DBS の効果を調査するため，衛星回線，ATM，FDDI，
WAN のネットワークで測定実験を行った．
y2
BSD/OS(4.4BSD Lite) では 2 セグメントである
8
(8)
コンピュータソフトウェア
1.8
JCSAT-1
(JSAT)
2Mbps (RTT ~0.5s)
1.4
Throughput (Mbps)
DCE
DCE
Ethernet 10Mbps
Ethernet
8192 recv
32768 recv
65535 recv
131072 recv
1.6
Satellite Channel
2Mbps
10Mbps
1.2
1
0.8
0.6
0.4
HOST1
HOST2
0.2
ウィンドウサイズ拡張オプションの評価
表4
CPU
OS
Router
MSS
TCP バッファサイズ
(最大ウィンドウサイズ)
メッセージサイズ
データ転送時刻
送信回数
その他
0
0
図8
機材と設定
Twinhead Subnote(486 33MHz)
BSD/OS V2.0.1
SPARCstation10(SunOS4.1.4)
512octet
8196byte (8196octet)
32768byte (32768octet)
65535byte (66535octet)
131072byte (131072octet)
1024byte
0.00 秒
1000 回
TCP DEBUG 機能を利用
5
10
15
Time (s)
20
25
30
ウィンドウサイズの拡張オプションの評価 (スルー
プットの変化)
300000
8192 cwnd
32768 cwnd
65535 cwnd
131072 cwnd
250000
Window Size (byte)
図6
200000
150000
100000
50000
1.2e+06
0
1e+06
Sequence Number
0
8192 recv
32768 recv
65535 recv
131072 recv
196608 recv
246723 recv
800000
図9
15
Time (s)
20
25
30
ウィンドウサイズの拡張オプションの評価 (輻輳ウィ
65535byte の場合は，7 秒目までバッファサイズが
131072byte の場合と重なるように変化している．
400000
7
8
9
結果を図，図，図に示す．
200000
0
0
5
10
15
Time (s)
20
25
30
ウィンドウサイズの拡張オプションの評価 (シーケン
ス番号の推移)
7.1
10
ンドウの変化) バッファサイズが 32768byte と
600000
図7
5
衛星回線
BSD/OS(4.4BSD Lite) には，TCP のウィンドウサ
結果をみると，最大ウィンドウサイズに関係なく，デー
タ転送開始から約
3 秒間は，TCP のスロースタート処
理のため，輻輳ウィンドウがなかなか大きくならず，転
送されるデータがごくわずかであることがわかる．約
3
秒経過すると，スロースタートによる輻輳ウィンドウ拡
大の効果が表れ，スループットが急激に増加する．しか
し，最大ウィンドウサイズが，ウィンドウの制限サイズ
64Koctet 以下の場合は，スループットが振動し
イズの制限を拡張するオプション [13] が実装されている．
である
この機能を利用して，約
て帯域を使い切っていない．拡張オプションを使用して，
0.5 秒のラウンドトリップ時間
2Mbps の帯域を持つ，静止衛星で構築された衛星回ウィンドウサイズを 128Koctet 以上に設定した場合は，
線でデータ転送実験を行った．測定環境を図 6と表 4に， 2Mbps の帯域をほぼ使いきっている．
で
(9)
Vol. 14 No. 6 Nov. 1997
JCSAT-1
2
(JSAT)
1.8
Satellite Channel
HOST1
HOST2
DCE
10Mbps
HOST3
HOST4
Ethernet
10Mbps
1.4
Throughput (Mbps)
DCE
Ethernet
host1-host5 recv
host2-host5 recv
host3-host5 recv
host4-host5 recv
total
1.6
2Mbps (RTT ~0.5s)
2Mbps
9
1.2
1
0.8
0.6
0.4
HOST5
0.2
表5
衛星回線での測定
0
0
衛星回線での測定環境と設定
CPU(HOST1,2,3,4)
CPU(HOST5)
OS
Router
MSS
TCP バッファサイズ
メッセージサイズ
データ転送時刻
送信回数
その他
Twinhead Subnote(486 33MHz)
GATEWAY2000(486 66MHz)
BSD/OS V2.1
SPARCstation10(SunOS4.1.4)
512octet
65535byte
2048byte
HOST1{HOST5: 0.00 秒
HOST2{HOST5: 2.00 秒
HOST3{HOST5: 4.00 秒
HOST4{HOST5: 6.00 秒
300 回
TCP DEBUG 機能を利用
図 12
10
20
30
Time (s)
40
50
60
衛星回線での測定結果 (スループットの変化)
70000
host1-host5 cwnd
host2-host5 cwnd
host3-host5 cwnd
host4-host5 cwnd
host1-host5 ssthresh
host2-host5 ssthresh
host3-host5 ssthresh
host4-host5 ssthresh
60000
50000
Size (byte)
図 10
40000
30000
20000
10000
0
0
10
20
1.2e+06
host1-host5 send
host2-host5 send
host3-host5 send
host4-host5 send
host1-host5 recv
host2-host5 recv
host3-host5 recv
host4-host5 recv
host1-host5 lost/rexmt
host2-host5 lost/rexmt
host3-host5 lost/rexmt
host4-host5 lost/rexmt
Sequence Number
1e+06
800000
600000
図 13
40
50
60
衛星回線での測定結果 (輻輳ウィンドウ (cwnd) と
スロースタート閾値 (ssthresh) の変化)
通信を終えることができる
(HOST4-HOST5)．しかし，
セグメントが喪失する場合は，しばらくの間スループッ
400000
トが向上しない．特に連続的にセグメントが喪失した
場合など，ウィンドウサイズが小さいときにセグメント
200000
0
0
図 11
30
Time (s)
10
20
30
Time (s)
40
50
60
衛星回線での測定結果 (シーケンス番号の推移)
また，この一つの衛星回線上で，複数のデータを転送
する実験も行った．測定環境を図
10と表 5に，結果を図
11，図 12，図 13に示す．データ転送をしているコネク
ションが一つの場合は，セグメントは喪失せず順調にデー
タ転送が行われるが，複数になるとセグメントの喪失が
起こり，スループットが悪化する．そのコネクションの
セグメントが喪失しない場合は，高スループットのまま
が喪失すると，長時間にわたって小さなスループットが
続く．この理由は，スロースタート閾値が小さく設定さ
れたために，スロースタートがほとんど行われず，すぐ
に輻輳回避段階に入ったからである
HOST3-HOST5)．
7.2
(HOST2-HOST5，
ATM と Router が混在する環境
14のように ATM とルータが接続された環境で，表
6に示す設定でデータ転送実験を行った．なお，HOST1，
HOST2 と，HOST3 の間の通信は，一旦 Router で IP
図
レベルの経路制御がされてから，終点ホストへ届けられ
10
( 10 )
コンピュータソフトウェア
35
Host1
host1-host3 recv
host2-host3 recv
ATM公衆網
32Mbps
ATM Switch
155Mbps
155Mbps
Router
Host2
奈良先端科学技術大学院大学
図 14
大阪大学豊中キャンパス
Throughput (Mbps)
100Mbps ATM Switch
100Mbps
30
Host3
25
20
15
10
ATM とルータが混在する環境での測定
5
0
0
表6
2
4
6
8
10
Time (s)
ATM とルータが混在する環境の設定
CPU
OS
ATM Switch
ATM Card
Router
AAL Type
MTU
MSS
TCP バッファサイズ
メッセージサイズ
データ転送時刻
送信回数
Sun SPARCstation10
SunOS 4.1.3
NEC ATOMIS5
Fore SBA-200
NEC IP 45/650 (Cisco7000)
AAL 5
9188octet
9148octet
52428byte
8196byte
HOST1{HOST3: 0.00 秒
HOST2{HOST3: 2.00 秒
HOST1{HOST3: 2000 回
HOST2{HOST3: 500 回
図 16
12
14
16
18
ATM とルータが混在する環境での測定結果 (ス
ループットの変化)
HOST1
HOST10
HOST2
FDDI
HOST9
HOST3
100Mbps
HOST8
HOST4
HOST7
HOST5
HOST6
1.8e+07
host1-host3 recv
host2-host3 recv
1.6e+07
図 17
FDDI での測定
Sequence Number
1.4e+07
1
のスループットが同期し，秒おきにバースト的なデー
1.2e+07
1e+07
タ転送と，転送停止を繰り返している．この結果から，
ATM のような送信権の制御がなく，セルレベルでデー
タが喪失するネットワークでは，TCP のセグメントレ
8e+06
6e+06
4e+06
ベルでの輻輳回避制御や再送制御が，うまく機能しない
2e+06
0
0
図 15
2
4
6
8
10
Time (s)
12
14
16
ATM とルータが混在する環境での測定結果 (シー
ケンス番号の推移)
る．結果を図
15，図 16に示す．
結果をみると，データ転送をしているコネクション
1 つしかなく，輻輳しない場合には，連続的で円滑な
データ転送が行われている．しかし 2 秒後，データ転送
をしているコネクションが 2 つに増えると，輻輳状態に
なり，スループットが極端に悪化している．2 つの転送
が
場合があると考えられる．
7.3
FDDI
17のような，論理的に同一の FDDI リング上にあ
るホストで，表 7に示す設定でデータ転送実験を行った．
その結果を図 18と図 19に示す．
結果から，データ転送をしているコネクションが N
図
本存在する場合，各々のスループットは，データリンク
の伝送速度の
1/N に近い値になることがわかる．また，
データ転送をしているコネクションの数が増えたり減っ
たりすると，それぞれのコネクションに割り当てられる
( 11 )
Vol. 14 No. 6 Nov. 1997
表7
FDDI の測定環境と設定
CPU
OS
MSS
TCP バッファサイズ
メッセージサイズ
データ転送時刻
送信回数
O
C
O
CN
N
O
C
N
11
WIDEバックボーンの一部
SGI INDY (R4600 100MHz)
IRIX R 5.3
4312octet
65535byte
8192byte
HOST1{HOST6: 0.00 秒
HOST2{HOST7: 0.50 秒
HOST3{HOST8: 1.00 秒
HOST4{HOST9: 1.00 秒
HOST5{HOST10: 1.50 秒
1000 回
東京
奈良
HOST1
1.5Mbps
1.5Mbps
奈良先端科学技術大学院大学
藤沢
HOST2
慶応湘南藤沢キャンパス
図 20
WAN での測定
9e+06
host1-host6 recv
host2-host7 recv
host3-host8 recv
host4-host9 recv
host5-host10 recv
8e+06
Sequence Number
7e+06
表8
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
図 18
0.5
1
1.5
2
Time (s)
2.5
3
3.5
4
WAN の測定環境と設定
CPU
SPARCstation(SUN)
OS
SunOS 4.1.3
MSS
536octet
TCP バッファサイズ実験 1:8196byte
実験 2:16384byte
コネクションの向き実験 1:HOST1(奈良) → HOST2(藤沢)
実験 2:HOST2(藤沢) → HOST1(奈良)
測定日時
実験 1:1996 年 2 月 9 日 16 時 10 分頃
実験 2:1996 年 2 月 3 日 19 時 40 分頃
メッセージサイズ
1024byte
その他
TCP DEBUG 機能を利用
FDDI での測定結果 (シーケンス番号の推移)
300000
90
Throughput (Mbps)
70
Sequence Number
80
send
recv
lost/rexmt
250000
host1-host6 recv
host2-host7 recv
host3-host8 recv
host4-host9 recv
host5-host10 recv
60
50
40
30
200000
150000
100000
50000
20
0
10
0
0
0
図 19
0.5
1
1.5
2
Time (s)
2.5
3
3.5
1/N に変化することもわかる．この実
験から，FDDI 上で TCP を利用すると，スループット
帯域が，素早く
が平等に割り当てられることが明らかになった．また，
れる．
10
15
Time (s)
20
25
30
4
図 21
WAN 実験 1 の測定結果 (シーケンス番号の推移
FDDI での測定結果 (スループットの変化)
FDDI は TCP と親和性が高いと考えら
このことから，
5
と喪失セグメント )
7.4
WAN
実際に運用している図 20のような専用線でつながれた
WAN で環境で，表 8の設定でデータ転送実験を行った．
実験 1 の結果を図 21，図 22，図 23に，実験 2 の結果
を図 24，図 25，図 26に示す．なお，実験 1 はセグメン
ト喪失率が 1%で，実験 2 はセグメント喪失率が 30%で
12
( 12 )
コンピュータソフトウェア
0.45
0.1
recv
0.4
0.08
Throughput (Mbps)
Throughput (Mbps)
0.35
0.3
0.25
0.2
0.15
0.07
0.06
0.05
0.04
0.03
0.1
0.02
0.05
0.01
0
0
0
図 22
recv
0.09
5
10
15
Time (s)
20
25
30
WAN 実験 1 の測定結果 (スループットの変化)
0
図 25
20
40
60
Time (s)
80
100
120
WAN 実験 2 の測定結果 (スループットの時間
変化)
10000
cwnd
ssthresh
8000
cwnd
ssthresh
8000
6000
6000
Size (byte)
Size (byte)
7000
4000
5000
4000
3000
2000
2000
0
1000
0
5
10
15
Time (s)
20
25
30
0
0
図 23
20
40
WAN 実験 1 の測定結果 (輻輳ウィンドウ
(cwnd) とスロースタート閾値 (ssthresh) の変化)
図 26
60
Time (s)
80
100
120
WAN 実験 2 の測定結果 (輻輳ウィンドウ
(cwnd) とスロースタート閾値 (ssthresh) の変化)
180000
スト的なデータ転送と，再送タイムアウトを繰り返すこ
send
recv
lost/rexmt
160000
とがわかる．それぞれバースト時のスループットは，実
Sequence Number
140000
1(図 22) では 100∼150Kbps，実験 2(図 25) では 20
∼30Kbps と読みとれる．また，図 21をみると，周期的
験
120000
100000
80000
にセグメントが複数個喪失していることがわかる．
60000
実験
40000
くなるにしたがってスループットが増加する傾向がみら
20000
0
0
図 24
20
40
60
Time (s)
80
100
120
WAN 実験 2 の測定結果 (シーケンス番号の推移
と喪失セグメント )
あった．
1 の図 22と図 23では，ウィンドウサイズが大き
TCP は輻輳状態になると，バー
それぞれの結果から，
れる．ウィンドウ拡大による送信量の制御はある程度う
2
まく働いていると考えられる．しかし，実験の図
図
25と
26からは，ウィンドウサイズによるスループットの変
化はほとんどわからない．
( 13 )
7.5
Vol. 14 No. 6 Nov. 1997
考察
13
べて機能の面で優れていることを明らかにした．また，
静止衛星による衛星回線では，ラウンドトリップ時間
TCP のスロースタート処理の影響で，ス
が長いため，
ループットが向上するまでにかなり時間がかかることが
わかった．また，輻輳時には輻輳ウィンドウがうまくコ
ントロールされず，利用されない無駄な帯域が多くなっ
たり，セグメントが喪失するタイミングによっては，ス
ループットが著しく不平等になることも明らかになった．
今後は，衛星回線の帯域を有効に利用し，かつ輻輳を
うまく抑制するための，効果的な輻輳ウィンドウ変更ア
ルゴリズムの検討や，選択確認応答
(SACK:Selective
Acknowledgment) [8] の有効性の調査，両方を考慮した
セグメントを送受信するたびに時刻を記録するという
DBS の処理が結果へ与える影響は小さく，DBS による
測定結果はほぼ妥当なものであることを示した．さらに，
Ethernet でつながれた 2 点間のホストという，単純な
ネットワーク上のデータ転送で，スループットが変化し
DBS によって明らかになり，スループッ
トの時間変化を測定する機能は，TCP の性能評価にとっ
て重要であることを示した．また，DBS を使って衛星
回線，ATM，FDDI，専用回線で構築されたネットワー
クで性能測定実験を行った．その結果，TCP の挙動に
ていることが
関して，既存の性能測定ツールでは明らかにできなかっ
制御について検討を行う必要がある．
た，より細かい評価や分析ができることを示した．この
機構がうまく動作せず，スループットが極端に悪かった．
ることが期待される．
ATM とルータが混在する環境では，TCP の輻輳回避
ATM の特徴である帯域制御
をしていない．ATM では ABR(Available Bit Rate)
などの帯域制御機構が提案されており，今後は TCP と
ABR の相性について測定する必要がある．
FDDI はセグメントが喪失せず，TCP との親和性が
高いという結果が得られた．しかし，FDDI ネットワー
ただし，今回の測定では
クをコンセントレータで多段に構築すると，トークンが
複数巡回してセグメントが喪失する場合がある．今後は
FDDI でセグメントが喪失するような環境で測定をする
必要がある．
WAN の測定では，輻輳時にバースト的なデータ転送
と，再送タイムアウトを繰り返すこと，セグメントが周
期的に複数個喪失することが観測された．また，喪失率
30%の環境下では，TCP のウィンドウ制御はあまり意
味をなさないことも明らかになった．これらは，TCP
にレート・フロー制御などの機能を組み込むことによっ
て，改善できる可能性がある．今後はその実装と実験が
望まれる．
8 まとめ
本稿では，複数のホストが接続された分散環境下で，
TCP の性能を評価する，TCP 性能評価システム DBS
の提案・構築について報告した．DBS の能力を確認す
るため，既存の性能測定ツールと機能や測定結果の比
較を行った．この結果から，
DBS は既存のツールと比
DBS の登場により，TCP の問題点が次々に明らかにな
今後は，
DBS による測定結果をより精密に分析し，
TCP の問題点を明らかにしていく予定である．さらに，
それらの問題点を克服する次世代の TCP を提案・実装
し，DBS で評価することを考えている．
謝辞
WIDE プロジェク
実験環境を提供してくださった，
( )
トならびに，株日本サテライトシステムズに感謝致し
ます．
A DBS の配布
本稿で説明した
いる．次の
DBS をフリーウェアとして配布して
URL から入手先できる．
<http://www.ai3.net/products/dbs/>
参考文献
[ 1 ] David D. Clark : Window and Acknowledgment
Strategy in TCP, RFC 813, (1982).
[ 2 ] David D. Clark: The Design Philosophy of the
DARPA Internet Protocols, Proc. SIGCOMM '88,
Computer Communication Review, Vol. 18, No. 4
(1988), pp. 106-114.
[ 3 ] D. Mills: Network Time Protocol version 2 specication and implementation, RFC 1119, 1989.
[ 4 ] Douglas E. Comer and John C. Lin: TCP Buering And Performance Over An ATM Network, Purdue Technical Report, CSD-TR 94-26, 1994.
[ 5 ] Hewlett-Packard Company: Netperf: A Network
Performance Benchmark Revision 2.1, Hew lett-
14
コンピュータソフトウェア
Packard Company, 1995.
[ 6 ] John Nagle: Congestion Control in IP/TCP Internetworks, RFC 896, January 1984.
[ 7 ] Jon Crowcroft, Ian Wakeman, Zheng Wang, and
Dejan Sirovica: Is Layering Harmful?, IEEE Network Magazine, Vol. 6, January 1992, pp. 20-24.
[ 8 ] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow: TCP Selective Acknowledgment Options,
RFC 2018, Oct 1996
[ 9 ] Roel Jonkman: Net Spec: A Network Performance Evaluation and Experimentation Tool,
http://www.tisl.ukans.edu/Projects/AAI/
products/netspec/, 1995
[10] Srinivasan Keshav: REAL: A Network Simu-
( 14 )
lator Computer Science Department Technical Re, University of California, December 1988
[11] T. Luckenbach, R. Ruppelt, F. Schulz: Performance Experiments within Local ATM Networks,
port
GMD-FOKUS(Berlin, D)
[12] Thomas Williams and Colin Kelley: GNUPLOT: An Interactive Plotting Program, 1993
[13] V. Jacobson and R. Braden and D. Borman:
TCP Extensions for High Performance, RFC 1323,
May 1992
[14] W. Stevens : TCP Slow Start, Congestion
Avoidance, Fast Retransmit, and Fast Recovery Algorithms, RFC2001, 1997.

Download Report