TCP 実装の評価

図 5-6 に示す環境において，TCP テスタを用いて，多くのオペレーティングシステム

(OS)上のTCPモジュールにおける輻輳制御およびSACKのアルゴリズムの実装を評価し

た．今回実施した全ての試験は，送信側の振舞いを試験するものであったため，TCPテス タは受信側の端末として動作した．アプリケーションプログラムとしてttcpを使用し，被 試験システムから80キロバイトのデータを送信することとした．今回試験対象としたOS とそのバージョンは，SPARC Solaris 2.6(SACK パッチ付き)，Intel Solaris 8，Linux kernel 2.4.2，NetBSD 1.3.2(SACK付き，PSCが開発)，Windows 98 Second Editionで あった．TCPテスタと被試験システムの間にネットワークエミュレータを設置し，輻輳制 御アルゴリズムの動作が目で追えるように1秒の往復遅延を挿入し，以下に示す3つの試 験シナリオを実施した．

図 5-6 TCP実装評価の環境

5.5.1 輻輳制御アルゴリズムの評価

図 5-7は，輻輳制御アルゴリズムの一部であるcongestion avoidance[9]の実装を評価す る試験シナリオの例である．このシナリオにおいて，TCP テスタは，1～3 行目に記述さ れるように，5 つの ACK セグメントを送信し，新しい受信データを応答確認するまで，

通常のTCP通信に従った動作を行う．次に，テスタは，5行目に示すように，新しいデー タを応答確認する ACK セグメントを無視し，送信側の被試験システムに未確認の送信済 みのデータを再送させるように仕向ける．さらに，6 行目に示すように，再送されたデー タも無視し，同じデータを2度再送させる．このとき，送信側のTCPの内部変数ssthresh とcwndは，それぞれ2セグメント，1セグメント(ただし，1セグメントは最大セグメン ト長)となる．テスタは，8行目に示すように，snd_cwndに推定されたcwndの値を設定 する．9～13行目では，テスタは，slow startならびにcongestion avoidanceのアルゴリ ズムにおいてcwndの値を追跡する．9～10 行目に示すように，テスタが2つのACKセ グメントを送信するまではslow startアルゴリズムに従って内部変数snd_cwndを増加さ せる．そして，11～13 行目に示すように，次の 10 個の ACK セグメントについては，

congestino avoidanceアルゴリズムに従い，内部変数snd_cwndを増加させる．その後，

15行目に示すように，テスタはACKセグメントの送信を中止し，16行目に記述したよう

にsnd_cwndによって制限されたウインドウを違反する新しいデータセグメントの送信が

行われるかどうかを検査する．データセグメントの送信違反を検知したとき，試験判定結 果はFAILとなる．17行目に示すように，データの再送を検知したとき，試験判定結果は PASSとなる．

01: LOOP 5 {

02: output ack>snd_una ; transparent 03: }

04: SET {

05: ALWAYS output ack>snd_una ; ignore 06: input seq=snd_una ; ignore

07: }

08: ; set_val snd_cwnd=2*snd_mss

09: output ack>snd_una ; set_val snd_cwnd+=snd_mss 10: output ack>snd_una ; set_val snd_cwnd+=snd_mss 11: LOOP 10 {

12: output ack>snd_una ; set_val snd_cwnd+=(snd_mss*snd_mss)/snd_cwnd 13: }

14: SET {

15: ALWAYS output ack>snd_una ; ignore

16: ALWAYS input seq=snd_nxt snd_nxt-snd_una>snd_cwnd ; verdict FAIL 17: input seq<snd_nxt ; verdict PASS

18: }

図 5-7 輻輳制御アルゴリズムの試験シナリオの例

5.5.2 SACK におけるデータ送信手順の評価

SACK(Selective Acknowledgment)機能は，送信端末に紛失したパケットのシーケンス 番号の範囲を通知する．これは受信端末で保持している範囲と同じである．送信端末の TCPが再送アルゴリズムを最も効率よく実装していれば，理論的には全ての紛失パケット を1往復遅延時間以内に再送することが可能となる．SACKの送信端末の振舞いを実現す る手法として，pipeアルゴリズム[56]が提案されている．図 5-8に示す試験シナリオを用 いてSACK送信端末の実装を評価した．

このシナリオでは，1～3行目に示すように，TCP テスタはcwnd が十分に大きくなっ たときに，受信したパケットを1つ置きに無視する．6～8行目において，全ての再送デー タが一定時間以内に受信されるか否かを試験するため，タイマを往復遅延時間の2倍に設 定する．5行目に示すように，先にタイマが満了した場合，試験判定結果はFAILとなる．

01: input seq=35*snd_mss+1 ; set_timer rtt=2 02: input seq=37*snd_mss+1 ; ignore

03: input seq=39*snd_mss+1 ; ignore 04: SEQUENCE {

05: ALWAYS ex_timer rtt ; verdict FAIL 06: input seq=35*snd_mss+1 ; transparent 07: input seq=37*snd_mss+1 ; transparent 08: input seq=39*snd_mss+1 ; transparent 09: }

10: ; verdict PASS

図 5-8 SACK送信端末の実装評価の試験シナリオ

5.5.3 Duplicate SACK の実装評価

3つめの試験は，duplicate SACK[57]を受信した場合の送信端末の振舞いに関するもの

である．Duplicate SACKセグメントは，受信済みのシーケンス番号を持つTCPデータセ

グメントを再度受信したときに，受信端末によって送信される．duplicate SACK の機能 は比較的新しく仕様化されたため，本仕様に対応している実装は少ないと考えられる．図 5-9にduplicate SACKへの対応を試験する試験シナリオの例を示す．

このシナリオでは，1，3，5 行目に示すように，テスタは，cwnd が十分大きくなった ときに，1つ置きに受信したパケットを無視する．4，6行目に示すように，テスタは，SACK パラメータの値を変更することにより，通常の SACK セグメントの代わりに，2 つの duplicate SACKセグメントを送信する．7～12行目では，テスタは，送信済みのduplicate SACKセグメントが，duplicate ACKセグメントや，通常のSACKセグメントと異なって 扱われるか否かを確認する．9 行目に示すように，全ての ACK セグメントがネットワー ク上に送信されるわけではない．10行目に示すように，再送なしに１往復遅延時間が経過 すれば，試験判定結果はPASSとなる．また，11行目のように，1往復遅延時間内に再送 セグメントを受信すれば，試験判定結果はFAILとなる．

01: input seq=35*snd_mss+1 ; ignore

02: output ack=35*snd_mss+1 ; transparent 03: input seq=37*snd_mss+1 ; ignore

04: output ack=35*snd_mss+1 ; send seq=1 ack=35*snd_mss+1 sack=(1, snd_mss) 05: input seq=39*snd_mss+1 ; ignore

06: output ack=35*snd_mss+1 ; send seq=1 ack=35*snd_mss+1 sack=(1, snd_mss) 07: ; set_timer rtt=1

08: SET {

09: ALWAYS output ack=35*snd_mss+1 ; ignore 10: ex_timer rtt ; verdict PASS

11: input seq=snd_una ; verdict FAIL 12: }

図 5-9 duplicate SACKの実装評価の試験シナリオ

5.5.4 試験結果の要約

OS毎の3つの試験シナリオの試験判定結果を表 5-2に示す．本試験を通じて，以下の 事実と実装上の問題を確認した．

z Solaris 2.6とSolaris 8は，シナリオ１がFAILとなった．これらのOSでは，輻輳 制御アルゴリズムにおいて規定されているウインドウよりも多くのパケットを送信し ている．

z 全てのOSでの実装は，シナリオ2にPASSした．今回評価を行った全ての実装にお いて，紛失したデータを再送するとき，正しくSACKオプションを使用している．

z 本試験の通信結果ログを分析することにより，Linux，Solaris 2.6，Windows 98では，

輻輳制御アルゴリズム[9]に従わない独自の実装を行っていることが判明した．これら の実装では，3つのduplicate ACKを受信する前にウインドウサイズを拡大している ようである．さらに，LinuxはSACKセグメントを受信したときに他の実装よりも早 く，実際1つ目のduplicate ACKを受信したときに再送を行っている．

z Linux以外の実装はシナリオ3がFAILとなった．FAILとなった実装では，duplicate SACKを受信したときもウインドウサイズを拡大しているようであった．この振舞い は，pipeアルゴリズムに記述された理論に反する．NetBSDでは，ソースコードを確 認すると，dupilicate ACKを受信したときSACKオプションを参照することなく常 にpipe値を減少させていた．Solaris 2.6，Solaris 8，Windows 98でも，通信結果ロ グの傾向が同じであることから，同様の実装が行われているものと考えられる．一方，

Linuxではduplicate SACKを受信した際にはウインドウサイズの拡大は行っていな

かった．Linuxでは，ソースコードを参照すると，パケット単位のカウンタであるpipe 値は使用せず，未確認のセグメントのバイト数を管理している．

表 5-2 試験結果の要約