Network Working Group S. Floyd
Request for Comments: 2582 ACIRI
Category: Experimental T. Henderson
U.C. Berkeley
April 1999
The NewReno Modification to TCP's Fast Recovery Algorithm
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].
スロースタート、輻輳回避、高速再送、および高速リカバリ：RFC 2001 [RFC2001]は、以下の4つの絡み合ったTCPの輻輳制御アルゴリズムを説明します。 RFC 2581には、[RFC2581]は、明示的にすべてのデータを新しいデータをカバーするTCP選択確認応答（SACK）オプション[MMFR96]を使用して修正し、修正する「部分的確認応答を」応答する（ACKを含む、これらのアルゴリズムの特定の改変が可能ではなく、優れた損失は、SACKの不存在下で）検出されたとき。この文書では、NewRenoのと呼ばれる部分的確認応答に対応するための特定のアルゴリズムを、説明しています。部分的確認応答にこの応答は、最初の[Hoe95]でJaney鍬によって提案されました。
For the typical implementation of the TCP Fast Recovery algorithm described in [RFC2581] (first implemented in the 1990 BSD Reno release, and referred to as the Reno algorithm in [FF96]), the TCP data sender only retransmits a packet after a retransmit timeout has occurred, or after three duplicate acknowledgements have arrived triggering the Fast Retransmit algorithm. A single retransmit timeout might result in the retransmission of several data packets, but each invocation of the Reno Fast Retransmit algorithm leads to the retransmission of only a single data packet.
[RFC2581]で説明TCP高速回復アルゴリズム（第1990 BSDリノリリースで実装され、[FF96]でリノアルゴリズムとも呼ばれる）の典型的な実施のために、TCPデータ送信側は、再送タイムアウトの後にパケットを再送信します3つの重複確認応答が高速再送アルゴリズムをトリガーに到着した後に発生した、またはしています。単一再送タイムアウトは、いくつかのデータパケットの再送信につながるかもしれませんが、リノの高速再送アルゴリズムの各呼び出しは、単一のデータ・パケットの再送信につながります。
Problems can arise, therefore, when multiple packets have been dropped from a single window of data and the Fast Retransmit and Fast Recovery algorithms are invoked. In this case, if the SACK option is available, the TCP sender has the information to make intelligent decisions about which packets to retransmit and which packets not to retransmit during Fast Recovery. This document applies only for TCP connections that are unable to use the TCP Selective Acknowledgement (SACK) option.
問題は、複数のパケットは、データの単一のウィンドウから削除されていると高速再送信および高速リカバリアルゴリズムが呼び出されたときに、そのため、発生する可能性があります。 SACKオプションが利用可能な場合この場合は、TCPの送信者は、パケットを再送するかについて知的な決定を下すための情報を持っており、高速リカバリ時に再送信しないようにどのパケット。この文書では、唯一のTCP選択確認応答（SACK）オプションを使用することができないTCP接続に適用されます。
In the absence of SACK, there is little information available to the TCP sender in making retransmission decisions during Fast Recovery. From the three duplicate acknowledgements, the sender infers a packet loss, and retransmits the indicated packet. After this, the data sender could receive additional duplicate acknowledgements, as the data receiver acknowledges additional data packets that were already in flight when the sender entered Fast Retransmit.
SACKがない場合には、高速リカバリ時の再送意思決定におけるTCPの送信者が利用可能な情報はほとんどありません。 3つの重複確認応答からは、送信側はパケットロスを推測し、指示されたパケットを再送します。データ受信機は、送信者が高速再送に入ったとき、飛行中に存在していた追加のデータパケットを認識し、この後、データ送信者は、追加の重複確認応答を受け取ることができます。
In the case of multiple packets dropped from a single window of data, the first new information available to the sender comes when the sender receives an acknowledgement for the retransmitted packet (that is the packet retransmitted when Fast Retransmit was first entered). If there had been a single packet drop, then the acknowledgement for this packet will acknowledge all of the packets transmitted before Fast Retransmit was entered (in the absence of reordering). However, when there were multiple packet drops, then the acknowledgement for the retransmitted packet will acknowledge some but not all of the packets transmitted before the Fast Retransmit. We call this packet a partial acknowledgment.
複数のパケットの場合、データの単一の窓から落とさ送信者は（つまり、高速再送が最初に入力されたとき、再送パケットである）再送パケットに対する確認応答を受信すると、送信者が利用可能な最初の新しい情報が来ます。単一パケットドロップがあった場合、高速再送信は、（並べ替えのない状態で）入力された前に、このパケットの確認応答が送信されたパケットの全てを承認します。複数のパケットドロップがあったときしかし、その後、再送パケットに対する肯定応答は、いくつかのではなく、高速再送信する前に送信したパケットの全てを確認します。私たちは、このパケット部分的確認応答を呼び出します。
Along with several other suggestions, [Hoe95] suggested that during Fast Recovery the TCP data sender respond to a partial acknowledgment by inferring that the indicated packet has been lost, and retransmitting that packet. This document describes a modification to the Fast Recovery algorithm in Reno TCP that incorporates a response to partial acknowledgements received during Fast Recovery. We call this modified Fast Recovery algorithm NewReno, because it is a slight but significant variation of the basic Reno algorithm. This document does not discuss the other suggestions in [Hoe95] and [Hoe96], such as a change to the ssthresh parameter during Slow-Start, or the proposal to send a new packet for every two duplicate acknowledgements during Fast Recovery. The version of NewReno in this document also draws on other discussions of NewReno in the literature [LM97].
他のいくつかの提案に加えて、[Hoe95]高速回復中にTCPデータの送信者が指示されたパケットが失われていることを推測し、そのパケットを再送することにより、部分的確認応答に応じることが示唆されました。この文書では、高速リカバリ中に受信した部分の確認応答に対する応答を組み込んリノTCPでの高速リカバリアルゴリズムに変更を説明しています。それは、基本的なリノアルゴリズムのわずかではあるが有意な変動であるので、私たちは、この修正された高速リカバリアルゴリズムNewRenoのを呼び出します。この文書では、このようなスロー・スタート時のSSTHRESHパラメータの変更、または高速リカバリ中に2つのずつの重複確認応答のための新たなパケットを送信するための提案として、[Hoe96] [Hoe95]で他の提案を議論していません。この文書に記載されているNewRenoのバージョンも文献[LM97]でNewRenoの他の議論を描画します。
We do not claim that the NewReno version of Fast Recovery described here is an optimal modification of Fast Recovery for responding to partial acknowledgements, for TCPs that are unable to use SACK. Based on our experiences with the NewReno modification in the NS simulator [NS], we believe that this modification improves the performance of the Fast Retransmit and Fast Recovery algorithms in a wide variety of scenarios, and we are simply documenting it for the benefit of the IETF community. We encourage the use of this modification to Fast Recovery, and we further encourage feedback about operational experiences with this or related modifications.
私たちは、ここで説明する高速リカバリのNewRenoのバージョンはSACKを使用することができないのTCPのために、部分的確認応答に対応するための高速リカバリの最適な修正であることを主張しません。 NSシミュレータ[NS]でNewRenoの変更と私たちの経験に基づいて、我々はこの変更は、さまざまなシナリオでのFast RetransmitとFast Recoveryアルゴリズムのパフォーマンスを向上することが信じている、と我々は単にの利益のためにそれを文書化していますIETFコミュニティ。私たちは、高速回復へのこの変更の使用を奨励し、我々はさらに、このまたは関連する修正を加えた運用経験についてのフィードバックを奨励します。
This document assumes that the reader is familiar with the terms MAXIMUM SEGMENT SIZE (MSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE (FlightSize) defined in [RFC2581]. FLIGHT SIZE is defined as in [RFC2581] as follows:
この文書は、読者が用語最大セグメントサイズ（MSS）、輻輳ウィンドウ（CWND）、及び[RFC2581]で定義さFLIGHTサイズ（FlightSize）に精通していることを前提としています。 FLIGHTサイズは次のように[RFC2581]に次のように定義されます。
FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged.
FLIGHTサイズ：送信されたがまだ認識されているデータの量。
The standard implementation of the Fast Retransmit and Fast Recovery algorithms is given in [RFC2581]. The NewReno modification of these algorithms is given below. This NewReno modification differs from the implementation in [RFC2581] only in the introduction of the variable "recover" in step 1, and in the response to a partial or new acknowledgement in step 5. The modification defines a "Fast Recovery procedure" that begins when three duplicate ACKs are received and ends when either a retransmission timeout occurs or an ACK arrives that acknowledges all of the data up to and including the data that was outstanding when the Fast Recovery procedure began.
高速再送信及び高速回復アルゴリズムの標準的な実装は、[RFC2581]に記載されています。これらのアルゴリズムのNewRenoの変更は以下のとおりです。このNewRenoの修飾は、ステップ1で、「回復」、およびステップ5において部分的または新しい確認応答に応答して変形が始まる「高速リカバリ手順」を定義する唯一の変数の導入に[RFC2581]での実装とは異なりますとき3つの重複ACKが受信され、再送タイムアウトが発生したり、ACKがそれが高速リカバリ手順が始まったときに優れたデータを含むまで、データのすべてを認めて到着したいずれかの時点で終了しています。
1. When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, set ssthresh to no more than the value given in equation 1 below. (This is equation 3 from [RFC2581]).
1.第三の重複ACKが受信され、送信者は、以下の数式1で与えられた値を超えないようにSSTHRESH設定、高速リカバリ手順で既にではない場合。 （これは[RFC2581]から式3です）。
ssthresh = max (FlightSize / 2, 2*MSS) (1)
SSTHRESH = MAX（FlightSize / 2、2 * MSS）（1）
Record the highest sequence number transmitted in the variable "recover".
変数「回復」に送信され、最も高いシーケンス番号を記録します。
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered.
2.失われたセグメントと設定SSTHRESHするのcwndプラス3 * MSSを再送します。これは、人工的に、受信機がバッファリングしているネットワークとを残しているセグメント（3）の数で輻輳ウィンドウを「膨張します」。
3. For each additional duplicate ACK received, increment cwnd by MSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.
ACKが受信された各追加の重複3.、MSSによりcwndを増加。これは人為的にネットワークから離脱した追加のセグメントを反映するために、輻輳ウィンドウを膨張させます。
4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window.
CWNDの新しい値と受信機の広告ウィンドウによって許可されている場合4.セグメントを送信します。
5. When an ACK arrives that acknowledges new data, this ACK could be the acknowledgment elicited by the retransmission from step 2, or elicited by a later retransmission.
ACKは、それが新たなデータを認識到着すると5.は、このACKは確認応答は、ステップ2からの再送によって誘発される、またはそれ以降の再送によって誘発することができます。
If this ACK acknowledges all of the data up to and including
"recover", then the ACK acknowledges all the intermediate
segments sent between the original transmission of the lost
segment and the receipt of the third duplicate ACK. Set cwnd to
either (1) min (ssthresh, FlightSize + MSS); or (2) ssthresh,
where ssthresh is the value set in step 1; this is termed
"deflating" the window. (We note that "FlightSize" in step 1
referred to the amount of data outstanding in step 1, when Fast
Recovery was entered, while "FlightSize" in step 5 refers to the
amount of data outstanding in step 5, when Fast Recovery is
exited.) If the second option is selected, the implementation
should take measures to avoid a possible burst of data, in case
the amount of data outstanding in the network was much less than
the new congestion window allows [HTH98]. Exit the Fast Recovery
procedure.
If this ACK does *not* acknowledge all of the data up to and including "recover", then this is a partial ACK. In this case, retransmit the first unacknowledged segment. Deflate the congestion window by the amount of new data acknowledged, then add back one MSS and send a new segment if permitted by the new value of cwnd. This "partial window deflation" attempts to ensure that, when Fast Recovery eventually ends, approximately ssthresh amount of data will be outstanding in the network. Do not exit the Fast Recovery procedure (i.e., if any duplicate ACKs subsequently arrive, execute Steps 3 and 4 above).
このACKは、* *までのすべてのデータを確認し、「回復」を含めない場合、これは部分的ACKです。この場合、最初の不承認のセグメントを再送します。 cwndの新しい値で許可された場合に認められ、新たなデータの量によって輻輳ウィンドウを収縮して、再び1つのMSSを追加し、新しいセグメントを送信します。この「部分ウィンドウデフレは、」高速リカバリが最終的に終了したときにデータの約SSTHRESH量がネットワークに優れただろう、それを確実にしようとします。高速リカバリ手順を終了していない（重複ACKが続いて到着した場合、すなわち、上記のステップ3および4を実行します）。
For the first partial ACK that arrives during Fast Recovery, also reset the retransmit timer.
高速回復中に到着した最初の部分ACKのために、また、再送信タイマーをリセットします。
Note that in Step 5, the congestion window is deflated when a partial acknowledgement is received. The congestion window was likely to have been inflated considerably when the partial acknowledgement was received. In addition, depending on the original pattern of packet losses, the partial acknowledgement might acknowledge nearly a window of data. In this case, if the congestion window was not deflated, the data sender might be able to send nearly a window of data back-to-back.
部分的確認応答を受信したとき、ステップ5において、輻輳ウィンドウが収縮されることに注意してください。輻輳ウィンドウは、部分的な承認を受けたときはかなり膨張されている可能性が高いでした。また、パケットロスの元のパターンに応じて、部分的な承認は、データのほとんど窓を認める場合があります。輻輳ウィンドウが収縮されなかった場合は、この場合には、データの送信者は、バックツーバック近いデータのウィンドウを送信することができるかもしれません。
There are several possible variants to the simple response to partial acknowledgements described above. First, there is a question of when to reset the retransmit timer after a partial acknowledgement. This is discussed further in Section 4 below.
上記の部分的確認応答に、単純な応答には、いくつかの可能なバリエーションがあります。まず、部分的に承認した後に再送信タイマーをリセットする際の問題があります。これは、以下の第4節で詳しく説明されています。
There is a related question of how many packets to retransmit after each partial acknowledgement. The algorithm described above retransmits a single packet after each partial acknowledgement. This is the most conservative alternative, in that it is the least likely to result in an unnecessarily-retransmitted packet. A variant that would recover faster from a window with many packet drops would be to effectively Slow-Start, requiring less than N roundtrip times to recover from N losses [Hoe96]. With this slightly-more-aggressive response to partial acknowledgements, it would be advantageous to reset the retransmit timer after each retransmission. Because we have not experimented with this variant in our simulator, we do not discuss this variant further in this document.
各部分承認後に再送信するためにどのように多くのパケットの関連する質問があります。上述のアルゴリズムは、各部分の肯定応答後に単一のパケットを再送します。これは、不必要に、再送パケットが発生する可能性が高い以上であることで、最も保守的な代替手段です。多くのパケットで窓から速く回復するの変異体は、N損失[Hoe96]から回復するためにN未満の往復時間を必要とする、効果的にスロースタートをすることです落ちます。部分的確認応答に、このわずかにより、積極的な応答と、それぞれの再送信の後に再送信タイマーをリセットすることが有利であろう。私たちは私たちのシミュレータでこのバリアントを試していないので、私たちは、この文書ではさらにこの変形については説明しません。
A third question involves avoiding multiple Fast Retransmits caused by the retransmission of packets already received by the receiver. This is discussed in Section 5 below. Avoiding multiple Fast Retransmits is particularly important if more aggressive responses to partial acknowledgements are implemented, because in this case the sender is more likely to retransmit packets already received by the receiver.
第三の問題は、すでに受信機によって受信されたパケットの再送信によって引き起こされる複数の高速再送を回避することを含みます。これは、以下のセクション5で議論されています。部分的確認応答に、より積極的な応答が実装されている場合は、この場合には、送信者がすでに受信機が受信したパケットを再送する可能性が高いので、複数のファスト再送信を回避することは、特に重要です。
As a final note, we would observe that in the absence of the SACK option, the data sender is working from limited information. One could spend a great deal of time considering exactly which variant of Fast Recovery is optimal for which scenario in this case. When the issue of recovery from multiple dropped packets from a single window of data is of particular importance, the best alternative would be to use the SACK option.
最後の注意として、私たちはSACKオプションが存在しない場合に、データの送信者が限られた情報から作業されていることを確認します。一つは、高速回復の変種が、この場合どのシナリオに最適であるかを正確に考慮する多大な時間を過ごすことができました。複数からの回復の問題は特に重要であるデータの単一のウィンドウからのパケットをドロップすると、最善の選択肢は、SACKオプションを使用することです。
The algorithm in Section 3 resets the retransmit timer only after the first partial ACK. In this case, if a large number of packets were dropped from a window of data, the TCP data sender's retransmit timer will ultimately expire, and the TCP data sender will invoke Slow-Start. (This is illustrated on page 12 of [F98].) We call this the Impatient variant of NewReno.
第3節でのアルゴリズムは、第1の部分ACKの後に再送信タイマーをリセットします。大量のパケットがデータの窓から落とされた場合この場合、TCPデータ送信側の再送信タイマーは、最終的に期限切れになり、TCPデータ送信側はスロースタート起動します。 （これは、[F98]の12ページに示されている。）私たちは、NewRenoののせっかちバリアントこれを呼び出します。
In contrast, the NewReno simulations in [FF96] illustrate the algorithm described above, with the modification that the retransmit timer is reset after each partial acknowledgement. We call this the Slow-but-Steady variant of NewReno. In this case, for a window with a large number of packet drops, the TCP data sender retransmits at most one packet per roundtrip time. (This behavior is illustrated in the New-Reno TCP simulation of Figure 5 in [FF96], and on page 11 of [F98].)
対照的に、[FF96]でNewRenoのシミュレーションは、再送タイマが各部分肯定応答後にリセットされる変更と、上述のアルゴリズムを示します。私たちは、NewRenoのの着実な低速であるがバリアントこれを呼び出します。この場合、パケットドロップの数が多いと窓ため、TCPデータ送信者は往復時間あたり最大で1つのパケットを再送します。 （この動作は[FF96]であり、[F98]の11ページの図5の新リノTCPシミュレーションで示されています。）
For TCP implementations where the Retransmission Timeout Value (RTO) is generally not much larger than the round-trip time (RTT), the Impatient variant can result in a retransmit timeout even in a scenario with a small number of packet drops. For TCP implementations where the Retransmission Timeout Value (RTO) is usually considerably larger than the round-trip time (RTT), the Slow-but-Steady variant can remain in Fast Recovery for a long time when multiple packets have been dropped from a window of data. Neither of these variants are optimal; one possibility for a more optimal algorithm might be one that recovered more quickly from multiple packet drops, and combined this with the Slow-but-Steady variant in terms of resetting the retransmit timers. We note, however, that there is a limitation to the potential performance in this case in the absence of the SACK option.
再送タイムアウト値（RTO）は、一般的にはるかに大きいラウンドトリップ時間（RTT）以下であるTCPの実装では、せっかち変異体であってもパケットドロップ数が少ないシナリオでは再送タイムアウトをもたらすことができます。再送タイムアウト値（RTO）は通常のラウンドトリップ時間（RTT）よりもかなり大きいTCPの実装では、定常スローが、バリアントは、複数のパケットが窓から落ちてきた長い時間のために高速リカバリに留まることができますデータの。これらの変異体のどちらが最適です。より最適なアルゴリズムの一つの可能性は、より迅速に、複数のパケットドロップから回収し、再送信タイマーをリセットするという点で着実に低速であるがバリアントでこれを組み合わせて1つかもしれません。私たちは、SACKオプションが存在しない場合に、この場合の潜在的なパフォーマンスには限界があること、しかし、注意してください。
In the absence of the SACK option, a duplicate acknowledgement carries no information to identify the data packet or packets at the TCP data receiver that triggered that duplicate acknowledgement. The TCP data sender is unable to distinguish between a duplicate acknowledgement that results from a lost or delayed data packet, and a duplicate acknowledgement that results from the sender's retransmission of a data packet that had already been received at the TCP data receiver. Because of this, multiple segment losses from a single window of data can sometimes result in unnecessary multiple Fast Retransmits (and multiple reductions of the congestion window) [Flo94].
SACKオプションの非存在下で、重複確認応答は、重複確認応答をトリガーし、TCPデータ受信装置でデータ・パケットまたはパケットを識別するための情報を全く運びません。 TCPデータの送信者が損失または遅延したデータパケットから得られる重複確認応答、およびすでにTCPデータ受信機で受信されたデータパケットの送信者の再送信の結果で重複確認応答を区別することができません。このため、データの単一のウィンドウから複数のセグメント損失は、しばしば不要複数の高速再送信（および輻輳ウィンドウの複数減少）Flo94]をもたらすことができます。
With the Fast Retransmit and Fast Recovery algorithms in Reno or NewReno TCP, the performance problems caused by multiple Fast Retransmits are relatively minor (compared to the potential problems with Tahoe TCP, which does not implement Fast Recovery). Nevertheless, unnecessary Fast Retransmits can occur with Reno or NewReno TCP, particularly if a Retransmit Timeout occurs during Fast Recovery. (This is illustrated for Reno on page 6 of [F98], and for NewReno on page 8 of [F98].) With NewReno, the data sender remains in Fast Recovery until either a Retransmit Timeout, or until all of the data outstanding when Fast Retransmit was entered has been acknowledged. Thus with NewReno, the problem of multiple Fast Retransmits from a single window of data can only occur after a Retransmit Timeout.
リノまたはNewRenoのTCPでのFast RetransmitとFast Recoveryアルゴリズムでは、複数のファスト再送信に起因するパフォーマンスの問題は、（高速リカバリを実装していないタホTCPの潜在的な問題、と比較して）比較的軽微なものです。それにもかかわらず、不必要な高速再送信は、再送信タイムアウトは高速回復中に発生した場合は特に、リノまたはNewRenoのTCPで発生する可能性があります。 （これは、[F98]の8ページ、およびNewRenoのために[F98]の6ページのリノのために例示されている。）NewRenoのでは、データの送信者が再送信タイムアウトするまで、高速リカバリのまま、あるいは優れたデータの全てまで入力された高速再送信が認められています。したがってNewRenoので、データの単一のウィンドウから複数の高速再送信の問題は再送タイムアウトの後に発生する可能性があります。
The following modification to the algorithms in Section 3 eliminates the problem of multiple Fast Retransmits. (This modification is called "bugfix" in [F98], and is illustrated on pages 7 and 9.) This modification uses a new variable "send_high", whose initial value is the initial send sequence number. After each retransmit timeout, the highest sequence numbers transmitted so far is recorded in the variable "send_high".
第3節ではアルゴリズムに以下の変更は、複数の高速再送信の問題を解消します。この変更は、その初期値を初期送信シーケンス番号である新しい変数「send_high」を、使用しています（この変更は、[F98]で「バグ修正」と呼ばれ、ページ7および9に示されています）。各再送タイムアウトの後、これまでに送信され、最も高いシーケンス番号を変数「send_high」に記録されています。
If, after a retransmit timeout, the TCP data sender retransmits three consecutive packets that have already been received by the data receiver, then the TCP data sender will receive three duplicate acknowledgements that do not acknowledge "send_high". In this case, the duplicate acknowledgements are not an indication of a new instance of congestion. They are simply an indication that the sender has unnecessarily retransmitted at least three packets.
、再送タイムアウトの後、TCPデータ送信側は、既にデータ受信機によって受信された三つの連続するパケットを再送する場合は、TCPデータの送信者が「send_high」認めていない3つの重複確認応答を受信します。この場合には、重複確認応答は、輻輳の新しいインスタンスの指標ではありません。彼らは、単に送信者が不必要に少なくとも3つのパケットを再送信していることを示しています。
We note that if the TCP data sender receives three duplicate acknowledgements that do not acknowledge "send_high", the sender does not know whether these duplicate acknowledgements resulted from a new packet drop or not. For a TCP that implements the bugfix described in this section for avoiding multiple fast retransmits, the sender does not infer a packet drop from duplicate acknowledgements in these circumstances. As always, the retransmit timer is the backup mechanism for inferring packet loss in this case.
私たちは、TCPデータの送信者が「send_high」認めていない3つの重複確認応答を受信した場合、送信者はこれらの重複確認応答が新たなパケットドロップに起因するかどうかわからないことに注意してください。複数の高速再送を回避するため、このセクションで説明するバグ修正を実装してTCPの場合は、送信者は、このような状況で重複確認応答のパケットドロップを推測することはありません。いつものように、再送信タイマは、この場合には、パケットロスを推測するためのバックアップメカニズムです。
The modification to Fast Retransmit for avoiding multiple Fast Retransmits replaces Step 1 in Section 3 with Step 1A below. In addition, the modification adds Step 6 below:
複数のファスト再送信を回避するための高速再送信への修正は、以下の工程1Aと第3のステップ1を置き換えます。また、変更は、以下のステップ6を追加します。
1A. When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, check to see if those duplicate ACKs cover more than "send_high". If they do, then set ssthresh to no more than the value given in equation 1, record the the highest sequence number transmitted in the variable "recover", and go to Step 2. If the duplicate ACKs don't cover "send_high", then do nothing. That is, do not enter the Fast Retransmit and Fast Recovery procedure, do not change ssthresh, do not go to Step 2 to retransmit the "lost" segment, and do not execute Step 3 upon subsequent duplicate ACKs.
1A。第三の重複ACKを受信し、送信側が高速リカバリ手順になっていないされている場合、それらの重複ACKが「send_high」以上をカバーするかどうかを確認します。彼らは、その後、式1で与えられた値を超えないようにSSTHRESHを設定しない場合、重複ACKは「send_high」カバーしていない場合は、「回復」、およびステップ2に進みます。変数に送信され、最も高いシーケンス番号を記録し、その後、何もしません。つまり、SSTHRESHを変更しない、高速再送信および高速リカバリ手順を入力しないと、「失われた」セグメントを再送するステップ2に行っていない、とその後の重複ACKの際にステップ3を実行しないでください。
Steps 2-5 are the same as those steps in Section 3 above.
ステップ2-5は、上記第3のもの工程と同じです。
6. After a retransmit timeout, record the highest sequence number transmitted in the variable "send_high" and exit the Fast Recovery procedure if applicable.
6.再送タイムアウトの後、変数「send_high」で送信された最大のシーケンス番号を記録し、該当する場合、高速リカバリ手順を終了します。
Step 1A above, in checking whether the duplicate ACKs cover *more* than "send_high", is the Careful variant of this algorithm. Another possible variant would be to require simply that the three duplicate acknowledgements *cover* "send_high" before initiating another Fast Retransmit. We call this the Less Careful variant to Fast Retransmit.
上記のステップ1Aは、重複ACKは「send_high」より* *以上をカバーするかどうかを確認するには、このアルゴリズムの慎重な変形です。別の可能な変異体は、別の高速再送信を開始する前に、3つの重複確認応答が*カバー*「send_high」単に必要とするだろう。私たちは、この高速再送信にはあまり慎重にバリアントを呼び出します。
There are two separate scenarios in which the TCP sender could receive three duplicate acknowledgements acknowledging "send_high" but no more than "send_high". One scenario would be that the data sender transmitted four packets with sequence numbers higher than "send_high", that the first packet was dropped in the network, and the following three packets triggered three duplicate acknowledgements acknowledging "send_high". The second scenario would be that the sender unnecessarily retransmitted three packets below "send_high", and that these three packets triggered three duplicate acknowledgements acknowledging "send_high". In the absence of SACK, the TCP sender in unable to distinguish between these two scenarios.
TCPの送信者が「send_high」ではなく「send_high」を超えないと認める3つの重複確認応答を受け取ることができた二つの別々のシナリオがあります。 1つのシナリオは、データの送信者が最初のパケットがネットワークで落とされたことを、「send_high」よりも高いシーケンス番号を持つ4つのパケットを送信し、次の3つのパケットが「send_high」認める3重複確認応答を引き起こしたということでしょう。 2つ目のシナリオでは、送信者が不必要に「send_high」以下の3つのパケットを再送することを、これらの3つのパケットが「send_high」認める3重複確認応答を引き起こしたということでしょう。 SACK、これらの2つのシナリオを区別することができませんでしにおけるTCP送信者が存在しない場合には。
For the Careful variant of Fast Retransmit, the data sender would have to wait for a retransmit timeout in the first scenario, but would not have an unnecessary Fast Retransmit in the second scenario. For the Less Careful variant to Fast Retransmit, the data sender would Fast Retransmit as desired in the first scenario, and would unnecessarily Fast Retransmit in the second scenario. The NS simulator has implemented the Less Careful variant of NewReno, and the TCP implementation in Sun's Solaris 7 implements the Careful variant. This document recommends the Careful variant given in Step 1A above.
高速再送信の慎重なバリエーションのために、データの送信者は、最初のシナリオでは再送タイムアウトを待たなければならないだろうが、2つ目のシナリオでは不要の高速再送信を持っていないでしょう。最初のシナリオでは、所望のように高速再送信にはあまり慎重な変異体について、データ送信側は再送信ファストなり、そして第2のシナリオであろう不必要に高速再送。 NSシミュレータはNewRenoのの少ない慎重なバリエーションを実施している、とSunのSolaris 7の中にTCPの実装は慎重にバリアントを実装しています。この文書では、上記の工程1Aで与えられた慎重なバリアントを推奨しています。
[RFC2001] specifies that "Out-of-order data segments SHOULD be acknowledged immediately, in order to trigger the fast retransmit algorithm." Neal Cardwell has noted [C98] that some data receivers do not send an immediate acknowledgement when they send a partial acknowledgment, but instead wait first for their delayed acknowledgement timer to expire. As [C98] notes, this severely limits the potential benefit from NewReno by delaying the receipt of the partial acknowledgement at the data sender. Our recommendation is that the data receiver send an immediate acknowledgement for an out-of-order segment, even when that out-of-order segment fills a hole in the buffer.
[RFC2001]は、「アウト・オブ・オーダーのデータセグメントは、高速再送アルゴリズムをトリガするために、すぐに認められるべきである。」ことを指定しますニールカードウェルは、いくつかのデータ受信機は、彼らが部分的に確認応答を送信するときにすぐに確認応答を送信が、その遅延確認応答タイマーが期限切れになるようにするために代わりに最初の待機しないこと[C98]指摘しています。 [C98]のノートのように、これは深刻なデータ送信側で部分的確認応答の受信を遅延させることによってNewRenoのからの潜在的な利点を制限します。我々の推奨は、アウト・オブ・オーダのセグメントは、バッファ内の穴を満たす場合でも、データ受信機がアウトオブオーダセグメントに対する即時確認応答を送信することです。
Simulations with NewReno are illustrated with the validation test "tcl/test/test-all-newreno" in the NS simulator. The command "../../ns test-suite-newreno.tcl reno" shows a simulation with Reno TCP, illustrating the data sender's lack of response to a partial acknowledgement. In contrast, the command "../../ns test-suite-newreno.tcl newreno_B" shows a simulation with the same scenario using the NewReno algorithms described in this paper.
NewRenoのとシミュレーションはNSシミュレータで検証テスト「TCL /試験/試験全NewRenoの」と示されています。コマンド「../../nsテストスイート-newreno.tclリノは、」部分的確認応答に対する応答のデータ送信者の欠如を示す、リノTCPとのシミュレーションを示しています。対照的に、コマンド「../../nsテストスイート-newreno.tcl newreno_B」は本稿で説明NewRenoのアルゴリズムを使用して、同じシナリオにシミュレーションを示します。
The tests "../../ns test-suite-newreno.tcl newreno1_B0" and "../../ns test-suite-newreno.tcl newreno1_B" show the Slow-but-Steady and the Impatient variants of NewReno, respectively.
テスト「../../nsテスト・スイート・newreno.tcl newreno1_B0" と」../../nsテストスイート-newreno.tcl newreno1_Bは」低速であるが着実とNewRenoののせっかち変種を示して、それぞれ。
Our recommendation is that TCP implementations include the NewReno modification to the Fast Recovery algorithm given in Section 3, along with the modification for avoiding multiple Fast Retransmits given in Section 5. The NewReno modification given in Section 3 can be important even for TCP implementations that support the SACK option, because the SACK option can only be used for TCP connections when both TCP end-nodes support the SACK option. The NewReno modification given in Section 3 implements the Impatient rather than the Slow-but-Steady variant of NewReno.
私たちの推薦はTCPの実装は第5節で与えられた複数のファスト再送信を回避するための修正に伴い、第3節で与えられた高速回復アルゴリズムへのNewRenoの変更が含まれる第3節で与えられたNewRenoの変更もサポートするTCPの実装のために重要であることができるということですSACKオプション、TCPエンドノードの両方がSACKオプションをサポートするときSACKオプションが唯一のTCP接続に使用することができるからです。第3に示すNewRenoの修飾は、せっかちではなく、NewRenoの定常スローなくバリアントを実装します。
While this document mentions several possible variations to the NewReno algorithm, we have not explored all of these possible variations, and therefore are unable to make recommendations about some of them. Our belief is that the differences between any two variants of NewReno are small compared to the differences between Reno and NewReno. That is, the important thing is to implement NewReno instead of Reno, for a TCP invocation without SACK; it is less important exactly which variant of NewReno is implemented.
このドキュメントはNewRenoのアルゴリズムにいくつかの可能なバリエーションを言及しながら、我々はこれらの可能なバリエーションのすべてを探求するため、それらのいくつかについての提言を行うことができないしていません。私たちの信念はNewRenoのうちの任意の2つのバリアント間の違いはリノとNewRenoの間の違いに比べて小さいということです。それは重要なことは、SACKなしTCPの呼び出しのために、代わりにリノのNewRenoのを実装することで、あります。それはNewRenoののバリアントが実装されているかを正確にそれほど重要ではありません。
Many thanks to Anil Agarwal, Mark Allman, Vern Paxson, Kacheong Poon, and Bernie Volz for detailed feedback on this document.
このドキュメントの詳細なフィードバックのためのアニルAgarwalさん、マーク・オールマン、バーン・パクソン、Kacheongプーン、バーニーフォルツに感謝します。
[C98] Neal Cardwell, "delayed ACKs for retransmitted packets: ouch!". November 1998. Email to the tcpimpl mailing list, Message-ID "Pine.LNX.4.02A.9811021421340.26785- 100000@sake.cs.washington.edu", archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[C98]ニールカードウェルは、「再送パケットのためのACKを遅らせ：痛いです！」。 「http://tcp-impl.lerc.nasa.govにアーカイブtcpimplメーリングリストへ1998年11月の電子メール、メッセージID「Pine.LNX.4.02A.9811021421340.26785- 100000@sake.cs.washington.edu」、 / TCP-IMPL」。
[F98] Sally Floyd. Revisions to RFC 2001. Presentation to the TCPIMPL Working Group, August 1998. URLs "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".
[F98]サリー・フロイド。 //ftp.ee.lbl：RFC 2001 TCPIMPLワーキンググループへのプレゼンテーション、1998年8月のURL「ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps」と「FTPの改訂.GOV /交渉/ SF-tcpimpl-aug98.pdf」。
[FF96] Kevin Fall and Sally Floyd. Simulation-based
[FF96]ケビン・秋とサリーフロイド。シミュレーションベース
Comparisons of Tahoe, Reno and SACK TCP. Computer
Communication Review, July 1996. URL
"ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. URL "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[Flo94] S.フロイド、TCPおよび連続高速再送信します。技術報告書、1994年10月URL「ftp://ftp.ee.lbl.gov/papers/fastretrans.ps」。
[Hen98] Tom Henderson, Re: NewReno and the 2001 Revision. September 1998. Email to the tcpimpl mailing list, Message ID "Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU", archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[Hen98]トム・ヘンダーソン、RE：NewRenoの年と2001年改訂。 「http://tcp-impl.lerc.nasa.gov/にアーカイブtcpimplメーリングリスト、メッセージID「Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU」を1998年9月の電子メール、 TCP-のimpl」。
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995. URL "http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps".
【Hoe95] J.鍬、TCPの輻輳制御と回避スキームの起動ダイナミクス。修士論文、MIT、1995年URL "http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps"。
[Hoe96] J. Hoe, "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", In ACM SIGCOMM, August 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".
ACM SIGCOMM、1996年8月URL「http://www.acm.org/sigcomm/sigcomm96/program.html」では、「TCP輻輳制御方式のスタート・アップ挙動を改善」[Hoe96] J.鍬、 。
[HTH98] Hughes, A., Touch, J. and J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress, March 1998.
[HTH98]ヒューズ、A.、タッチ、J.とJ. Heidemann、 "TCPアイドルの後にスロースタートの再起動での問題"、進歩、1998年3月での作業。
[LM97] Dong Lin and Robert Morris, "Dynamics of Random Early Detection", SIGCOMM 97, September 1997. URL "http://www.acm.org/sigcomm/sigcomm97/program.html".
[LM97]ドン林とロバート・モリス、「ランダム早期検出のダイナミクス」、SIGCOMM 97、1997年9月URL「http://www.acm.org/sigcomm/sigcomm97/program.html」。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
【MMFR96]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[NS] The UCB/LBNL/VINT Network Simulator (NS). URL "http://www-mash.cs.berkeley.edu/ns/".
[NS] UCB / LBNL / VINTネットワークシミュレータ（NS）。 URL "http://www-mash.cs.berkeley.edu/ns/"。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。
[RFC2581] Stevens, W., Allman, M. and V. Paxson, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]スティーブンス、W.、オールマン、M.およびV.パクソン、 "TCP輻輳制御"、RFC 2581、1999年4月。
RFC 2581 discusses general security considerations concerning TCP congestion control. This document describes a specific algorithm that conforms with the congestion control requirements of RFC 2581, and so those considerations apply to this algorithm, too. There are no known additional security concerns for this specific algorithm.
RFC 2581は、TCPの輻輳制御に関する一般的なセキュリティの考慮事項について説明します。この文書は、RFC 2581の輻輳制御要件に準拠する特定のアルゴリズムを記述し、そのため、これらの考慮事項は、あまりにも、このアルゴリズムに適用されます。この特定のアルゴリズムには知られている追加のセキュリティ上の懸念はありません。
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
サリーフロイドAT＆T ICSIでのインターネット研究センター（ACIRI）
Phone: +1 (510) 642-4274 x189 EMail: floyd@acm.org URL: http://www.aciri.org/floyd/
電話：+1（510）642-4274 x189メール：floyd@acm.org URL：http://www.aciri.org/floyd/
Tom Henderson University of California at Berkeley
カリフォルニア大学バークレー校のトム・ヘンダーソン大学
Phone: +1 (510) 642-8919 EMail: tomh@cs.berkeley.edu URL: http://www.cs.berkeley.edu/~tomh/
電話：+1（510）642-8919 Eメール：tomh@cs.berkeley.edu URL：http://www.cs.berkeley.edu/~tomh/
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。