|
Network Working Group Request for Comments: 2415 Category: Informational |
K. Poduri K. Nichols Bay Networks September 1998 |
このドキュメントは、インターネット社会の為の情報を定義している。このメモは、いかなる種類のインターネット標準も規定しない。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
TCP コネクションの許された初期ウィンドウサイズを、1 セグメントから 3 か 4 セグメントに増やすことは、tcp-impl ワーキンググループで議論中である。このドキュメントは、TCP の初期ウィンドウサイズを増やす影響についてのシミュレーション研究を示している。長期生存 TCP コネクション (ファイル転送) と短期生存ウェッブブラウジングスタイルのコネクションの両方がモデルである。このシミュレーションは公に利用可能な ns-2 シミュレータを使用して実行した。我々のカスタムモデルとファイルは入手可能である。
Table of Contents
1. 導入
2. モデルと仮定
3. 結果
4. 議論
5. 参照
6. 謝辞
7. セキュリティの考慮
8. 作者のアドレス
完全なコピーライト宣言
増やされた TCP 初期ウィンドウ (IW) における 1 セットのシミュレーションの結果を提示する。その主目的は大きい IW が "勝る" 条件を調査し、もしあるなら大きい IW が 1 セグメントの IW を使用する他のトラフィックフローに対する影響を決定することである。
この研究はミュンヘン IETF tcp-impl と tcp-sat 会議での議論によって起こされた。IW サイズを約 4K バイト (1460 バイトのセグメントの場合に 4380 バイト) に増やす提案が議論された。増やす有効性と他のトラフィックに対する影響についての心配が上げられた。個々のコネクション上で増やされた IW の肯定的な影響を示す幾つかの研究が提示されたが、どの研究もシミュレーショントラフィックフローの多様性が示されていなかった。上げられている疑問点の幾つかは、ns-2 シミュレーションで取り組めるようであった。我々のシミュレーションから得られた初期の結果は、以前に tcp-impl メーリングリストに投稿され、1997/12 の IETF tcp-impl WG 会議に提示された。
以下のようなボトルネックを持つネットワークトポロジをシミュレートした。
10Mb, 10Mb,
(all 4 links) (all 4 links)
C n2_________ ______ n6 S
l n3_________\ /______ n7 e
i \\ 1.5Mb, 50ms // r
e n0 ------------------------ n1 v
n n4__________// \ \_____ n8 e
t n5__________/ \______ n9 r
s s
URLs --> <--- FTP & Web data
ファイルダウンロードとウェッブブラウジングを行うクライアントを、左側のノード (n2-n5) に接続する。これらのクライアントは、右側のノード (n6-n9) に接続された FTP と Web サーバによるサービスを受ける。それらのノードへ/からの回線は 10 Mbps である。ボトルネック回線は n1 と n0 間である。全ての回線は両方向であるが、ACK, SYN, FIN, URL だけが左から右へ流れる。右から左へ同時に流れるデータトラフィックを持つ幾つかのシミュレーションも実行されたが、結果には影響なかった。
シミュレーションでは、全ての ftp が 1 MB のファイルを転送し、全ての Web ページが正確に 3 つの埋め込み URL を持つと仮定した。Web クライアントは非常に積極的にブラウズし、1 〜 5 秒の間で均等に配分したランダムな遅延の後、新しいページを要求する。これは、単一ユーザの Web ブラウジングパターンを現実的にモデル化することは意図していないが、個々の TCP コネクションが正確に真の Web トラフィックを反映するような、重いトラフィック負荷を効果的に生み出すことを意図している。初期の研究で使用された時のこれらのモデルの議論は、[3] と [4] で参照できる。
最大 TCP ウィンドウは 11 パケットに設定され、最大パケット (あるいはセグメント) サイズは 1460 バイトに設定され、バッファサイズは 25 パケットで設定される。(ns-2 TCP はパケット数でウィンドウサイズとバッファサイズを設定する必要がある。TCP 全体のコードでは、幾つかの内部パラメタはバイト単位で設定されるが、外部パラメタはまだパケット数で設定しなければならない)。シミュレーションでは、全てのセグメントを 1460 バイトに保ちながら、新たな TCP コネクションに送信するデータセグメントの数 (あるいは初期ウィンドウ) を 1 から 4 に変化させる。欠損したパケットは、現在の試行と同様に 1 セグメントの再開ウィンドウを使用する。
ns-2 ユーザ: TCP コード全体は、"アプリケーション" クラスを使用するために修正され、3 つのアプリケーションクライアント-サーバのペア、簡単なファイル転送 (FTP)、HTTP1.0 スタイルのウェッブコネクションのモデル、HTTP1.1 スタイルウェッブコネクションの非常に大まかなモデルが記述される。これらのシミュレーションで必要なファイルとスクリプトは、ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} か http://www-nrg.ee.lbl.gov/floyd/tcp_init_win.html のサイトにある、ns シミュレータウェッブページで配布されたコードセクションから入手可能である。
シミュレーションは、8, 16, 32 個のウェッブクライアントと 0 〜 3 に及ぶ数多くの FTP クライアントで実行される。4 パケットのケースは現在の推奨を超えるが、IW は 1 〜 4 までの間で変化させる。用いられる有効な数字は転送量、ウェッブクライアントによって見られる平均ページ遅延、FTP クライアントに見られる平均ファイル転送遅延であった。シミュレートされた実行時間は、適切なサンプルを保証するためにかなり大きく、360 秒であった。(平均値はより大きい実行時間のシミュレーションでも同じであり、変化無いと考えられる)。
シミュレーションでは、回線の輻輳を変化させるためにファイル転送クライアントの数を変えた。FTP クライアントが継続的に 1M バイトの転送を要求することを思い出されたい。そのため、一つの FTP クライアントが提供された時でさえ、回線使用率が 90% を超える。三つのファイル転送が同時に実行される時、結果としての輻輳は病的であり、記録される値に変化はない。全てのコネクションは同じ初期ウィンドウを使用するが、1M バイトのファイル転送で IW を増やす影響が検知できない。従って、ウェッブブラウジングのコネクションに的を絞った。(表中では、"Webs" はウェッブクライアントの数を示すために使用し、"FTPs" は割り付けられたファイル転送クライアントの数を示すために使用する)。表 1 は、TCP IW を増やして、ウェッブ転送によって経験した平均遅延を示す。IW を増やしたウェッブコネクションの転送遅延に、多くのケースで 30% オーダの明白な改善がある。1 の IW から 2 の IW に変わる際の急激なパフォーマンス改善は、主に各々の URL によって取って来られるファイルの配分による (参照 [1] と [2] 参照)。最初の URL とインライン URL の両方の平均サイズは、完全に二個のパケットに収まる。もしファイルの配分が変わったら、このカーブの形も変わるかもしれない。
表 1 : 平均ウェッブページ遅延
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
(s) (% decrease)
----------------------------------------------
8 0 0.56 14.3 17.9 16.1
8 1 1.06 18.9 25.5 32.1
8 2 1.18 16.1 17.1 28.9
8 3 1.26 11.9 19.0 27.0
16 0 0.64 11.0 15.6 18.8
16 1 1.04 17.3 24.0 35.6
16 2 1.22 17.2 20.5 25.4
16 3 1.31 10.7 21.4 22.1
32 0 0.92 17.6 28.6 21.0
32 1 1.19 19.6 25.0 26.1
32 2 1.43 23.8 35.0 33.6
32 3 1.56 19.2 29.5 33.3
平均ウェッブページ遅延 グラフ→
表 2 は、同じ実験でのボトルネック回線使用率とパケット欠損率を示す。パケット欠損率は IW と共に増加したが、単一の最も病的な負荷のケースを除く全てのケースで、欠損率の増加は 1% 以下であった。幾つかの負荷状態で、特に FTP 転送が回線の帯域の大半を消費し、ウェッブ転送の大半が回線の残りの帯域を共有した時、パケット欠損率の減少が観測された。このケースでは、ウェッブ転送で幾つかのパケット消失を経験し、IW=4 のウェッブクライアントの幾つかは同じウィンドウから複数のパケット消失を被り、結果的に 1 ウィンドウで 1 つのパケット消失がある場合よりも長い回復時間がかかった。回復時間の間、コネクションは非活性となり輻輳を軽減する。従って結果的にパケット欠損率が減少した。それは、極めて負荷の高いシナリオでのみ観測されることに注意すべきである。
表 2 : 回線使用率とパケット欠損率
Percentage Link Utilization | Packet drop rate
#Webs #FTPs IW=1 IW=2 IW=3 IW=4 |IW=1 IW=2 IW=3 IW=4
-----------------------------------------------------------------------
8 0 34 37 38 39 | 0.0 0.0 0.0 0.0
8 1 95 92 93 92 | 0.6 1.2 1.4 1.3
8 2 98 97 97 96 | 1.8 2.3 2.3 2.7
8 3 98 98 98 98 | 2.6 3.0 3.5 3.5
-----------------------------------------------------------------------
16 0 67 69 69 67 | 0.1 0.5 0.8 1.0
16 1 96 95 93 92 | 2.1 2.6 2.9 2.9
16 2 98 98 97 96 | 3.5 3.6 4.2 4.5
16 3 99 99 98 98 | 4.5 4.7 5.2 4.9
-----------------------------------------------------------------------
32 0 92 87 85 84 | 0.1 0.5 0.8 1.0
32 1 98 97 96 96 | 2.1 2.6 2.9 2.9
32 2 99 99 98 98 | 3.5 3.6 4.2 4.5
32 3 100 99 99 98 | 9.3 8.4 7.7 7.6
より完全なパフォーマンスの状況を得るために、ネットワークパワーを算出し、全てのシナリオの転送量を平均遅延時間で割って (Mbyte/ms)、 IW に対して記入した。(各々のシナリオは、ウェッブの数とファイル転送の数によってユニークに識別される)。これらの値は (pdf 版の) 図 1 に記入してあり、IW を増やすことの一般的な利点を示している。非常に数多くのウェッブクライアントが FTP、特に複数の FTP、と一緒になる時、極端な輻輳のために病的な結果となる。これらのケースでは、IW を増やす結果としておこる特別な傾向は見られず、実際シミュレーションは特に安定性はない。
全ての試験されたシナリオに渡って何が起こっているか、より明確な状況を得るために、1 の IW におけるシナリオでのネットワークパワーによって、病的でないシナリオのネットワークパワー値を正常化した。これらの結果は図 2 に図示されている。IW は 1 から 4 に増えるので、巨大な転送に専有された輻輳シナリオでさえ、ネットワークパワーは少なくとも 15% 増加した。ウェッブトラフィックが利用可能な帯域を優勢的に共有するシミュレーションでは、ネットワークバワーの増加は最大 60% である。
大きい初期ウィンドウサイズにおけるネットワークパワーの増加は、スループットの増加と遅延の減少による。より良いパフォーマンスに (わずかに) 増加した欠損率が伴うので、欠損率は明確にはユーザレベルのパフォーマンスの指標にはならない。
ウェッブクライアントに見られるパフォーマンスの増加は、ファイル転送に見られるパフォーマンスと比較する必要がある。FTP ネットワークパワーを算出し、表 3 にこれを示す。ウェッブコネクションに見られるネットワークの改善は、同時にファイル転送を行った場合、ごくわずかな効果であるように見える。IW のサイズを増やしたファイル転送のネットワークパワーのバリエーションが小さいことが観察できるが、それ以外に特に傾向は見られない。ファイル転送のネットワークパワーは本質的に同じままであると結論付けられる。しかし、大きい IW によって、ウェッブ転送において小さい IW よりも、わずかながらより多く帯域増やすことができることに注意すべきである。これは、FTP アプリケーションで転送されたバイトがより少なくなり、我々が算出したネットワークパワーがわずかに軽減したことを意味し得る。
表 3 : TCP IW サイズを増加させたファイル転送のネットワークパワー
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
--------------------------------------------
8 1 4.7 4.2 4.2 4.2
8 2 3.0 2.8 3.0 2.8
8 3 2.2 2.2 2.2 2.2
16 1 2.3 2.4 2.4 2.5
16 2 1.8 2.0 1.8 1.9
16 3 1.4 1.6 1.5 1.7
32 1 0.7 0.9 1.3 0.9
32 2 0.8 1.0 1.3 1.1
32 3 0.7 1.0 1.2 1.0
ネットワークパワー グラフ→
上記のシミュレーションは、全て HTTP1.0 スタイルのウェッブコネクションを使用した。従って HTTP1.1 に移行することによって、どのような影響が結果的に発生するかという当然の質問が尋ねられる。この動作の大雑把なモデルが、最初の URL と三つの埋め込み、あるいはインライン URL の両方から全ての情報を送信するための 1 本のコネクションを使用することによってシミュレートされた。転送サイズは 4 つのウェッブファイルから構成されるので、前の結果で示された、1 の IW と 2 の IW の間のパフォーマンスにおける改善の勾配は滑らかであった。結果は表 4 & 5 と図 3 & 4 に示される。たまたま IW が 3 から 4 に増加したことにより、スループットが増加しないか、わずかに減少したためにネットワークパワーが減少した。非常に輻輳されたネットワークに高いウィンドウで開設する TCP コネクションは、幾つかのパケット欠損を経験し、最終的にスループットがわずかに減少する。これは、初期ウィンドウサイズが更に高い値 (>4) に増加することが、常に望ましいネットワークパフォーマンスを結果的に生み出すわけではないかもしれないことを示す。これは、ネットワークパワーが二つの高い輻輳ケースでの減少を示す図 4 で、明確に見ることができる。
表 4 : HTTP1.1 における平均ウェッブ遅延
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
(s) (% decrease)
----------------------------------------------
8 0 0.47 14.9 19.1 21.3
8 1 0.84 17.9 19.0 25.0
8 2 0.99 11.5 17.3 23.0
8 3 1.04 12.1 20.2 28.3
16 0 0.54 07.4 14.8 20.4
16 1 0.89 14.6 21.3 27.0
16 2 1.02 14.7 19.6 25.5
16 3 1.11 09.0 17.0 18.9
32 0 0.94 16.0 29.8 36.2
32 1 1.23 12.2 28.5 21.1
32 2 1.39 06.5 13.7 12.2
32 3 1.46 04.0 11.0 15.0
HTTP1.1 における平均ウェッブ遅延 グラフ→
表 5 : TCP IW サイズを増加させたファイル転送のネットワークパワー
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
--------------------------------------------
8 1 4.2 4.2 4.2 3.7
8 2 2.7 2.5 2.6 2.3
8 3 2.1 1.9 2.0 2.0
16 1 1.8 1.8 1.5 1.4
16 2 1.5 1.2 1.1 1.5
16 3 1.0 1.0 1.0 1.0
32 1 0.3 0.3 0.5 0.3
32 2 0.4 0.3 0.4 0.4
32 3 0.4 0.3 0.4 0.5
ネットワークパワー グラフ→
更に洞察するために、我々は HTTP1.0 モデルに戻し、幾つかの 1 の IW を持つウェッブブラウジングコネクションを 3 の IW を持つものと混在させた。この実験では、まず始めに全て 1 の IW を使用する 16 個のウェッブブラウジングコネクションの総計をシミュレートした。その後、クライアントを 8 個ずつのグループに分け、一方は IW=1 を使用し、もう一方は IW=3 を使用した。
32 個と 64 個のウェッブブラウジングクライアントの総計によるシミュレーションを繰り返し、それらをそれぞれ 16 と 32 のグループに分けた。表 6 は、これらの結果を示す。転送量 (Mbyte単位)、ウェッブページ遅延 (ミリ秒単位)、回線使用率、パケット欠損率を示す。
表 6 : 半々シナリオの結果
Median Page Delays and Goodput (MB) | Link Utilization (%) & Drops (%)
#Webs IW=1 | IW=3 | IW=1 | IW=3
G.put dly | G.put dly | L.util Drops| L.util Drops
------------------|-------------------|---------------|---------------
16 35.5 0.64| 36.4 0.54 | 67 0.1 | 69 0.7
8/8 16.9 0.67| 18.9 0.52 | 68 0.5 |
------------------|-------------------|---------------|---------------
32 48.9 0.91| 44.7 0.68 | 92 3.5 | 85 4.3
16/16 22.8 0.94| 22.9 0.71 | 89 4.6 |
------------------|-------------------|---------------|----------------
64 51.9 1.50| 47.6 0.86 | 98 13.0 | 91 8.6
32/32 29.0 1.40| 22.0 1.20 | 98 12.0 |
予想通り、分けていない方の実験は前の結果と矛盾無く、IW=3 のクライアントが IW=1 のクライアントを凌いでいる。IW=3 と IW=1 の混在で実行している 8/8 と 16/16 に分けた方は、IW=1 の会話に悪影響を及ぼしてはおらず、IW=3 の会話はそのパフォーマンスを維持している。しかし 32/32 に分けた方は、IW=3 のウェッブブラウジングコネクションが反対に影響していることを示している。これは、この極めて輻輳したシナリオの病的な力学によるものだと信じている。埋め込み URL はコネクションを同時にオープンするので、大量の TCPコネクションが、IW=3 の会話における複数のパケット消失を結果として引き起こすボトルネック回線に到着する。この同時オープン方法による無数の問題は、もちろん HTTP1.1 を開発する動機の一部である。
これらの結果から示されるものは、初期ウィンドウサイズを 3 パケット (4380 バイト) に増やすことは、認識されるパフォーマンスの改善を助けるということである。これらのシミュレーションシナリオに対して更に多くのバリエーションがありえ、他の環境で利用するために入手可能なシミュレーションモデルとスクリプトを作成した。
他の幾つかのシミュレーション研究を実現するために、ns-2 に含まれる RED キュー管理も使用した。完全な研究を考慮していないので、それらの結果はここには報告していない。ボトルネック回線に RED を追加することによって、RED 無しで IW を増加させた時と同様のパフォーマンス増加 (1 の IW において) が達成されることが分かった。他の人は、これを更に調査したいと思うかもしれない。
シミュレーションセットは T1 回線で実行されたが、輻輳のレベルを変化させたり、ウェッブや FTP クライアントの個数を変化させる幾つかのシナリオが解析された。高帯域回線に対して結果の調整を期待することは効率的である。しかし興味のある読者は、この面を更に調査してもよいだろう。
[1] B. Mah, "An Empirical Model of HTTP Network Traffic", Proceedings of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
[2] C.R. Cunha, A. Bestavros, M.E. Crovella, "Characteristics of WWW Client-based Traces", Boston University Computer Science Technical Report BU-CS-95-010, July 18, 1995.
[3] K.M. Nichols and M. Laubach, "Tiers of Service for Data Access in a HFC Architecture", Proceedings of SCTE Convergence Conference, January, 1997.
[4] K.M. Nichols, "Improving Network Simulation with Feedback", available from knichols@baynetworks.com
この作業は、Van Jacobson との議論やコメントのおかげである。
このドキュメントは、TCP に提案された変更の影響のシミュレーション調査について論じている。従って、このドキュメントに直接関係するセキュリティの考慮は無い。提案された変更に関連する既知のセキュリティ考慮も無い。
Kedarnath Poduri Bay Networks 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185 Phone: +1-408-495-2463 Fax: +1-408-495-1299 EMail: kpoduri@Baynetworks.com Kathleen Nichols Bay Networks 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185 EMail: knichols@baynetworks.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
(このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説明したり、実装を援助するといった派生作業を準備、コピー、出版、配布してもよい。しかし、このドキュメント自身は、インターネット標準プロセスで定義された手続きに従わなければならず、インターネット標準を開発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合を除いて、コピーライト記述やインターネット社会、他のインターネット組織への参照等を、如何なる方法でも修正してはならない。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や割当て者によって無効にされることはないだろう。)
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
