[要約] 要約：RFC 2415は、初期TCPウィンドウサイズの増加に関するシミュレーション研究についての報告です。 目的：このRFCの目的は、初期TCPウィンドウサイズの増加がネットワークのパフォーマンスに与える影響を評価し、その利点と制約を明らかにすることです。
Network Working Group K. Poduri
Request for Comments: 2415 K. Nichols
Category: Informational Bay Networks
September 1998
Simulation Studies of Increased Initial TCP Window Size
増加した初期TCPウィンドウサイズのシミュレーション研究
Status of this 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）The Internet Society（1998）。全著作権所有。
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接続の許容初期ウィンドウサイズを1セグメントから3または4セグメントに増やすことは、tcp-implワーキンググループで議論されています。このドキュメントでは、TCPの初期ウィンドウサイズを大きくした場合の影響に関するシミュレーション研究について説明します。存続期間の長いTCP接続（ファイル転送）と存続期間の短いWebブラウジングスタイルの接続の両方がモデル化されました。シミュレーションは、一般に入手可能なns-2シミュレーターを使用して実行され、カスタムモデルとカスタムファイルも使用できます。
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）を増やした一連のシミュレーションの結果を示します。主な目的は、大きいIWが「勝つ」条件を調査し、1つのセグメントの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-sat会議での議論に触発されました。 IWサイズを約4Kバイト（1460バイトのセグメントの場合は4380バイト）に増やす提案が議論されました。増加の効用と他のトラフィックへの影響の両方に対する懸念が提起されました。個々の接続に対するIWの増加のプラスの影響を示すいくつかの研究が発表されましたが、多種多様な同時トラフィックフローについての研究は示されていません。提起されている質問のいくつかは、ns-2シミュレーションで対処できるようです。シミュレーションの初期の結果は、以前にtcp-implメーリングリストに投稿され、1997年12月のIETFでのtcp-impl WGミーティングで発表されました。
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
URLs --> <--- FTP & Web data
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.
ファイルのダウンロードとWebブラウジングのクライアントは、左側のノード（n2-n5）に接続されています。これらのクライアントは、右側のノード（n6-n9）に接続されたFTPサーバーとWebサーバーによって処理されます。これらのノードとの間のリンクは10 Mbpsです。ボトルネックリンクはn1とn0の間です。すべてのリンクは双方向ですが、左から右に流れるのはACK、SYN、FIN、および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].
シミュレーションでは、すべてのftpが1 MBのファイルを転送し、すべてのWebページに正確に3つの埋め込みURLがあると想定しました。 Webクライアントは非常に積極的にブラウジングしており、ランダムな遅延が1〜5秒の間に均一に分散した後に新しいページを要求しています。これは、1人のユーザーのWebブラウジングパターンを現実的にモデル化するためのものではなく、個々のTCP接続が実際のWebトラフィックを正確に反映するかなり重いトラフィック負荷を作成するためのものです。以前の研究で使用されたこれらのモデルのいくつかの議論は、参考文献[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パケットに設定されています。 （ns-2 TCPでは、ウィンドウサイズとバッファーサイズをパケット数で設定する必要があります。tcp-fullコードでは、内部パラメーターの一部がバイト指向に設定されていますが、外部値はパケット数で設定する必要があります。 ）シミュレーションでは、すべてのセグメントを1460バイトに維持しながら、新しいTCP接続（または初期ウィンドウ）に送信されるデータセグメントの数を1から4に変更しました。ドロップされたパケットにより、現在の慣例と同様に、1つのセグメントの再起動ウィンドウが使用されます。
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.
ns-2ユーザーの場合：「アプリケーション」クラスを使用するようにtcp-fullコードが変更され、3つのアプリケーションクライアント/サーバーペアが作成されました。単純なファイル転送（ftp）、http1.0スタイルのWeb接続のモデル、およびhttp1.1スタイルのWeb接続の大まかなモデル。これらのシミュレーションに必要なファイルとスクリプトは、サイトftp://ftp.ee.lbl.gov/IW.{tar、tar.Z}またはhttp：/のns-simulator Webページの提供されたコードセクションにあります。 /www-nrg.ee.lbl.gov/floyd/tcp_init_win.html。
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のWebクライアントと0〜3の範囲の多数のFTPクライアントで実行されました。IWは1から4まで変化しましたが、4パケットのケースは現在推奨されているものを超えています。使用されたメリットの数値は、グッドプット、Webクライアントから見たページ遅延の中央値、FTPクライアントから見たファイル転送遅延の中央値でした。適切なサンプルを確保するために、シミュレーションの実行時間は360秒とかなり長くなりました。 （中央値は、実行時間が長いシミュレーションでも同じで、安定していると見なすことができます）
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クライアントは1 Mバイトの転送を継続的に要求するため、単一のftpクライアントが存在する場合でも、リンクの使用率は90％を超えます。 3つのファイル転送クライアントが同時に実行されている場合、結果として生じる輻輳はある程度病理的であり、記録された値が安定します。すべての接続で同じ初期ウィンドウを使用しますが、1 Mバイトのファイル転送でIWを増やす影響は検出されないため、Webブラウジング接続に焦点を合わせます。 （表では、「webs」を使用してWebクライアントの数を示し、「ftps」を使用して、接続されているファイル転送クライアントの数を示しています。表1は、TCP IWの増加に伴うWeb転送の遅延の中央値を示しています。 IWの増加に伴い、多くの場合30％程度のWeb接続の転送遅延が明らかに改善されています。 IWが1から2に変化する際のパフォーマンスの改善は、主に各URLによってフェッチされたファイルの分散によるものです（参照[1]および[2]を参照）。プライマリURLとインラインURLの両方の中央サイズは、2つのパケットに完全に適合します。ファイルの分布が変化すると、この曲線の形状も変化する可能性があります。
Table 1. Median web page delay
表1. Webページの遅延の中央値
#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
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は、同じ実験のボトルネックリンク使用率とパケットドロップ率を示しています。パケットドロップ率はIWとともに増加しましたが、単一の最も病理学的な過負荷を除くすべてのケースで、ドロップ率の増加は1％未満でした。パケットドロップの割合の減少は、特にFTP転送がリンク帯域幅のほとんどを消費し、多数のWeb転送がリンクの残りの帯域幅を共有した場合など、一部の過負荷状態で観察されます。この場合、Web転送で重大なパケット損失が発生し、一部のIW = 4 Webクライアントは同じウィンドウから複数のパケット損失を被るので、ウィンドウで単一のパケット損失がある場合よりも回復時間が長くなります。回復時間中、接続は非アクティブであり、これにより輻輳が緩和され、その結果、パケットドロップ率が低下します。このような観察は極端に過負荷のシナリオでのみ行われたことに注意してください。
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
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.
パフォーマンスをより完全に把握するために、ネットワークパワーを計算し、グッドプットを中央遅延（Mバイト/ミリ秒）で割って、すべてのシナリオでIWに対してプロットしました。 （各シナリオは、Webの数とファイル転送の数によって一意に識別されます。）これらの値を図1（pdfバージョン）にプロットし、IWを増やすことに対する一般的な利点を示します。多数のWebクライアントがFTP、特に複数のFTPと組み合わされている場合、極端な輻輳が原因で病理学的なケースが発生します。これらの場合、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%.
テストしたすべてのシナリオで何が起こっているかをより明確に把握するために、非病理的シナリオのネットワーク電力値を、IWが1であるそのシナリオのネットワーク電力で正規化しました。これらの結果を図2にプロットします。IWが1から4に増加すると、バルク転送トラフィックが支配する混雑したシナリオでも、ネットワーク電力は少なくとも15％増加します。 Webトラフィックが利用可能な帯域幅の支配的なシェアを持っているシミュレーションでは、ネットワーク電力の増加は最大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.
より高い初期ウィンドウサイズでのネットワークパワーの増加は、スループットの増加と遅延の減少によるものです。ドロップ率が（わずかに）高くなるとパフォーマンスが向上したため、ドロップ率は明らかにユーザーレベルのパフォーマンスを示すものではありません。
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.
Webクライアントから見たパフォーマンスの向上は、ファイル転送で見られるパフォーマンスとバランスを取る必要があります。 ftpネットワークパワーを計算し、これを表3に示しました。Web接続で見られるネットワークパワーの改善は、同時ファイル転送にほとんど影響を与えないようです。この表から、IWのサイズの増加に伴ってファイル転送のネットワーク能力に小さな変動があることがわかりますが、特定の傾向は見られません。ファイル転送のネットワーク能力は基本的に同じであると結論付けることができます。ただし、IWが大きいと、IWが小さい場合よりもWeb転送の帯域幅がわずかに増えることに注意してください。これは、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
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スタイルのWeb接続を使用したため、http1.1への移行によって結果がどのように影響を受けるかを問うのは自然な問題です。この動作の大まかなモデルは、1つの接続を使用して、プライマリURLと3つの埋め込みURL、つまりインラインURLの両方からすべての情報を送信することによってシミュレートされました。転送サイズは4つのWebファイルで構成されているため、IWが1と2の場合のパフォーマンスの急激な改善は、以前の結果で指摘されていたように、スムーズになりました。結果を表4＆5および図5に示します。 3および4。IWが3から4に増加すると、スループットが増加しないか、わずかに減少するため、ネットワーク電力が減少することがあります。非常に輻輳したネットワークへのウィンドウサイズを大きくしてTCP接続を開くと、いくつかのパケットドロップが発生し、その結果、スループットがわずかに低下する可能性があります。これは、初期ウィンドウサイズをさらに高い値（> 4）に増やしても、必ずしも良好なネットワークパフォーマンスが得られるとは限らないことを示しています。これは、ネットワークの電力が2つの非常に輻輳したケースで減少している図4ではっきりと見ることができます。
Table 4. Median web page delay for http1.1
表4. http 1.1の中央値のWebページ遅延
#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
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
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モデルに戻り、IWが1のWebブラウジング接続とIWが3を使用している接続を混在させました。この実験では、最初に合計1つのIWを使用して、合計16のWebブラウジング接続をシミュレートしました。次に、クライアントは8つずつの2つのグループに分割され、1つはIW = 1を使用し、もう1つは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のWebブラウジングクライアントに対してシミュレーションを繰り返し、それぞれを16と32のグループに分割しました。表6にこれらの結果を示します。グッドプット（Mバイト単位）、Webページの遅延（ミリ秒単位）、リンクの使用率、およびドロップされたパケットの割合を報告します。
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 |
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のWebブラウジング接続が悪影響を受けていることを示しています。これは、この非常に混雑したシナリオの病理学的ダイナミクスによるものと考えています。埋め込まれたURLは同時に接続を開くため、非常に多くのTCP接続がボトルネックリンクに到達し、IW = 3の会話で複数のパケット損失が発生します。この同時オープン戦略の無数の問題は、もちろん、http1.1を開発する動機の一部です。
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.
また、ns-2に含まれているREDキュー管理を使用して、他のシミュレーション研究を実行しました。調査が完了したとは考えていないため、ここではそれらの結果については報告していません。ボトルネックリンクにREDを追加することにより、REDなしでIWを増やした場合と同様のパフォーマンスの向上（IWが1）が得られることがわかりました。他の人はこれをさらに調査したいと思うかもしれません。
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, interested readers could investigate this aspect further.
シミュレーションセットはT1リンクに対して実行されましたが、さまざまなレベルの輻輳とさまざまな数のWebおよびFTPクライアントを使用するいくつかのシナリオが分析されました。帯域幅が広いリンクの場合、結果が拡大することを期待するのは妥当です。ただし、興味のある読者はこの側面をさらに調査することができます。
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.
また、ns-2に含まれているREDキュー管理を使用して、他のシミュレーション研究を実行しました。調査が完了したとは考えていないため、ここではそれらの結果については報告していません。ボトルネックリンクにREDを追加することにより、REDなしでIWを増やした場合と同様のパフォーマンスの向上（IWが1）が得られることがわかりました。他の人はこれをさらに調査したいと思うかもしれません。
[1] B. Mah, "An Empirical Model of HTTP Network Traffic", Proceedings of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
[1] B.マー、「HTTPネットワークトラフィックの実証モデル」、INFOCOM '97の議事録、神戸、日本、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. Cunha、A。Bestavros、M.E。Crovella、「Characteristics of WWW Client-based Traces」、ボストン大学コンピューターサイエンステクニカルレポートBU-CS-95-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. NicholsとM. Laubach、「HFCアーキテクチャでのデータアクセスのためのサービスの層」、1997年1月のSCTEコンバージェンス会議の議事録。
[4] K.M. Nichols, "Improving Network Simulation with Feedback", available from knichols@baynetworks.com
[4] K.M. Nichols、「フィードバックによるネットワークシミュレーションの改善」、knichols @ baynetworks.comから入手可能
This work benefited from discussions with and comments from Van Jacobson.
この作品は、ヴァンジェイコブソンとの議論とコメントから利益を得ました。
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に対する提案された変更の影響のシミュレーション研究について説明します。したがって、ドキュメントに直接関連するセキュリティ上の考慮事項はありません。提案された変更に関連する既知のセキュリティ上の考慮事項もありません。
Kedarnath Poduri Bay Networks 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185
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
Kathleen Nichols Bay Networks 4401 Great America Parkway SC01-04 Santa Clara、CA 95052-8185
EMail: knichols@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。