Network Working Group S. Floyd
Request for Comments: 3782 ICSI
Obsoletes: 2582 T. Henderson
Category: Standards Track Boeing
A. Gurtov
TeliaSonera
April 2004
The NewReno Modification to TCP's Fast Recovery Algorithm
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
このドキュメントの目的は、実験的な標準化へのトラックの状態から、RFC 2582にNewRenoのTCPのFast RetransmitとFast Recoveryアルゴリズムを進めることです。
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP.
RFC 2582には、この文書の相対での主な変更点は、NewRenoのの高速再送と高速リカバリアルゴリズムを慎重にバリアントを指定することです。 RFC 2582に記載の塩基アルゴリズムは、タイムアウト後に発生する可能性があり、不必要な複数のファスト再送信を避けるためにしようとしませんでした。ただし、RFC 2582にも「慎重な」定義されており、これらの不要な高速再送信を避けるため、「あまり慎重な」変異体、および慎重なバリエーションをお勧めします。この文書では、NewRenoのTCPの基本的なバージョンとして、以前に命名「慎重な」バリアントを指定します。
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 Fast Retransmit algorithm in RFC 2581 leads to the retransmission of only a single data packet.
[RFC2581]で説明TCP高速回復アルゴリズム（第1990 BSDリノリリースで実装され、[FF96]でリノアルゴリズムとも呼ばれる）の典型的な実施のために、TCPデータ送信側は、再送タイムアウトの後にパケットを再送信します3つの重複確認応答が高速再送アルゴリズムをトリガーに到着した後に発生した、またはしています。単一再送タイムアウトは、いくつかのデータパケットの再送信につながるかもしれないが、RFC 2581での高速再送アルゴリズムの各呼び出しは、単一のデータ・パケットの再送信につながります。
Problems can arise, therefore, when multiple packets are 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, either because the option is not locally supported or because the TCP peer did not indicate a willingness to use SACK.
複数のパケットは、データの単一のウィンドウとFast RetransmitとFast Recoveryアルゴリズムが呼び出されるからドロップされると、問題は、それゆえ、発生する可能性があります。 SACKオプションが利用可能な場合この場合は、TCPの送信者は、パケットを再送するかについて知的な決定を下すための情報を持っており、高速リカバリ時に再送信しないようにどのパケット。このドキュメントでは、TCPピアがSACKを使用する意欲を示すものではありませんでしたので、オプションがローカルでサポートされたりされていないかので、唯一の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 is a single packet drop and no reordering, then the acknowledgement for this packet will acknowledge all of the packets transmitted before Fast Retransmit was entered. However, if there are 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 acknowledgement a partial acknowledgment.
複数のパケットの場合、データの単一の窓から落とさ送信者は（つまり、高速再送が最初に入力されたとき、再送パケットである）再送パケットに対する確認応答を受信すると、送信者が利用可能な最初の新しい情報が来ます。単一パケットドロップなし並べ替えがある場合は、高速再送が入力された前に、このパケットの確認応答が送信されたパケットの全てを承認します。複数のパケットドロップがある場合は、その後、再送パケットに対する肯定応答は、いくつかのではなく、高速再送信する前に送信したパケットの全てを確認します。我々は、部分的な承認この承認を呼び出します。
Along with several other suggestions, [Hoe95] suggested that during Fast Recovery the TCP data sender responds to a partial acknowledgment by inferring that the next in-sequence packet has been lost, and retransmitting that packet. This document describes a modification to the Fast Recovery algorithm in RFC 2581 that incorporates a response to partial acknowledgements received during
他のいくつかの提案に加えて、[Hoe95]高速回復中にTCPデータの送信者は、次のインシーケンスパケットが失われていることを推測し、そのパケットを再送することにより、部分的確認応答に応答することを示唆しました。この文書では、中に受信した部分の確認応答に対する応答を組み込んだRFC 2581での高速リカバリアルゴリズムに変更を説明します
Fast Recovery. We call this modified Fast Recovery algorithm NewReno, because it is a slight but significant variation of the basic Reno algorithm in RFC 2581. 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, Hen98].
早い回復。それはこの文書では、このようなSSTHRESHへの変更など、他[Hoe95]で提案して[Hoe96]を、議論していないRFC 2581での基本的なリノアルゴリズムのわずかではあるが有意な変動があるので、私たちは、この修正された高速リカバリアルゴリズムのNewRenoのを呼び出しますスロースタート時のパラメータ、または高速リカバリ中に2つのずつの重複確認応答のための新たなパケットを送信するために提案。この文書に記載されているNewRenoのバージョンも文献[LM97、Hen98]で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 TCP connections that are unable to use SACK. Based on our experiences with the NewReno modification in the NS simulator [NS] and with numerous implementations of NewReno, we believe that this modification improves the performance of the Fast Retransmit and Fast Recovery algorithms in a wide variety of scenarios.
私たちは、ここで説明する高速リカバリのNewRenoのバージョンはSACKを使用することができないのTCP接続のために、部分的確認応答に対応するための高速リカバリの最適な修正であることを主張しません。 NSシミュレータ[NS]でとNewRenoの多数の実装とNewRenoの変更と私たちの経験に基づいて、我々はこの変更は、さまざまなシナリオでの高速再送と高速リカバリアルゴリズムの性能を向上させると信じています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. This RFC indicates requirement levels for compliant TCP implementations implementing the NewReno Fast Retransmit and Fast Recovery algorithms described in this document.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119 [RFC2119]に記載されているように解釈されるべきです。このRFCは、本書に記載さNewRenoの高速再送信および高速リカバリアルゴリズムを実装対応のTCPの実装のために要件レベルを示しています。
This document assumes that the reader is familiar with the terms SENDER MAXIMUM SEGMENT SIZE (SMSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE (FlightSize) defined in [RFC2581]. FLIGHT SIZE is defined as in [RFC2581] as follows:
この文書は、読者が[RFC2581]で定義された用語SENDER最大セグメントサイズ（SMSS）、輻輳ウィンドウ（CWND）、飛行SIZE（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]. This section specifies the basic NewReno algorithm. Sections 4 through 6 describe some optional variants, and the motivations behind them, that an implementor may want to consider when tuning performance for certain network scenarios. Sections 7 and 8 provide some guidance to implementors based on experience with NewReno implementations.
高速再送信及び高速回復アルゴリズムの標準的な実装は、[RFC2581]に記載されています。このセクションでは、基本的なNewRenoのアルゴリズムを指定します。 〜6節4は、実装者が特定のネットワークシナリオのパフォーマンスをチューニングする際に検討する必要がありますことを、いくつかのオプションの変異体、およびそれらの背後にある動機を説明します。セクション7および8は、NewRenoの実装と経験に基づいて実装するためにいくつかのガイダンスを提供します。
The NewReno modification concerns the 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.
NewRenoの変更は3つの重複ACKを受信したときに始まる高速リカバリ手順に関する再送タイムアウトのいずれかが発生したときに終了するかACKはそれが最大と高速リカバリ手順が始まったときに優れたデータを含むデータのすべてを認めて到着しました。
The NewReno algorithm specified in this document differs from the implementation in [RFC2581] in the introduction of the variable "recover" in step 1, in the response to a partial or new acknowledgement in step 5, and in modifications to step 1 and the addition of step 6 for avoiding multiple Fast Retransmits caused by the retransmission of packets already received by the receiver.
この文書で指定されたNewRenoのアルゴリズムは、ステップ5で部分的または新しい確認応答に応答して、ステップ1に変更に、ステップ1で「回復」変数の導入[RFC2581]での実装とは異なり、またすでに受信機によって受信されたパケットの再送信によって引き起こされる複数の高速再送信を回避するステップ6。
The algorithm specified in this document uses a variable "recover", whose initial value is the initial send sequence number.
この文書で指定されたアルゴリズムは、その初期値を初期送信シーケンス番号で、「回復」の変数を使用しています。
1) Three duplicate ACKs: When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, check to see if the Cumulative Acknowledgement field covers more than "recover". If so, go to Step 1A. Otherwise, go to Step 1B.
1）三個の重複ACK：第三の重複ACKが受信されると、送信者は、高速リカバリ手順になっていない場合は、累積確認応答フィールドが「回復」以上をカバーしていないか確認してください。その場合は、1Aに進みます。それ以外の場合は、図1（b）に進みます。
1A) Invoking Fast Retransmit: If so, then set ssthresh to no more than the value given in equation 1 below. (This is equation 3 from [RFC2581]).
高速再送信を起動1A）：これは、以下の式1で与えられた値以下にSSTHRESHを設定した場合。 （これは[RFC2581]から式3です）。
ssthresh = max (FlightSize / 2, 2*SMSS) (1)
SSTHRESH = MAX（FlightSize / 2、2 * SMSS）（1）
In addition, record the highest sequence number transmitted in the variable "recover", and go to Step 2.
また、変数「回復」に送信され、最も高いシーケンス番号を記録し、ステップ2に進みます。
1B) Not invoking Fast Retransmit: Do not enter the Fast Retransmit and Fast Recovery procedure. In particular, 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.
図1（b））の高速再送信を呼び出していない：高速再送と高速リカバリ手順を入力しないでください。特に、SSTHRESHを変更しない、「失われた」セグメントを再送するステップ2に行っていない、とその後の重複ACKの際にステップ3を実行しないでください。
2) Entering Fast Retransmit: Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and the receiver has buffered.
2）高速再送を入力：失われたセグメントと設定のcwnd SSTHRESHするプラス3 *のSMSSを再送。これは、人工的にネットワークから離脱しており、受信機がバッファリングしているセグメントの数（3つ）によって輻輳ウィンドウを「膨張します」。
3) Fast Recovery: For each additional duplicate ACK received while in Fast Recovery, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.
3）高速リカバリ：高速リカバリに、増分はSMSSによりcwndをしながら、ACKが受信された各追加の重複について。これは人為的にネットワークから離脱した追加のセグメントを反映するために、輻輳ウィンドウを膨張させます。
4) Fast Recovery, continued: Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window.
4）高速回復、継続的な：のcwndの新しい値と受信者の広告ウィンドウによって許可されている場合、セグメントを送信します。
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からの再送によって誘発される、またはそれ以降の再送によって誘発することができます。
Full acknowledgements:
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 + SMSS) 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 is
encouraged to take measures to avoid a possible burst of data, in
case the amount of data outstanding in the network is much less
than the new congestion window allows. A simple mechanism is to
limit the number of data packets that can be sent in response to
a single acknowledgement; this is known as "maxburst_" in the NS
simulator. Exit the Fast Recovery procedure.
Partial acknowledgements: 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 by the cumulative acknowledgement field. If the partial ACK acknowledges at least one SMSS of new data, then add back SMSS bytes to the congestion window. As in Step 3, this artificially inflates the congestion window in order to reflect the additional segment that has left the network. 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です。この場合、最初の不承認のセグメントを再送します。累積確認応答フィールドによって認め、新たなデータの量によって輻輳ウィンドウを収縮。パーシャルACKが新しいデータの少なくとも1 SMSSを認める場合には、輻輳ウィンドウにSMSSバイトを再度追加。ステップ3のように、これは人為的にネットワークから離脱した追加セグメントを反映するために輻輳ウィンドウを膨張させます。 cwndの新しい値によって許可されている場合、新しいセグメントを送信します。この「部分ウィンドウデフレは、」高速リカバリが最終的に終了したときにデータの約SSTHRESH量がネットワークに優れただろう、それを確実にしようとします。高速リカバリ手順を終了していない（重複ACKが続いて到着した場合、すなわち、上記のステップ3および4を実行します）。
For the first partial ACK that arrives during Fast Recovery, also reset the retransmit timer. Timer management is discussed in more detail in Section 4.
高速回復中に到着した最初の部分ACKのために、また、再送信タイマーをリセットします。タイマ管理は、第4章で詳しく説明されています。
6) Retransmit timeouts: After a retransmit timeout, record the highest sequence number transmitted in the variable "recover" and exit the Fast Recovery procedure if applicable.
6）再送信のタイムアウト：再送タイムアウトの後、変数「回復」と該当する場合は、高速リカバリ手順を終了して送信シーケンス番号が最大を記録します。
Step 1 specifies a check that the Cumulative Acknowledgement field covers more than "recover". Because the acknowledgement field contains the sequence number that the sender next expects to receive, the acknowledgement "ack_number" covers more than "recover" when:
ステップ1は、累積確認応答フィールドが「回復」以上をカバーしていることを確認を指定します。確認応答フィールドは、送信者が次の時に「回復」よりもカバー「ack_number」、確認応答を受信することを期待シーケンス番号が含まれているため。
ack_number - 1 > recover;
ack_number - 1>回復。
i.e., at least one byte more of data is acknowledged beyond the highest byte that was outstanding when Fast Retransmit was last entered.
すなわち、データのより少なくとも1バイトの高速再送信が最後に入力されたときに優れた最上位バイトを超えて認められています。
Note that in Step 5, the congestion window is deflated after 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において、輻輳ウィンドウが収縮されることに注意してください。輻輳ウィンドウは、部分的な承認を受けたときはかなり膨張されている可能性が高いでした。また、パケットロスの元のパターンに応じて、部分的な承認は、データのほとんど窓を認める場合があります。輻輳ウィンドウが収縮されなかった場合は、この場合には、データの送信者は、バックツーバック近いデータのウィンドウを送信することができるかもしれません。
This document does not specify the sender's response to duplicate ACKs when the Fast Retransmit/Fast Recovery algorithm is not invoked. This is addressed in other documents, such as those describing the Limited Transmit procedure [RFC3042]. This document also does not address issues of adjusting the duplicate acknowledgement threshold, but assumes the threshold specified in the IETF standards; the current standard is RFC 2581, which specifies a threshold of three duplicate acknowledgements.
この文書では、高速再送/高速リカバリアルゴリズムが呼び出されていない場合のACKを複製するために、送信者の応答を指定しません。これは、限定の送信手順を説明するものなどの他のドキュメント、[RFC3042]でアドレス指定されます。この文書はまた、重複確認応答のしきい値を調整する問題に対処するが、IETF標準で指定されたしきい値を負いません。現在の標準は3つの重複確認応答のしきい値を指定するRFC 2581、です。
As a final note, we would observe that in the absence of the SACK option, the data sender is working from limited information. 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オプションを使用することです。
4. Resetting the Retransmit Timer in Response to Partial Acknowledgements
4.部分謝辞に応じて再送信タイマーをリセット
One possible variant to the response to partial acknowledgements specified in Section 3 concerns when to reset the retransmit timer after a partial acknowledgement. The algorithm in Section 3, Step 5, 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. We note that the Impatient variant in Section 3 doesn't follow the recommended algorithm in RFC 2988 of restarting the retransmit timer after every packet transmission or retransmission [RFC2988, Step 5.1].
部分的に承認した後に再送信タイマーをリセットするとき、第3節の懸念に指定された部分の確認応答に応じに対する1つの可能な変種。第3節では、アルゴリズム、ステップ5は、最初の部分的ACKの後に再送信タイマーをリセットします。大量のパケットがデータの窓から落とされた場合この場合、TCPデータ送信側の再送信タイマーは、最終的に期限切れになり、TCPデータ送信側はスロースタート起動します。 （これは、[F98]の12ページに示されている。）私たちは、NewRenoののせっかちバリアントこれを呼び出します。私たちは、3節でせっかち変異体は、すべてのパケット送信または再送信[RFC2988、ステップ5.1]の後に再送信タイマーを再起動するのRFC 2988で推奨アルゴリズムに従っていないことに注意してください。
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シミュレーションで示されています）。
When N packets have been dropped from a window of data for a large value of N, the Slow-but-Steady variant can remain in Fast Recovery for N round-trip times, retransmitting one more dropped packet each round-trip time; for these scenarios, the Impatient variant gives a faster recovery and better performance. The tests "ns test-suite-newreno.tcl impatient1" and "ns test-suite-newreno.tcl slow1" in the NS simulator illustrate such a scenario, where the Impatient variant performs better than the Slow-but-Steady variant. The Impatient variant can be particularly important for TCP connections with large congestion windows, as illustrated by the tests "ns test-suite-newreno.tcl impatient4" and "ns test-suite-newreno.tcl slow4" in the NS simulator.
NパケットがNの値が大きいため、データの窓から落ちてきた場合には、定常スローが、バリアントは、1以上の各ラウンドトリップ時間、パケットドロップ再送信、N往復時間のための高速回復にとどまることができます。これらのシナリオのために、せっかちな変種は、より速く回復し、優れたパフォーマンスを提供します。 NSシミュレータでテスト「NSテストスイート-newreno.tcl impatient1」及び「NS試験スイート-newreno.tcl SLOW1は」せっかち変異体が定常スローしかし、変異体よりも良好に機能するようなシナリオを示しています。 NSシミュレータでテスト「NSテスト・スイート・newreno.tcl impatient4」と「NSは、テスト・スイート・newreno.tcl slow4」によって示されるようにせっかち変異体は、大混雑窓のTCP接続のために特に重要となり得ます。
One can also construct scenarios where the Slow-but-Steady variant gives better performance than the Impatient variant. As an example, this occurs when only a small number of packets are dropped, the RTO is sufficiently small that the retransmit timer expires, and performance would have been better without a retransmit timeout. The tests "ns test-suite-newreno.tcl impatient2" and "ns test-suite-newreno.tcl slow2" in the NS simulator illustrate such a scenario.
一つは、また、安定した低速であるがバリアントはせっかちバリアントよりも優れたパフォーマンスを提供するシナリオを構築することができます。パケットのほんの数がドロップされたときの例のように、これは、RTOは再送タイマが満了したことを十分に小さく発生し、パフォーマンスが再送タイムアウトせずにもっと良かったはず。 NSシミュレータでテスト「NSテストスイート-newreno.tcl impatient2」及び「NS試験スイート-newreno.tcl SLOW2」は、そのようなシナリオを示しています。
The Slow-but-Steady variant can also achieve higher goodput than the Impatient variant, by avoiding unnecessary retransmissions. This could be of special interest for cellular links, where every transmission costs battery power and money. The tests "ns test-suite-newreno.tcl impatient3" and "ns test-suite-newreno.tcl slow3" in the NS simulator illustrate such a scenario. The Slow-but-Steady variant can also be more robust to delay variation in the network, where a delay spike might force the Impatient variant into a timeout and go-back-N recovery.
定常低速であるが変異体はまた、不必要な再送信を回避することにより、せっかちな変種よりも高いグッドプットを達成することができます。これは、すべての送信は、バッテリ電源とお金がかかるセルラーリンク、のために特別な関心がある可能性があります。 NSシミュレータでテスト「NSテストスイート-newreno.tcl impatient3」及び「NS試験スイート-newreno.tcl slow3」は、そのようなシナリオを示しています。定常低速であるが変異体はまた遅延スパイクがタイムアウトにせっかちバリアントを強制し、回復バック-Nの行くかもしれないネットワークに変化を遅らせるために、より堅牢にすることができます。
Neither of the two variants discussed above are optimal. Our recommendation is for the Impatient variant, as specified in Section 3 of this document, because of the poor performance of the Slow-but-Steady variant for TCP connections with large congestion windows.
上記の二つの変形のどちらが最適です。私たちの推薦は大きいため、輻輳ウィンドウとのTCP接続のための安定した低速であるがバリアントのパフォーマンスの低下のため、このドキュメントのセクション3で指定されるように、せっかちなバリエーションのためです。
One possibility for a more optimal algorithm would be one that recovered from multiple packet drops as quickly as does slow-start, while resetting the retransmit timers after each partial acknowledgement, as described in the section below. We note, however, that there is a limitation to the potential performance in this case in the absence of the SACK option.
より最適なアルゴリズムの一つの可能性は、以下のセクションで説明したように、各部分の肯定応答の後再送タイマーをリセットしながら、早くスロースタートと同様に低下する複数のパケットから回収されたものであろう。私たちは、SACKオプションが存在しない場合に、この場合の潜在的なパフォーマンスには限界があること、しかし、注意してください。
One possible variant to the response to partial acknowledgements specified in Section 3 would be to retransmit more than one packet after each partial acknowledgement, and to reset the retransmit timer after each retransmission. The algorithm specified in Section 3 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, retransmitting two packets after each partial acknowledgement. Such an approach would take less than N roundtrip times to recover from N losses [Hoe96]. However, in the absence of SACK, recovering as quickly as slow-start introduces the likelihood of unnecessarily retransmitting packets, and this could significantly complicate the recovery mechanisms.
第3節で指定された部分の確認応答に応じに対する1つの可能な変形は、各部分承認後に複数のパケットを再送信するために、それぞれの再送信の後に再送信タイマーをリセットすることです。第3節で指定されたアルゴリズムは、各部分承認後に単一のパケットを再送します。これは、不必要に、再送パケットが発生する可能性が高い以上であることで、最も保守的な代替手段です。多くのパケットで窓から速く回復するバリアントは、各部分の確認応答の後に2つのパケットを再送する、効果的にスロースタートになり下がります。このようなアプローチは、N損失[Hoe96]から回復するためにNの往復時間未満を取るでしょう。しかし、SACKが存在しない場合に、早くとしてスロースタートを回復することは不必要に再送信するパケットの可能性を紹介し、これは大幅に回復メカニズムを複雑にし得ます。
We note that the response to partial acknowledgements specified in Section 3 of this document and in RFC 2582 differs from the response in [FF96], even though both approaches only retransmit one packet in response to a partial acknowledgement. Step 5 of Section 3 specifies that the TCP sender responds to a partial ACK by deflating the congestion window by the amount of new data acknowledged, adding back SMSS bytes if the partial ACK acknowledges at least SMSS bytes of new data, and sending a new segment if permitted by the new value of cwnd. Thus, only one previously-sent packet is retransmitted in response to each partial acknowledgement, but additional new packets might be transmitted as well, depending on the amount of new data acknowledged by the partial acknowledgement. In contrast, the variant of NewReno illustrated in [FF96] simply set the congestion window to ssthresh when a partial acknowledgement was received. The approach in [FF96] is more conservative, and does not attempt to accurately track the actual number of outstanding packets after a partial acknowledgement is received. While either of these approaches gives acceptable performance, the variant specified in Section 3 recovers more smoothly when multiple packets are dropped
我々は両方のアプローチは部分的にしか確認に応答して、1つのパケットを再送するにもかかわらず、このドキュメントのセクション3にし、RFC 2582で指定された部分の確認応答に対する応答は、[FF96]での応答と異なっていることに注意してください。第3のステップ5は、TCPの送信者が認めた、新しいデータの量によって輻輳ウィンドウを収縮パーシャルACKが新しいデータの少なくともSMSSバイトを認識した場合、バックSMSSバイトを追加し、新しいセグメントを送信することにより、部分的ACKに応答することを指定しますcwndの新しい値によって許可されている場合。このように、一つだけ以前に送られたパケットは、各部分の確認応答に応じて再送されていますが、追加の新しいパケットは、部分的な承認により認め、新たなデータの量に応じて、同様に送信される可能性があります。対照的に、[FF96]に示すNewRenoのの変異体は、単に部分的肯定応答が受信されたときにSSTHRESHする混雑ウィンドウを設定します。 [FF96]でのアプローチは、より保守的であり、そして部分的確認応答が受信された後に正確に未処理パケットの実際の数を追跡しようとしません。これらのアプローチのいずれかが許容可能な性能を提供しながら、複数のパケットがドロップされた場合、変異体は、よりスムーズに、セクション3で指定された回復
from a window of data. (The [FF96] behavior can be seen in the NS simulator by setting the variable "partial_window_deflation_" for "Agent/TCP/Newreno" to 0; the behavior specified in Section 3 is achieved by setting "partial_window_deflation_" to 1.)
データの窓から。 （[FF96]挙動は0に「エージェント/ TCP / NewRenoの」の変数「partial_window_deflation_」を設定することにより、NSシミュレータで見ることができ、セクション3で指定された動作は、1に「partial_window_deflation_」を設定することによって達成されます）
This section describes the motivation for the sender's state variable "recover", and discusses possible heuristics for distinguishing between a retransmitted packet that was dropped, and three duplicate acknowledgements from the unnecessary retransmission of three packets.
このセクションでは、「回復」送信者の状態変数の動機を説明し、ドロップされた再送パケット、および3つのパケットの不必要な再送信から3つの重複確認応答を区別するための可能なヒューリスティックを説明します。
In the absence of the SACK option or timestamps, a duplicate acknowledgement carries no information to identify the data packet or packets at the TCP data receiver that triggered that duplicate acknowledgement. In this case, 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 unnecessary retransmission of a data packet that had already been received at the TCP data receiver. Because of this, with the Retransmit and Fast Recovery algorithms in Reno TCP, multiple segment losses from a single window of data can sometimes result in unnecessary multiple Fast Retransmits (and multiple reductions of the congestion window) [F94].
SACKオプションまたはタイムスタンプの不存在下で、重複確認応答は、重複確認応答をトリガーし、TCPデータ受信装置でデータ・パケットまたはパケットを識別するための情報を全く運びません。この場合、TCPデータの送信者が損失または遅延したデータパケットから得られる重複確認応答、およびすでにTCPデータで受信されたデータパケットの送信者の不必要な再送信の結果で重複確認応答を区別することができません受信機。このため、リノTCPにおける再送と高速回復アルゴリズムを用いて、データの単一のウィンドウから複数のセグメント損失は、しばしば不要複数の高速再送信（および輻輳ウィンドウの複数減少）[F94]をもたらすことができます。
With the Fast Retransmit and Fast Recovery algorithms in Reno 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 TCP unless some explicit mechanism is added to avoid this, such as the use of the "recover" variable. (This modification is called "bugfix" in [F98], and is illustrated on pages 7 and 9 of that document. Unnecessary Fast Retransmits for Reno without "bugfix" is illustrated on page 6 of [F98].)
リノTCPでのFast RetransmitとFast Recoveryアルゴリズムでは、複数のファスト再送信に起因するパフォーマンスの問題は、高速リカバリを実装していませんタホTCP、潜在的な問題に比べて比較的軽微なものです。いくつかの明示的なメカニズムは、そのような「回復」変数の使用など、この問題を回避するために追加されていない限り、それにもかかわらず、不必要な高速再送信はリノTCPで発生する可能性があります。 （この変更は、[F98]に「バグ修正」と呼ばれ、その文書のページ7および9に示されている。リノに不要な高速再送信が「バグ修正」することなく、[F98]のページ6に示されています。）
Section 3 of [RFC2582] defined a default variant of NewReno TCP that did not use the variable "recover", and did not check if duplicate ACKs cover the variable "recover" before invoking Fast Retransmit. With this default variant from RFC 2582, the problem of multiple Fast Retransmits from a single window of data can occur after a Retransmit Timeout (as in page 8 of [F98]) or in scenarios with reordering (as in the validation test "./test-all-newreno newreno5_noBF" in directory "tcl/test" of the NS simulator. This gives performance similar to that on page 8 of [F03].) RFC 2582 also defined Careful and Less Careful variants of the NewReno algorithm, and recommended the Careful variant.
[RFC2582]のセクション3は、「回復する」、および重複ACKが変数をカバーしているかどうかを確認していない高速再送信を起動する前に「回復」変数を使用しなかったNewRenoのTCPのデフォルトのバリアントを定義しました。 RFC 2582からのこのデフォルトの変種では、データの単一のウィンドウから複数の高速再送信の問題は、（[F98]の8ページのように）再送信タイムアウト後、または（「検証テストのように並べ替えとのシナリオで発生する可能性があります./テストすべて-NewRenoのnewreno5_noBF NSシミュレータのTCL /テスト 『」ディレクトリに』。これは、[F03]の8ページと同様のパフォーマンスを提供します。）RFC 2582はまた、NewRenoのアルゴリズムを慎重かつ少ない慎重なバリアントを定義し、推奨慎重な変種。
The algorithm specified in Section 3 of this document corresponds to the Careful variant of NewReno TCP from RFC 2582, and eliminates the problem of multiple Fast Retransmits. This algorithm uses the variable "recover", whose initial value is the initial send sequence number. After each retransmit timeout, the highest sequence number transmitted so far is recorded in the variable "recover".
このドキュメントのセクション3で指定されたアルゴリズムは、RFC 2582からNewRenoのTCPの慎重なバリエーションに対応し、複数の高速再送信の問題を解消します。このアルゴリズムは、その初期値を初期送信シーケンス番号で、「回復」の変数を使用しています。各再送タイムアウトの後、これまでに送信され、最も高いシーケンス番号が変数「回復」に記録されています。
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 cover more than "recover". 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データの送信者が「回復」以上のものをカバーしていない3つの重複確認応答を受信します。この場合には、重複確認応答は、輻輳の新しいインスタンスの指標ではありません。彼らは、単に送信者が不必要に少なくとも3つのパケットを再送信していることを示しています。
However, when a retransmitted packet is itself dropped, the sender can also receive three duplicate acknowledgements that do not cover more than "recover". In this case, the sender would have been better off if it had initiated Fast Retransmit. For a TCP that implements the algorithm specified in Section 3 of this document, the sender does not infer a packet drop from duplicate acknowledgements in this scenario. As always, the retransmit timer is the backup mechanism for inferring packet loss in this case.
しかし、再送パケットが自身であるとき、送信者はまた、「回復」以上をカバーしていない3つの重複確認応答を受け取ることができ、落下。この場合、送信者は、それが高速再送信を開始した場合のほうだったでしょう。このドキュメントのセクション3で指定したアルゴリズムを実装するTCPの場合、送信者は、このシナリオでは、重複確認応答のパケットドロップを推測することはありません。いつものように、再送信タイマは、この場合には、パケットロスを推測するためのバックアップメカニズムです。
There are several heuristics, based on timestamps or on the amount of advancement of the cumulative acknowledgement field, that allow the sender to distinguish, in some cases, between three duplicate acknowledgements following a retransmitted packet that was dropped, and three duplicate acknowledgements from the unnecessary retransmission of three packets [Gur03, GF04]. The TCP sender MAY use such a heuristic to decide to invoke a Fast Retransmit in some cases, even when the three duplicate acknowledgements do not cover more than "recover".
送信者が区別できるようにするタイムスタンプにまたは累積確認応答フィールドの前進量に基づいていくつかの経験則では、ドロップされた再送パケットを次の三つの重複確認応答、および不要の3つの重複確認応答の間、いくつかのケースではありますが、 3個のパケット[Gur03、GF04]の再送。 TCPの送信者は3つの重複確認応答が「回復」以上をカバーしていない場合でも、いくつかのケースでは、高速再送信を起動することを決定するために、このようなヒューリスティックを使用するかもしれません。
For example, when three duplicate acknowledgements are caused by the unnecessary retransmission of three packets, this is likely to be accompanied by the cumulative acknowledgement field advancing by at least four segments. Similarly, a heuristic based on timestamps uses the fact that when there is a hole in the sequence space, the timestamp echoed in the duplicate acknowledgement is the timestamp of the most recent data packet that advanced the cumulative acknowledgement field [RFC1323]. If timestamps are used, and the sender stores the timestamp of the last acknowledged segment, then the timestamp echoed by duplicate acknowledgements can be used to distinguish between a retransmitted packet that was dropped and three duplicate acknowledgements from the unnecessary retransmission of three packets. The heuristics are illustrated in the NS simulator in the validation test "./test-all-newreno".
3つの重複確認応答が3つのパケットの不必要な再送信によって引き起こされる場合、例えば、これは、少なくとも4つのセグメントにより前進累積確認応答フィールドが付随する可能性があります。同様に、タイムスタンプに基づいてヒューリスティックは、シーケンス空間に穴があることを利用し、重複確認応答にエコータイムスタンプは、累積確認応答フィールド[RFC1323]を高度な最新のデータパケットのタイムスタンプです。タイムスタンプが最後に認めセグメントのタイムスタンプを使用し、送信元の店舗されている場合は、重複確認応答でエコータイムスタンプがドロップされた再送パケットと3つのパケットの不必要な再送信から3つの重複確認応答を区別するために使用することができます。ヒューリスティックは、検証テスト「./test-all-newreno」にNSシミュレータに例示されています。
If the ACK-based heuristic is used, then following the advancement of the cumulative acknowledgement field, the sender stores the value of the previous cumulative acknowledgement as prev_highest_ack, and stores the latest cumulative ACK as highest_ack. In addition, the following step is performed if Step 1 in Section 3 fails, before proceeding to Step 1B.
ACKベースのヒューリスティックが使用されている場合には、累積確認応答フィールドの進歩以下、送信元の店舗prev_highest_ackとして以前の累積的な承認の値、およびhighest_ackなど最新の累積ACKを格納します。第3のステップ1に障害が発生した場合に加えて、次のステップは、図1Bのステップに進む前に、行われます。
1*) If the Cumulative Acknowledgement field didn't cover more than "recover", check to see if the congestion window is greater than SMSS bytes and the difference between highest_ack and prev_highest_ack is at most 4*SMSS bytes. If true, duplicate ACKs indicate a lost segment (proceed to Step 1A in Section 3). Otherwise, duplicate ACKs likely result from unnecessary retransmissions (proceed to Step 1B in Section 3).
累積確認応答フィールドが「回復」以上をカバーしていない場合は1 *）、輻輳ウィンドウは、SMSSバイトよりも大きく、highest_ackとprev_highest_ack間の差はほとんど4 *のSMSSバイトであるかどうかを確認します。 trueの場合、重複ACK（セクション3 1Aに進み）、失われたセグメントを示します。不要な再送信（セクション3で1Bに進み）からそれ以外の場合は、重複ACKおそらく結果。
The congestion window check serves to protect against fast retransmit immediately after a retransmit timeout, similar to the "exitFastRetrans_" variable in NS. Examples of applying the ACK heuristic are in validation tests "./test-all-newreno newreno_rto_loss_ack" and "./test-all-newreno newreno_rto_dup_ack" in directory "tcl/test" of the NS simulator.
輻輳ウィンドウのチェックはすぐにNSで「exitFastRetrans_」変数に似て再送タイムアウト、後に高速再送から保護するのに役立ちます。 ACKヒューリスティックを適用した例としては、検証テストNSシミュレータのディレクトリ 『TCL /テスト』で「./test-all-newreno newreno_rto_loss_ack」と「./test-all-newreno newreno_rto_dup_ack」です。
If several ACKs are lost, the sender can see a jump in the cumulative ACK of more than three segments, and the heuristic can fail. A validation test for this scenario is "./test-all-newreno newreno_rto_loss_ackf". RFC 2581 recommends that a receiver should send duplicate ACKs for every out-of-order data packet, such as a data packet received during Fast Recovery. The ACK heuristic is more likely to fail if the receiver does not follow this advice, because then a smaller number of ACK losses are needed to produce a sufficient jump in the cumulative ACK.
いくつかのACKが失われた場合、送信者は以上の三つのセグメントの累積ACKでジャンプを見ることができる、とヒューリスティックは失敗する可能性があります。このシナリオの検証テストは、「./test-all-newreno newreno_rto_loss_ackf」です。 RFC 2581は、受信機は、このような高速回復中に受信したデータパケットとして、すべてのアウトオブオーダーデータパケットの重複ACKを送信する必要がありますことをお勧めします。 ACKヒューリスティックは、ACK損失の少ない数は累積ACKで十分なジャンプを生成するために必要とされているため、受信機は、このアドバイスに従わない場合は失敗する可能性が高いです。
If this heuristic is used, the sender stores the timestamp of the last acknowledged segment. In addition, the second paragraph of step 1 in Section 3 is replaced as follows:
このヒューリスティックを使用する場合、送信側は最後認めセグメントのタイムスタンプを格納します。次のように加えて、第3のステップ1の第2段落は、置換されています。
1**) If the Cumulative Acknowledgement field didn't cover more than "recover", check to see if the echoed timestamp in the last non-duplicate acknowledgment equals the stored timestamp. If true, duplicate ACKs indicate a lost segment (proceed to Step 1A in Section 3). Otherwise, duplicate ACKs likely result from unnecessary retransmissions (proceed to Step 1B in Section 3).
1 **）累積確認応答フィールドが「回復」以上をカバーしていない場合は、最後の非重複確認応答におけるエコータイムスタンプが保存されたタイムスタンプと等しいかどうかを確認します。 trueの場合、重複ACK（セクション3 1Aに進み）、失われたセグメントを示します。不要な再送信（セクション3で1Bに進み）からそれ以外の場合は、重複ACKおそらく結果。
Examples of applying the timestamp heuristic are in validation tests "./test-all-newreno newreno_rto_loss_tsh" and "./test-all-newreno newreno_rto_dup_tsh". The timestamp heuristic works correctly, both when the receiver echoes timestamps as specified by [RFC1323], and by its revision attempts. However, if the receiver arbitrarily echoes timestamps, the heuristic can fail. The heuristic can also fail if a timeout was spurious and returning ACKs are not from retransmitted segments. This can be prevented by detection algorithms such as [RFC3522].
タイムスタンプヒューリスティックを適用した例としては、検証テスト「./test-all-newreno newreno_rto_loss_tsh」と「./test-all-newreno newreno_rto_dup_tsh」です。タイムスタンプヒューリスティックが正常に動作し、両方の[RFC1323]によって、およびその改訂試行によって指定されるように、受信機は、タイムスタンプをエコーします。受信機が任意にタイムスタンプをエコーする場合は、ヒューリスティックは失敗する可能性があります。タイムアウトがスプリアスた場合ヒューリスティックも失敗することができますし、戻ってACKが再送されたセグメントからではありません。これは、[RFC3522]のような検出アルゴリズムによって防止することができます。
[RFC2581] specifies that "Out-of-order data segments SHOULD be acknowledged immediately, in order to accelerate loss recovery." Neal Cardwell has noted 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 [C98]. As [C98] notes, this severely limits the potential benefit of NewReno by delaying the receipt of the partial acknowledgement at the data sender. Echoing RFC 2581, 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.
[RFC2581]は、「アウト・オブ・オーダーのデータセグメントが損失回復を促進するために、すぐに認められるべきである。」ことを指定しますニールカードウェルは、いくつかのデータ受信機は、彼らが部分的に確認応答を送信するときにすぐに確認応答を送信、代わりに期限切れにその遅延確認応答タイマー[C98]のための最初の待機していないことを指摘しています。 [C98]のノートのように、これは深刻なデータ送信側で部分的確認応答の受信を遅延させることによりNewRenoのの潜在的な利点を制限します。 RFC 2581をエコー、我々の推奨は、アウト・オブ・オーダのセグメントは、バッファ内の穴を充填する場合にも、データ受信機は、アウト・オブ・オーダのセグメントのための即時の確認応答を送信することです。
In Section 3, Step 5 above, it is noted that implementations should take measures to avoid a possible burst of data when leaving Fast Recovery, in case the amount of new data that the sender is eligible to send due to the new value of the congestion window is large. This can arise during NewReno when ACKs are lost or treated as pure window updates, thereby causing the sender to underestimate the number of new segments that can be sent during the recovery procedure. Specifically, bursts can occur when the FlightSize is much less than the new congestion window when exiting from Fast Recovery. One simple mechanism to avoid a burst of data when leaving Fast Recovery is to limit the number of data packets that can be sent in response to a single acknowledgment. (This is known as "maxburst_" in the ns simulator.) Other possible mechanisms for avoiding bursts include rate-based pacing, or setting the slow-start threshold to the resultant congestion window and then resetting the congestion window to FlightSize. A recommendation on the general mechanism to avoid excessively bursty sending patterns is outside the scope of this document.
第3節では、ステップ上記5は、高速リカバリを離れる際に実装が輻輳の新しい値にする場合には、送信者が送信する資格があること、新たなデータの量をデータの可能性のあるバーストを回避するための措置をとるべきであることに留意されたいです窓が大きいです。 ACKがそれによって回復手順中に送信することができる新たなセグメントの数を過小評価するために、送信者を引き起こして、失われたまたは純粋なウィンドウの更新として扱われるとき、これはNewRenoの間に生じ得ます。高速リカバリから出たときにFlightSizeが新しい輻輳ウィンドウよりもはるかに小さい場合に具体的に、バーストが発生する可能性があります。高速リカバリを離れる際にデータのバーストを回避する1つの単純なメカニズムは、単一の確認応答に応答して送信できるデータパケットの数を制限することです。 （これは、NSシミュレータの「maxburst_」として知られている。）バーストを回避するための他の可能なメカニズムは、レートベースのペーシングを含む、または得られた混雑ウィンドウと遅い開始臨界値を設定した後FlightSizeに輻輳ウィンドウをリセットします。過剰バースト性送信パターンを回避するための一般的な機構に推薦は、この文書の範囲外です。
An implementation may want to use a separate flag to record whether or not it is presently in the Fast Recovery procedure. The use of the value of the duplicate acknowledgment counter for this purpose is not reliable because it can be reset upon window updates and out-of-order acknowledgments.
実装は、それが高速リカバリ手順に現在あるかどうかを記録するために別のフラグを使用することをお勧めします。それは、ウィンドウの更新やアウトオブオーダー確認応答時にリセットすることができますので、この目的のために重複確認応答カウンタの値を使用することは信頼できるものではありません。
When not in Fast Recovery, the value of the state variable "recover" should be pulled along with the value of the state variable for acknowledgments (typically, "snd_una") so that, when large amounts of data have been sent and acked, the sequence space does not wrap and falsely indicate that Fast Recovery should not be entered (Section 3, step 1, last paragraph).
ない高速リカバリでは、変数の状態の値が「回復」すると確認応答の状態変数の値と一緒に引かれるべき（通常は、「snd_una」）大量のデータを送信し、ACKされた場合、そのので、スペースが誤ってラップしない配列は、高速リカバリ（セクション3、ステップ1、最後の段落）に入力すべきではないことを示しています。
It is important for the sender to respond correctly to duplicate ACKs received when the sender is no longer in Fast Recovery (e.g., because of a Retransmit Timeout). The Limited Transmit procedure [RFC3042] describes possible responses to the first and second duplicate acknowledgements. When three or more duplicate acknowledgements are received, the Cumulative Acknowledgement field doesn't cover more than "recover", and a new Fast Recovery is not invoked, it is important that the sender not execute the Fast Recovery steps (3) and (4) in Section 3. Otherwise, the sender could end up in a chain of spurious timeouts. We mention this only because several NewReno implementations had this bug, including the implementation in the NS simulator. (This bug in the NS simulator was fixed in July 2003, with the variable "exitFastRetrans_".)
送信者は送信者が（理由は再送信タイムアウトのため、例えば）高速回復されなくなったときにACKが受信複製しないように正しく応答することが重要です。限定送信手順[RFC3042]は第一および第二の重複確認応答に可能な応答を記述する。三の以上の重複確認応答が受信されると、累積確認応答フィールドは、「回復」、および新しい高速リカバリが起動されていない以上をカバーしていない、送信者が高速リカバリ手順を実行しないことが重要である（3）と（4 ）それ以外の場合は第3節では、送信者は、スプリアスタイムアウトの連鎖で終わることができました。我々はいくつかのNewRenoの実装はNSシミュレータでの実装を含む、このバグを持っていたという理由だけでこれを言及します。 （NSシミュレータではこのバグは、変数「exitFastRetrans_」で、2003年7月に修正されました。）
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のアルゴリズムを使用して、同じシナリオにシミュレーションを示します。
As we stated in the introduction, we believe that the NewReno modification described in this document improves the performance of the Fast Retransmit and Fast Recovery algorithms of Reno TCP in a wide variety of scenarios. This has been discussed in some depth in [FF96], which illustrates Reno TCP's poor performance when multiple packets are dropped from a window of data and also illustrates NewReno TCP's good performance in that scenario.
私たちは冒頭で述べたように、私たちは、この文書で説明したNewRenoの変更は、さまざまなシナリオでのリノTCPの高速再送信および高速リカバリアルゴリズムの性能を向上させると信じています。これは、複数のパケットがデータのウィンドウから削除されリノTCPのパフォーマンスの低下を示し、また、そのシナリオでNewRenoのTCPの良好な性能を示しており、[FF96]である深さで議論されています。
We do, however, know of one scenario where Reno TCP gives better performance than NewReno TCP, that we describe here for the sake of completeness. Consider a scenario with no packet loss, but with sufficient reordering so that the TCP sender receives three duplicate acknowledgements. This will trigger the Fast Retransmit and Fast Recovery algorithms. With Reno TCP or with Sack TCP, this will result in the unnecessary retransmission of a single packet, combined with a halving of the congestion window (shown on pages 4 and 6 of [F03]). With NewReno TCP, however, this reordering will also result in the unnecessary retransmission of an entire window of data (shown on page 5 of [F03]).
私たちは、しかし、我々は完全を期すために、ここで説明していること、リノTCPはNewRenoのTCPよりも高いパフォーマンスを提供します1つのシナリオを知っています。 TCPの送信側が3つの重複確認応答を受け取るようにしますが、十分な並べ替えと、パケットロスとのシナリオを検討してください。これは、Fast RetransmitとFast Recoveryアルゴリズムをトリガします。リノTCPまたは袋TCPと、これは輻輳ウィンドウ（[F03]のページ4及び6に示されている）の半分と組み合わせる単一のパケットの不必要な再送信をもたらすであろう。 NewRenoのTCPと、ただし、この並べ替えは、（[F03]のページ5に示されている）データのウィンドウ全体の不要な再送信をもたらすであろう。
While Reno TCP performs better than NewReno TCP in the presence of reordering, NewReno's superior performance in the presence of multiple packet drops generally outweighs its less optimal performance in the presence of reordering. (Sack TCP is the preferred solution, with good performance in both scenarios.) This document recommends the Fast Retransmit and Fast Recovery algorithms of NewReno TCP instead of those of Reno TCP for those TCP connections that do not support SACK. We would also note that NewReno's Fast Retransmit and Fast Recovery mechanisms are widely deployed in TCP implementations in the Internet today, as documented in [PF01]. For example, tests of TCP implementations in several thousand web servers in 2001 showed that for those TCP connections where the web browser was not SACK-capable, more web servers used the Fast Retransmit and Fast Recovery algorithms of NewReno than those of Reno or Tahoe TCP [PF01].
リノTCPは、並べ替えの存在下でのNewRenoのTCPよりも良い行いながら、複数のパケットの存在下でのNewRenoのの優れた性能は、並べ替えの存在下で、その少ない最適なパフォーマンスを上回る一般的に低下します。 （袋TCPは、両方のシナリオにおいて良好な性能を持つ好ましい解決策、である。）この文書は、NewRenoのTCPの代わりに、SACKをサポートしていないTCP接続のためのリノTCPのそれらの高速再送信および高速リカバリアルゴリズムを推奨しています。また、[PF01]に記載されているようにNewRenoのの高速再送と高速リカバリメカニズムが広く、今日のインターネットではTCP実装に配備されていることに注意します。例えば、2001年には数千のWebサーバにおけるTCPの実装のテストは、WebブラウザがSACK対応されなかったそれらのTCP接続のために、より多くのWebサーバがリノやタホTCPのものよりNewRenoのの高速再送信および高速リカバリアルゴリズムを使用したことを示しました。 [PF01]。
The purpose of this document is to advance the NewReno's Fast Retransmit and Fast Recovery algorithms in RFC 2582 to Standards Track.
このドキュメントの目的は、標準化過程のRFC 2582にNewRenoののFast RetransmitとFast Recoveryアルゴリズムを進めることです。
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout (described in more detail in the section above). However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno. As described below, this algorithm uses a variable "recover", whose initial value is the send sequence number.
RFC 2582には、この文書の相対での主な変更点は、NewRenoのの高速再送と高速リカバリアルゴリズムを慎重にバリアントを指定することです。 RFC 2582に記載の塩基アルゴリズムは、（上記のセクションでより詳細に説明する）タイムアウト後に発生することができ、不必要な複数の高速再送を回避しようとしませんでした。ただし、RFC 2582にも「慎重な」定義されており、これらの不要な高速再送信を避けるため、「あまり慎重な」変異体、および慎重なバリエーションをお勧めします。この文書では、NewRenoのの基本的なバージョンとして、以前に命名「慎重な」バリアントを指定します。以下に説明するように、このアルゴリズムは、その初期値を送信シーケンス番号であり、「回復」変数を使用します。
The algorithm specified in Section 3 checks whether the acknowledgement field of a partial acknowledgement covers *more* than "recover", as defined in Section 3. Another possible variant would be to simply require that the acknowledgement field covers *more than or equal to* "recover" before initiating another Fast Retransmit. We called this the Less Careful variant in RFC 2582.
3つのチェックセクションで指定されたアルゴリズムは、部分的な肯定応答の確認応答フィールドは、*セクション別の可能な変形例のようになり3で定義されるように、単に肯定応答フィールドをカバーすることを必要とするように、「回復」より*より*以上または等しい*カバーするかどうか別の高速再送信を開始する前に「回復」。私たちは、このRFC 2582であまり慎重にバリアントと呼ばれます。
There are two separate scenarios in which the TCP sender could receive three duplicate acknowledgements acknowledging "recover" but no more than "recover". One scenario would be that the data sender transmitted four packets with sequence numbers higher than "recover", that the first packet was dropped in the network, and the following three packets triggered three duplicate acknowledgements acknowledging "recover". The second scenario would be that the sender unnecessarily retransmitted three packets below "recover", and that these three packets triggered three duplicate acknowledgements acknowledging "recover". In the absence of SACK, the TCP sender is unable to distinguish between these two scenarios.
TCPの送信者が「回復していない」ではなく「回復」よりも多く認める3つの重複確認応答を受け取ることができた二つの別々のシナリオがあります。 1つのシナリオは、データの送信者が最初のパケットがネットワークで落とされたことを、「回復」よりも高いシーケンス番号を持つ4つのパケットを送信し、次の3つのパケットが「回復」認める3重複確認応答を引き起こしたということでしょう。 2つ目のシナリオでは、送信者が不必要に「回復」は、以下の3つのパケットを再送することを、これらの3つのパケットが「回復」認める3重複確認応答を引き起こしたということでしょう。 SACKがない場合には、TCPの送信者は、これらの2つのシナリオを区別することができません。
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. This document only specifies the Careful variant in Section 3. Unnecessary Fast Retransmits with the Less Careful variant in scenarios with reordering are illustrated in page 8 of [F03].
高速再送信の慎重なバリエーションのために、データの送信者は、最初のシナリオでは再送タイムアウトを待たなければならないだろうが、2つ目のシナリオでは不要の高速再送信を持っていないでしょう。最初のシナリオでは、所望のように高速再送信にはあまり慎重な変異体について、データ送信側は再送信ファストなり、そして第2のシナリオであろう不必要に高速再送。この文書では、唯一の並べ替えとのシナリオではあまり慎重にバリアント3.不要な高速再送信は、[F03]の8ページに示されているセクションで慎重にバリアントを指定します。
The document also specifies two heuristics that the TCP sender MAY use to decide to invoke Fast Retransmit even when the three duplicate acknowledgements do not cover more than "recover". These heuristics, an ACK-based heuristic and a timestamp heuristic, are described in Sections 6.1 and 6.2 respectively.
文書はまた、TCPの送信側が3つの重複確認応答が「回復」以上をカバーしていない場合でも、高速再送信を起動することを決定するために使用し得る2つのヒューリスティックを指定します。これらのヒューリスティック、ACKベースのヒューリスティック及びタイムスタンプヒューリスティックは、それぞれ、セクション6.1および6.2に記載されています。
This document specifies the NewReno Fast Retransmit and Fast Recovery algorithms for TCP. This NewReno modification to TCP can even be important 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. NewReno performs better than Reno (RFC 2581) in a number of scenarios discussed herein.
この文書では、TCPのためのNewRenoのFast RetransmitとFast Recoveryアルゴリズムを指定します。 TCPの両方のエンドノードがSACKオプションをサポートするときSACKオプションのみのTCP接続のために使用することができるので、TCPこのNewRenoの変更であっても、SACKオプションをサポートするTCP実装のために重要であり得ます。 NewRenoのは、本明細書で論じたシナリオの数にリノ（RFC 2581）よりも良好に機能します。
A number of options to the basic algorithm presented in Section 3 are also described. These include the handling of the retransmission timer (Section 4), the response to partial acknowledgments (Section 5), and the value of the congestion window when leaving Fast Recovery (section 3, step 5). Our belief is that the differences between these 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 connection without SACK; it is less important exactly which of the variants of NewReno is implemented.
第3節で提示し、基本的なアルゴリズムに対するオプションの数についても記載されています。これらは、再送タイマーの処理（第4章）、部分応答（セクション5）に対応し、高速リカバリを残して輻輳ウィンドウ（セクション3、ステップ5）の値を含みます。私たちの信念はNewRenoののこれらの変異体の違いはリノとNewRenoの間の違いに比べて小さいということです。それは重要なことは、SACKなしのTCP接続のために、代わりにリノのNewRenoのを実装することで、あります。それが実装されているNewRenoのの変種のかを正確にそれほど重要ではありません。
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の輻輳制御要件に準拠する特定のアルゴリズムを記述し、そのため、これらの考慮事項は、あまりにも、このアルゴリズムに適用されます。この特定のアルゴリズムには知られている追加のセキュリティ上の懸念はありません。
Many thanks to Anil Agarwal, Mark Allman, Armando Caro, Jeffrey Hsu, Vern Paxson, Kacheong Poon, Keyur Shah, and Bernie Volz for detailed feedback on this document or on its precursor, RFC 2582.
この文書にまたはその前駆体、RFC 2582に詳細なフィードバックのためのアニルAgarwalさん、マーク・オールマン、アルマンドカロ、ジェフリー・スー、バーン・パクソン、Kacheongプーン、Keyurシャー、バーニーフォルツに感謝します。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[C98] Cardwell, N., "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]カードウェル、N.は、 "再送パケットのためのACKを遅らせ：痛いです！"。 「http://tcp-impl.lerc.nasa.govにアーカイブ1998年11月、tcpimplメーリングリストへの電子メール、メッセージID「Pine.LNX.4.02A.9811021421340.26785- 100000@sake.cs.washington.edu」、 / TCP-IMPL」。
[F98] Floyd, S., 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]フロイド、S.、RFC 2001の修正、「TCPIMPLワーキンググループへのプレゼンテーション」、1998年8月のURL「ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps」と"ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf"。
[F03] Floyd, S., "Moving NewReno from Experimental to Proposed Standard? Presentation to the TSVWG Working Group", March 2003. URLs "http://www.icir.org/floyd/talks/newreno-Mar03.ps" and "http://www.icir.org/floyd/talks/newreno-Mar03.pdf".
[F03]フロイド、S.、「TSVWGワーキンググループへのProposed Standard？プレゼンテーションに実験からNewRenoの移動」を、2003年3月のURL「http://www.icir.org/floyd/talks/newreno-Mar03.ps」そして "http://www.icir.org/floyd/talks/newreno-Mar03.pdf"。
[FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, July 1996. URL "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[FF96]秋、K.およびS.フロイド、コンピュータコミュニケーションレビュー、1996年7月URL「ftp://ftp.ee.lbl.gov/papers/sacks「タホ、リノとSACK TCPのシミュレーションベースの比較」 .ps.Z」。
[F94] Floyd, S., "TCP and Successive Fast Retransmits", Technical report, October 1994. URL "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[F94]フロイド、S.、 "TCPおよび連続高速再送信"、技術報告書、1994年10月URL "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps"。
[GF04] Gurtov, A. and S. Floyd, "Resolving Acknowledgment Ambiguity in non-SACK TCP", Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN'04), February 2004. URL "http://www.cs.helsinki.fi/u/gurtov/papers/ heuristics.html".
[GF04] Gurtov、A.とS.フロイド、 "非SACKのTCPでの解決謝辞あいまいさ"、次世代トラヒック及び有線/無線高度なネットワーク（NEW2AN'04）、2004年2月URLは「http：//www.cs .helsinki.fi / U / gurtov /論文/ heuristics.html」。
[Gur03] Gurtov, A., "[Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N", email to the tsvwg mailing list, message ID <3F25B467.9020609@cs.helsinki.fi>, July 28, 2003. URL "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04334.html".
[Gur03] Gurtov、A.、 "[TSVWG]ゴーバック-Nにおける不要の高速再送の問題を解決する"、TSVWGメーリングリストへの電子メール、メッセージID <3F25B467.9020609@cs.helsinki.fi>、7月28日、2003年URL "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04334.html"。
[Hen98] Henderson, T., 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]ヘンダーソン、T.、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] Hoe, J., "Startup Dynamics of TCP's Congestion Control and Avoidance Schemes", Master's Thesis, MIT, 1995.
[Hoe95]鍬、J.、「TCPの輻輳制御と回避スキームのスタートアップダイナミクス」、修士論文、MIT、1995。
[Hoe96] Hoe, J., "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", ACM SIGCOMM, August 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".
[Hoe96]鍬、J.、ACM SIGCOMM「TCP輻輳制御方式のスタートアップ行動の改善」、1996年8月URL「http://www.acm.org/sigcomm/sigcomm96/program.html」 。
[LM97] Lin, D. and R. Morris, "Dynamics of Random Early Detection", SIGCOMM 97, September 1997. URL "http://www.acm.org/sigcomm/sigcomm97/program.html".
[LM97]林、D.とR.モリス、 "ランダム早期検出のダイナミクス"、SIGCOMM 97、1997年9月URL "http://www.acm.org/sigcomm/sigcomm97/program.html"。
[NS] The Network Simulator (NS). URL "http://www.isi.edu/nsnam/ns/".
[NS]ネットワークシミュレータ（NS）。 URL "http://www.isi.edu/nsnam/ns/"。
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior of Web Servers", June 2001, SIGCOMM 2001.
[PF01] Padhye、J.とS.フロイド、 "WebサーバーのTCPの動作の識別" を、2001年6月、SIGCOMM 2001。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]ブラントン、E.、オールマン、M.、秋、K.とL.王、 "保守的な選択的確認応答（SACK）ベースの損失TCPのために回復アルゴリズム"、RFC 3517、2003年4月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、RFC 3522、2003年4月。
Authors' Addresses
著者のアドレス
Sally Floyd International Computer Science Institute
サリーフロイド国際コンピュータサイエンス研究所
Phone: +1 (510) 666-2989 EMail: floyd@acm.org URL: http://www.icir.org/floyd/
電話：+1（510）666-2989 Eメール：floyd@acm.org URL：http://www.icir.org/floyd/
Tom Henderson The Boeing Company
トム・ヘンダーソンザ・ボーイング・カンパニー
EMail: thomas.r.henderson@boeing.com
メールアドレス：thomas.r.henderson@boeing.com
Andrei Gurtov TeliaSonera
アンドレイGurtovテリアソネラ
EMail: andrei.gurtov@teliasonera.com
メールアドレス：andrei.gurtov@teliasonera.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。