[要約] RFC 3522は、TCPのためのEifel検出アルゴリズムについての要約です。このRFCの目的は、ネットワークの過負荷を検出し、TCPのパフォーマンスを向上させることです。
Network Working Group R. Ludwig
Request for Comments: 3522 M. Meyer
Category: Experimental Ericsson Research
April 2003
The Eifel Detection Algorithm for TCP
TCPのEIFEL検出アルゴリズム
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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.
EIFEL検出アルゴリズムにより、TCP送信者は、不必要に損失回復に入ったかどうかを検出できます。RFC 1323で定義されているTCPタイムスタンプオプションを接続に有効にする必要があります。EIFEL検出アルゴリズムは、TCPタイムスタンプオプションがTCPの再送信のあいまいさを排除するという事実を利用しています。損失回収中に到着する最初の許容可能なACKのタイムスタンプに基づいて、損失回収が不必要に入力されたかどうかを決定します。EIFEL検出アルゴリズムは、将来の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]に記載されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
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.
Octetの初めての伝送を「元の送信」と呼びます。同じオクテットのその後の伝送は、「再送信」と呼ばれます。ほとんどの場合、この用語は同様に、オクテットとは対照的にデータセグメントに適用できます。ただし、再パケット化により、セグメントには、オクテットの初めての送信と再送信の両方を含めることができます。その場合、この用語は、オクテットに適用された場合にのみ一貫しています。EIFEL検出アルゴリズムの場合、再パケット化が発生したときにも正しく動作するため、これは違いはありません。
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」は、高速再送信が送信される前にTCP送信者がすでに受信している重複ACKのカウンターです。変数「dupthresh」を使用して、いわゆる重複確認のしきい値、つまりTCP送信者に到達する必要がある重複ACKの数を参照して、高速な再送信をトリガーします。現在、Dupthreshは3つの固定値として指定されています[RFC2581]。将来のTCPは、適応型のデプスレッシュを実装する可能性があります。
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送信者の不能です。この問題は、タイムアウトベースの再送信の後と高速再送信の後に発生します。EIFEL検出アルゴリズムは、[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]）。このようなワイヤレスネットワークでは、疑いのあるタイムアウトが深刻な問題を引き起こした後に通常発生する不必要なGo-Back-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].
EIFEL検出アルゴリズムに基づいて、TCP送信者は専用の応答アルゴリズムを実装することを選択できます。このような応答アルゴリズムの目標の1つは、誤ってトリガーされた損失回復の結果を軽減することです。これには、TCP送信者の混雑制御状態の復元、および言及された不必要なGo-Back-N Recransmitsの回避が含まれる場合があります。もう1つの目標は、重複認識しきい値[RFC2581]やRTT推定器[RFC2988]などのプロトコルパラメーターを適応させることです。これは、接続が進行するにつれてTCPの損失回復を誤って引き起こすリスクを減らすためです。ただし、このような応答アルゴリズムは、このドキュメントの範囲外です。注：元の提案である「eifelアルゴリズム」[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.
EIFEL検出アルゴリズムの重要な特徴は、速い再送信またはタイムアウトが偽物であろうと、損失回復中に到着する最初の許容可能なACKに既に検出されていることです。これは、言及されたGo-Back-N Recransmitsを避けることができるために重要です。別の特徴は、eifel検出アルゴリズムが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オプションを使用して、再送信のあいまいさを排除することはできません。したがって、言及された不必要なGo-Back-N Recransmitsを回避するために使用することはできません。さらに、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パスで突然発生する遅延の増加によって引き起こされる可能性があります。これにより、許容可能なACKが遅すぎる可能性があります。つまり、TCP送信者の再送信タイマーが期限切れになった後にのみです。セクション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を生成します。これにより、3つ以上のデータセグメントが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の複製が3つ以上の重複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].
パケットの並べ替えとパケットの重複によって引き起こされるTCPパフォーマンスへのマイナスの影響は一般的に同じです：単一の偽の再送信（高速再送信）、およびその後の高速回復相[RFC2581]の結果としての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パフォーマンスへのマイナスの影響は、より深刻です。第一に、タイムアウトイベント自体は単一の偽の再送信を引き起こし、TCP送信者にスロースタートに不必要に強制します[RFC2581]。次に、接続が進むにつれて、TCPのパフォーマンスをさらに低下させる連鎖反応がトリガーされます。タイムアウトはスプリアスだったため、再送信のACKが到着する前に、通常、元の送信のための少なくとも一部のACKがTCP送信者に到着します。（これは、重度のパケットの並べ替えが、再送信のACKがTCP送信者に到着する最初の許容ACKであるように偽りのタイムアウトと一致していない限りです。）元の送信のためのこれらのACKは、暗黙のGo-Back-N損失をトリガーしますTCP送信者[LK00]での回復。優れたセグメントのどれも、対応するACKが失われていないと仮定すると、すべての未解決のセグメントが不必要に再送信されます。実際、この段階では、TCP送信者はパケット保存原理に違反します[JAC88]。これは、不必要なGo-Back-N Recransmitsがスロースタート中に送信されるためです。したがって、ネットワークを離れ、元のフライトの前半に属する各パケットについて、2つの役に立たない再送信がネットワークに送信されます。さらに、一部のTCPは偽の速い再送信に苦しんでいます。これは、TCPレシーバーで重複するように不必要なGo-Back-N再送信が到着し、一連の重複ACKをトリガーするためです。この最後の偽の速い再送信は、「bugfix」[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.
EIFEL検出アルゴリズムの目標は、TCP送信者が不必要に損失回復に入ったかどうかを検出できるようにすることです。さらに、TCP送信者は、タイムアウトベースの再送信または高速再送信が送信された後に到着する最初の許容可能なACKにこの決定を下すことができるはずです。これには、TCP送信者が元の送信または再送信に応じて送信されたかどうかを明確に区別できるACKの追加情報が必要です。このような追加情報は、TCPタイムスタンプオプション[RFC1323]によって提供されます。一般的に、タイムスタンプは、すべてのセグメントに追加された「シリアル番号」を単調に増加させ、対応するACK内にエコーされます。これは、次の方法でeifel検出アルゴリズムによって活用されます。
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.
eifel検出アルゴリズムが最初に許容可能なACKを決定するという事実は、将来の応答アルゴリズムが不必要なタイムアウト後に発生する不必要なGo-Back-n Recransmitsを回避できるようにするために重要です。また、損失の回復が不必要に入力された場合、すべてが再送信の保存されたタイムスタンプよりも小さいタイムスタンプを運ぶ窓に相当するAcksが傑出しています。これらのACKのいずれかの到着は、EIFEL検出アルゴリズムが機能するのに十分です。したがって、ソリューションは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送信者は、このサブセクションで定義されているようにEIFEL検出アルゴリズムを使用する場合があります。
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.
EIFEL検出アルゴリズムを使用する場合、TCP送信者は次の手順を実行する必要がありますが、損失回復の開始時にのみ、つまり、タイムアウトベースの再送信または高速再送信が送信される場合のみです。損失回復がすでに開始された後、EIFEL検出アルゴリズムを再現してはなりません。特に、同じセグメントの後続のタイムアウトで再現されてはなりません。また、選択的損失回復中に、最も古い未解決のセグメント以外のセグメントを再送信するときではありません。
(1) Set a "SpuriousRecovery" variable to FALSE (equal 0).
(1) 「SpouriousRecovery」変数をfalse（等しい0）に設定します。
(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) 「再送信」変数を、損失回収が開始されたときに送信された再送信に含まれるタイムスタンプ値フィールドの値フィールドの値に設定します。TCP送信者は、2回目のタイムアウトとその後の同じオクテットの2回目の再送信の場合、損失回復が進行するにつれて再送信が上書きされないことを確認する必要があります。
(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）に進み、
else proceed to step (DONE).
それ以外の場合は、ステップ（完了）に進みます。
(5) If the acceptable ACK carries a DSACK option [RFC2883], then proceed to step (DONE),
(5) 許容可能なACKが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),
それ以外の場合、TCP接続の寿命の間にTCP送信者が以前にDSACKオプションを使用してACKを受け取った場合、または許容可能なACKがすべての未解決のデータを確認しない場合、ステップ（6）に進みます。
else proceed to step (DONE).
それ以外の場合は、ステップ（完了）に進みます。
(6) If the loss recovery has been initiated with a timeout-based retransmit, then set SpuriousRecovery <- SPUR_TO (equal 1),
(6) タイムアウトベースの再送信で損失回復が開始された場合、Spurious Recovery <-spur_to（等しい1）を設定します。
else set SpuriousRecovery <- dupacks+1
それ以外の場合は、SpouriousRecovery <-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）の「より小さい」比較は保守的です。理論的には、タイムスタンプのクロックが遅い場合、またはネットワークが高速な場合、再送信はせいぜい元の送信に応じて送信された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接続の寿命の間に、TCP送信者が以前にDSACKオプションを使用してACKを受信した場合」に注意してください。。しかし、残念ながら、これは[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パスのこの暗黙的な形式の混雑制御を効果的に無効にします。この問題は、このセクションの残りの部分で説明されているように、EIFEL検出アルゴリズムのステップ（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によって運ばれ、再送信によって運ばれるタイムスタンプよりも一般的に小さい。その結果、EIFEL検出アルゴリズムは、TCPレシーバーがDSACK対応[RFC2883]でない限り、そのようなタイムアウトを偽りのように誤って解釈します。その場合、許容可能なACKにはDSACKオプションが搭載され、eifelアルゴリズムはステップの最初の部分（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でエコーされ、eifel検出アルゴリズムはステップ（4）で終了します。したがって、すべてのACKは、接続のDSACKオプションが有効になっているかどうかとは無関係に失われましたが、EIFEL検出アルゴリズムは効果がありません。
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の飛行全体に加えて、データセグメントが失われる限り問題ではありません。EIFEL検出アルゴリズムは、そのようなタイムアウトが偽物であると誤って解釈し、EIFEL応答アルゴリズムはうっ血コントロール状態を逆転させます。それでも、TCP送信者は、発行済みのフライトでの最初の損失について発見するとすぐに、混雑に（データパスで）応答します。つまり、TCP送信者は、そのパケットの飛行のために輻輳ウィンドウを半分にします。ACKのフライト全体が失われている間にデータセグメントが失われない場合、損失回復が入力された後にTCP送信者に到着する最初の許容可能なACKは、すべての未解決のデータを認めています。その場合、eifelアルゴリズムはステップの第2部（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.
ACKの飛行全体の喪失によって発生した避けられないタイムアウト、つまりEIFEL検出アルゴリズムがステップで終了したときに、避けられないタイムアウトの後にスロースタートを入力するときに、パケット保存原則に違反することについてはほとんど懸念がないことに注意してください（5）。これは、その場合、許容可能な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レシーバーに対して堅牢にする方法で、EIFEL検出アルゴリズムを変更する方法があります。アイデアは、TCPレシーバーがセグメントを受信するかどうかのみを知るというセグメントの「秘密」としてタイムスタンプを使用することです。逆に、TCPレシーバーは、失われたセグメントのタイムスタンプを知りません。したがって、TCP送信者が再送信したセグメントの元の送信を受け取ったことを「証明」するために、TCPレシーバーはその元の送信のタイムスタンプを返す必要があります。その後、EIFEL検出アルゴリズムを変更して、最初の許容可能な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.
（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）に進み、
else proceed to step (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がネットワークで再注文されなかったこと、およびTCPレシーバーがタイムスタンプを偽造せず、RFC 1323に準拠していることを前提としています。シーケンス空間のギャップのすべてまたは一部を埋めるデータセグメントのACKを生成するためのルール（[RFC2581]のセクション4.2を参照）、およびその場合のタイムスタンプをエコーするためのルール（セクション3.4のルール（c）を参照[rfc1323]）。スプリアスタイムアウトの場合、スプリアスタイムアウトを引き起こした遅延により、TCPレシーバーの遅延ACKタイマー[RFC1122]が元の送信が到着する前に期限切れになった可能性があります。また、この場合、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-1とn 1が到着している間にセグメントnが失われた場合、TCPレシーバーはセグメントn-1およびn 1のタイムスタンプの中央にあるタイムスタンプを推測し、送信したACKにエコーすることができます。特にTCP送信者が粗い粒度を備えたタイムスタンプを実装する場合、セグメントNの再送信に応じて、誤っているTCPレシーバーはそのようなアプローチで成功する可能性があります。実際、[WS95]で500ミリ秒の粒度が示唆されているため、セグメント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].
このリスクを減らす1つの方法は、細かい粒子標識のタイムスタンプを実装することです。タイムスタンプの粒度は、再送信タイマーの粒度とは無関係であることに注意してください。たとえば、一部のTCP実装は、ミリ秒ごとにチェックを付けるタイムスタンプクロックを実行します。これにより、TCPレシーバーが失われたセグメントのタイムスタンプを推測することがより困難になるはずです。あるいは、明示的な混雑通知（ECN）[RFC3168]に対して行われるように、タイムスタンプを非CEと組み合わせることが可能かもしれません。ただし、連続したセグメントのタイムスタンプが単調に増加したままであり、[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.
EIFEL検出アルゴリズムに関連するセキュリティ上の考慮事項はないようです。これは、EIFEL検出アルゴリズムがTCP送信者の既存のプロトコル状態を変更しないためです。EIFEL検出アルゴリズムには、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レシーバーに対して堅牢にするEIFEL検出アルゴリズムのバリアントがセクション3.4で提案されています。これは、EIFEL検出アルゴリズムがEIFEL応答アルゴリズム[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.
キース・スクラワー、ランディ・カッツ、ステファン・バウク、サリー・フロイド、ヴァーン・パクソン、マーク・オールマン、イーサン・ブラントン、アンドレイ・ガルトフ、パシ・サロラティ、アレクセイ・クズネツォフに、この仕事に貢献した有用な議論に感謝します。
Normative References
引用文献
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Floyd、S.、Mahdavi、J.、Mathis、M.、Podolsky、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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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] Blanton、E。およびM. Allman、「TCP DSACKとSCTPを使用してTSNSを重複させてスプリアスな再送信を検出する」、進行中の作業。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、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] Floyd、S。およびT. Henderson、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 2582、1999年4月。
[Gu01] Gurtov, A., "Effect of Delays on TCP Performance", In Proceedings of IFIP Personal Wireless Communications, August 2001.
[Gu01] Gurtov、A。、「TCPパフォーマンスに対する遅延の影響」、IFIP Personal Wireless Communicationsの議事録、2001年8月。
[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。、ガートフ、A。、およびF.カフィゾフ、「2番目（2.5g）および3番目の（3G）世代ワイヤレスネットワーク上のTCP」、RFC 3481、2003年2月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In Proceedings of ACM SIGCOMM 88.
[Jac88] Jacobson、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.
[KP87] Karn、P。およびC. Partridge、ACM Sigcomm 87の議事録における「信頼できる輸送プロトコルにおける往復時間推定の改善」。
[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] Ludwig、R。およびR. H. Katz、「アイフェルアルゴリズム：スプリアスレトランミッションに対してTCPを堅牢にする」、ACM Computer Communication Review、Vol。30、No。1、2000年1月。
[LG03] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", Work in Progress.
[LG03] Ludwig、R。およびA. Gurtov、「TCPのEIFEL応答アルゴリズム」は進行中です。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、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] Ramakrishnan、K.、Floyd、S。およびD. Black、「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. Kojo、「F-RTO：不必要な再送信を回避するためのTCP RTO回復アルゴリズム」、進行中の作業。
[WS95] Wright, G. R. and W. R. Stevens, "TCP/IP Illustrated, Volume 2 (The Implementation)", Addison Wesley, January 1995.
[WS95] Wright、G。R。およびW. R. Stevens、「TCP/IP Illustrated、Volume 2（The Enformation）」、Addison Wesley、1995年1月。
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", In Proceedings of ACM SIGCOMM 86.
[Zh86] Zhang、L。、「なぜTCPタイマーがうまく機能しないのか」、ACM Sigcomm 86の議事録。
Authors' Addresses
著者のアドレス
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath、ドイツ
EMail: Reiner.Ludwig@eed.ericsson.se
Michael Meyer Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
マイケル・マイヤー・エリクソン・リサーチ・エリクソン・アリー1 52134ヘルツォーゲンラス、ドイツ
EMail: Michael.Meyer@eed.ericsson.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。