RFC2415 日本語訳
2415 Simulation Studies of Increased Initial TCP Window Size. K.Poduri, K. Nichols. September 1998. (Format: TXT=24205 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Poduri
Request for Comments: 2415 K. Nichols
Category: Informational Bay Networks
September 1998
Poduriがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2415年のK.ニコルズカテゴリ: 情報のベイネットワークス1998年9月
Simulation Studies of Increased Initial TCP Window Size
増加する初期のTCPウィンドウサイズのシミュレーション研究
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
An increase in the permissible initial window size of a TCP connection, from one segment to three or four segments, has been under discussion in the tcp-impl working group. This document covers some simulation studies of the effects of increasing the initial window size of TCP. Both long-lived TCP connections (file transfers) and short-lived web-browsing style connections were modeled. The simulations were performed using the publicly available ns-2 simulator and our custom models and files are also available.
tcp-implワーキンググループには1つのセグメントから3か4つのセグメントまでTCP接続の許されている初期のウィンドウサイズの増加は議論中でありました。 このドキュメントはTCPの初期のウィンドウサイズを増加させるという効果のいくつかのシミュレーション研究をカバーしています。 長命のTCP接続(ファイル転送)と短命なウェブ閲覧スタイル接続の両方がモデル化されました。 シミュレーションは公的に利用可能なナノ秒-2シミュレータを使用することで実行されました、そして、また、私たちの注文品を扱っているモデルとファイルも利用可能です。
1. Introduction
1. 序論
We present results from a set of simulations with increased TCP initial window (IW). The main objectives were to explore the conditions under which the larger IW was a "win" and to determine the effects, if any, the larger IW might have on other traffic flows using an IW of one segment.
私たちは増加するTCP初期の窓(IW)による1セットのシミュレーションから結果を提示します。 主な目標は、1つのセグメントのIWを使用することで、より大きいIWが「勝利」であった状態について調査して、もしあればより大きいIWが他の交通の流れに持っているかもしれない効果を決定することでした。
This study was inspired by discussions at the Munich IETF tcp-impl and tcp-sat meetings. A proposal to increase the IW size to about 4K bytes (4380 bytes in the case of 1460 byte segments) was discussed. Concerns about both the utility of the increase and its effect on other traffic were raised. Some studies were presented showing the positive effects of increased IW on individual connections, but no studies were shown with a wide variety of simultaneous traffic flows. It appeared that some of the questions being raised could be addressed in an ns-2 simulation. Early results from our simulations were previously posted to the tcp-impl mailing list and presented at the tcp-impl WG meeting at the December 1997 IETF.
この研究はミュンヘンIETF tcp-implとtcpによって座ったミーティングで議論で奮い立たせられました。 IWサイズをおよそ4Kのバイト(1460年のバイトのセグメントの場合における4380バイト)まで増加させるという提案について議論しました。 増加に関するユーティリティと他の交通へのその効果の両方に関する心配は高められました。 いくつかの研究が個々の接続への増加するIWの明白な効果を示していながら、発表されましたが、研究は全くさまざまな同時の交通の流れで示されませんでした。 ナノ秒-2シミュレーションで引き起こされる疑問のいくつかを記述できるだろうというように見えました。 私たちのシミュレーションからの早めの結果は、以前に、tcp-implメーリングリストに掲示されて、1997年12月のIETFのtcp-impl WGミーティングに提示されました。
Poduri & Nichols Informational [Page 1] RFC 2415 TCP Window Size September 1998
[1ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
2. Model and Assumptions
2. モデルと仮定
We simulated a network topology with a bottleneck link as shown:
私たちは示されるようにボトルネックリンクでネットワーク形態をシミュレートしました:
10Mb, 10Mb,
(all 4 links) (all 4 links)
10Mb、10Mb(すべての4個のリンク)(すべての4個のリンク)
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
C n2_________ ______ n6 S l n3_________\ /______ n7のeのiの\の1.5円のMb、50ms//r e n0------------------------ n1対n n4__________// \ \_____ n8e t n5__________/ \______ n9r s s
URLs --> <--- FTP & Web data
URL--><。--- FTPとウェブデータ
File downloading and web-browsing clients are attached to the nodes (n2-n5) on the left-hand side. These clients are served by the FTP and Web servers attached to the nodes (n6-n9) on the right-hand side. The links to and from those nodes are at 10 Mbps. The bottleneck link is between n1 and n0. All links are bi-directional, but only ACKs, SYNs, FINs, and URLs are flowing from left to right. Some simulations were also performed with data traffic flowing from right to left simultaneously, but it had no effect on the results.
ファイルのダウンロードとウェブ閲覧クライアントは左の方にノード(n2-n5)を付けられています。 これらのクライアントはサーバが右側の上のノード(n6-n9)に付けたFTPとウェブによって役立たれています。 ノードとそれらのノードからのリンクが10Mbpsにあります。 n1とn0の間には、ボトルネックリンクがあります。 すべてのリンクが双方向ですが、唯一のACKs、SYNs、FINs、およびURLは左から右まで流れています。 また、いくつかのシミュレーションが結果で効き目がなく実行されました。
In the simulations we assumed that all ftps transferred 1-MB files and that all web pages had exactly three embedded URLs. The web clients are browsing quite aggressively, requesting a new page after a random delay uniformly distributed between 1 and 5 seconds. This is not meant to realistically model a single user's web-browsing pattern, but to create a reasonably heavy traffic load whose individual tcp connections accurately reflect real web traffic. Some discussion of these models as used in earlier studies is available in references [3] and [4].
シミュレーションで、私たちはすべてのftpsが1MBのファイルを移して、すべてのウェブページにはまさに3つの埋め込まれたURLがあったと思いました。 ウェブクライアントは全く積極的にブラウズしています、無作為の遅れが一様に1〜5秒を分配した後に新しいページを要求して。 現実的にシングルユーザーのウェブ閲覧パターンをモデル化することが意味されるのではなく、これは、個々のtcp接続が正確に本当のウェブ・トラフィックを反映する合理的に重いトラヒック負荷を作成するために意味されます。 以前の研究で同じくらい中古のこれらのモデルの何らかの議論が参照[3]と[4]で利用可能です。
The maximum tcp window was set to 11 packets, maximum packet (or segment) size to 1460 bytes, and buffer sizes were set at 25 packets. (The ns-2 TCPs require setting window sizes and buffer sizes in number of packets. In our tcp-full code some of the internal parameters have been set to be byte-oriented, but external values must still be set in number of packets.) In our simulations, we varied the number of data segments sent into a new TCP connection (or initial window) from one to four, keeping all segments at 1460 bytes. A dropped packet causes a restart window of one segment to be used, just as in current practice.
最大のtcpの窓は11のパケットに設定されました、1460バイトまでの最大のパケット(または、セグメント)サイズ、そして、バッファサイズが25のパケットに設定されました。 (ナノ秒-2TCPsが、ウィンドウサイズとバッファサイズをパケットの数にはめ込むのを必要とします。 私たちのtcp完全なコードでは、内部のパラメタのいくつかがバイト指向であるように設定されましたが、パケットの数でまだ対外価値を設定しなければなりません。) 私たちのシミュレーションで、私たちは1〜4までの新しいTCP接続(または、初期の窓)に送られたデータ・セグメントの数を変えました、1460バイトですべてのセグメントを保って。 低下しているパケットで、ちょうど現在の習慣のように1つのセグメントの再開ウィンドウを使用します。
Poduri & Nichols Informational [Page 2] RFC 2415 TCP Window Size September 1998
[2ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
For ns-2 users: The tcp-full code was modified to use an
"application" class and three application client-server pairs were
written: a simple file transfer (ftp), a model of http1.0 style web
connection and a very rough model of http1.1 style web connection.
The required files and scripts for these simulations are available
under the contributed code section on the ns-simulator web page at
the sites ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} or http://www-
nrg.ee.lbl.gov/floyd/tcp_init_win.html.
ナノ秒-2人のユーザのために: tcp完全なコードは「アプリケーション」のクラスを使用するように変更されました、そして、3アプリケーションクライアント/サーバ組は書かれました: 簡単なファイル転送(ftp)、http1.0スタイルウェブ接続のモデル、およびhttp1.1の非常に荒いモデルはウェブ接続を流行に合わせます。 tar.Z、タールを塗るか、またはこれらのシミュレーションのための必要なファイルとスクリプトは遺跡 ftp://ftp.ee.lbl.gov/IW のナノ秒シミュレータウェブページの寄付されたコード部の下で利用可能です。 http://www- nrg.ee.lbl.gov/floyd/は_イニット_win.htmlをtcpします。
Simulations were run with 8, 16, 32 web clients and a number of ftp clients ranging from 0 to 3. The IW was varied from 1 to 4, though the 4-packet case lies beyond what is currently recommended. The figures of merit used were goodput, the median page delay seen by the web clients and the median file transfer delay seen by the ftp clients. The simulated run time was rather large, 360 seconds, to ensure an adequate sample. (Median values remained the same for simulations with larger run times and can be considered stable)
シミュレーションは8、16、32人のウェブクライアントと0〜3まで及ぶ多くのftpクライアントとの走行でした。 4パケットのケースが現在お勧めであることのことを超えてありましたが、IWは1〜4に変えられました。 使用される長所の数字はgoodput(ftpクライアントによって見られたウェブクライアントと中央のファイル転送遅れによって見られた中央のページ遅れ)でした。 シミュレートされたランタイムは、適切なサンプルを確実にするために360秒にかなり大きかったです。 (中央の値を、より大きいランタイムでシミュレーションに同じままで残っていて、安定していると考えることができます)
3. Results
3. 結果
In our simulations, we varied the number of file transfer clients in order to change the congestion of the link. Recall that our ftp clients continuously request 1 Mbyte transfers, so the link utilization is over 90% when even a single ftp client is present. When three file transfer clients are running simultaneously, the resultant congestion is somewhat pathological, making the values recorded stable. Though all connections use the same initial window, the effect of increasing the IW on a 1 Mbyte file transfer is not detectable, thus we focus on the web browsing connections. (In the tables, we use "webs" to indicate number of web clients and "ftps" to indicate the number of file transfer clients attached.) Table 1 shows the median delays experienced by the web transfers with an increase in the TCP IW. There is clearly an improvement in transfer delays for the web connections with increase in the IW, in many cases on the order of 30%. The steepness of the performance improvement going from an IW of 1 to an IW of 2 is mainly due to the distribution of files fetched by each URL (see references [1] and [2]); the median size of both primary and in-line URLs fits completely into two packets. If file distributions change, the shape of this curve may also change.
私たちのシミュレーションで、私たちは、リンクの混雑を変えるためにファイル転送クライアントの数を変えました。 独身のftpクライアントさえ出席しているとき、リンク利用が90%以上であるために私たちのftpクライアントが絶え間なく1メガバイトの転送を要求すると思い出してください。 3人のファイル転送クライアントが同時に走るとき、値を記録されたうまやにして、結果の混雑はいくらか病理学的です。 すべての接続が同じ初期の窓を使用しますが、IWを増加させるという1メガバイトのファイル転送への効果が検出可能でない、その結果、私たちはウェブ閲覧接続に焦点を合わせます。 (テーブルでは、私たちは添付のファイル転送クライアントの数を示すためにウェブクライアントと「ftps」の数を示すのに「ウェブ」を使用します。) テーブル1はTCP IWの増加があるウェブ転送で経験された中央の遅れを示しています。 IWの増加とのウェブ関係のための転送遅れには改良が明確にあります、多くの場合、30%の注文に関して。 1のIWから2のIWまで行く性能改良の急坂は主に各URLによってとって来られたファイルの分配のためです。(参照[1]と[2])を見てください。 第一の、そして、インラインの両方のURLの中央のサイズは2つのパケットに完全に収まります。 また、ファイル配が変化するなら、このカーブの形は変化するかもしれません。
Poduri & Nichols Informational [Page 3] RFC 2415 TCP Window Size September 1998
[3ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
Table 1. Median web page delay
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
#ウェブ#FTP IW=1 IW=2 IW=3 IW=4(%減)---------------------------------------------- 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
Table 2 shows the bottleneck link utilization and packet drop percentage of the same experiment. Packet drop rates did increase with IW, but in all cases except that of the single most pathological overload, the increase in drop percentage was less than 1%. A decrease in packet drop percentage is observed in some overloaded situations, specifically when ftp transfers consumed most of the link bandwidth and a large number of web transfers shared the remaining bandwidth of the link. In this case, the web transfers experience severe packet loss and some of the IW=4 web clients suffer multiple packet losses from the same window, resulting in longer recovery times than when there is a single packet loss in a window. During the recovery time, the connections are inactive which alleviates congestion and thus results in a decrease in the packet drop percentage. It should be noted that such observations were made only in extremely overloaded scenarios.
テーブル2は同じ実験のボトルネックリンク利用とパケット低下割合を示しています。 最も病理学的なオーバーロードでは、低下割合の増加が1%未満であったのを除いて、パケット低下率は、IWと共に増加しましたが、すべての場合で増加しました。 パケット低下割合の減少はいくつかの積みすぎられた状況で観測されます、特に、ftp転送がリンク帯域幅の大部分を消費して、多くのウェブ転送がリンクの残っている帯域幅を共有したとき。 この場合、ウェブ転送は厳しいパケット損失を経験します、そして、何人かのIW=4ウェブクライアントが同じ窓からの複数のパケット損失を受けます、単一のパケット損失が窓にある時より長い回復回をもたらして。 回復時間の間、接続は不活発です(パケット低下割合の減少で混雑とその結果結果を軽減します)。 非常に積みすぎられたシナリオだけでそのような観測をしたことに注意されるべきです。
Poduri & Nichols Informational [Page 4] RFC 2415 TCP Window Size September 1998
[4ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
Table 2. Link utilization and packet drop rates
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
割合リンク利用| パケット低下率#のウェブ#FTP 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
To get a more complete picture of performance, we computed the network power, goodput divided by median delay (in Mbytes/ms), and plotted it against IW for all scenarios. (Each scenario is uniquely identified by its number of webs and number of file transfers.) We plot these values in Figure 1 (in the pdf version), illustrating a general advantage to increasing IW. When a large number of web clients is combined with ftps, particularly multiple ftps, pathological cases result from the extreme congestion. In these cases, there appears to be no particular trend to the results of increasing the IW, in fact simulation results are not particularly stable.
私たちは、性能の、より完全な絵を得るために、ネットワークパワー、中央の遅れが割られたgoodput(Mbytes/msの)を計算して、すべてのシナリオのためにIWに対してそれを企みました。 (各シナリオはウェブの番号とファイル転送の数によって唯一特定されます。) 増加するIWの一般的な利点を例証して、私たちは図1(pdfバージョンの)のこれらの値をプロットします。 多くのウェブクライアントがftps、特に複数のftpsに結合されるとき、病理学的なケースは極端な混雑から生じます。 これらの場合では、IWを増加させるという結果へのどんな特定の傾向もあるように見えません、事実上、シミュレーションの結果が特に安定していません。
To get a clearer picture of what is happening across all the tested scenarios, we normalized the network power values for the non- pathological scenario by the network power for that scenario at IW of one. These results are plotted in Figure 2. As IW is increased from one to four, network power increased by at least 15%, even in a congested scenario dominated by bulk transfer traffic. In simulations where web traffic has a dominant share of the available bandwidth, the increase in network power was up to 60%.
何がすべてのテストされたシナリオの向こう側に起こるかに関する、より明確な絵を得るために、私たちは非病理学的なシナリオのために1のIWのそのシナリオのためのネットワークパワーでネットワークパワー値を正常にしました。 これらの結果は図2に記入されます。 IW1〜4に増えられるのに従って、ネットワークパワーは少なくとも15%増えました、バルク転送交通で支配された混雑しているシナリオでさえ。 ウェブ・トラフィックが利用可能な帯域幅の優位なシェアを持っているシミュレーションで、ネットワークパワーの増加は最大60%でした。
The increase in network power at higher initial window sizes is due to an increase in throughput and a decrease in the delay. Since the (slightly) increased drop rates were accompanied by better performance, drop rate is clearly not an indicator of user level performance.
より高い初期のウィンドウサイズにおけるネットワークパワーの増加はスループットの増加と遅れの減少のためです。 より良い性能で(わずかに)増加する低下率が伴われたので、低下率は明確にユーザレベル性能のインディケータではありません。
Poduri & Nichols Informational [Page 5] RFC 2415 TCP Window Size September 1998
[5ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
The gains in performance seen by the web clients need to be balanced against the performance the file transfers are seeing. We computed ftp network power and show this in Table 3. It appears that the improvement in network power seen by the web connections has negligible effect on the concurrent file transfers. It can be observed from the table that there is a small variation in the network power of file transfers with an increase in the size of IW but no particular trend can be seen. It can be concluded that the network power of file transfers essentially remained the same. However, it should be noted that a larger IW does allow web transfers to gain slightly more bandwidth than with a smaller IW. This could mean fewer bytes transferred for FTP applications or a slight decrease in network power as computed by us.
ウェブクライアントによって見られた性能における利得は、ファイル転送が見えている性能がに対してバランスをとる必要があります。 私たちは、ftpネットワークパワーを計算して、Table3にこれを示しています。 ウェブ接続によって見られたネットワークパワーにおける改良が同時発生のファイル転送にごくわずかな影響を持っているように見えます。 テーブルからIWのサイズの増加に伴うファイル転送のネットワークパワーの小さい変化があるのを観測できますが、どんな特定の傾向も見ることができません。 ファイル転送のネットワークパワーが本質的には同じままで残っていたと結論づけることができます。 しかしながら、より大きいIWがウェブ転送により小さいIWより多くの帯域幅をわずかに獲得させることに注意されるべきです。 これは私たちによって計算されるようにネットワークパワーにおけるFTPアプリケーションか微減のために移されたより少ないバイトを意味するかもしれません。
Table 3. Network power of file transfers with an increase in the TCP
IW size
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
#ウェブ#FTP 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
The above simulations all used http1.0 style web connections, thus, a natural question is to ask how results are affected by migration to http1.1. A rough model of this behavior was simulated by using one connection to send all of the information from both the primary URL and the three embedded, or in-line, URLs. Since the transfer size is now made up of four web files, the steep improvement in performance between an IW of 1 and an IW of two, noted in the previous results, has been smoothed. Results are shown in Tables 4 & 5 and Figs. 3 & 4. Occasionally an increase in IW from 3 to 4 decreases the network power owing to a non-increase or a slight decrease in the throughput. TCP connections opening up with a higher window size into a very congested network might experience some packet drops and consequently a slight decrease in the throughput. This indicates that increase of the initial window sizes to further higher values (>4) may not always result in a favorable network performance. This can be seen clearly in Figure 4 where the network power shows a decrease for the two highly congested cases.
上のシミュレーションはすべて、http1.0スタイルウェブ接続を使用しました、その結果、自然な質問が結果が移動でどう影響を受けるかをhttp1.1に招くことです。 この振舞いの荒いモデルは、第一のURLと3つの埋め込まれたか、またはインラインのURLの両方から情報のすべてを送るのに1つの接続を使用することによって、シミュレートされました。 転送サイズが現在4個のウェブファイルで補われるので、前の結果で注意した1のIWと2のIWの間の性能における急な改良は整えられました。 結果はTables4と5と図に示されます。 3 & 4. 時折、3〜4までのIWの増加は非増加かスループットの微減のためにネットワークパワーを減少させます。 より高いウィンドウサイズで非常に混雑しているネットワークに開くTCP接続はスループットのいくつかのパケット滴とその結果微減を経験するかもしれません。 これは、より高い値(>4)を促進する初期のウィンドウサイズの増加がいつも好ましいネットワーク性能をもたらすかもしれないというわけではないのを示します。 明確にネットワークパワーが、2のための減少がケースを非常に充血させたのを示す図4のこれを見られることができます。
Poduri & Nichols Informational [Page 6] RFC 2415 TCP Window Size September 1998
[6ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
Table 4. Median web page delay for http1.1
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
#ウェブ#FTP IW=1 IW=2 IW=3 IW=4(%減)---------------------------------------------- 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
Table 5. Network power of file transfers with an increase in the
TCP IW size
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
#ウェブ#FTP 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
For further insight, we returned to the http1.0 model and mixed some web-browsing connections with IWs of one with those using IWs of three. In this experiment, we first simulated a total of 16 web- browsing connections, all using IW of one. Then the clients were split into two groups of 8 each, one of which uses IW=1 and the other used IW=3.
さらなる洞察のために、私たちは、http1.0モデルに戻って、ものが3のIWsを使用している1のIWsに何人かのウェブ閲覧接続と交際しました。 この実験では、1のIWをすべて使用して、私たちは最初に、合計16のウェブブラウジング接続をシミュレートしました。 次に、クライアントは2つのそれぞれそれの1つがIW=1を使用する8人のグループに分けられました、そして、もう片方がIW=3を使用しました。
We repeated the simulations for a total of 32 and 64 web-browsing clients, splitting those into groups of 16 and 32 respectively. Table 6 shows these results. We report the goodput (in Mbytes), the web page delays (in milli seconds), the percent utilization of the link and the percent of packets dropped.
私たちは合計32と64人のウェブ閲覧クライアントのためにシミュレーションを繰り返しました、それぞれそれらを16と32人のグループに分けて。 テーブル6はこれらの結果を示しています。 私たちは、goodput(Mbytesの)、ウェブページ遅れ(ミリ秒で)、リンクのパーセント利用、およびパケットのパーセントが低下したと報告します。
Poduri & Nichols Informational [Page 7] RFC 2415 TCP Window Size September 1998
[7ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
Table 6. Results for half-and-half scenario
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 |
メディアンページ遅れとGoodput(MB)| リンク利用(%)と低下(%)#ウェブIW=1| IW=3| IW=1| IW=3 G.はdlyを置きます。| G. dlyを置いてください。| L.util低下| L.util低下------------------|-------------------|---------------|--------------- 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 |
Unsurprisingly, the non-split experiments are consistent with our earlier results, clients with IW=3 outperform clients with IW=1. The results of running the 8/8 and 16/16 splits show that running a mixture of IW=3 and IW=1 has no negative effect on the IW=1 conversations, while IW=3 conversations maintain their performance. However, the 32/32 split shows that web-browsing connections with IW=3 are adversely affected. We believe this is due to the pathological dynamics of this extremely congested scenario. Since embedded URLs open their connections simultaneously, very large number of TCP connections are arriving at the bottleneck link resulting in multiple packet losses for the IW=3 conversations. The myriad problems of this simultaneous opening strategy is, of course, part of the motivation for the development of http1.1.
当然ながら、非分裂実験が私たちの以前の結果と一致している、IW=3をもっているクライアントはIW=1をもっているクライアントより優れています。 8/8と16/16の股割りを走らせるという結果は、IW=3とIW=1の混合物を動かすのがIW=1の会話にマイナスの効果を全く持っていないのを示します、IW=3の会話は彼らの性能を維持しますが。 しかしながら、32/32分裂は、IW=3とのウェブ閲覧接続が悪影響を受けるのを示します。 私たちは、これがこの非常に混雑しているシナリオの病理学的な力学のためであると信じています。 埋め込まれたURLが同時に彼らの接続を開くので、非常に多くのTCP接続がIW=3の会話のための複数のパケット損失をもたらすボトルネックリンクに到着する予定です。 この同時の始まり戦略の無数の問題はもちろんhttp1.1の開発に関する動機の一部です。
4. Discussion
4. 議論
The indications from these results are that increasing the initial window size to 3 packets (or 4380 bytes) helps to improve perceived performance. Many further variations on these simulation scenarios are possible and we've made our simulation models and scripts available in order to facilitate others' experiments.
これらの結果からの指摘は初期のウィンドウサイズを3つのパケット(4380バイト)まで増加させるのが、知覚された性能を向上させるのを助けるということです。 これらのシミュレーションシナリオのさらなる多くの変化が可能です、そして、私たちは他のものの実験を容易にするためにシミュレーションモデルとスクリプトを利用可能にしました。
We also used the RED queue management included with ns-2 to perform some other simulation studies. We have not reported on those results here since we don't consider the studies complete. We found that by adding RED to the bottleneck link, we achieved similar performance gains (with an IW of 1) to those we found with increased IWs without RED. Others may wish to investigate this further.
また、ある他のシミュレーション研究を実行するためにナノ秒-2で待ち行列管理を含んでいて、私たちはREDを使用しました。 研究が完全であると考えないので、私たちはここでそれらの結果に関して報告していません。 私たちは、ボトルネックリンクにREDを加えることによって、同様の性能向上(1のIWと)を私たちがREDのない増加するIWsと共に見つけたものに獲得したのがわかりました。 他のものはさらにこれを調査したがっているかもしれません。
Although the simulation sets were run for a T1 link, several scenarios with varying levels of congestion and varying number of web and ftp clients were analyzed. It is reasonable to expect that the results would scale for links with higher bandwidth. However,
シミュレーションセットはT1リンクに経営されていましたが、異なったレベルの混雑があるいくつかのシナリオ、異なった数のウェブ、およびftpクライアントは分析されました。 結果が、より高い帯域幅とのリンクに比例すると予想するのは妥当です。 しかしながら
Poduri & Nichols Informational [Page 8] RFC 2415 TCP Window Size September 1998
[8ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
interested readers could investigate this aspect further.
興味のある読者はさらにこの局面を調査できました。
We also used the RED queue management included with ns-2 to perform some other simulation studies. We have not reported on those results here since we don't consider the studies complete. We found that by adding RED to the bottleneck link, we achieved similar performance gains (with an IW of 1) to those we found with increased IWs without RED. Others may wish to investigate this further.
また、ある他のシミュレーション研究を実行するためにナノ秒-2で待ち行列管理を含んでいて、私たちはREDを使用しました。 研究が完全であると考えないので、私たちはここでそれらの結果に関して報告していません。 私たちは、ボトルネックリンクにREDを加えることによって、同様の性能向上(1のIWと)を私たちがREDのない増加するIWsと共に見つけたものに獲得したのがわかりました。 他のものはさらにこれを調査したがっているかもしれません。
5. References
5. 参照
[1] B. Mah, "An Empirical Model of HTTP Network Traffic", Proceedings
of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
[1] B.Mah、「HTTPネットワークトラフィックの経験的モデル」、INFOCOM97年、神戸(日本)1997年4月7日〜11日の議事。
[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.
[2] C.R.クーニャ、A.Bestavros、M.E.Crovella、「WWWのクライアントベースの跡の特性」、ボストン大学コンピュータサイエンス技術報告書BU Cs95-010、1995年7月18日。
[3] K.M. Nichols and M. Laubach, "Tiers of Service for Data Access in
a HFC Architecture", Proceedings of SCTE Convergence Conference,
January, 1997.
[3] K.M.ニコルズとM.Laubach、「データのためのサービスの層はHFCで構造にアクセスします」、SCTE集合コンファレンスの議事、1997年1月。
[4] K.M. Nichols, "Improving Network Simulation with Feedback",
available from knichols@baynetworks.com
[4] 「フィードバックとのネットワーク・シミュレーションを改良し」て、 knichols@baynetworks.com から手があいているK.M.ニコルズ
6. Acknowledgements
6. 承認
This work benefited from discussions with and comments from Van Jacobson.
この仕事は、ヴァン・ジェーコブソンから議論の利益を得て、コメントしました。
7. Security Considerations
7. セキュリティ問題
This document discusses a simulation study of the effects of a proposed change to TCP. Consequently, there are no security considerations directly related to the document. There are also no known security considerations associated with the proposed change.
このドキュメントはTCPへの変更案の効果のシミュレーション研究について議論します。 その結果、直接ドキュメントに関連するセキュリティ問題が全くありません。 変更案に関連しているまた、知られていないセキュリティ問題があります。
Poduri & Nichols Informational [Page 9] RFC 2415 TCP Window Size September 1998
[9ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
8. Authors' Addresses
8. 作者のアドレス
Kedarnath Poduri Bay Networks 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185
Kedarnath Poduriベイネットワークス4401グレート・アメリカ公園道路SC01-04サンタクララ、カリフォルニア95052-8185
Phone: +1-408-495-2463 Fax: +1-408-495-1299 EMail: kpoduri@Baynetworks.com
以下に電話をしてください。 +1-408-495-2463 Fax: +1-408-495-1299 メールしてください: kpoduri@Baynetworks.com
Kathleen Nichols Bay Networks 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185
キャサリーンニコルズベイネットワークス4401グレート・アメリカ公園道路SC01-04サンタクララ、カリフォルニア95052-8185
EMail: knichols@baynetworks.com
メール: knichols@baynetworks.com
Poduri & Nichols Informational [Page 10] RFC 2415 TCP Window Size September 1998
[10ページ]RFC2415TCPウィンドウサイズ1998年9月の情報のPoduriとニコルズ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Poduri & Nichols Informational [Page 11]
PoduriとニコルズInformationalです。[11ページ]
一覧
スポンサーリンク
