[要約] RFC 3390は、TCPの初期ウィンドウサイズを増やすためのガイドラインを提供しています。その目的は、ネットワークの効率性とパフォーマンスを向上させることです。
Network Working Group M. Allman
Request for Comments: 3390 BBN/NASA GRC
Obsoletes: 2414 S. Floyd
Updates: 2581 ICIR
Category: Standards Track C. Partridge
BBN Technologies
October 2002
Increasing TCP's Initial Window
TCPの最初のウィンドウを増やす
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
Abstract
概要
This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes, replacing RFC 2414. It discusses the advantages and disadvantages of the higher initial window, and includes discussion of experiments and simulations showing that the higher initial window does not lead to congestion collapse. Finally, this document provides guidance on implementation issues.
このドキュメントは、RFC 2414を置き換える1つまたは2つのセグメントから約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 obsoletes [RFC2414] and updates [RFC2581] and specifies an increase in the permitted upper bound for TCP's initial window from one or two segment(s) 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 may be significantly larger than 4K bytes).
このドキュメントは[RFC2414]と更新[RFC2581]を廃止し、TCPの最初のウィンドウの許可された上限が1つまたは2つのセグメントから2つのセグメントの間に増加します。ほとんどの場合、この変更により、約4Kバイトの初期ウィンドウの上限が発生します（大きなセグメントサイズが与えられますが、2つのセグメントの許容された初期ウィンドウは4Kバイトより大きく大きくてもよい）。
The upper bound for the initial window is given more precisely in (1):
初期ウィンドウの上限は、（1）でより正確に与えられます。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
Min（4 * MSS、MAX（2 * MSS、4380バイト））（1）
Note: Sending a 1500 byte packet indicates a maximum segment size (MSS) of 1460 bytes (assuming no IP or TCP options). Therefore, limiting the initial window's MSS to 4380 bytes allows the sender to transmit three segments initially in the common case when using 1500 byte packets.
注：1500バイトのパケットを送信すると、最大セグメントサイズ（MSS）が1460バイト（IPまたはTCPオプションがないと仮定）を示します。したがって、最初のウィンドウのMSSを4380バイトに制限すると、送信者は1500バイトのパケットを使用するときに最初に共通の場合に3つのセグメントを送信することができます。
Equivalently, the upper bound for the initial window size is based on the 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: a TCP MAY start with a larger initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above.
この初期ウィンドウの増加はオプションです.TCPは初期ウィンドウで始まります。ただし、ほとんどの汎用TCP実装は、上記の式（1）で示されているより大きな初期輻輳ウィンドウを使用することを選択することを期待しています。
This upper bound for the initial window size represents a change from RFC 2581 [RFC2581], which specified that the congestion window be initialized to one or two segments.
初期ウィンドウサイズのこの上限は、RFC 2581 [RFC2581]からの変更を表します。これは、輻輳ウィンドウを1つまたは2つのセグメントに初期化したことを指定しました。
This change applies to the initial window of the connection in the first round trip time (RTT) of data 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 consisting of MSS bytes.
この変更は、TCP三方向ハンドシェイクのデータ伝送の最初のラウンドトリップ時間（RTT）内の接続の初期ウィンドウに適用されます。三方ハンドシェイクのSYN / ACKもその確認応答（ACK）も、式（1）で概説されている初期ウィンドウサイズを上回るはずです。SYNまたはSYN / ACKが失われた場合、正しく送信されたSYNの後に送信側で使用される初期ウィンドウは、MSSバイトからなる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 transmission after a long idle period (the restart window); and (3) to restart transmission after a retransmit timeout (the loss window). The change specified 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 of MSS bytes (to permit the lowest possible window size in the case of severe congestion).
TCP実装は、3つの異なる方法でスロースタートを使用します。（1）新しい接続を開始する（初期ウィンドウ）。（2）長期期間（再起動ウィンドウ）の後に送信を再開する。（3）再送タイムアウト（損失ウィンドウ）の後に送信を再開する。この文書で指定された変更は、最初のウィンドウの値に影響します。オプションで、TCPは、再起動ウィンドウを初期ウィンドウに使用された値の最小値とCWNDの現在の値（すなわち、再起動ウィンドウに大きな値を使用すると、CWNDのサイズを増やすべきではないはず）に設定することができる。これらの変更は損失ウィンドウを変更しません。これは、MSSバイトの1セグメントのままにする必要があります（重度の輻輳の場合は可能な限り低いウィンドウサイズを許可するため）。
When larger initial windows are implemented along with Path MTU Discovery [RFC1191], 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 [RFC1191]とともにより大きな初期ウィンドウが実装され、使用されているMSSが大きすぎることが判明した場合、輻輳ウィンドウ「CWND」は小さなセグメントの大きなバーストを防ぐために減らす必要があります。具体的には、古いセグメントサイズと新しいセグメントサイズとの比率によって「CWND」を縮小する必要があります。
When larger initial windows are implemented along with Path MTU Discovery [RFC1191], 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 as to which of these two alternatives is best; we would hope that implementation experiences will shed light on this question. 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.
Path MTU Discovery [RFC1191]と共により大きな初期ウィンドウが実装されている場合、代替手段は、最初のウィンドウのすべてのセグメント内の「フラグメント化しない」（DF）ビットを設定するか、「フラグメントを設定しない」を設定することです（DF一方のセグメント内のビット。それはこれら2つの選択肢のどれが最善であるかに関してそれは開かれた質問です。実装経験がこの質問で光を当てることを願っています。すべてのセグメントでDFビットを設定する最初のケースでは、初期パケットが大きすぎる場合、すべての初期パケットはネットワーク内でドロップされます。初期パケットが大きすぎる場合は、1つのセグメントのみにDFビットを設定する2番目の場合、初期パケットの1つがネットワーク内で断片化されます。 2番目のケースに従うと、最初のウィンドウの最後のセグメントのDFビットを設定すると、初期セグメントサイズが大きすぎると判断されたときに不要な再送信に最小限の機会があります。これは、高速再送信をトリガーすることを最小限に抑えます。 。しかし、より大きな初期のウィンドウとパスMTUの発見の間の相互作用にもっと注意が必要です。
The larger initial window specified in this document is not intended as 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, they are working against TCP's congestion control mechanisms [FF99], 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. We suggest the use of HTTP/1.1 [RFC2068] (persistent TCP connections and pipelining) as a way to achieve better performance of web transfers.
このドキュメントで指定されている初期ウィンドウが大きいほど、Webブラウザの奨励を意図していません。Webブラウザが同じ宛先への同時TCP接続を開くと、初期ウィンドウのサイズに関係なく、TCPの輻輳制御メカニズム[FF99]に対して作業しています。この動作をより大きな初期のウィンドウと組み合わせると、ネットワーク内の他のトラフィックに対する不公平がさらに増加します。Web転送のより良い性能を達成する方法として、HTTP / 1.1 [RFC2068]（永続的TCP接続とパイプライン化）の使用をお勧めします。
1. When the initial window is one segment, a receiver employing delayed ACKs [RFC1122] 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, and possibly up to 500 msec [RFC1122]).
1. 初期ウィンドウが1つのセグメントの場合、遅延ACKを使用する受信機[RFC1122]は、ACKを生成する前にタイムアウトを待つように強制されます。少なくとも2つのセグメントの初期ウィンドウでは、受信機は第2のデータセグメントが到着した後にACKを生成する。これにより、タイムアウト（多くの場合200ミリ秒まで、おそらく500ミリ秒の[RFC1122]）がなくなります。
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 [RFC1945, RFC2068]) transfers that are less than 4K bytes, the larger initial window would reduce the data transfer time to a single RTT.
2. 少量のデータのみを送信する接続の場合、初期ウィンドウが大きくなると送信時間が短縮されます（最大で中程度のセグメントドロップレート）。多くの電子メール（SMTP [POS82]）とWebページ（HTTP [RFC1945、RFC2068]）は4Kバイト未満の転送で、初期ウィンドウが大きくなると、データ転送時間が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 will 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接続は、ルータが小さなバーストを処理することができないために不要な再送信が発生する可能性があります。 。これにより、不要な再送信タイムアウトが発生する可能性があります。再送タイムアウトなしで回復できる大型ウィンドウ接続の場合、これは、ウィンドウ増加アルゴリズムのスロースタートから輻輳回避段階への不必要に早期への移行をもたらす可能性がある。これらの早期セグメントの低下は、輻輳したルータがアクティブなキュー管理を使用するのに十分なバッファリングまたは中程度に輻輳したネットワークで、未確認のネットワークで発生することはほとんどありません。
Some TCP connections will receive better performance with the larger 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接続が再送信タイムアウトなしでセグメントドロップから回復する場合、（1）TRUEはTRUEになります。（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 judgment is that while there are dangers of congestion collapse in the current Internet (see [FF99] 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.
ネットワークのためのこれらの潜在的な危険性は、以下のセクションで説明されているシミュレーションおよび実験で探求されています。私たちの判断は、現在のインターネットで輻輳崩壊の危険性がありますが（FF99を参照してください。エンドツーエンドの輻輳制御なしのUDP接続の展開の増大からの輻輳の危険性の議論のための[FF99]を参照）、そのようなものはありません。ネットワークがTCPの初期ウィンドウを4Kバイトに増やすことからの危険性があります。
Using a larger initial burst of data can exacerbate existing problems with spurious retransmit timeouts on low-bandwidth paths, assuming the standard algorithm for determining the TCP retransmission timeout (RTO) [RFC2988]. The problem is that across low-bandwidth network paths on which the transmission time of a packet is a large portion of the round-trip time, the small packets used to establish a TCP connection do not seed the RTO estimator appropriately. When the first window of data packets is transmitted, the sender's retransmit timer could expire before the acknowledgments for those packets are received. As each acknowledgment arrives, the retransmit timer is generally reset. Thus, the retransmit timer will not expire as long as an acknowledgment arrives at least once a second, given the one-second minimum on the RTO recommended in RFC 2988.
より大きな初期バーストを使用すると、TCP再送タイムアウト（RTO）[RFC2988]を決定するための標準的なアルゴリズムを想定して、低帯域幅経路上のスプリアス再送信タイムアウトで既存の問題を悪化させることができます。問題は、パケットの送信時間が往復時間の大部分である低帯域幅ネットワーク経路を越えて、TCP接続を確立するために使用される小さなパケットはRTO推定器を適切にシードしないことである。データパケットの最初のウィンドウが送信されると、送信者の再送信タイマはそれらのパケットに対する確認応答が受信される前に期限切れになる可能性がある。各確認応答が到着するにつれて、再送信タイマは一般にリセットされる。したがって、RFC 2988で推奨されているRTOの1秒の最小値を考慮して、確認応答が少なくとも1回1回1回到着する限り、再送信タイマは期限切れにならない。
For instance, consider a 9.6 Kbps link. The initial RTT measurement will be on the order of 67 msec, if we simply consider the transmission time of 2 packets (the SYN and SYN-ACK), each consisting of 40 bytes. Using the RTO estimator given in [RFC2988], this yields an initial RTO of 201 msec (67 + 4*(67/2)). However, we round the RTO to 1 second as specified in RFC 2988. Then assume we send an initial window of one or more 1500-byte packets (1460 data bytes plus overhead). Each packet will take on the order of 1.25 seconds to transmit. Therefore, the RTO will fire before the ACK for the first packet returns, causing a spurious timeout. In this case, a larger initial window of three or four packets exacerbates the problems caused by this spurious timeout.
たとえば、9.6 kbpsのリンクを考えます。最初のRTT測定は、2パケットの送信時間（SYNとSYN-ACK）を単に考慮した場合、それぞれ40バイトからなる場合は、67ミリ秒のオーダーになります。[RFC2988]に記載されているRTO推定量を使用すると、これにより、201ミリ秒の初期RTOが得られます（67 4 *（67/2））。ただし、RFC 2988で指定されているように、RTOを1秒に丸めます。その後、1つ以上の1500バイトのパケットの初期ウィンドウ（1460データバイトとオーバーヘッド）を送信します。各パケットは送信するのに1.25秒のオーダーで取ります。したがって、RTOは、最初のパケットのACKが返される前に、スプリアスタイムアウトを引き起こす前にRTOが発生します。この場合、3つか4つのパケットのより大きな初期ウィンドウがこのスプリアスタイムアウトによって引き起こされる問題を悪化させる。
One way to deal with this problem is to make the RTO algorithm more conservative. During the initial window of data, for instance, the RTO could be updated for each acknowledgment received. In addition, if the retransmit timer expires for some packet lost in the first window of data, we could leave the exponential-backoff of the retransmit timer engaged until at least one valid RTT measurement, that involves a data packet, is received.
この問題に対処する1つの方法は、RTOアルゴリズムをより保守的にすることです。たとえば、データの初期ウィンドウの間、RTOは受信された各確認応答に対して更新できます。さらに、データの最初のウィンドウで失われたいくつかのパケットで再送信タイマが期限切れになると、データパケットを含む少なくとも1つの有効なRTT測定が受信されるまで、再送信タイマの指数バックオフを取り出すことができます。
Another method would be to refrain from taking an RTT sample during connection establishment, leaving the default RTO in place until TCP takes a sample from a data segment and the corresponding ACK. While this method likely helps prevent spurious retransmits, it also may slow the data transfer down if loss occurs before the RTO is seeded. The use of limited transmit [RFC3042] to aid a TCP connection in recovering from loss using fast retransmit rather than the RTO timer mitigates the performance degradation caused by using the high default RTO during the initial window of data transmission.
別の方法は、接続確立中にRTTサンプルを取ることを控えることであり、TCPがデータセグメントおよび対応するACKからサンプルを取り出すまでデフォルトのRTOを所定の位置に残すことであろう。この方法はスプリアスの再送信を防ぐのに役立つ可能性がありますが、RTOが播種される前に損失が発生した場合にはデータ転送を遅くする可能性があります。RTOタイマーではなく高速再送信を使用して損失から回復するのを助けるために、制限された送信[RFC3042]の使用は、データ送信の初期ウィンドウの間に高デフォルトRTOを使用することによって生じる性能劣化を軽減する。
This specification leaves the decision about what to do (if anything) with regards to the RTO, when using a larger initial window, to the implementer. However, the RECOMMENDED approach is to refrain from sampling the RTT during the three-way handshake, keeping the default RTO in place until an RTT sample involving a data packet is taken. In addition, it is RECOMMENDED that TCPs use limited transmit [RFC3042].
この仕様は、より大きな初期ウィンドウを使用するときに、RTOに関して何をすべきか（何であれば）実装者に決定を残す。しかしながら、推奨されるアプローチは、3方向ハンドシェイク中にRTTをサンプリングすることを控えて、データパケットを含むRTTサンプルが行われるまでデフォルトのRTOを所定の位置に保ちます。また、TCPSを使用することをお勧めします.Simals Transmit [RFC3042]。
7. Typical Levels of Burstiness for TCP Traffic.
7. 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つのセグメントのバーストはすでにTCP [FLO97]の典型的なものです。輻輳回避中に受信された遅延ACK（以前に2つの以前に未確認セグメントをカバーする）は、輻輳ウィンドウをスライドさせ、2つのセグメントを送信する。スロースタート中に受信された同じ遅延ACKは、ウィンドウを2つのセグメントでスライドさせ、次に1つのセグメントによってインクリメントされ、その結果3セグメントバーストが発生します。必ずしも典型的ではないが、TCP用の4つのセグメントおよび5つのセグメントのバーストは稀ではない。遅延ACKを想定して、単一のドロップされた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回目の変更は、赤のようなキュー管理メカニズムの展開であり、これは過渡的なトラフィックバーストを耐えるように設計されています。
This section surveys simulations and experiments that explore the effect of larger initial windows on TCP connections. The first set of experiments explores performance over satellite links. Larger initial windows have been shown to improve the 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 [Nic98].
このセクションでは、TCP接続でのより大きな初期ウィンドウの効果を調査するシミュレーションと実験を調査します。最初の実験セットは衛星リンクの上のパフォーマンスを探ります。より大きな初期ウィンドウが衛星チャネル上でのTCP接続の性能を向上させることが示されています[ALL97B]。本研究では、4つのセグメントの初期ウィンドウ（512バイトMSS）で、最大30％のスループットの改善が得られました（転送サイズによって異なります）。[KAGT98]は、ACTS衛星システムを介したHTTPテストでの転送時間が経過すると、より大きな初期ウィンドウの使用が転送時間の短縮をもたらすことを示しています。ハイブリッドファイバCOAX（HFC）を介した多数のHTTPトランザクションのシミュレーションを含む検討（HFC）は、より大きな初期ウィンドウの使用がWWWページ[NIC98]をロードするのに必要な時間を減少させることを示します。
A second set of experiments 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 simulation study [RFC2416] 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.
2番目の実験セットは、ダイヤルアップモデムリンクでTCPパフォーマンスを調査しました。28.8 BPSダイヤルアップチャネル[ALL97A、AHO98]で実験では、4セグメント初期ウィンドウが16KBファイルの転送時間を約10％減少させ、ドロップレートの増加はありません。シミュレーションスタディ[RFC2416]は、スローモデムリンクで接続されているホスト上のより大きな初期ウィンドウと3パケットバッファを持つルータの効果を調べました。この研究は、シナリオで調査されたシナリオでは、より大きな初期窓の使用はTCP性能に有害ではなかったと結論付けました。
Finally, [All00] illustrates that the percentage of connections at a particular web server that experience loss in the initial window of data transmission increases with the size of the initial congestion window. However, the increase is in line with what would be expected from sending a larger burst into the network.
最後に、[All00]は、データ送信の初期ウィンドウで損失を経験する特定のWebサーバでの接続の割合が初期輻輳ウィンドウのサイズとともに増加することを示しています。しかしながら、増加は、ネットワークへのより大きなバーストを送信することから予想されるものと一致している。
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個のインターネットホストへの16 KBの移動について、4セグメント初期窓が0.04セグメント/移動の低下率が小さくなりました。ドロップレートはわずかに増加したが、1セグメントの初期ウィンドウと比較して、4セグメント（512バイトのMSS）初期ウィンドウを使用して転送時間は約25％減少しました。
A simulation study in [RFC2415] 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.
[RFC2415]のシミュレーション研究は、競合するネットワークトラフィックに対するより大きな初期ウィンドウの影響を探ります。この調査では、HTTPフローとFTPフローは単一の輻輳ゲートウェイを共有します（HTTPフローとFTPフローの数は、シミュレーションの1つのシミュレーションによって異なります）。シミュレーションセットごとに、この論文は、FTP転送の集計リンク利用およびパケットのドロップレート、メディアンWebページ遅延、およびネットワーク電源を調べます。初期ウィンドウが大きいほど、スループット、わずかに増加したパケットドロップレート、および全体的なネットワーク電力の増加が増加した。 1つのシナリオを除いて、初期ウィンドウが大きいほど、1セグメントの初期ウィンドウを使用するときに経験する損失率を超える1％未満のドロップレートが増加しました。このシナリオでは、ドロップ率は1セグメントの初期窓と3.5％から4セグメントの初期窓で4.5％に増加しました。全体的な結論は、TCP初期ウィンドウを3つのパケット（または4380バイト）に増加させることで、知覚性能を向上させるのに役立ちます。
Morris [Mor97] investigated larger initial windows in a highly congested network with transfers of 20K in size. 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 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接続は再送信タイマ（RTO）が1つのセグメントの初期ウィンドウを使用して費やされたものよりも期限切れになるのを待っていました。 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 specifies a small change to TCP that will likely be beneficial to short-lived TCP connections and those over links with long RTTs (saving several RTTs during the initial slow-start phase).
このドキュメントは、短命のTCP接続とLONG RTTとのリンクを介したもの（初期スロースタートフェーズ中に複数のRTTを保存する）に有益である可能性が高いTCPへの小さな変更を指定します。
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 and for feedback on this document.
私たちは、これらの問題の議論とこの文書に関するフィードバックの継続的な議論のために、ティム・シェパード、エンドツーエンドのメーリングリストのメンバー、およびIETF TCP実装作業グループのメンバーを認めたいと思います。
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. ACM Computer Communication Review, 28(3), July 1998. URL "http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps".
[AHO98]マークAllman、Chris Hayes、Shawn Ostermann、より大きな初期のWindows、1998年3月のTCPの評価。ACM Computer Communication Review、28（3）、1998年7月。URL "http：//roland.lerc.nasa。gov / ~mallman /論文/ initwin.ps "。
[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting -- TCP Implementations WG. December, 1997. Washington, DC.
[ALL97A]マークAllman。より大きな初期ウィンドウを有するTCPの評価40th IETF会議 - TCP実装WG。1997年12月。ワシントンDC。
[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
[ALL97B]マークAllman。衛星チャネル上のTCP性能の向上オハイオ大学の修士論文、1997年6月。
[All00] Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000.
[All00]マークAllman。トランスポート層のWebサーバのビュー。ACMコンピュータ通信レビュー、30（5）、2000年10月。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
[FF96] Tahoe、Reno、Sack TCPの秋、K、およびFLOYD、S。、シミュレーションに基づく比較。コンピュータ通信レビュー、26（3）、1996年7月。
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. IEEE/ACM Transactions on Networking, August 1999. URL "http://www.icir.org/floyd/end2end-paper.html".
[FF99]サリーフロイド、ケビンフォール。インターネットにおけるエンドツーエンド輻輳制御の使用を促進する。1999年8月、ネットワーキングに関するIEEE / ACMトランザクション。URL "http://www.icir.org/floyd/end2end--paper.html"。
[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.、輻輳回避のためのランダム早期検出ゲートウェイ。Networking、V.1 N.4、1993年8月、P。のIEEE / ACMトランザクション397-413。
[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
[FLO94] Floyd、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] Floyd、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の最初のウィンドウを増やします。ViewGraphs、40th 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://roland.lerc.nasa.gov/~mallman/papers/nash98.ps".
[KAGT98] Hans Kruse、マークAllman、Jim Griner、Diepchi Tran。地理静止衛星リンクよりもHTTPページ転送速度1998年3月電気通信システムに関する第6回国際会議の議事録。URL "http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps"。
[Mor97] Robert Morris. Private communication, 1997. Cited for acknowledgement purposes only.
[MOR97]ロバートモリス。謝辞目的のみを引用した。
[Nic98] Kathleen Nichols. Improving Network Simulation With Feedback, Proceedings of LCN 98, October 1998. URL "http://www.computer.org/proceedings/lcn/8810/8810toc.htm".
[NIC98] Kathleen Nichols。フィードバックでネットワークシミュレーションの改善、1998年10月10日のLCN 98の議事録。URL "http://www.computer.org/proceedings/lcn/8810/8810toc.htm"。
[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月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、「インターネットホストの要求 - 通信層の要件」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J.およびS.Theuring、 "Path Mtu Discovery"、RFC 1191、1990年11月。
[RFC1945] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945] Berners-Lee、T.、Field、R.およびH.Nielsen、「Hypertext Transfer Protocol - HTTP / 1.0」、RFC 1945、1996年5月。
[RFC2068] Fielding, R., Mogul, J., Gettys, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[RFC2068] Fielding、R.、Mogul、J.、Gettys、J.、Frystyk、H.およびT.Berners-Lee、 "Hypertext Transfer Protocol - HTTP / 1.1"、RFC 2616、1997年1月。
[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] Braden、B.、Clark、D.、Crowcroft、J.、Davie、B.、The、S.、Estrin、D.、Floyd、S.、Jacobson、V.、Minshall、G.、Partridge、C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.およびL.Zhang、「インターネットにおけるキュー管理および輻輳回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] Allman、M.、Floyd、S.およびC.パーリッジ、「TCPの初期ウィンドウの増加」、RFC 2414、1998年9月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K.およびK。Nichols、1998年9月、RFC 2415、RFC 2415。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416] Shepard、T.およびC.パーリッジ、「TCPが4つのバッファだけに4つのパケットで起動したとき」、RFC 2416、1998年9月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V. W. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V.およびM. Allman、2000年11月、「TCPの再送信タイマーのコンピューティング」、RFC 2988。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042] Allman、M.、Balakrishnan、H.およびS. Floyd、「限定送信を用いたTCPの損失回復の強化」、RFC 3042、2001年1月。
[RFC3168] Ramakrishnan, K.K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.K.、Floyd、S.およびD. Black、「明示的な輻輳通知（ECN）へのECN）の追加、2001年9月。
Appendix A - Duplicate Segments
付録A - 重複セグメント
In the current environment (without Explicit Congestion Notification [Flo94] [RFC2481]), 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 arrived at the receiver.
現在の環境（明示的な輻輳通知[FLO94] [RFC2481]）では、すべてのTCPSを使用すると、利用可能な帯域幅の制限についてネットワークからの指示が表示されます。ここで、より大きな初期ウィンドウへの変更は、送信者がすでに受信者に到着した多数の重複セグメントを再送信することになるべきであると主張しています。
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 by 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, in the absence of Limited Transmit [RFC3042]. 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）1つのセグメントのウィンドウから、再送信タイムアウトの後に行われるように、またはTAHOE TCPで高速再送信の後に行われます。 （2）Reno TCPで3つの重複したACKの後に行われるように、選択的謝辞（袋）なしの高速回復（SACK）。 （3）SACKを使用した高速回復、送信者と受信者の両方がSACKオプション[MMFR96]をサポートしているTCPのための高速回復。 3つのケースすべての場合において、単一のセグメントが最初のウィンドウからドロップされた場合、重複セグメント（すなわち、受信機で既に受信されているセグメント）は送信される。最初のウィンドウで4つの512バイトのセグメントを送信するTCPの場合、単一のセグメントドロップでは再送信タイムアウトを必要とせず、高速再送信アルゴリズムを使用して回復することができます（再送信タイマーが期限切れに切れる限り）。さらに、3つのセグメントの初期ウィンドウからドロップされた単一のセグメントは、どのセグメントがドロップされ、遅延ACKが使用されているかどうかによって、高速再送信アルゴリズムを使用して修復される可能性があります。たとえば、3つのセグメント初期ウィンドウの最初のセグメントをドロップすると、トランスミットが制限されていない場合は、タイムアウトの待機を必要とします[RFC3042]。ただし、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つの可能なシナリオの検討（ここでは全く行かない）は、脱落したパケットの位置によっては、送信者がMAGEがある場合があります。重複したセグメントを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つのセグメントがドロップされると、袋がない場合は、ドロップされたセグメントの位置に応じて、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 in which more than one duplicate segment will be transmitted. Our conclusion is than the number of duplicate segments transmitted as a result of a larger initial window should be small.
概要は、袋がない場合、1つの重複セグメントが送信される最初のウィンドウから複数のセグメント降下を持つシナリオがいくつかあります。複数の重複セグメントが送信されるシナリオはありません。私たちの結論は、より大きな初期ウィンドウの結果として送信された重複セグメントの数よりも小さくなければなりません。
Author's Addresses
作者の住所
Mark Allman
BBN Technologies/NASA Glenn Research Center
21000 Brookpark Rd
MS 54-5
Cleveland, OH 44135
EMail: mallman@bbn.com
http://roland.lerc.nasa.gov/~mallman/
Sally Floyd
ICSI Center for Internet Research
1947 Center St, Suite 600
Berkeley, CA 94704
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
http://www.icir.org/floyd/
Craig Partridge BBN Technologies 10 Moulton St Cambridge, MA 02138 EMail: craig@bbn.com
Craig Partridge BBN Technologies 10 Moulton St Cambridge、MA 02138メール：craig @ bbn.com
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
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.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。