Network Working Group R. Ludwig
Request for Comments: 3522 M. Meyer
Category: Experimental Ericsson Research
April 2003
The Eifel Detection Algorithm for TCP
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state.
アイフェル検出アルゴリズムは、TCPの送信者は、それが不必要に損失回復に入ったかどうかを事後に検出することができます。これは、RFC 1323で定義されたTCPタイムスタンプオプションは、接続のために有効にする必要があります。アイフェル検出アルゴリズムは、TCPタイムスタンプオプションがTCPで再送あいまいさを排除しているという事実を利用しています。損失回復の間に到着した最初の許容できるACKのタイムスタンプに基づいて、損失回復が不必要に入力されたかどうかを決定します。アイフェル検出アルゴリズムは、将来のTCP機能強化のための基礎を提供します。これは、TCPの送信側の輻輳制御状態を復元することによって損失回復のバックアウトする応答アルゴリズムを含んでいます。
Terminology
用語
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
We refer to the first-time transmission of an octet as the 'original transmit'. A subsequent transmission of the same octet is referred to as a 'retransmit'. In most cases, this terminology can likewise be applied to data segments as opposed to octets. However, with repacketization, a segment can contain both first-time transmissions and retransmissions of octets. In that case, this terminology is only consistent when applied to octets. For the Eifel detection algorithm, this makes no difference as it also operates correctly when repacketization occurs.
我々は、「元の送信」としてオクテットの初回送信を指します。同じオクテットの後続の送信は、「再送」と呼ばれます。オクテットとは対照的に、ほとんどの場合、この用語は、同様にデータ・セグメントに適用することができます。しかし、再パケット化して、セグメントは、初回の送信とオクテットの再送信の両方を含めることができます。オクテットに適用されたときにその場合には、この用語は一貫しています。再パケット化が発生したときに、それはまた、正常に動作するようアイフェル検出アルゴリズムについては、これは違いはありません。
We use the term 'acceptable ACK' as defined in [RFC793]. That is an ACK that acknowledges previously unacknowledged data. We use the term 'duplicate ACK', and the variable 'dupacks' as defined in [WS95]. The variable 'dupacks' is a counter of duplicate ACKs that have already been received by a TCP sender before the fast retransmit is sent. We use the variable 'DupThresh' to refer to the so-called duplicate acknowledgement threshold, i.e., the number of duplicate ACKs that need to arrive at a TCP sender to trigger a fast retransmit. Currently, DupThresh is specified as a fixed value of three [RFC2581]. Future TCPs might implement an adaptive DupThresh.
[RFC793]で定義されている私たちは、用語「許容できるACK」を使用します。それは、以前に未確認のデータを承認ACKです。 [WS95]で定義されている私たちは、用語「重複ACK」、および変数「dupacks」を使用します。変数「dupacks」高速再送が送信される前に、既にTCPの送信側が受信した重複ACKのカウンターです。私たちは、変数を使用する「DupThresh」、すなわち、いわゆる重複確認応答閾値と、高速再送信をトリガするためにTCPの送信側に到着する必要があり、重複ACKの数を参照すること。現在、DupThresh三[RFC2581]の固定値として指定されています。今後のTCPは適応DupThreshを実装するかもしれません。
The retransmission ambiguity problem [Zh86], [KP87] is a TCP sender's inability to distinguish whether the first acceptable ACK that arrives after a retransmit was sent in response to the original transmit or the retransmit. This problem occurs after a timeout-based retransmit and after a fast retransmit. The Eifel detection algorithm uses the TCP Timestamps option defined in [RFC1323] to eliminate the retransmission ambiguity. It thereby allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily.
再送曖昧性の問題[Zh86]、[KP87]は、再送信は、元の送信または再送信に応答して送信された後に到着する最初の許容されるACKかを区別するためにTCP送信者のできないことです。この問題は、タイムアウトベースの再送後および高速再送後に発生します。アイフェル検出アルゴリズムは、再送信の曖昧さを排除するために、[RFC1323]で定義されたTCPタイムスタンプオプションを使用しています。それによってTCPの送信者は、それが不必要に損失回復に入ったかどうかを事後に検出することができます。
This added capability of a TCP sender is useful in environments where TCP's loss recovery and congestion control algorithms may often get falsely triggered. This can be caused by packet reordering, packet duplication, or a sudden delay increase in the data or the ACK path that results in a spurious timeout. For example, such sudden delay increases can often occur in wide-area wireless access networks due to handovers, resource preemption due to higher priority traffic (e.g., voice), or because the mobile transmitter traverses through a radio coverage hole (e.g., see [Gu01]). In such wireless networks, the often unnecessary go-back-N retransmits that typically occur after a spurious timeout create a serious problem. They decrease end-to-end throughput, are useless load upon the network, and waste transmission (battery) power. Note that across such networks the use of timestamps is recommended anyway [RFC3481].
TCP送信者のこの追加された機能は、TCPの損失回復と輻輳制御アルゴリズムは、多くの場合、誤ってトリガされるかもしれません環境で有用です。これは、パケットの並べ替え、パケットの複製、またはデータの急激な遅延の増加またはスプリアスタイムアウトになるACK経路によって引き起こされ得ます。モバイルトランスミッタが無線カバレッジホール内を通るので、例えば、このような突然の遅延増加は、多くの場合、より高い優先順位のトラフィック（例えば、音声）に起因するハンドオーバリソースプリエンプションに広域無線アクセスネットワークに起こり得る、または（例えば、参照[ Gu01]）。このような無線ネットワークでは、多くの場合、不要なゴーバック-Nは、スプリアスタイムアウトが深刻な問題を作成した後、一般的に起こることを再送信します。彼らは、エンドツーエンドのスループットを低下させる無駄なネットワークの負荷、および廃棄送信（バッテリ）電源です。このようなネットワーク間でのタイムスタンプの使用はとにかく推奨されています[RFC3481]。
Based on the Eifel detection algorithm, a TCP sender may then choose to implement dedicated response algorithms. One goal of such a response algorithm would be to alleviate the consequences of a falsely triggered loss recovery. This may include restoring the TCP sender's congestion control state, and avoiding the mentioned unnecessary go-back-N retransmits. Another goal would be to adapt protocol parameters such as the duplicate acknowledgement threshold [RFC2581], and the RTT estimators [RFC2988]. This is to reduce the risk of falsely triggering TCP's loss recovery again as the connection progresses. However, such response algorithms are outside the scope of this document. Note: The original proposal, the "Eifel algorithm" [LK00], comprises both a detection and a response algorithm. This document only defines the detection part. The response part is defined in [LG03].
アイフェル検出アルゴリズムに基づいて、TCPの送信者は、その後、専用の応答アルゴリズムを実装することを選択できます。このような応答アルゴリズムの1つの目標は、誤ってトリガ損失回復の影響を軽減するだろう。これは、TCPの送信側の輻輳制御状態を復元し、言及した不要なゴーバック-Nは、再送信を回避挙げられます。もう一つの目標は、このような重複確認応答閾値を[RFC2581]、およびRTT推定器[RFC2988]などのプロトコルパラメータを適応させることであろう。これは、接続が進むにつれて再び誤ってTCPの損失回復を誘発する危険性を軽減することです。しかしながら、そのような応答アルゴリズムは、この文書の範囲外です。注：元の提案、「アイフェルアルゴリズム」[LK00]を、検出および応答アルゴリズムの両方を含みます。この文書では、唯一の検出部を定義します。応答部は、[LG03]で定義されています。
A key feature of the Eifel detection algorithm is that it already detects, upon the first acceptable ACK that arrives during loss recovery, whether a fast retransmit or a timeout was spurious. This is crucial to be able to avoid the mentioned go-back-N retransmits. Another feature is that the Eifel detection algorithm is fairly robust against the loss of ACKs.
アイフェル検出アルゴリズムの重要な特徴は、それがすでに高速再送またはタイムアウトが偽りであったかどうか、損失回復の間に到着した最初の許容できるACK時に、検出したということです。これは、再送信言及ゴーバック-Nを避けることができることが重要です。もう一つの特徴は、アイフェル検出アルゴリズムは、ACKの損失に対してかなり堅牢であることです。
Also the DSACK option [RFC2883] can be used to detect a posteriori whether a TCP sender has entered loss recovery unnecessarily [BA02]. However, the first ACK carrying a DSACK option usually arrives at a TCP sender only after loss recovery has already terminated. Thus, the DSACK option cannot be used to eliminate the retransmission ambiguity. Consequently, it cannot be used to avoid the mentioned unnecessary go-back-N retransmits. Moreover, a DSACK-based detection algorithm is less robust against ACK losses. A recent proposal based on neither the TCP timestamps nor the DSACK option does not have the limitation of DSACK-based schemes, but only addresses the case of spurious timeouts [SK03].
またDSACKオプション[RFC2883]はTCPの送信者が不必要に損失回復[BA02]を入力したかどうかを事後に検出するために使用することができます。しかし、通常はDSACKオプションを運ぶ最初のACKが損失回復が既に終了した後にのみ、TCPの送信側に到着します。このように、DSACKオプションは、再送信の曖昧さを排除するために使用することはできません。したがって、言及不要ゴーバック-Nの再送を避けるために使用することはできません。また、DSACKベースの検出アルゴリズムは、ACK損失に対してよりロバストです。 TCPタイムスタンプもDSACKオプションのいずれに基づいて、最近の提案はDSACKベースのスキームの制限がありますが、唯一のスプリアスタイムアウト[SK03]の場合に対処していません。
The following events may falsely trigger a TCP sender's loss recovery and congestion control algorithms. This causes a so-called spurious retransmit, and an unnecessary reduction of the TCP sender's congestion window and slow start threshold [RFC2581].
次のイベントが誤ってTCP送信者の損失回復と輻輳制御アルゴリズムをトリガすることができます。これは、いわゆるスプリアス再送、およびTCPの送信側の輻輳ウィンドウとスロースタートしきい値[RFC2581]の不要な低下を引き起こします。
- Spurious timeout
- スプリアスタイムアウト
- Packet reordering
- パケットの並べ替え
- Packet duplication
- パケット重複
A spurious timeout is a timeout that would not have occurred had the sender "waited longer". This may be caused by increased delay that suddenly occurs in the data and/or the ACK path. That in turn might cause an acceptable ACK to arrive too late, i.e., only after a TCP sender's retransmission timer has expired. For the purpose of specifying the algorithm in Section 3, we define this case as SPUR_TO (equal 1).
スプリアスタイムアウトは、送信者が「長く待っていた」が発生しなかったであろうタイムアウトです。これは、突然のデータおよび/またはACK路で生じる遅延の増加によって引き起こされ得ます。それは順番にTCPの送信側の再送タイマが満了した後にのみ、許容できるACKはすなわち、あまりにも遅れて到着することがあります。セクション3でアルゴリズムを指定する目的のために、我々はSPUR_TO（1に等しい）、このケースを定義します。
Note: There is another case where a timeout would not have occurred had the sender "waited longer": the retransmission timer expires, and afterwards the TCP sender receives the duplicate ACK that would have triggered a fast retransmit of the oldest outstanding segment. We call this a 'fast timeout', since in competition with the fast retransmit algorithm the timeout was faster. However, a fast timeout is not spurious since apparently a segment was in fact lost, i.e., loss recovery was initiated rightfully. In this document, we do not consider fast timeouts.
注意：再送信タイマーが満了し、その後TCPの送信者は、最古の優れたセグメントの高速再転送をトリガしているだろう、重複ACKを受信します。そこタイムアウトが発生していないと、他の場合は、送信者が「長く待って」いましたです。高速再送アルゴリズムとの競争にタイムアウトが速かったので、私たちは、「速いタイムアウト」これを呼び出します。しかし、高速のタイムアウトは、すなわち、損失回復が当然開始された、明らかにセグメントが実際に失われたので、スプリアスではありません。この文書では、我々は、高速なタイムアウトを考慮していません。
Packet reordering in the network may occur because IP [RFC791] does not guarantee in-order delivery of packets. Additionally, a TCP receiver generates a duplicate ACK for each segment that arrives out-of-order. This results in a spurious fast retransmit if three or more data segments arrive out-of-order at a TCP receiver, and at least three of the resulting duplicate ACKs arrive at the TCP sender. This assumes that the duplicate acknowledgement threshold is set to three as defined in [RFC2581].
IPは、[RFC791]パケットの順序配信を保証しないため、ネットワーク内のリオーダリングパケットが発生する可能性があります。また、TCP受信機は、アウト・オブ・オーダ到着する各セグメントの重複ACKを生成します。三つ以上のデータセグメントがTCP受信機でのアウトオブオーダー到着する場合、これは偽高速再送信を生じる、得られた重複ACKの少なくとも3つがTCP送信者に到達します。これは[RFC2581]で定義されるように、重複確認応答閾値を3に設定されていることを前提としています。
Packet duplication may occur because a receiving IP does not (cannot) remove packets that have been duplicated in the network. A TCP receiver in turn also generates a duplicate ACK for each duplicate segment. As with packet reordering, this results in a spurious fast retransmit if duplication of data segments or ACKs results in three or more duplicate ACKs to arrive at a TCP sender. Again, this assumes that the duplicate acknowledgement threshold is set to three.
受信IPネットワークに複製されたパケットを削除する（ことができない）しないため、パケットの重複が発生する可能性があります。次にTCP受信機は、各重複セグメントの重複ACKを生成します。三つ以上の重複ACKのデータセグメントまたはACKの結果の重複場合、パケットの並べ替えと同様に、これはTCP送信者に到達するスプリアス高速再送信をもたらします。繰り返しますが、これは、重複確認応答閾値が3に設定されていることを前提としています。
The negative impact on TCP performance caused by packet reordering and packet duplication is commonly the same: a single spurious retransmit (the fast retransmit), and the unnecessary halving of a TCP sender's congestion window as a result of the subsequent fast recovery phase [RFC2581].
（高速再送信）は、単一のスプリアス再送、及びその後の高速回復期[RFC2581]の結果としてTCP送信者の輻輳ウィンドウの不要半減：パケットの並び替え、パケットの複製によって引き起こされるTCPの性能にマイナスの影響は、一般的に同じです。
The negative impact on TCP performance caused by a spurious timeout is more severe. First, the timeout event itself causes a single spurious retransmit, and unnecessarily forces a TCP sender into slow start [RFC2581]. Then, as the connection progresses, a chain reaction gets triggered that further decreases TCP's performance. Since the timeout was spurious, at least some ACKs for original transmits typically arrive at the TCP sender before the ACK for the retransmit arrives. (This is unless severe packet reordering coincided with the spurious timeout in such a way that the ACK for the retransmit is the first acceptable ACK to arrive at the TCP sender.) Those ACKs for original transmits then trigger an implicit go-back-N loss recovery at the TCP sender [LK00]. Assuming that none of the outstanding segments and none of the corresponding ACKs were lost, all outstanding segments get retransmitted unnecessarily. In fact, during this phase, a TCP sender violates the packet conservation principle [Jac88]. This is because the unnecessary go-back-N retransmits are sent during slow start. Thus, for each packet that leaves the network and that belongs to the first half of the original flight, two useless retransmits are sent into the network. In addition, some TCPs suffer from a spurious fast retransmit. This is because the unnecessary go-back-N retransmits arrive as duplicates at the TCP receiver, which in turn triggers a series of duplicate ACKs. Note that this last spurious fast retransmit could be avoided with the careful variant of 'bugfix' [RFC2582].
スプリアスタイムアウトによるTCPのパフォーマンスにマイナスの影響がより深刻です。まず、タイムアウトイベント自体は、単一のスプリアス再送が発生し、不必要にスロースタート[RFC2581]にTCPの送信者を強制します。接続が進むにつれてその後、連鎖反応がさらにTCPの性能が低下することをトリガします。タイムアウトが偽であったので、再送のためのACKが到着する前に、元の送信のために少なくともいくつかのACKは、典型的にはTCP送信者に到達します。 （重度のパケットの並べ替えは、再送に対するACKがTCP送信者に到達する最初の許容されるACKであるようにスプリアスタイムアウトと一致しない限り、これがある。）は、元の送信用のものACKは暗黙行くバック-N損失をトリガTCP送信者[LK00]で回復。対応するACKの優れたセグメントのどれとどれが失われなかったと仮定すると、すべての未処理のセグメントが不必要に再送され得ます。実際には、このフェーズの間に、TCPの送信者は[Jac88]パケットの保全の原則に違反します。不要なゴーバック-Nの再送が遅い開始時に送信されるためです。したがって、ネットワークを離れ、それは元のフライトの最初の半分に属する各パケットのために、2つの無駄な再送がネットワークに送信されます。また、いくつかのTCPがスプリアス高速再送に苦しみます。不要なゴーバック-Nが順番に重複ACKのシリーズをトリガTCP受信機、で重複として到着し再送信するためです。この最後のスプリアス高速再送は、「バグ修正」[RFC2582]の慎重な変種で回避することができることに注意してください。
More detailed explanations, including TCP trace plots that visualize the effects of spurious timeouts and packet reordering, can be found in the original proposal [LK00].
スプリアスタイムアウトとパケットの並べ替えの効果を可視化するTCPトレースプロットを含むより詳細な説明は、オリジナルの提案[LK00]で見つけることができます。
The goal of the Eifel detection algorithm is to allow a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. Furthermore, the TCP sender should be able to make this decision upon the first acceptable ACK that arrives after the timeout-based retransmit or the fast retransmit has been sent. This in turn requires extra information in ACKs by which the TCP sender can unambiguously distinguish whether that first acceptable ACK was sent in response to the original transmit or the retransmit. Such extra information is provided by the TCP Timestamps option [RFC1323]. Generally speaking, timestamps are monotonously increasing "serial numbers" added into every segment that are then echoed within the corresponding ACKs. This is exploited by the Eifel detection algorithm in the following way.
アイフェル検出アルゴリズムの目標は、TCPの送信者は、それが不必要に損失回復に入ったかどうかを事後に検出することができるようにすることです。さらに、TCPの送信者は、タイムアウトベースの再送後に到着するや高速再送が送信された最初の許容できるACK時にこの決定を行うことができるはずです。これは、順番にTCPの送信側が明確にその最初の許容できるACKが、元の送信または再送信に対応して送信されたかどうかを区別することが可能なACKの中の余分な情報が必要です。このような追加情報は、TCPタイムスタンプオプション[RFC1323]で提供されます。一般的に言えば、タイムスタンプは、単調に「シリアル番号」は、対応するACKの内エコーされ、すべてのセグメントに追加増加しています。これは、次のようにアイフェル検出アルゴリズムによって利用されます。
Given that timestamps are enabled for a connection, a TCP sender always stores the timestamp of the retransmit sent in the beginning of loss recovery, i.e., the timestamp of the timeout-based retransmit or the fast retransmit. If the timestamp of the first acceptable ACK, that arrives after the retransmit was sent, is smaller then the stored timestamp of that retransmit, then that ACK must have been sent in response to an original transmit. Hence, the TCP sender must have entered loss recovery unnecessarily.
タイムスタンプは、接続のために有効になっていることを考えると、TCPの送信者は、常に損失回復の初めに送信され、再送信、すなわち、タイムアウトベースの再送信のタイムスタンプや高速再送のタイムスタンプを格納します。再送が送信された後に到着する最初の許容されるACKのタイムスタンプは、その再送の格納されたタイムスタンプ次に小さい場合、ACKは、元の送信に応答して送信されていなければならないこと。したがって、TCPの送信者は、不必要に損失回復に入っている必要があります。
The fact that the Eifel detection algorithm decides upon the first acceptable ACK is crucial to allow future response algorithms to avoid the unnecessary go-back-N retransmits that typically occur after a spurious timeout. Also, if loss recovery was entered unnecessarily, a window worth of ACKs are outstanding that all carry a timestamp that is smaller than the stored timestamp of the retransmit. The arrival of any one of those ACKs is sufficient for the Eifel detection algorithm to work. Hence, the solution is fairly robust against ACK losses. Even the ACK sent in response to the retransmit, i.e., the one that carries the stored timestamp, may get lost without compromising the algorithm.
アイフェル検出アルゴリズムは、最初に許容できるACK時に決定したという事実は、将来のレスポンスアルゴリズムは不要ゴーバック-Nは、通常、スプリアスタイムアウト後に起こることを再送信を避けるためにできるようにすることが重要です。損失回復が不必要に入力された場合にも、ACKの窓の価値は、すべて再送信の保存されたタイムスタンプより小さいタイムスタンプを運ぶことに優れています。アイフェル検出アルゴリズムが機能するために、これらのACKのいずれかの到着は十分です。したがって、解決策は、ACKの損失に対してかなり堅牢です。再送に応答して送信されてもACKは、すなわち、格納されたタイムスタンプを運ぶ一つは、アルゴリズムを損なうことなく、迷子にしてもよいです。
Given that the TCP Timestamps option [RFC1323] is enabled for a connection, a TCP sender MAY use the Eifel detection algorithm as defined in this subsection.
このサブセクションで定義されているTCPタイムスタンプオプション[RFC1323]は、接続が有効になっていることを考えると、TCPの送信者は、アイフェル検出アルゴリズムを使用するかもしれません。
If the Eifel detection algorithm is used, the following steps MUST be taken by a TCP sender, but only upon initiation of loss recovery, i.e., when either the timeout-based retransmit or the fast retransmit is sent. The Eifel detection algorithm MUST NOT be reinitiated after loss recovery has already started. In particular, it must not be reinitiated upon subsequent timeouts for the same segment, and not upon retransmitting segments other than the oldest outstanding segment, e.g., during selective loss recovery.
アイフェル検出アルゴリズムを使用する場合は、次の手順は、タイムアウトベースの再送や高速再送のいずれかが送信されたとき、すなわち、TCP送信者が撮影したが、唯一の損失回復の開始時にしなければなりません。損失回復が既に開始された後にアイフェル検出アルゴリズムを再開してはなりません。特に、同じセグメントの後続のタイムアウト時ではなく、選択的な損失回復中の最も古い未解決のセグメント、例えば、以外のセグメントを再送信する際に再開されてはなりません。
(1) Set a "SpuriousRecovery" variable to FALSE (equal 0).
（1）FALSE（0に等しい）を "SpuriousRecovery" 変数を設定します。
(2) Set a "RetransmitTS" variable to the value of the Timestamp Value field of the Timestamps option included in the retransmit sent when loss recovery is initiated. A TCP sender must ensure that RetransmitTS does not get overwritten as loss recovery progresses, e.g., in case of a second timeout and subsequent second retransmit of the same octet.
（2）タイムスタンプオプションのタイムスタンプ値フィールドの値に「RetransmitTS」変数を設定損失回復が開始されたときに送信され、再送に含まれています。 TCPの送信者は、損失回復が第二タイムアウトと同じオクテットの次の第2の再送信の場合には、例えば、進むにつれてRetransmitTSが上書きされないようにする必要があります。
(3) Wait for the arrival of an acceptable ACK. When an acceptable ACK has arrived, proceed to step (4).
（3）許容されるACKの到着を待ちます。許容されるACKが到着したとき、（4）に進みます。
(4) If the value of the Timestamp Echo Reply field of the acceptable ACK's Timestamps option is smaller than the value of RetransmitTS, then proceed to step (5),
（4）許容されるACKのタイムスタンプ・オプションのタイムスタンプエコー応答フィールドの値は、（5）に進み、その後、RetransmitTSの値よりも小さい場合
else proceed to step (DONE).
それ以外（DONE）に進みます。
(5) If the acceptable ACK carries a DSACK option [RFC2883], then proceed to step (DONE),
（5）許容されるACKは、（DONE）に進み、その後、DSACKオプション[RFC2883]を運ぶ場合
else if during the lifetime of the TCP connection the TCP
sender has previously received an ACK with a DSACK option,
or the acceptable ACK does not acknowledge all outstanding
data, then proceed to step (6),
else proceed to step (DONE).
それ以外（DONE）に進みます。
(6) If the loss recovery has been initiated with a timeout-based retransmit, then set SpuriousRecovery <- SPUR_TO (equal 1),
損失回復がタイムアウトに基づく再送信で開始された場合（6）、次いでSpuriousRecovery <設定 - SPUR_TO（等しい1）、
else set
SpuriousRecovery <- dupacks+1
(RESP) Do nothing (Placeholder for a response algorithm).
（RESP）（レスポンスアルゴリズムのためのプレースホルダ）何もしません。
(DONE) No further processing.
さらなる処理を（行われません）。
The comparison "smaller than" in step (4) is conservative. In theory, if the timestamp clock is slow or the network is fast, RetransmitTS could at most be equal to the timestamp echoed by an ACK sent in response to an original transmit. In that case, it is assumed that the loss recovery was not falsely triggered.
比較ステップ（4）における「より小さい」が保守的です。タイムスタンプクロックが遅いまたはネットワークが高速であれば理論的には、RetransmitTSは最大で元の送信に応答して送信されたACKによってエコータイムスタンプに等しいとすることができます。その場合には、損失回復が誤ってトリガされていなかったと仮定されます。
Note that the condition "if during the lifetime of the TCP connection the TCP sender has previously received an ACK with a DSACK option" in step (5) would be true in case the TCP receiver would signal in the SYN that it is DSACK-enabled. But unfortunately, this is not required by [RFC2883].
TCP受信機は、それがDSACK、有効であることをSYNの信号になる場合の条件がステップにおいて「TCP接続の寿命の間にTCP送信者が以前にDSACKオプションでACKを受信した場合は、」（5）が真であることに注意してください。しかし残念ながら、これは[RFC2883]によって必要とされていません。
Even though the oldest outstanding segment arrived at a TCP receiver, the TCP sender is forced into a timeout if all ACKs are lost. Although the resulting retransmit is unnecessary, such a timeout is unavoidable. It should therefore not be considered spurious. Moreover, the subsequent reduction of the congestion window is an appropriate response to the potentially heavy congestion in the ACK path. The original proposal [LK00] does not handle this case well. It effectively disables this implicit form of congestion control for the ACK path, which otherwise does not exist in TCP. This problem is fixed by step (5) of the Eifel detection algorithm as explained in the remainder of this section.
最古の優れたセグメントがTCP受信機に到着したにもかかわらず、すべてのACKが失われた場合、TCPの送信者がタイムアウトに強制されます。得られた再送信は不要であるが、そのようなタイムアウトが避けられません。したがって、スプリアスとみなされるべきではありません。また、輻輳ウィンドウのその後の還元は、ACK経路における潜在的に重い輻輳に対する適切な応答です。当初の提案[LK00]はうまくこのケースを処理しません。これは、効果的に別段のTCPに存在しないACK経路用輻輳制御のこの暗黙の形態を無効にします。このセクションの残りの部分で説明したように、この問題は、アイフェル検出アルゴリズムのステップ（5）によって固定されています。
If all ACKs are lost while the oldest outstanding segment arrived at the TCP receiver, the retransmit arrives as a duplicate. In response to duplicates, RFC 1323 mandates that the timestamp of the last segment that arrived in-sequence should be echoed. That timestamp is carried by the first acceptable ACK that arrives at the TCP sender after loss recovery was entered, and is commonly smaller than the timestamp carried by the retransmit. Consequently, the Eifel detection algorithm misinterprets such a timeout as being spurious, unless the TCP receiver is DSACK-enabled [RFC2883]. In that case, the acceptable ACK carries a DSACK option, and the Eifel algorithm is terminated through the first part of step (5).
最古の優れたセグメントがTCP受信機に到着しながら、全てのACKが失われた場合、再送信は、重複として到着しました。重複に応答して、RFC 1323の任務は、インシーケンス到着した最後のセグメントのタイムスタンプはエコーされるべきです。そのタイムスタンプは、損失回復が入力された後にTCPの送信側に到着し、一般的に再送信によって運ばれたタイムスタンプよりも小さくなっている最初の許容できるACKによって運ばれます。 TCP受信機が[RFC2883]をDSACKが有効でない限り、結果として、アイフェル検出アルゴリズムは、偽であるとして、そのようなタイムアウトを誤解します。その場合には、許容されるACKはDSACKオプションを運び、そしてアイフェルアルゴリズムがステップ（5）の最初の部分を介して終了します。
Note: Not all TCP implementations strictly follow RFC 1323. In response to a duplicate data segment, some TCP receivers echo the timestamp of the duplicate. With such TCP receivers, the corner case discussed in this section does not apply. The timestamp carried by the retransmit would be echoed in the first acceptable ACK, and the Eifel detection algorithm would be terminated through step (4). Thus, even though all ACKs were lost and independent of whether the DSACK option was enabled for a connection, the Eifel detection algorithm would have no effect.
注：すべてのTCP実装が厳密に重複したデータ・セグメントに応じてRFC 1323に従っていない、いくつかのTCP受信機は重複のタイムスタンプをエコー。そのようなTCP受信機では、このセクションで説明するコーナーケースは適用されません。再送によって運ばれるタイムスタンプは、最初に許容されるACKにエコーされるであろう、とアイフェル検出アルゴリズムは、ステップ（4）を介して終了することになります。このように、全てのACKが失われたとDSACKオプションは、接続のために有効にされたかどうかの独立したにもかかわらず、アイフェル検出アルゴリズムは効果がありませんでしょう。
With TCP receivers that are not DSACK-enabled, disabling the mentioned implicit congestion control for the ACK path is not a problem as long as data segments are lost, in addition to the entire flight of ACKs. The Eifel detection algorithm misinterprets such a timeout as being spurious, and the Eifel response algorithm would reverse the congestion control state. Still, the TCP sender would respond to congestion (in the data path) as soon as it finds out about the first loss in the outstanding flight. I.e., the TCP sender would still halve its congestion window for that flight of packets. If no data segment is lost while the entire flight of ACKs is lost, the first acceptable ACK that arrives at the TCP sender after loss recovery was entered acknowledges all outstanding data. In that case, the Eifel algorithm is terminated through the second part of step (5).
DSACK対応していないTCP受信機では、ACKパスのために言及した暗黙の輻輳制御を無効にすると、ACKの全体の飛行に加えて、限り、データセグメントが失われるなどの問題ではありません。アイフェル検出アルゴリズムは偽であるようなタイムアウトを誤って解釈し、アイフェル応答アルゴリズムは、輻輳制御状態を逆になります。それでも、TCPの送信者は、すぐにそれが優れた飛行中の最初の損失について見つけ出しとして（データ・パスで）混雑に応答することになります。すなわち、TCPの送信者は、依然として、パケットの飛行のためにその輻輳ウィンドウを半分にします。 ACKの全体の飛行が失われている間はデータセグメントが失われていない場合は、損失回復が入力された後にTCPの送信側に到着した最初の許容できるACKは、すべての未処理データを認めています。その場合には、アイフェルアルゴリズムは、ステップ（5）の第二部を介して終了します。
Note that there is little concern about violating the packet conservation principle when entering slow start after an unavoidable timeout caused by the loss of an entire flight of ACKs, i.e., when the Eifel detection algorithm was terminated through step (5). This is because in that case, the acceptable ACK corresponds to the retransmit, which is a strong indication that the pipe has drained entirely, i.e., that no more original transmits are in the network. This is different with spurious timeouts as discussed in Section 2.
アイフェル検出アルゴリズムは、ステップ（5）を介して終了したとき、すなわち、ACKの全体飛行の損失によるやむを得ないタイムアウト後のスロースタートに入るときに、パケットの保全の原則に違反についてはほとんど関心があることに注意してください。その場合には、許容されるACKは、もはや元の送信は、ネットワーク内にないこと、すなわち、管が完全に排出されたことを強く示している再送に対応するためです。第2節で説明したように、これは、スプリアスタイムアウトと異なっています。
A TCP receiver can easily make a genuine retransmit appear to the TCP sender as a spurious retransmit by forging echoed timestamps. This may pose a security concern.
簡単に本物の再送信を行うことができますTCP受信機はエコータイムスタンプを鍛造によりスプリアス再送などのTCP送信者に表示されます。これは、セキュリティ上の問題を引き起こす可能性があります。
Fortunately, there is a way to modify the Eifel detection algorithm in a way that makes it robust against lying TCP receivers. The idea is to use timestamps as a segment's "secret" that a TCP receiver only gets to know if it receives the segment. Conversely, a TCP receiver will not know the timestamp of a segment that was lost. Hence, to "prove" that it received the original transmit of a segment that a TCP sender retransmitted, the TCP receiver would need to return the timestamp of that original transmit. The Eifel detection algorithm could then be modified to only decide that loss recovery has been unnecessarily entered if the first acceptable ACK echoes the timestamp of the original transmit.
幸いなことに、TCP受信機を嘘に対して、それは堅牢に方法でアイフェル検出アルゴリズムを変更する方法があります。アイデアは、TCP受信機が唯一それがセグメントを受け取るかどうかを知ることを得ることセグメントの「秘密」としてタイムスタンプを使用することです。逆に、TCP受信機は失われたセグメントのタイムスタンプを知ることができません。したがって、それはTCPの送信側が再送セグメントの本来の送信を受けたことを「証明」するために、TCP受信機はその本来の送信のタイムスタンプを返す必要があります。アイフェル検出アルゴリズムは、最初の許容できるACKが元の送信のタイムスタンプをエコーする場合は、不必要に入力されているだけでその損失回復を決定するように変更することができます。
Hence, implementers may choose to implement the algorithm with the following modifications.
したがって、実装は、以下の改変を伴うアルゴリズムを実行することを選択することができます。
Step (2) is replaced with step (2'):
（2）ステップは、ステップ（2' ）に置き換えられます。
(2') Set a "RetransmitTS" variable to the value of the Timestamp Value field of the Timestamps option that was included in the original transmit corresponding to the retransmit. Note: This step requires that the TCP sender stores the timestamps of all outstanding original transmits.
再送に対応する元の送信に含まれていたタイムスタンプ・オプションのタイムスタンプ値フィールドの値に 『RetransmitTS』変数を設定（2' ）。注：このステップでは、すべての未処理のオリジナル送信のTCPの送信元の店舗のタイムスタンプする必要があります。
Step (4) is replaced with step (4'):
（4）ステップは、ステップ（4' ）で置換されています。
(4') If the value of the Timestamp Echo Reply field of the acceptable ACK's Timestamps option is equal to the value of the variable RetransmitTS, then proceed to step (5),
（4' ）に許容されるACKのタイムスタンプ・オプションのタイムスタンプエコー応答フィールドの値が、（5）に進み、その後、変数RetransmitTSの値に等しい場合
else proceed to step (DONE).
それ以外（DONE）に進みます。
These modifications come at a cost: the modified algorithm is fairly sensitive against ACK losses since it relies on the arrival of the acceptable ACK that corresponds to the original transmit.
これらの変更はコストで来る：それは元の送信に対応して許容されるACKの到着に依存しているので、修正されたアルゴリズムは、ACK損失に対してかなり敏感です。
Note: The first acceptable ACK that arrives after loss recovery has been unnecessarily entered should echo the timestamp of the original transmit. This assumes that the ACK corresponding to the original transmit was not lost, that that ACK was not reordered in the network, and that the TCP receiver does not forge timestamps but complies with RFC 1323. In case of a spurious fast retransmit, this is implied by the rules for generating ACKs for data segments that fill in all or part of a gap in the sequence space (see section 4.2 of [RFC2581]) and by the rules for echoing timestamps in that case (see rule (C) in section 3.4 of [RFC1323]). In case of a spurious timeout, it is likely that the delay that has caused the spurious timeout has also caused the TCP receiver's delayed ACK timer [RFC1122] to expire before the original transmit arrives. Also, in this case the rules for generating ACKs and the rules for echoing timestamps (see rule (A) in section 3.4 of [RFC1323]) ensure that the original transmit's timestamp is echoed.
注意：オリジナルの送信のタイムスタンプをエコーすべき損失回復が不必要に入力された後に到着した最初の許容できるACKを。これは、元の送信に対応するACKが、そのACKをネットワークに並べ替えされなかったこと、失われなかったこと、およびTCP受信機がタイムスタンプを偽造しないことを前提としていますが、スプリアス高速再送信の場合にはRFC 1323に準拠し、これが暗示されますすべてまたは配列空間における間隙の一部を埋めるデータセグメントのためのACKを生成するためのルールによって（[RFC2581]のセクション4.2を参照）、その場合にタイムスタンプをエコーするためのルールによって（セクション3.4でルール（C）を参照してください[RFC1323]）。スプリアスタイムアウトの場合には、本来の送信が到着する前に期限切れに[RFC1122]スプリアスタイムアウトが発生している遅延はまた、TCP受信機の遅延ACKタイマを引き起こしている可能性があります。また、この場合、ACKおよびタイムスタンプをエコーするためのルールを生成するルールは（[RFC1323]のセクション3.4にルール（A）を参照）、元の送信のタイムスタンプをエコーされていることを確認します。
A remaining problem is that a TCP receiver might guess a lost segment's timestamp from observing the timestamps of recently received segments. For example, if segment N was lost while segment N-1 and N+1 have arrived, a TCP receiver could guess the timestamp that lies in the middle of the timestamps of segments N-1 and N+1, and echo it in the ACK sent in response to the retransmit of segment N. Especially if the TCP sender implements timestamps with a coarse granularity, a misbehaving TCP receiver is likely to be successful with such an approach. In fact, with the 500 ms granularity suggested in [WS95], it even becomes quite likely that the timestamps of segments N-1, N, N+1 are identical.
残りの問題は、TCP受信機が最近受信したセグメントのタイムスタンプを観測から失われたセグメントのタイムスタンプを推測するかもしれないということです。例えば、セグメントNは、セグメントN-1及びN + 1が到着しているが、TCP受信機はセグメントのタイムスタンプN-1及びN + 1の真ん中にあるタイムスタンプを推測し、それをエコー可能性が失われた場合ACKがTCP送信者は粗い粒度でタイムスタンプを実装する場合は特に、セグメントNの再送に応答して送信され、不正動作するTCP受信機は、このようなアプローチで成功する可能性があります。 500ミリ秒の粒度が[WS95]で提案されていると、実際には、それも、セグメントN-1、N、N + 1のタイムスタンプが同一であることが非常にやすくなります。
One way to reduce this risk is to implement fine grained timestamps. Note that the granularity of the timestamps is independent of the granularity of the retransmission timer. For example, some TCP implementations run a timestamp clock that ticks every millisecond. This should make it more difficult for a TCP receiver to guess the timestamp of a lost segment. Alternatively, it might be possible to combine the timestamps with a nonce, as is done for the Explicit Congestion Notification (ECN) [RFC3168]. One would need to take care, though, that the timestamps of consecutive segments remain monotonously increasing and do not interfere with the RTT timing defined in [RFC1323].
このリスクを軽減するための一つの方法は、きめの細かいタイムスタンプを実装することです。タイムスタンプの粒度は再送タイマーの細かさとは無関係であることに注意してください。例えば、いくつかのTCP実装はミリ秒毎に刻むタイムスタンプクロックを実行します。 TCP受信機が失われたセグメントのタイムスタンプを推測するためにこのことをより困難にする必要があります。あるいは、明示的輻輳通知（ECN）[RFC3168]のために行われているように、ノンスと、タイムスタンプを組み合わせることが可能であるかもしれません。一つは、連続したセグメントのタイムスタンプが単調増加を維持し、[RFC1323]で定義されたRTTタイミングに干渉しないこと、しかし、世話をする必要があります。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights at http://www.ietf.org/ipr.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細についてはhttp://www.ietf.org/iprで要求された権利のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
There do not seem to be any security considerations associated with the Eifel detection algorithm. This is because the Eifel detection algorithm does not alter the existing protocol state at a TCP sender. Note that the Eifel detection algorithm only requires changes to the implementation of a TCP sender.
アイフェル検出アルゴリズムに関連するすべてのセキュリティ上の考慮事項があるように思えません。アイフェル検出アルゴリズムは、TCPの送信側で既存のプロトコルの状態を変更しないためです。アイフェル検出アルゴリズムのみTCPの送信側の実装に変更する必要があることに注意してください。
Moreover, a variant of the Eifel detection algorithm has been proposed in Section 3.4 that makes it robust against lying TCP receivers. This may become relevant when the Eifel detection algorithm is combined with a response algorithm such as the Eifel response algorithm [LG03].
また、アイフェル検出アルゴリズムの変種は、TCP受信機を嘘に対して、それは堅牢に3.4節で提案されています。アイフェル検出アルゴリズムは、このようなアイフェル応答アルゴリズム[LG03]などの応答アルゴリズムと組み合わされる場合に関連するようになることができます。
Acknowledgments
謝辞
Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi Sarolahti, and Alexey Kuznetsov for useful discussions that contributed to this work.
この作業に貢献した有益な議論のためのキースSklower、ランディカッツ、ステファンBaucke、サリー・フロイド、バーン・パクソン、マーク・オールマン、イーサンブラントン、アンドレイGurtov、パシSarolahti、およびアレクセイ・クズネツォフに感謝します。
Normative References
引用規格
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[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月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A. Romanow, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]フロイド、S.、Mahdavi、J.、マティス、M.、ポドルスキー、M.及びA. Romanow、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[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月。
[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月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
Informative References
参考文献
[BA02] Blanton, E. and M. Allman, "Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions", Work in Progress.
[BA02]ブラントン、E.およびM.オールマン、進行中の作業「スプリアス再送を検出するために、TCPのDSACKsとSCTP複製のTSNを使用します」。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[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月。
[Gu01] Gurtov, A., "Effect of Delays on TCP Performance", In Proceedings of IFIP Personal Wireless Communications, August 2001.
IFIPパーソナル無線通信の議事録、2001年8月[Gu01] Gurtov、A.、 "TCPパフォーマンス上の遅延の影響"、。
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", RFC 3481, February 2003.
[RFC3481]稲村、H.、モンテネグロ、G.、ルートヴィヒ、R.、Gurtov、A.およびF. Khafizov、 "セカンド（2.5G）と第3（3G）世代無線ネットワーク上でTCP"、RFC 3481、2003年2月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In Proceedings of ACM SIGCOMM 88.
【Jac88]ジェーコブソン、V.、 "輻輳回避とコントロール"、ACM SIGCOMM 88の議事で。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", In Proceedings of ACM SIGCOMM 87.
ACM SIGCOMM 87の議事録[KP87]カーン、P.とC.ヤマウズラ、「信頼性の高いトランスポートプロトコルにラウンドトリップ時間の見積りの改善」、。
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM Computer Communication Review, Vol. 30, No. 1, January 2000.
[LK00]ルートヴィヒ、R.とR. H.カッツ、「アイフェルアルゴリズム：スプリアス再送に対するTCPは堅牢にする」、ACMコンピュータコミュニケーションレビュー、巻。 30、第1号、2000年1月。
[LG03] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", Work in Progress.
[LG03]ルートヴィヒ、R.とA. Gurtov、 "TCPのためのアイフェルレスポンスアルゴリズム" が進行中で働いています。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "IPに明示的輻輳通知（ECN）の追加"、RFC 3168、2001年9月。
[SK03] Sarolahti, P. and M. Kojo, "F-RTO: A TCP RTO Recovery Algorithm for Avoiding Unnecessary Retransmissions", Work in Progress.
[SK03] Sarolahti、P.とM.古城、 "F-RTO：不必要な再送信を回避するためのTCP RTO回復アルゴリズム" が進行中で働いています。
[WS95] Wright, G. R. and W. R. Stevens, "TCP/IP Illustrated, Volume 2 (The Implementation)", Addison Wesley, January 1995.
[WS95]ライト、G. R.およびW. R.スティーブンス、 "TCP / IPイラスト、第2巻（実施）"、アディソンウェズリー、1995年1月。
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", In Proceedings of ACM SIGCOMM 86.
[Zh86]チャン、L.は、ACM SIGCOMM 86の議事録では、 "なぜ、TCPタイマーがうまく機能しません"。
Authors' Addresses
著者のアドレス
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
ライナールートヴィヒ・エリクソン研究エリクソンアリー1 52134 Herzogenrathの、ドイツ
EMail: Reiner.Ludwig@eed.ericsson.se
メールアドレス：Reiner.Ludwig@eed.ericsson.se
Michael Meyer Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
マイケル・メイヤーエリクソン研究エリクソンアリー1 52134 Herzogenrathの、ドイツ
EMail: Michael.Meyer@eed.ericsson.se
メールアドレス：Michael.Meyer@eed.ericsson.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。