[要約] RFC 2414は、TCPの初期ウィンドウサイズを増やすための提案です。その目的は、ネットワークの効率性とパフォーマンスを向上させることです。
Network Working Group M. Allman
Request for Comments: 2414 NASA Lewis/Sterling Software
Category: Experimental S. Floyd
LBNL
C. Partridge
BBN Technologies
September 1998
Increasing TCP's Initial Window
TCPの初期ウィンドウを増やす
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP.
このドキュメントでは、TCPの許可された初期ウィンドウが1つのセグメントから約4Kバイトに増加することを指定しています。このドキュメントでは、このような変更の利点と欠点について説明し、TCPへのこのような変更のコストと利点を示す実験結果の概要を示します。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document specifies an increase in the permitted upper bound for TCP's initial window from one segment to between two and four segments. In most cases, this change results in an upper bound on the initial window of roughly 4K bytes (although given a large segment size, the permitted initial window of two segments could be significantly larger than 4K bytes). The upper bound for the initial window is given more precisely in (1):
このドキュメントでは、TCPの初期ウィンドウの許容上限を1つのセグメントから2〜4つのセグメントに増やすことを指定しています。ほとんどの場合、この変更により、初期ウィンドウの上限は約4Kバイトになります（セグメントサイズが大きい場合、2つのセグメントの許可された初期ウィンドウは4Kバイトよりも大幅に大きくなる可能性があります）。初期ウィンドウの上限は、より正確に（1）で指定されます。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
最小（4 * MSS、最大（2 * MSS、4380バイト））（1）
Equivalently, the upper bound for the initial window size is based on the maximum segment size (MSS), as follows:
同様に、初期ウィンドウサイズの上限は、次のように最大セグメントサイズ（MSS）に基づいています。
If (MSS <= 1095 bytes)
then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes)
then win <= 4380;
If (2190 bytes <= MSS)
then win <= 2 * MSS;
This increased initial window is optional: that a TCP MAY start with a larger initial window, not that it SHOULD.
この増加した初期ウィンドウはオプションです。つまり、TCPはより大きな初期ウィンドウで開始する場合があり、SHOULDではありません。
This upper bound for the initial window size represents a change from RFC 2001 [S97], which specifies that the congestion window be initialized to one segment. If implementation experience proves successful, then the intent is for this change to be incorporated into a revision to RFC 2001.
この初期ウィンドウサイズの上限は、輻輳ウィンドウを1つのセグメントに初期化することを指定するRFC 2001 [S97]からの変更を表しています。実装の経験が成功した場合は、この変更をRFC 2001の改訂に組み込むことを目的としています。
This change applies to the initial window of the connection in the first round trip time (RTT) of transmission following the TCP three-way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in the three-way handshake should increase the initial window size above that outlined in equation (1). If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment.
この変更は、TCP 3ウェイハンドシェイクに続く伝送の最初のラウンドトリップ時間（RTT）における接続の初期ウィンドウに適用されます。 3ウェイハンドシェイクでのSYN / ACKもその確認応答（ACK）も、初期ウィンドウサイズを式（1）で概説したサイズより大きくすることはできません。 SYNまたはSYN / ACKが失われた場合、正しく送信されたSYNの後に送信者が使用する初期ウィンドウは1つのセグメントでなければなりません。
TCP implementations use slow start in as many as three different ways: (1) to start a new connection (the initial window); (2) to restart a transmission after a long idle period (the restart window); and (3) to restart after a retransmit timeout (the loss window). The change proposed in this document affects the value of the initial window. Optionally, a TCP MAY set the restart window to the minimum of the value used for the initial window and the current value of cwnd (in other words, using a larger value for the restart window should never increase the size of cwnd). These changes do NOT change the loss window, which must remain 1 segment (to permit the lowest possible window size in the case of severe congestion).
TCP実装は、3つの異なる方法でスロースタートを使用します。（1）新しい接続を開始する（初期ウィンドウ）。 （2）長いアイドル期間の後に送信を再開する（再開ウィンドウ）。 （3）再送信タイムアウト（損失ウィンドウ）後に再起動する。このドキュメントで提案されている変更は、初期ウィンドウの値に影響します。オプションで、TCPは再起動ウィンドウを初期ウィンドウに使用される値と現在のcwndの値の最小値に設定できます（つまり、再起動ウィンドウに大きな値を使用しても、cwndのサイズが大きくなることはありません）。これらの変更は、1セグメントのままでなければならない損失ウィンドウを変更しません（深刻な輻輳の場合に可能な限り最小のウィンドウサイズを許可するため）。
When larger initial windows are implemented along with Path MTU Discovery [MD90], and the MSS being used is found to be too large, the congestion window `cwnd' SHOULD be reduced to prevent large bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced by the ratio of the old segment size to the new segment size.
より大きな初期ウィンドウがPath MTU Discovery [MD90]とともに実装され、使用されているMSSが大きすぎることが判明した場合、輻輳ウィンドウ「cwnd」を小さくして、小さなセグメントの大きなバーストを防ぐ必要があります。具体的には、「cwnd」は、古いセグメントサイズと新しいセグメントサイズの比率で減らす必要があります。
When larger initial windows are implemented along with Path MTU Discovery [MD90], alternatives are to set the "Don't Fragment" (DF) bit in all segments in the initial window, or to set the "Don't Fragment" (DF) bit in one of the segments. It is an open question which of these two alternatives is best; we would hope that implementation experiences will shed light on this. In the first case of setting the DF bit in all segments, if the initial packets are too large, then all of the initial packets will be dropped in the network. In the second case of setting the DF bit in only one segment, if the initial packets are too large, then all but one of the initial packets will be fragmented in the network. When the second case is followed, setting the DF bit in the last segment in the initial window provides the least chance for needless retransmissions when the initial segment size is found to be too large, because it minimizes the chances of duplicate ACKs triggering a Fast Retransmit. However, more attention needs to be paid to the interaction between larger initial windows and Path MTU Discovery.
より大きな初期ウィンドウがパスMTUディスカバリ[MD90]とともに実装されている場合、代替方法は、初期ウィンドウのすべてのセグメントに「フラグメントしない」（DF）ビットを設定するか、「フラグメントしない」（DF ）セグメントの1つのビット。これらの2つの選択肢のどちらが最適かは未解決の問題です。実装の経験がこれに光を当てることを願っています。すべてのセグメントでDFビットを設定する最初のケースでは、初期パケットが大きすぎると、すべての初期パケットがネットワークでドロップされます。 1つのセグメントのみにDFビットを設定する2番目のケースでは、最初のパケットが大きすぎる場合、最初のパケットの1つを除くすべてがネットワークでフラグメント化されます。 2番目のケースが続く場合、初期ウィンドウの最後のセグメントでDFビットを設定すると、初期セグメントサイズが大きすぎることが判明したときに、不要な再送信の可能性が最も低くなります。これにより、重複ACKが高速再送信をトリガーする可能性が最小限に抑えられます。 。ただし、より大きな初期ウィンドウとパスMTUディスカバリーの間の相互作用にもっと注意を払う必要があります。
The larger initial window proposed in this document is not intended as an encouragement for web browsers to open multiple simultaneous TCP connections all with large initial windows. When web browsers open simultaneous TCP connections to the same destination, this works against TCP's congestion control mechanisms [FF98], regardless of the size of the initial window. Combining this behavior with larger initial windows further increases the unfairness to other traffic in the network.
このドキュメントで提案されているより大きな初期ウィンドウは、すべてが大きな初期ウィンドウで複数の同時TCP接続を開くことをWebブラウザーに推奨するものではありません。 Webブラウザーが同じ宛先への同時TCP接続を開く場合、これは、初期ウィンドウのサイズに関係なく、TCPの輻輳制御メカニズム[FF98]に対して機能します。この動作と大きな初期ウィンドウを組み合わせると、ネットワーク内の他のトラフィックへの不公平がさらに高まります。
1. When the initial window is one segment, a receiver employing delayed ACKs [Bra89] is forced to wait for a timeout before generating an ACK. With an initial window of at least two segments, the receiver will generate an ACK after the second data segment arrives. This eliminates the wait on the timeout (often up to 200 msec).
1. 初期ウィンドウが1セグメントの場合、遅延ACK [Bra89]を使用する受信機は、ACKを生成する前に強制的にタイムアウトを待機します。少なくとも2つのセグメントの初期ウィンドウでは、受信者は2番目のデータセグメントが到着した後にACKを生成します。これにより、タイムアウトの待機がなくなります（多くの場合、最大200ミリ秒）。
2. For connections transmitting only a small amount of data, a larger initial window reduces the transmission time (assuming at most moderate segment drop rates). For many email (SMTP [Pos82]) and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less than 4K bytes, the larger initial window would reduce the data transfer time to a single RTT.
2. 少量のデータのみを送信する接続の場合、初期ウィンドウを大きくすると、送信時間が短縮されます（ほとんどの場合、セグメントのドロップ率は中程度と想定）。 4Kバイト未満の多くの電子メール（SMTP [Pos82]）およびWebページ（HTTP [BLFN96、FJGFBL97]）の転送では、初期ウィンドウが大きいと、データ転送時間が1つのRTTに短縮されます。
3. For connections that will be able to use large congestion windows, this modification eliminates up to three RTTs and a delayed ACK timeout during the initial slow-start phase. This would be of particular benefit for high-bandwidth large-propagation-delay TCP connections, such as those over satellite links.
3.大きな輻輳ウィンドウを使用できる接続の場合、この変更により、最初のスロースタートフェーズ中に最大3つのRTTと遅延ACKタイムアウトが排除されます。これは、衛星リンクを介した接続など、高帯域幅で大きな伝播遅延のあるTCP接続に特に役立ちます。
4. Disadvantages of Larger Initial Windows for the Individual Connection
4. 個々の接続のための大きな初期ウィンドウの短所
In high-congestion environments, particularly for routers that have a bias against bursty traffic (as in the typical Drop Tail router queues), a TCP connection can sometimes be better off starting with an initial window of one segment. There are scenarios where a TCP connection slow-starting from an initial window of one segment might not have segments dropped, while a TCP connection starting with an initial window of four segments might experience unnecessary retransmits due to the inability of the router to handle small bursts. This could result in an unnecessary retransmit timeout. For a large-window connection that is able to recover without a retransmit timeout, this could result in an unnecessarily-early transition from the slow-start to the congestion-avoidance phase of the window increase algorithm. These premature segment drops are unlikely to occur in uncongested networks with sufficient buffering or in moderately-congested networks where the congested router uses active queue management (such as Random Early Detection [FJ93, RFC2309]).
輻輳が激しい環境では、特にバースト性のトラフィックに対してバイアスをかけるルーター（通常のドロップテールルーターキューなど）の場合、TCP接続は、1つのセグメントの初期ウィンドウから開始する方がよい場合があります。 1つのセグメントの初期ウィンドウからスロースタートするTCP接続ではセグメントがドロップされない場合がありますが、4つのセグメントの初期ウィンドウで開始されるTCP接続では、ルーターが小さなバーストを処理できないために不要な再送信が発生する場合があります。 。これにより、不必要な再送信タイムアウトが発生する可能性があります。再送タイムアウトなしで回復できる大きなウィンドウの接続の場合、これにより、ウィンドウ増加アルゴリズムのスロースタートから輻輳回避フェーズに不必要に早く移行する可能性があります。これらの早期セグメントドロップは、十分なバッファリングがある非輻輳ネットワーク、または輻輳ルータがアクティブキュー管理を使用する中程度に輻輳したネットワーク（ランダム早期検出[FJ93、RFC2309]など）では発生しそうにありません。
Some TCP connections will receive better performance with the higher initial window even if the burstiness of the initial window results in premature segment drops. This will be true if (1) the TCP connection recovers from the segment drop without a retransmit timeout, and (2) the TCP connection is ultimately limited to a small congestion window by either network congestion or by the receiver's advertised window.
一部のTCP接続では、初期ウィンドウのバースト性により早期のセグメントドロップが発生した場合でも、初期ウィンドウが大きいほどパフォーマンスが向上します。これは、（1）TCP接続が再送タイムアウトなしでセグメントのドロップから回復し、（2）TCP接続が最終的に、ネットワークの輻輳または受信側のアドバタイズされたウィンドウのいずれかによって小さな輻輳ウィンドウに制限されている場合に当てはまります。
In terms of the potential for congestion collapse, we consider two separate potential dangers for the network. The first danger would be a scenario where a large number of segments on congested links were duplicate segments that had already been received at the receiver. The second danger would be a scenario where a large number of segments on congested links were segments that would be dropped later in the network before reaching their final destination.
輻輳の崩壊の可能性に関して、ネットワークには2つの別個の潜在的な危険があると考えます。最初の危険は、輻輳したリンク上の多数のセグメントが、すでに受信側で受信された重複セグメントであるシナリオです。 2番目の危険は、輻輳したリンク上の多数のセグメントが、最終的な宛先に到達する前にネットワークで後でドロップされるセグメントであるシナリオです。
In terms of the negative effect on other traffic in the network, a potential disadvantage of larger initial windows would be that they increase the general packet drop rate in the network. We discuss these three issues below.
ネットワーク内の他のトラフィックへの悪影響に関して、初期ウィンドウが大きいことの潜在的な欠点は、ネットワーク内の一般的なパケットドロップ率が増加することです。以下では、これらの3つの問題について説明します。
Duplicate segments:
重複するセグメント：
As described in the previous section, the larger initial window could occasionally result in a segment dropped from the initial window, when that segment might not have been dropped if the sender had slow-started from an initial window of one segment. However, Appendix A shows that even in this case, the larger initial window would not result in the transmission of a large number of duplicate segments.
前のセクションで説明したように、送信者が1つのセグメントの初期ウィンドウからスロースタートした場合、そのセグメントが削除されなかった場合、初期ウィンドウが大きくなると、セグメントが最初のウィンドウから削除されることがあります。ただし、付録Aでは、この場合でも、初期ウィンドウが大きくなっても、重複したセグメントが多数送信されることはありません。
Segments dropped later in the network:
後でネットワークでドロップされたセグメント：
How much would the larger initial window for TCP increase the number of segments on congested links that would be dropped before reaching their final destination? This is a problem that can only occur for connections with multiple congested links, where some segments might use scarce bandwidth on the first congested link along the path, only to be dropped later along the path.
TCPの初期ウィンドウが大きくなると、最終的な宛先に到達する前にドロップされる、輻輳したリンク上のセグメントの数がどのくらい増加しますか？これは、複数のリンクが混雑した接続でのみ発生する可能性のある問題です。一部のセグメントは、パスに沿った最初の混雑したリンクで希少な帯域幅を使用し、後でパスに沿ってドロップされるだけです。
First, many of the TCP connections will have only one congested link along the path. Segments dropped from these connections do not "waste" scarce bandwidth, and do not contribute to congestion collapse.
まず、TCP接続の多くは、パスに沿ってリンクが1つだけ混雑します。これらの接続からドロップされたセグメントは、不足する帯域幅を「浪費」せず、輻輳の縮小に寄与しません。
However, some network paths will have multiple congested links, and segments dropped from the initial window could use scarce bandwidth along the earlier congested links before ultimately being dropped on subsequent congested links. To the extent that the drop rate is independent of the initial window used by TCP segments, the problem of congested links carrying segments that will be dropped before reaching their destination will be similar for TCP connections that start by sending four segments or one segment.
ただし、一部のネットワークパスには複数の輻輳リンクがあり、最初のウィンドウからドロップされたセグメントは、その後の輻輳リンクで最終的にドロップされる前に、以前の輻輳リンクに沿って少ない帯域幅を使用する可能性があります。ドロップ率がTCPセグメントで使用される初期ウィンドウに依存しない限り、宛先に到達する前にドロップされるセグメントを運ぶリンクの輻輳の問題は、4つのセグメントまたは1つのセグメントを送信することから始まるTCP接続でも同様です。
An increased packet drop rate:
パケットドロップ率の増加：
For a network with a high segment drop rate, increasing the TCP initial window could increase the segment drop rate even further. This is in part because routers with Drop Tail queue management have difficulties with bursty traffic in times of congestion. However, given uncorrelated arrivals for TCP connections, the larger TCP initial window should not significantly increase the segment drop rate. Simulation-based explorations of these issues are discussed in Section 7.2.
セグメントドロップ率が高いネットワークでは、TCP初期ウィンドウを大きくすると、セグメントドロップ率がさらに高くなる可能性があります。これは、一部には、ドロップテールキュー管理を備えたルーターが、輻輳時にバースト性のあるトラフィックを処理することが困難なためです。ただし、TCP接続の無相関到着を考えると、TCPの初期ウィンドウが大きくても、セグメントのドロップ率が大幅に増加することはありません。これらの問題のシミュレーションに基づく調査については、セクション7.2で説明します。
These potential dangers for the network are explored in simulations and experiments described in the section below. Our judgement would be, while there are dangers of congestion collapse in the current Internet (see [FF98] for a discussion of the dangers of congestion collapse from an increased deployment of UDP connections without end-to-end congestion control), there is no such danger to the network from increasing the TCP initial window to 4K bytes.
ネットワークのこれらの潜在的な危険は、以下のセクションで説明するシミュレーションと実験で調査されます。私たちの判断は、現在のインターネットには輻輳崩壊の危険性があるが（エンドツーエンドの輻輳制御のないUDP接続の増加した配備による輻輳崩壊の危険性については[FF98]を参照）、 TCPの初期ウィンドウを4Kバイトに増やすことによるネットワークへのそのような危険。
6. Typical Levels of Burstiness for TCP Traffic.
6. TCPトラフィックのバースト性の一般的なレベル。
Larger TCP initial windows would not dramatically increase the burstiness of TCP traffic in the Internet today, because such traffic is already fairly bursty. Bursts of two and three segments are already typical of TCP [Flo97]; A delayed ACK (covering two previously unacknowledged segments) received during congestion avoidance causes the congestion window to slide and two segments to be sent. The same delayed ACK received during slow start causes the window to slide by two segments and then be incremented by one segment, resulting in a three-segment burst. While not necessarily typical, bursts of four and five segments for TCP are not rare. Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK to cover four previously unacknowledged segments. During congestion avoidance this leads to a four-segment burst and during slow start a five-segment burst is generated.
より大きなTCP初期ウィンドウは、今日のインターネットのTCPトラフィックのバースト性を劇的に増加させません。 2セグメントと3セグメントのバーストはすでにTCPの典型的なものです[Flo97]。輻輳回避中に受信された遅延ACK（以前に確認されなかった2つのセグメントをカバーする）により、輻輳ウィンドウがスライドし、2つのセグメントが送信されます。スロースタート中に同じ遅延ACKを受信すると、ウィンドウが2セグメントずつスライドし、1セグメントずつインクリメントされ、3セグメントのバーストが発生します。必ずしも一般的ではありませんが、TCPの4セグメントと5セグメントのバーストはまれではありません。遅延ACKを想定すると、1つのドロップされたACKにより、後続のACKは以前に未確認だった4つのセグメントをカバーします。輻輳回避中はこれにより4セグメントバーストが発生し、スロースタート中は5セグメントバーストが生成されます。
There are also changes in progress that reduce the performance problems posed by moderate traffic bursts. One such change is the deployment of higher-speed links in some parts of the network, where a burst of 4K bytes can represent a small quantity of data. A second change, for routers with sufficient buffering, is the deployment of queue management mechanisms such as RED, which is designed to be tolerant of transient traffic bursts.
中程度のトラフィックバーストによって引き起こされるパフォーマンスの問題を軽減する進行中の変更もあります。そのような変更の1つは、ネットワークの一部に高速リンクを配置することです。4Kバイトのバーストが少量のデータを表す可能性があります。 2番目の変更点は、十分なバッファリングを備えたルーターの場合、一時的なトラフィックバーストに耐えられるように設計されたREDなどのキュー管理メカニズムの展開です。
This section surveys simulations and experiments that have been used to explore the effect of larger initial windows on the TCP connection using that larger window. The first set of experiments explores performance over satellite links. Larger initial windows have been shown to improve performance of TCP connections over satellite channels [All97b]. In this study, an initial window of four segments (512 byte MSS) resulted in throughput improvements of up to 30% (depending upon transfer size). [KAGT98] shows that the use of larger initial windows results in a decrease in transfer time in HTTP tests over the ACTS satellite system. A study involving simulations of a large number of HTTP transactions over hybrid fiber coax (HFC) indicates that the use of larger initial windows decreases the time required to load WWW pages [Nic97].
このセクションでは、大きいウィンドウを使用したTCP接続での大きい初期ウィンドウの影響を調査するために使用されたシミュレーションと実験について概説します。最初の一連の実験では、衛星リンクのパフォーマンスを調査します。より大きい初期ウィンドウは、衛星チャネル上のTCP接続のパフォーマンスを改善することが示されています[All97b]。この調査では、4つのセグメントの初期ウィンドウ（512バイトMSS）により、スループットが最大30％向上しました（転送サイズによって異なります）。 [KAGT98]は、より大きな初期ウィンドウを使用すると、ACTS衛星システムを介したHTTPテストでの転送時間が短縮されることを示しています。ハイブリッドファイバー同軸（HFC）を介した多数のHTTPトランザクションのシミュレーションに関する調査では、より大きな初期ウィンドウを使用すると、WWWページの読み込みに必要な時間が短縮されることが示されています[Nic97]。
A second set of experiments has explored TCP performance over dialup modem links. In experiments over a 28.8 bps dialup channel [All97a, AHO98], a four-segment initial window decreased the transfer time of a 16KB file by roughly 10%, with no accompanying increase in the drop rate. A particular area of concern has been TCP performance over low speed tail circuits (e.g., dialup modem links) with routers with small buffers. A simulation study [SP97] investigated the effects of using a larger initial window on a host connected by a slow modem link and a router with a 3 packet buffer. The study concluded that for the scenario investigated, the use of larger initial windows was not harmful to TCP performance. Questions have been raised concerning the effects of larger initial windows on the transfer time for short transfers in this environment, but these effects have not been quantified. A question has also been raised concerning the possible effect on existing TCP connections sharing the link.
2番目の実験では、ダイヤルアップモデムリンクでのTCPパフォーマンスを調査しました。 28.8 bpsのダイヤルアップチャネル[All97a、AHO98]を介した実験では、4セグメントの初期ウィンドウにより、16KBファイルの転送時間が約10％短縮され、ドロップ率も増加しませんでした。懸念される特定の領域は、小さなバッファーを持つルーターを使用した低速テール回線（たとえば、ダイヤルアップモデムリンク）でのTCPパフォーマンスです。シミュレーション研究[SP97]は、遅いモデムリンクで接続されたホストと3パケットバッファを備えたルーターで、より大きな初期ウィンドウを使用した場合の影響を調査しました。調査では、調査したシナリオでは、より大きな初期ウィンドウの使用はTCPパフォーマンスに悪影響を及ぼさないと結論付けました。この環境での短い転送の転送時間に対する大きな初期ウィンドウの影響に関する質問が出されましたが、これらの効果は定量化されていません。リンクを共有する既存のTCP接続への影響の可能性についても質問が出されました。
This section surveys simulations and experiments investigating the impact of the larger window on other TCP connections sharing the path. Experiments in [All97a, AHO98] show that for 16 KB transfers to 100 Internet hosts, four-segment initial windows resulted in a small increase in the drop rate of 0.04 segments/transfer. While the drop rate increased slightly, the transfer time was reduced by roughly 25% for transfers using the four-segment (512 byte MSS) initial window when compared to an initial window of one segment.
このセクションでは、パスを共有する他のTCP接続に対する大きなウィンドウの影響を調査するシミュレーションと実験について調査します。 [All97a、AHO98]の実験では、100 KBのインターネットホストへの16 KBの転送で、4セグメントの初期ウィンドウにより、0.04セグメント/転送のドロップ率がわずかに増加したことが示されています。ドロップ率はわずかに増加しましたが、1セグメントの初期ウィンドウと比較して、4セグメント（512バイトMSS）の初期ウィンドウを使用した転送の転送時間は約25％短縮されました。
One scenario of concern is heavily loaded links. For instance, a couple of years ago, one of the trans-Atlantic links was so heavily loaded that the correct congestion window size for a connection was about one segment. In this environment, new connections using larger initial windows would be starting with windows that were four times too big. What would the effects be? Do connections thrash?
懸念されるシナリオの1つは、負荷の高いリンクです。たとえば、数年前、大西洋横断リンクの1つが非常に負荷が高いため、接続の正しい輻輳ウィンドウサイズは約1セグメントでした。この環境では、より大きな初期ウィンドウを使用した新しい接続は、4倍の大きさのウィンドウから始まります。どのような影響がありますか？接続はスラッシュしますか？
A simulation study in [PN98] explores the impact of a larger initial window on competing network traffic. In this investigation, HTTP and FTP flows share a single congested gateway (where the number of HTTP and FTP flows varies from one simulation set to another). For each simulation set, the paper examines aggregate link utilization and packet drop rates, median web page delay, and network power for the FTP transfers. The larger initial window generally resulted in increased throughput, slightly-increased packet drop rates, and an increase in overall network power. With the exception of one scenario, the larger initial window resulted in an increase in the drop rate of less than 1% above the loss rate experienced when using a one-segment initial window; in this scenario, the drop rate increased from 3.5% with one-segment initial windows, to 4.5% with four-segment initial windows. The overall conclusions were that increasing the TCP initial window to three packets (or 4380 bytes) helps to improve perceived performance.
[PN98]のシミュレーション研究では、競合するネットワークトラフィックに対する大きな初期ウィンドウの影響を調査しています。この調査では、HTTPおよびFTPフローは単一の輻輳したゲートウェイを共有しています（HTTPおよびFTPフローの数はシミュレーションセットごとに異なります）。このペーパーでは、シミュレーションセットごとに、総リンク使用率とパケットドロップ率、Webページ遅延の中央値、およびFTP転送のネットワーク電力を調べます。初期ウィンドウが大きくなると、一般にスループットが増加し、パケットドロップ率がわずかに増加し、ネットワーク全体の電力が増加します。 1つのシナリオを除いて、初期ウィンドウが大きくなると、ドロップ率の増加は1セグメントの初期ウィンドウを使用した場合の損失率よりも1％少なくなりました。このシナリオでは、ドロップ率は、1セグメントの初期ウィンドウでの3.5％から4セグメントの初期ウィンドウでの4.5％に増加しました。全体的な結論は、TCP初期ウィンドウを3パケット（または4380バイト）に増やすと、知覚されるパフォーマンスが向上することです。
Morris [Mor97] investigated larger initial windows in a very congested network with transfers of size 20K. The loss rate in networks where all TCP connections use an initial window of four segments is shown to be 1-2% greater than in a network where all connections use an initial window of one segment. This relationship held in scenarios where the loss rates with one-segment initial windows ranged from 1% to 11%. In addition, in networks where connections used an initial window of four segments, TCP connections spent more time waiting for the retransmit timer (RTO) to expire to resend a segment than was spent when using an initial window of one segment. The time spent waiting for the RTO timer to expire represents idle time when no useful work was being accomplished for that connection. These results show that in a very congested environment, where each connection's share of the bottleneck bandwidth is close to one segment, using a larger initial window can cause a perceptible increase in both loss rates and retransmit timeouts.
Morris [Mor97]は、サイズが20Kの転送を伴う非常に混雑したネットワークで、より大きな初期ウィンドウを調査しました。すべてのTCP接続が4つのセグメントの初期ウィンドウを使用するネットワークでの損失率は、すべての接続が1つのセグメントの初期ウィンドウを使用するネットワークよりも1〜2％大きいことが示されています。この関係は、1セグメントの初期ウィンドウでの損失率が1％から11％のシナリオで発生しました。さらに、接続が4つのセグメントの初期ウィンドウを使用するネットワークでは、TCP接続は、1つのセグメントの初期ウィンドウを使用する場合よりも、セグメントを再送信するために再送信タイマー（RTO）が期限切れになるまで待機する時間を費やしました。 RTOタイマーが期限切れになるのを待つのに費やされた時間は、その接続で有効な作業が行われていなかったアイドル時間を表します。これらの結果は、ボトルネック帯域幅の各接続のシェアが1つのセグメントに近い非常に輻輳した環境で、より大きな初期ウィンドウを使用すると、損失率と再送信タイムアウトの両方が大幅に増加する可能性があることを示しています。
This document discusses the initial congestion window permitted for TCP connections. Changing this value does not raise any known new security issues with TCP.
このドキュメントでは、TCP接続で許可される初期の輻輳ウィンドウについて説明します。この値を変更しても、TCPに関する既知の新しいセキュリティ問題は発生しません。
This document proposes a small change to TCP that may be beneficial to short-lived TCP connections and those over links with long RTTs (saving several RTTs during the initial slow-start phase).
このドキュメントでは、TCPの小さな変更を提案しています。これは、存続期間の短いTCP接続や、RTTが長い（最初のスロースタートフェーズでいくつかのRTTを節約する）リンクを介した接続に役立つ可能性があります。
We would like to acknowledge Vern Paxson, Tim Shepard, members of the End-to-End-Interest Mailing List, and members of the IETF TCP Implementation Working Group for continuing discussions of these issues for discussions and feedback on this document.
このドキュメントに関するディスカッションとフィードバックのためにこれらの問題のディスカッションを継続していただいたVern Paxson、Tim Shepard、End-to-End-Interestメーリングリストのメンバー、およびIETF TCP実装ワーキンググループのメンバーに感謝いたします。
[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting -- TCP Implementations WG. December, 1997. Washington, DC.
[All97a]マークオールマン。より大きな初期ウィンドウでのTCPの評価。第40回IETFミーティング-TCP実装WG。 1997年12月。ワシントンDC。
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. Submitted to ACM Computer Communication Review. URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/ initwin.ps".
[AHO98] Mark Allman、Chris Hayes、およびShawn Ostermann、より大きな初期ウィンドウを備えたTCPの評価、1998年3月。ACMComputer Communication Reviewに提出。 URL： "http://gigahertz.lerc.nasa.gov/~mallman/papers/ initwin.ps"。
[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
[All97b]マークオールマン。衛星チャネルでのTCPパフォーマンスの向上。修士論文、オハイオ大学、1997年6月。
[BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[BLFN96] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「Hypertext Transfer Protocol-HTTP / 1.0」、RFC 1945、1996年5月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
[FF96]秋、K、およびフロイド、S、シミュレーションに基づくタホ、リノ、およびSACK TCPの比較。コンピュータ通信レビュー、26（3）、1996年7月。
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking. URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".
[FF98]サリー・フロイド、ケビン・フォール。インターネットにおけるエンドツーエンドの輻輳制御の使用の促進。 IEEE Transactions on Networkingに提出されました。 URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html"。
[FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[FJGFBL97] Fielding、R.、Mogul、J.、Gettys、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93] Floyd、S.とJacobson、V.、輻輳回避のためのランダム早期検出ゲートウェイ。 IEEE / ACM Transactions on Networking、V.1 N.4、1993年8月、p。 397-413。
[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
[Flo94]フロイド、S.、TCPおよび明示的な輻輳通知。コンピュータ通信レビュー、24（5）：10-23、1994年10月。
[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
[Flo96]フロイド、S.、SACKを使用したTCPの問題。テクニカルレポート、1996年1月。http：//www-nrg.ee.lbl.gov/floyd/から入手できます。
[Flo97] Floyd, S., Increasing TCP's Initial Window. Viewgraphs, 40th IETF Meeting - TCP Implementations WG. December, 1997. URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
[Flo97] Floyd、S.、TCPの初期ウィンドウを増やしています。ビューグラフ、第40回IETFミーティング-TCP実装WG。 1997年12月。URL「ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps」。
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".
[KAGT98]ハンス・クルーゼ、マーク・オールマン、ジム・グリナー、ディエプチ・トラン。静止衛星リンク上のHTTPページ転送速度。 1998年3月。第6回電気通信システムに関する国際会議の議事録。 URL "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps"。
[MD90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MD90] Mogul、J。、およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、1996年10月。
[Mor97] Robert Morris. Private communication, 1997. Cited for acknowledgement purposes only.
[Mor97]ロバートモリス。プライベートコミュニケーション、1997年。確認の目的でのみ引用。
[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
[Nic97]キャスリーン・ニコルズ。フィードバックによるネットワークシミュレーションの改善。 Com21、Inc.テクニカルレポート。 http://www.com21.com/pages/papers/068.pdfから入手できます。
[PN98] Poduri, K., and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[PN98] Poduri、K。、およびK. Nichols、「増加した初期TCPウィンドウサイズのシミュレーション研究」、RFC 2415、1998年9月。
[Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[Pos82] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RF97] Ramakrishnan, K., and S. Floyd, "A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress.
[RF97] Ramakrishnan、K。、およびS. Floyd、「IPv6およびTCPに明示的な輻輳通知（ECN）を追加する提案」、進行中。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、1998年4月。
[S97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[S97]スティーブンス、W。、「TCPスロースタート、輻輳回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。
[SP97] Shepard, T., and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP97] Shepard、T。、およびC. Partridge、「TCPが4つのパケットで3つのバッファのみに入るとき」、RFC 2416、1998年9月。
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Road MS 54-2 Cleveland, OH 44135
Mark Allman NASA Lewis Research Center / Sterling Software 21000 Brookpark Road MS 54-2 Cleveland、OH 44135
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Sally Floyd Lawrence Berkeley National Laboratory One Cyclotron Road Berkeley, CA 94720
サリーフロイドローレンスバークレー国立研究所One Cyclotron Road Berkeley、CA 94720
EMail: floyd@ee.lbl.gov
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138
Craig Partridge BBN Technologies 10 Moulton Street Cambridge、MA 02138
EMail: craig@bbn.com
In the current environment (without Explicit Congestion Notification [Flo94] [RF97]), all TCPs use segment drops as indications from the network about the limits of available bandwidth. We argue here that the change to a larger initial window should not result in the sender retransmitting a large number of duplicate segments that have already been received at the receiver.
現在の環境（明示的な輻輳通知[Flo94] [RF97]なし）では、すべてのTCPが、利用可能な帯域幅の制限に関するネットワークからの指示としてセグメントドロップを使用します。ここでは、より大きな初期ウィンドウへの変更によって、送信側が受信側ですでに受信されている多数の重複セグメントを再送信しないようにする必要があると主張します。
If one segment is dropped from the initial window, there are three different ways for TCP to recover: (1) Slow-starting from a window of one segment, as is done after a retransmit timeout, or after Fast Retransmit in Tahoe TCP; (2) Fast Recovery without selective acknowledgments (SACK), as is done after three duplicate ACKs in Reno TCP; and (3) Fast Recovery with SACK, for TCP where both the sender and the receiver support the SACK option [MMFR96]. In all three cases, if a single segment is dropped from the initial window, no duplicate segments (i.e., segments that have already been received at the receiver) are transmitted. Note that for a TCP sending four 512-byte segments in the initial window, a single segment drop will not require a retransmit timeout, but can be recovered from using the Fast Retransmit algorithm (unless the retransmit timer expires prematurely). In addition, a single segment dropped from an initial window of three segments might be repaired using the fast retransmit algorithm, depending on which segment is dropped and whether or not delayed ACKs are used. For example, dropping the first segment of a three segment initial window will always require waiting for a timeout. However, dropping the third segment will always allow recovery via the fast retransmit algorithm, as long as no ACKs are lost.
1つのセグメントが初期ウィンドウから削除された場合、TCPが回復するには3つの異なる方法があります。（1）再送信タイムアウト後、またはTahoe TCPの高速再送信後に行われる、1つのセグメントのウィンドウからのスロースタート。 （2）Reno TCPでの3つの重複ACKの後に行われる、選択的確認応答（SACK）なしの高速リカバリ。 （3）送信側と受信側の両方がSACKオプション[MMFR96]をサポートするTCPのSACKを使用した高速リカバリ。 3つのケースすべてで、単一のセグメントが初期ウィンドウから削除された場合、重複するセグメント（つまり、受信側ですでに受信されているセグメント）は送信されません。初期ウィンドウで4つの512バイトセグメントを送信するTCPの場合、単一セグメントのドロップでは再送信タイムアウトは必要ありませんが、高速再送信アルゴリズムを使用して回復できます（再送信タイマーが早期に期限切れにならない限り）。さらに、3つのセグメントの初期ウィンドウからドロップされた単一のセグメントは、ドロップされたセグメントと遅延ACKが使用されているかどうかに応じて、高速再送信アルゴリズムを使用して修復される場合があります。たとえば、3セグメントの初期ウィンドウの最初のセグメントをドロップすると、常にタイムアウトを待つ必要があります。ただし、3番目のセグメントをドロップすると、ACKが失われない限り、常に高速再送信アルゴリズムによる回復が可能になります。
Next we consider scenarios where the initial window contains two to four segments, and at least two of those segments are dropped. If all segments in the initial window are dropped, then clearly no duplicate segments are retransmitted, as the receiver has not yet received any segments. (It is still a possibility that these dropped segments used scarce bandwidth on the way to their drop point; this issue was discussed in Section 5.)
次に、初期ウィンドウに2〜4個のセグメントが含まれ、それらのセグメントのうち少なくとも2つが削除されるシナリオを検討します。最初のウィンドウのすべてのセグメントが削除された場合、レシーバーはまだセグメントを受信していないため、重複するセグメントは再送信されません。 （これらのドロップされたセグメントが、ドロップポイントに到達するまでの間に少ない帯域幅を使用した可能性があります。この問題はセクション5で説明されています。）
When two segments are dropped from an initial window of three segments, the sender will only send a duplicate segment if the first two of the three segments were dropped, and the sender does not receive a packet with the SACK option acknowledging the third segment.
3つのセグメントの最初のウィンドウから2つのセグメントがドロップされた場合、3つのセグメントの最初の2つがドロップされ、送信側は3番目のセグメントを確認するSACKオプション付きのパケットを受信しない場合にのみ、重複セグメントを送信します。
When two segments are dropped from an initial window of four segments, an examination of the six possible scenarios (which we don't go through here) shows that, depending on the position of the dropped packets, in the absence of SACK the sender might send one duplicate segment. There are no scenarios in which the sender sends two duplicate segments.
4つのセグメントの初期ウィンドウから2つのセグメントがドロップされると、6つの可能なシナリオ（ここでは説明しません）を調べると、ドロップされたパケットの位置によっては、SACKがない場合に送信者が重複するセグメントを1つ送信します。送信者が2つの重複するセグメントを送信するシナリオはありません。
When three segments are dropped from an initial window of four segments, then, in the absence of SACK, it is possible that one duplicate segment will be sent, depending on the position of the dropped segments.
4つのセグメントの初期ウィンドウから3つのセグメントがドロップされると、SACKがない場合、ドロップされたセグメントの位置によっては、1つの重複セグメントが送信される可能性があります。
The summary is that in the absence of SACK, there are some scenarios with multiple segment drops from the initial window where one duplicate segment will be transmitted. There are no scenarios where more that one duplicate segment will be transmitted. Our conclusion is that the number of duplicate segments transmitted as a result of a larger initial window should be small.
要約すると、SACKがない場合、最初のウィンドウから複数のセグメントがドロップし、1つの重複セグメントが送信されるシナリオがいくつかあります。複数の重複セグメントが送信されるシナリオはありません。私たちの結論は、より大きな初期ウィンドウの結果として送信される重複セグメントの数は少ないはずです。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。