Network Working Group R. Ludwig
Request for Comments: 4015 Ericsson Research
Category: Standards Track A. Gurtov
HIIT
February 2005
The Eifel Response Algorithm for TCP
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
Eifel応答アルゴリズムは、適切な検出アルゴリズムに基づいて、検出されたスプリアスタイムアウトにTCP送信者が応答する方法を提供します。 再送信タイマーを調整して、さらにスプリアスタイムアウトを回避し、（検出アルゴリズムに応じて）送信することが多い不必要なgo-back-N再送信を回避できます。 さらに、Eifel応答アルゴリズムは、パケットのバーストが回避されるように輻輳制御状態を復元します。
The Eifel response algorithm relies on a detection algorithm such as the Eifel detection algorithm, defined in [RFC3522]. That document contains informative background and motivation context that may be useful for implementers of the Eifel response algorithm, but it is not necessary to read [RFC3522] in order to implement the Eifel response algorithm. Note that alternative response algorithms have been proposed [BA02] that could also rely on the Eifel detection algorithm, and alternative detection algorithms have been proposed [RFC3708], [SK04] that could work together with the Eifel response algorithm.
Eifel応答アルゴリズムは、[RFC3522]で定義されているEifel検出アルゴリズムなどの検出アルゴリズムに依存しています。 そのドキュメントには、Eifel応答アルゴリズムの実装者に役立つかもしれない有益な背景と動機付けコンテキストが含まれていますが、Eifel応答アルゴリズムを実装するために[RFC3522]を読む必要はありません。 Eifel検出アルゴリズムにも依存できる代替応答アルゴリズム[BA02]が提案されており、Eifel応答アルゴリズムと連携できる代替検出アルゴリズム[RFC3708]、[SK04]が提案されていることに注意してください。
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
Eifel応答アルゴリズムは、適切な検出アルゴリズムに基づいて、検出されたスプリアスタイムアウトにTCP送信者が応答する方法を提供します。 再送信タイマーを調整して、さらにスプリアスタイムアウトを回避し、（検出アルゴリズムに応じて）送信することが多い不必要なgo-back-N再送信を回避できます。 さらに、Eifel応答アルゴリズムは、パケットのバーストが回避されるように輻輳制御状態を復元します。
Note: A previous version of the Eifel response algorithm also included a response to a detected spurious fast retransmit. However, as a consensus was not reached about how to adapt the duplicate acknowledgement threshold in that case, that part of the algorithm was removed for the time being.
注：Eifel応答アルゴリズムの以前のバージョンには、検出された偽の高速再送信に対する応答も含まれていました。 ただし、その場合に重複する肯定応答のしきい値をどのように適応させるかについてはコンセンサスに達していないため、当面はアルゴリズムのその部分は削除されました。
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]で説明されているように解釈される必要があります。MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONAL。
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 also be applied to data segments. However, when repacketization occurs, 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 and response algorithms, this makes no difference, as they also operate correctly when repacketization occurs.
オクテットの初回送信を「元の送信」と呼びます。 同じオクテットの後続の送信は、「再送信」と呼ばれます。 ほとんどの場合、この用語はデータセグメントにも適用できます。 ただし、再パケット化が発生すると、セグメントにはオクテットの初回送信と再送信の両方が含まれます。 その場合、この用語はオクテットに適用された場合にのみ一貫しています。 Eifel検出および応答アルゴリズムの場合、再パケット化が発生したときにも正しく動作するため、これは違いを生じません。
We use the term 'acceptable ACK' as defined in [RFC793]. That is an ACK that acknowledges previously unacknowledged data. We use the term 'bytes_acked' to refer to the amount (in terms of octets) of previously unacknowledged data that is acknowledged by the most recently received acceptable ACK. We use the TCP sender state variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA holds the segment sequence number of the oldest outstanding segment. SND.NXT holds the segment sequence number of the next segment the TCP sender will (re-)transmit. In addition, we define as 'SND.MAX' the segment sequence number of the next original transmit to be sent. The definition of SND.MAX is equivalent to the definition of 'snd_max' in [WS95].
[RFC793]で定義されている「許容可能なACK」という用語を使用します。 これは、以前に未確認のデータを確認するACKです。 「bytes_acked」という用語は、最後に受信した受け入れ可能なACKによって確認された、以前に確認されていないデータの量（オクテット単位）を指します。 [RFC793]で定義されているように、TCP送信者状態変数「SND.UNA」および「SND.NXT」を使用します。 SND.UNAは、最も古い未解決のセグメントのセグメントシーケンス番号を保持します。 SND.NXTは、TCP送信者が（再）送信する次のセグメントのセグメントシーケンス番号を保持します。 さらに、送信する次の元の送信のセグメントシーケンス番号を「SND.MAX」として定義します。 SND.MAXの定義は、[WS95]の「snd_max」の定義と同等です。
We use the TCP sender state variables 'cwnd' (congestion window), and 'ssthresh' (slow-start threshold), and the term 'FlightSize' as defined in [RFC2581]. FlightSize is the amount (in terms of octets) of outstanding data at a given point in time. We use the term 'Initial Window' (IW) as defined in [RFC3390]. The IW is the size of the sender's congestion window after the three-way handshake is completed. We use the TCP sender state variables 'SRTT' and
TCP送信側の状態変数「cwnd」（輻輳ウィンドウ）、「ssthresh」（スロースタートしきい値）、および[RFC2581]で定義されている用語「FlightSize」を使用します。 FlightSizeは、特定の時点での未処理データの量（オクテット単位）です。 [RFC3390]で定義されている「初期ウィンドウ」（IW）という用語を使用します。 IWは、スリーウェイハンドシェイクが完了した後の送信者の輻輳ウィンドウのサイズです。 TCP送信者状態変数「SRTT」を使用し、
'RTTVAR', and the terms 'RTO' and 'G' as defined in [RFC2988]. G is the clock granularity of the retransmission timer. In addition, we assume that the TCP sender maintains the value of the latest round-trip time (RTT) measurement in the (local) variable 'RTT-SAMPLE'.
[RTTVAR]、および[RFC2988]で定義されている用語「RTO」および「G」。 Gは、再送信タイマーのクロック粒度です。 さらに、TCP送信者は、（ローカル）変数「RTT-SAMPLE」で最新の往復時間（RTT）測定値を維持すると想定しています。
We use the TCP sender state variable 'T_last', and the term 'tcpnow' as used in [RFC2861]. T_last holds the system time when the TCP sender sent the last data segment, whereas tcpnow is the TCP sender's current system time.
TCP送信側の状態変数「T_last」、および[RFC2861]で使用されている「tcpnow」という用語を使用します。 T_lastは、TCP送信者が最後のデータセグメントを送信したときのシステム時刻を保持しますが、tcpnowはTCP送信者の現在のシステム時刻です。
If the Eifel response algorithm is implemented at the TCP sender, it MUST be implemented together with a detection algorithm that is specified in a standards track or experimental RFC.
Eifel応答アルゴリズムがTCP送信側で実装されている場合、標準化過程または実験的なRFCで指定されている検出アルゴリズムとともに実装する必要があります。
Designers of detection algorithms who want their algorithms to work together with the Eifel response algorithm should reuse the variable "SpuriousRecovery" with the semantics and defined values specified in [RFC3522]. In addition, we define the constant LATE_SPUR_TO (set equal to -1) as another possible value of the variable SpuriousRecovery. Detection algorithms should set the value of SpuriousRecovery to LATE_SPUR_TO if the detection of a spurious retransmit is based on the ACK for the retransmit (as opposed to an ACK for an original transmit). For example, this applies to detection algorithms that are based on the DSACK option [RFC3708].
アルゴリズムをEifel応答アルゴリズムと連携させたい検出アルゴリズムの設計者は、[RFC3522]で指定されたセマンティクスと定義値で変数 "SpuriousRecovery"を再利用する必要があります。 さらに、定数LATE_SPUR_TO（-1に設定）を変数SpuriousRecoveryの別の可能な値として定義します。 スプリアス再送信の検出が（元の送信のACKとは対照的に）再送信のACKに基づいている場合、検出アルゴリズムはSpuriousRecoveryの値をLATE_SPUR_TOに設定する必要があります。 たとえば、これはDSACKオプション[RFC3708]に基づく検出アルゴリズムに適用されます。
The complete algorithm is specified in section 3.1. In sections 3.2 - 3.6, we discuss the different steps of the algorithm.
完全なアルゴリズムはセクション3.1で指定されています。 セクション3.2-3.6では、アルゴリズムのさまざまなステップについて説明します。
Given that a TCP sender has enabled a detection algorithm that complies with the requirements set in Section 2, a TCP sender MAY use the Eifel response algorithm as defined in this subsection.
TCP送信者がセクション2で設定された要件に準拠した検出アルゴリズムを有効にした場合、TCP送信者はこのサブセクションで定義されているEifel応答アルゴリズムを使用することができます。
If the Eifel response algorithm is used, the following steps MUST be taken by the TCP sender, but only upon initiation of a timeout-based loss recovery. That is when the first timeout-based retransmit is sent. The algorithm MUST NOT be reinitiated after a timeout-based loss recovery has already been started but not completed. In particular, it may not be reinitiated upon subsequent timeouts for the same segment, or upon retransmitting segments other than the oldest outstanding segment.
Eifel応答アルゴリズムを使用する場合、TCP送信者は次の手順を実行する必要がありますが、タイムアウトベースの損失回復の開始時のみです。 それは、最初のタイムアウトベースの再送信が送信されるときです。 タイムアウトベースの損失回復がすでに開始されているが完了していない場合、アルゴリズムを再開してはなりません。 特に、同じセグメントの後続のタイムアウト時、または最も古い未処理のセグメント以外のセグメントの再送信時に再起動されない場合があります。
(0) Before the variables cwnd and ssthresh get updated when loss recovery is initiated, set a "pipe_prev" variable as follows: pipe_prev <- max (FlightSize, ssthresh)
（0）損失回復が開始されたときに変数cwndおよびssthreshが更新される前に、「pipe_prev」変数を次のように設定します。pipe_prev <-max（FlightSize、ssthresh）
Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as
follows:
SRTT_prev <- SRTT + (2 * G)
RTTVAR_prev <- RTTVAR
(DET) This is a placeholder for a detection algorithm that must be executed at this point, and that sets the variable SpuriousRecovery as outlined in Section 2. If [RFC3522] is used as the detection algorithm, steps (1) - (6) of that algorithm go here.
（DET）これは、この時点で実行する必要がある検出アルゴリズムのプレースホルダーであり、セクション2で概説した変数SpuriousRecoveryを設定します。[RFC3522]が検出アルゴリズムとして使用される場合、ステップ（1）-（6） そのアルゴリズムのここに行きます。
(7) If SpuriousRecovery equals SPUR_TO, then proceed to step (8);
（7）SpuriousRecoveryがSPUR_TOと等しい場合、ステップ（8）に進みます。
else if SpuriousRecovery equals LATE_SPUR_TO, then
proceed to step (9);
else proceed to step (DONE).
それ以外の場合は、ステップ（完了）に進みます。
(8) Resume the transmission with previously unsent data:
（8）以前に未送信のデータを使用して送信を再開します。
Set
SND.NXT <- SND.MAX
(9) Reverse the congestion control state:
（9）輻輳制御状態を反転します。
If the acceptable ACK has the ECN-Echo flag [RFC3168] set,
then
proceed to step (DONE);
else set cwnd <- FlightSize + min (bytes_acked, IW) ssthresh <- pipe_prev
それ以外の場合はcwnd <-FlightSize + min（bytes_acked、IW）ssthresh <-pipe_prevを設定します
Proceed to step (DONE).
ステップ（完了）に進みます。
(10) Interworking with Congestion Window Validation:
（10）輻輳ウィンドウ検証との相互作用：
If congestion window validation is implemented according
to [RFC2861], then set
T_last <- tcpnow
(11) Adapt the conservativeness of the retransmission timer:
（11）再送信タイマーの保守性を調整します。
Upon the first RTT-SAMPLE taken from new data; i.e., the
first RTT-SAMPLE that can be derived from an acceptable
ACK for data that was previously unsent when the spurious
timeout occurred,
if the retransmission timer is implemented according
to [RFC2988], then set
SRTT <- max (SRTT_prev, RTT-SAMPLE)
RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2)
RTO <- SRTT + max (G, 4*RTTVAR)
Run the bounds check on the RTO (rules (2.4) and
(2.5) in [RFC2988]), and restart the
retransmission timer;
else appropriately adapt the conservativeness of the retransmission timer that is implemented.
それ以外の場合は、実装される再送信タイマーの保守性を適切に調整します。
(DONE) No further processing.
（完了）それ以上の処理はありません。
The TCP sender stores in pipe_prev what is considered a safe slow-start threshold (ssthresh) before loss recovery is initiated; i.e., before the loss indication is taken into account. This is either the current FlightSize, if the TCP sender is in congestion avoidance, or the current ssthresh, if the TCP sender is in slow-start. If the TCP sender later detects that it has entered loss recovery unnecessarily, then pipe_prev is used in step (9) to reverse the congestion control state. Thus, until the loss recovery phase is terminated, pipe_prev maintains a memory of the congestion control state of the time right before the loss recovery phase was initiated. A similar approach is proposed in [RFC2861], where this state is stored in ssthresh directly after a TCP sender has become idle or application limited.
TCPセンダーは、損失回復が開始される前に、安全なスロースタートしきい値（ssthresh）と見なされるものをpipe_prevに保存します。 すなわち、損失表示が考慮される前。 これは、TCP送信側が輻輳回避状態にある場合は現在のFlightSizeであり、TCP送信側がスロースタート状態にある場合は現在のssthreshです。 TCP送信者が後で不必要に損失回復に入ったことを検出した場合、ステップ（9）でpipe_prevを使用して輻輳制御状態を反転します。 したがって、損失回復フェーズが終了するまで、pipe_prevは、損失回復フェーズが開始される直前の時間の輻輳制御状態のメモリを維持します。 同様のアプローチが[RFC2861]で提案されており、TCP送信者がアイドル状態になった、またはアプリケーションが制限された直後にこの状態がssthreshに保存されます。
There had been debates about whether the value of pipe_prev should be decayed over time; e.g., upon subsequent timeouts for the same outstanding segment. We do not require decaying pipe_prev for the Eifel response algorithm and do not believe that such a conservative approach should be in place. Instead, we follow the idea of revalidating the congestion window through slow-start, as suggested in [RFC2861]. That is, in step (9), the cwnd is reset to a value that avoids large packet bursts, and ssthresh is reset to the value of pipe_prev. Note that [RFC2581] and [RFC2861] also do not require
pipe_prevの値を経時的に減衰させるべきかどうかについては議論がありました。 たとえば、同じ未解決のセグメントの後続のタイムアウト時。 Eifel応答アルゴリズムにpipe_prevを減衰させる必要はなく、そのような保守的なアプローチが適切であるとは考えていません。 代わりに、[RFC2861]で提案されているように、スロースタートにより輻輳ウィンドウを再検証するという考えに従います。 つまり、ステップ（9）で、cwndは大きなパケットバーストを回避する値にリセットされ、ssthreshはpipe_prevの値にリセットされます。 [RFC2581]と[RFC2861]も必要ないことに注意してください
a decaying of ssthresh after it has been reset in response to a loss indication, or after a TCP sender has become idle or application limited.
損失表示に応じてリセットされた後、またはTCP送信者がアイドル状態またはアプリケーション制限になった後のssthreshの減衰。
Without the use of the TCP timestamps option [RFC1323], the TCP sender suffers from the retransmission ambiguity problem [Zh86], [KP87]. Therefore, when the first acceptable ACK arrives after a spurious timeout, the TCP sender must assume that this ACK was sent in response to the retransmit when in fact it was sent in response to an original transmit. Furthermore, the TCP sender must further assume that all other segments that were outstanding at that point were lost.
TCPタイムスタンプオプション[RFC1323]を使用しないと、TCP送信者は再送信のあいまいさの問題[Zh86]、[KP87]に悩まされます。 したがって、スプリアスタイムアウト後に最初の受け入れ可能なACKが到着した場合、TCP送信者は、実際には元の送信への応答として送信されたこのACKが再送信への応答として送信されたと想定する必要があります。 さらに、TCP送信者は、その時点で未処理であった他のすべてのセグメントが失われたとさらに想定する必要があります。
Note: Except for certain cases where original ACKs were lost, the first acceptable ACK cannot carry a DSACK option [RFC2883].
注：元のACKが失われた特定の場合を除き、最初の受け入れ可能なACKはDSACKオプション[RFC2883]を伝送できません。
Consequently, once the TCP sender's state has been updated after the first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is what causes the often unnecessary go-back-N retransmits. From that point on every arriving acceptable ACK that was sent in response to an original transmit will advance SND.NXT. But as long as SND.NXT is smaller than the value that SND.MAX had when the timeout occurred, those ACKs will clock out retransmits, whether or not the corresponding original transmits were lost.
したがって、最初の受け入れ可能なACKが到着した後にTCP送信者の状態が更新されると、SND.NXTはSND.UNAに等しくなります。 これが、しばしば不必要なgo-back-N再送信の原因です。 その時点から、元の送信に応答して送信されたすべての受け入れ可能なACKで、SND.NXTが進みます。 ただし、SND.NXTがタイムアウト発生時のSND.MAXの値よりも小さい限り、それらのACKは、対応する元の送信が失われたかどうかに関係なく、再送信をクロックアウトします。
In fact, during this phase the TCP sender breaks 'packet conservation' [Jac88]. This is because the go-back-N retransmits are sent during slow-start. For each original transmit leaving the network, two retransmits are sent into the network as long as SND.NXT does not equal SND.MAX (see [LK00] for more detail).
実際、この段階でTCP送信者は「パケット保存」を破ります[Jac88]。 これは、スローバック中にgo-back-N再送信が送信されるためです。 ネットワークを離れる元の送信ごとに、SND.NXTがSND.MAXと等しくない限り、2回の再送信がネットワークに送信されます（詳細については[LK00]を参照）。
Once a spurious timeout has been detected (upon receipt of an ACK for an original transmit), it is safe to let the TCP sender resume the transmission with previously unsent data. Thus, the Eifel response algorithm changes the TCP sender's state by setting SND.NXT to SND.MAX. Note that this step is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a detection algorithm such as the Eifel detection algorithm [RFC3522] or the F-RTO algorithm [SK04] that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
スプリアスタイムアウトが検出されると（元の送信に対するACKの受信時）、TCP送信者に以前に送信されていないデータで送信を再開させることが安全です。 したがって、Eifel応答アルゴリズムは、SND.NXTをSND.MAXに設定することにより、TCP送信者の状態を変更します。 このステップは、変数SpuriousRecoveryがSPUR_TOに等しい場合にのみ実行されることに注意してください。SPUR_TOは、Eifel検出アルゴリズム[RFC3522]やF-RTOアルゴリズム[SK04]などの検出アルゴリズムを必要とします。 元の送信（再送信のACK [RFC3708]とは対照的に）。
When a TCP sender enters loss recovery, it reduces cwnd and ssthresh. However, once the TCP sender detects that the loss recovery has been falsely triggered, this reduction proves unnecessary. We therefore believe that it is safe to revert to the previous congestion control state, following the approach of revalidating the congestion window as outlined below. This is unless the acceptable ACK signals congestion through the ECN-Echo flag [RFC3168]. In that case, the TCP sender MUST refrain from reversing congestion control state.
TCP送信者が損失回復に入ると、cwndとssthreshが削減されます。 ただし、損失の回復が誤ってトリガーされたことをTCP送信者が検出すると、この削減は不要であることがわかります。 したがって、以下に概説するように輻輳ウィンドウを再検証するアプローチに従って、以前の輻輳制御状態に戻ることは安全であると考えています。 これは、受け入れ可能なACKがECN-Echoフラグ[RFC3168]を介して輻輳を通知しない限りです。 その場合、TCP送信者は輻輳制御状態を逆にすることを控えなければなりません。
If the ECN-Echo flag is not set, cwnd is reset to the sum of the current FlightSize and the minimum of bytes_acked and IW. In some cases, this can mean that the first few acceptable ACKs that arrive will not clock out any data segments. Recall that bytes_acked is the number of bytes that have been acknowledged by the acceptable ACK. Note that the value of cwnd must not be changed any further for that ACK, and that the value of FlightSize at this point in time may be different from the value of FlightSize in step (0). The value of IW puts a limit on the size of the packet burst that the TCP sender may send into the network after the Eifel response algorithm has terminated. The value of IW is considered an acceptable burst size. It is the amount of data that a TCP sender may send into a yet "unprobed" network at the beginning of a connection.
ECN-Echoフラグが設定されていない場合、cwndは現在のFlightSizeと最小のbytes_ackedおよびIWの合計にリセットされます。 場合によっては、これは到着する最初の数個の受け入れ可能なACKがデータセグメントの時間を記録しないことを意味します。 bytes_ackedは、受け入れ可能なACKによって確認されたバイト数であることを思い出してください。 cwndの値はそのACKに対してこれ以上変更してはならず、この時点でのFlightSizeの値はステップ（0）のFlightSizeの値と異なる場合があることに注意してください。 IWの値は、Eifel応答アルゴリズムが終了した後にTCP送信者がネットワークに送信できるパケットバーストのサイズに制限を設けます。 IWの値は、許容可能なバーストサイズと見なされます。 接続の開始時に、TCP送信者がまだ「プローブされていない」ネットワークに送信できるデータの量です。
Then ssthresh is reset to the value of pipe_prev. As a result, the TCP sender either immediately resumes probing the network for more bandwidth in congestion avoidance, or it slow-starts to what is considered a safe operating point for the congestion window.
次に、ssthreshがpipe_prevの値にリセットされます。 その結果、TCP送信側は、輻輳回避のために帯域幅を増やすためにネットワークのプローブをすぐに再開するか、輻輳ウィンドウの安全な動作点と見なされるものまでスロースタートします。
An implementation of the Congestion Window Validation (CWV) algorithm [RFC2861] could potentially misinterpret a delay spike that caused a spurious timeout as a phase where the TCP sender had been idle. Therefore, T_last is reset to prevent the triggering of the CWV algorithm in this case.
Congestion Window Validation（CWV）アルゴリズム[RFC2861]の実装は、TCP送信者がアイドル状態だったフェーズとしてスプリアスタイムアウトを引き起こした遅延スパイクを誤って解釈する可能性がありました。 したがって、この場合、CWVアルゴリズムのトリガーを防ぐためにT_lastがリセットされます。
Note: The term 'idle' implies that the TCP sender has no data outstanding; i.e., all data sent has been acknowledged [Jac88]. According to this definition, a TCP sender is not idle while it is waiting for an acceptable ACK after a timeout. Unfortunately, the pseudo-code in [RFC2861] does not include a check for the condition "idle" (SND.UNA == SND.MAX). We therefore had to add step (10) to the Eifel response algorithm.
注：「アイドル」という用語は、TCP送信者に未解決のデータがないことを意味します。 つまり、送信されたすべてのデータが確認されました[Jac88]。 この定義によれば、TCP送信者は、タイムアウト後に許容可能なACKを待機している間、アイドル状態ではありません。 残念ながら、[RFC2861]の擬似コードには、条件「アイドル」のチェックは含まれていません（SND.UNA == SND.MAX）。 したがって、ステップ（10）をEifel応答アルゴリズムに追加する必要がありました。
There is currently only one retransmission timer standardized for TCP [RFC2988]. We therefore only address that timer explicitly. Future standards that might define alternatives to [RFC2988] should propose similar measures to adapt the conservativeness of the retransmission timer.
現在、TCP [RFC2988]用に標準化された再送信タイマーは1つだけです。 したがって、そのタイマーに明示的に対処するだけです。 [RFC2988]に代わるものを定義するかもしれない将来の標準は、再送信タイマーの保守性を適合させる同様の手段を提案するべきです。
A spurious timeout often results from a delay spike, which is a sudden increase of the RTT that usually cannot be predicted. After a delay spike, the RTT may have changed permanently; e.g., due to a path change, or because the available bandwidth on a bandwidth-dominated path has decreased. This may often occur with wide-area wireless access links. In this case, the RTT estimators (SRTT and RTTVAR) should be reinitialized from the first RTT-SAMPLE taken from new data according to rule (2.2) of [RFC2988]. That is, from the first RTT-SAMPLE that can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
スプリアスタイムアウトは、通常は予測できないRTTの突然の増加である遅延スパイクから生じることがよくあります。 遅延スパイクの後、RTTが永続的に変更された可能性があります。 たとえば、パスの変更、または帯域幅が支配的なパスで利用可能な帯域幅が減少したことが原因です。 これは、ワイドエリアワイヤレスアクセスリンクでよく発生します。 この場合、RTT推定量（SRTTおよびRTTVAR）は、[RFC2988]のルール（2.2）に従って新しいデータから取得した最初のRTT-SAMPLEから再初期化する必要があります。 つまり、最初のRTT-SAMPLEから、スプリアスタイムアウトが発生したときに以前は送信されていなかったデータの受け入れ可能なACKから取得できます。
However, a delay spike may only indicate a transient phase, after which the RTT returns to its previous range of values, or even to smaller values. Also, a spurious timeout may occur because the TCP sender's RTT estimators were only inaccurate enough that the retransmission timer expires "a tad too early". We believe that two times the clock granularity of the retransmission timer (2 * G) is a reasonable upper bound on "a tad too early". Thus, when the new RTO is calculated in step (11), we ensure that it is at least (2 * G) greater (see also step (0)) than the RTO was before the spurious timeout occurred.
ただし、遅延スパイクは一時的なフェーズのみを示している可能性があり、その後、RTTは以前の値の範囲、またはさらに小さい値に戻ります。 また、TCP送信者のRTT推定器が不正確で、再送信タイマーが「少し早すぎる」期限切れになるため、スプリアスタイムアウトが発生する場合があります。 再送信タイマーの2倍のクロック粒度（2 * G）は、「少し早すぎる」の妥当な上限であると考えています。 したがって、ステップ（11）で新しいRTOが計算されるとき、スプリアスタイムアウトが発生する前のRTOよりも少なくとも（2 * G）大きい（ステップ（0）も参照）ことを確認します。
Note that other TCP sender processing will usually take place between steps (10) and (11). During this phase (i.e., before step (11) has been reached), the RTO is managed according to the rules of [RFC2988]. We believe that this is sufficiently conservative for the following reasons. First, the retransmission timer is restarted upon the acceptable ACK that was used to detect the spurious timeout. As a result, the delay spike is already implicitly factored in for segments outstanding at that time. This is discussed in more detail in [EL04], where this effect is called the "RTO offset". Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE can be derived from that acceptable ACK. This RTT-SAMPLE must be relatively large, as it includes the delay spike that caused the spurious timeout. Consequently, the RTT estimators will be updated rather conservatively. Without timestamps the RTO will stay conservatively backed-off due to Karn's algorithm [RFC2988] until the first RTT-SAMPLE can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
他のTCP送信者処理は通常、ステップ（10）と（11）の間に行われることに注意してください。このフェーズの間（すなわち、ステップ（11）に到達する前）、RTOは[RFC2988]のルールに従って管理されます。次の理由により、これは十分に保守的であると考えています。最初に、スプリアスタイムアウトの検出に使用された受け入れ可能なACKで再送信タイマーが再起動されます。その結果、遅延スパイクは、その時点で未処理のセグメントに対してすでに暗黙的に考慮されています。これについては[EL04]で詳しく説明されています。この効果は「RTOオフセット」と呼ばれます。さらに、タイムスタンプが有効になっている場合、その有効なACKから新しい有効なRTT-SAMPLEを取得できます。このRTT-SAMPLEは、スプリアスタイムアウトの原因となった遅延スパイクを含むため、比較的大きくする必要があります。その結果、RTT推定量はかなり控えめに更新されます。タイムスタンプがなければ、カーンのアルゴリズム[RFC2988]により、スプリアスタイムアウトが発生したときに以前に送信されなかったデータの受け入れ可能なACKから最初のRTT-SAMPLEが得られるまで、RTOは控えめにバックオフされます。
For the new RTO to become effective, the retransmission timer has to be restarted. This is consistent with [RFC2988], which recommends restarting the retransmission timer with the arrival of an acceptable ACK.
新しいRTOを有効にするには、再送信タイマーを再起動する必要があります。 これは、[RFC2988]と一致しています。[RFC2988]は、受け入れ可能なACKの到着で再送信タイマーを再起動することを推奨しています。
We have studied environments where spurious timeouts and multiple losses from the same flight of packets often coincide [GL02], [GL03]. In such a case, the oldest outstanding segment arrives at the TCP receiver, but one or more packets from the remaining outstanding flight are lost. In those environments, end-to-end performance suffers if the Eifel response algorithm is operated without an advanced loss recovery scheme such as a SACK-based scheme [RFC3517] or NewReno [RFC3782]. The reason is TCP-Reno's aggressiveness after a spurious timeout. Even though TCP-Reno breaks 'packet conservation' (see Section 3.3) when blindly retransmitting all outstanding segments, it usually recovers all packets lost from that flight within a single round-trip time. On the contrary, the more conservative TCP-Reno-with-Eifel is often forced into another timeout. Thus, we recommend that the Eifel response algorithm always be operated in combination with [RFC3517] or [RFC3782]. Additional robustness is achieved with the Limited Transmit and Early Retransmit algorithms [RFC3042], [AAAB04].
私たちは、パケットの同じ飛行によるスプリアスタイムアウトと複数の損失がしばしば一致する環境を研究しました[GL02]、[GL03]。このような場合、最も古い未処理のセグメントがTCP受信機に到着しますが、残りの未処理のフライトからの1つ以上のパケットは失われます。これらの環境では、SACKベースのスキーム[RFC3517]やNewReno [RFC3782]などの高度な損失回復スキームなしでEifel応答アルゴリズムを操作すると、エンドツーエンドのパフォーマンスが低下します。理由は、スプリアスタイムアウト後のTCP-Renoの積極性です。 TCP-Renoは、未処理のすべてのセグメントを盲目的に再送信すると「パケット保存」（セクション3.3を参照）を解除しますが、通常、1回の往復時間内にそのフライトから失われたすべてのパケットを回復します。それどころか、より保守的なTCP-Reno-with-Eifelは、しばしば別のタイムアウトに追い込まれます。したがって、Eifel応答アルゴリズムは常に[RFC3517]または[RFC3782]と組み合わせて運用することをお勧めします。制限された送信および早期再送信アルゴリズム[RFC3042]、[AAAB04]により、追加の堅牢性が実現されます。
Note: The SACK-based scheme we used for our simulations in [GL02] and [GL03] is different from the SACK-based scheme that later got standardized [RFC3517]. The key difference is that [RFC3517] is more robust to multiple losses from the same flight. It is less conservative in declaring that a packet has left the network, and is therefore less dependent on timeouts to recover genuine packet losses.
注：[GL02]および[GL03]のシミュレーションに使用したSACKベースのスキームは、後に標準化された[RFC3517]のSACKベースのスキームとは異なります。 主な違いは、[RFC3517]は同じフライトからの複数の損失に対してより堅牢であることです。 パケットがネットワークを離れたことを宣言する際の保守性は低く、したがって、真のパケット損失を回復するためのタイムアウトへの依存度は低くなります。
If the NewReno algorithm [RFC3782] is used in combination with the Eifel response algorithm, step (1) of the NewReno algorithm SHOULD be modified as follows, but only if SpuriousRecovery equals SPUR_TO:
NewRenoアルゴリズム[RFC3782]がEifel応答アルゴリズムと組み合わせて使用される場合、NewRenoアルゴリズムのステップ（1）は、SpuriousRecoveryがSPUR_TOと等しい場合にのみ、次のように変更する必要があります。
(1) Three duplicate ACKs: When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, go to step 1A.
（1）3つの重複したACK：3番目の重複したACKを受信し、送信者が高速回復手順にまだない場合は、手順1Aに進みます。
That is, the entire step 1B of the NewReno algorithm is obsolete because step (8) of the Eifel response algorithm avoids the case where three duplicate ACKs result from unnecessary go-back-N retransmits after a timeout. Step (8) of the Eifel response algorithm avoids such unnecessary go-back-N retransmits in the first place. However, recall that step (8) is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a detection algorithm, such as the Eifel detection algorithm [RFC3522] or the F-RTO algorithm [SK04], that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
つまり、New Renoアルゴリズムのステップ1B全体は、Eifel応答アルゴリズムのステップ（8）により、タイムアウト後の不要なgo-back-N再送信によって3つの重複したACKが生じるケースが回避されるため、廃止されます。 アイフェル応答アルゴリズムのステップ（8）は、そもそもこのような不必要なgo-back-N再送信を回避します。 ただし、変数SpuriousRecoveryがSPUR_TOに等しい場合にのみステップ（8）が実行されることを思い出してください。SPUR_TOには、偽の再送信を検出するEifel検出アルゴリズム[RFC3522]やF-RTOアルゴリズム[SK04]などの検出アルゴリズムが必要です 元の送信のACKの受信に基づいて（再送信のACKとは対照的に[RFC3708]）。
There is a risk that a detection algorithm is fooled by spoofed ACKs that make genuine retransmits appear to the TCP sender as spurious retransmits. When such a detection algorithm is run together with the Eifel response algorithm, this could effectively disable congestion control at the TCP sender. Should this become a concern, the Eifel response algorithm SHOULD only be run together with detection algorithms that are known to be safe against such "ACK spoofing attacks".
偽造されたACKによって検出アルゴリズムがだまされて、TCP送信者に偽の再送信として本物の再送信が表示されるリスクがあります。 このような検出アルゴリズムがEifel応答アルゴリズムとともに実行されると、TCP送信側で輻輳制御が事実上無効になる可能性があります。 これが問題になる場合、Eifel応答アルゴリズムは、そのような「ACKスプーフィング攻撃」に対して安全であることが知られている検出アルゴリズムと一緒にのみ実行されるべきです。
For example, the safe variant of the Eifel detection algorithm [RFC3522], is a reliable method to protect against this risk.
たとえば、Eifel検出アルゴリズムの安全なバリアント[RFC3522]は、このリスクから保護するための信頼できる方法です。
Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions that contributed to this work.
この仕事に貢献してくれた多くの議論に対して、キース・スクロウアー、ランディ・カッツ、マイケル・マイヤー、ステファン・バウケ、サリー・フロイド、ヴァーン・パクソン、マーク・オールマン、イーサン・ブラントン、パシ・サロラハティ、アレクセイ・クズネツォフ、ヨゲシュ・スワミに感謝します。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP Congestion Control」、RFC 2581、1999年4月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[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月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]フロイド、S。、ヘンダーソン、T。、およびA.グルトフ、「TCPの高速回復アルゴリズムに対するNewRenoの修正」、RFC 3782、2004年4月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861] Handley、M.、Padhye、J。、およびS. Floyd、「TCP Congestion Window Validation」、RFC 2861、2000年6月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522] Ludwig、R.、M。Meyer、「TCPのアイフェル検出アルゴリズム」、RFC 3522、2003年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「Computing TCPの再送信タイマー」、RFC 2988、2000年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J。、「伝送制御プロトコル」、STD 7、RFC 793、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月。
[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月。
[AAAB04] Allman, M., Avrachenkov, K., Ayesta, U., and J. Blanton, Early Retransmit for TCP and SCTP, Work in Progress, July 2004.
[AAAB04] Allman、M.、Avrachenkov、K.、Ayesta、U。、およびJ. Blanton、TCPおよびSCTPの早期再送信、Work in Progress、2004年7月。
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to Packet Reordering, ACM Computer Communication Review, Vol. 32, No. 1, January 2002.
[BA02] Blanton、E.、M。Allman、TCPをパケットの並べ替えに対してより堅牢にすること、ACM Computer Communication Review、Vol。 32、No。1、2002年1月。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, February 2004.
[RFC3708] Blanton、E。、およびM. Allman、「TCP重複選択的確認応答（DSACK）およびストリーム制御伝送プロトコル（SCTP）重複伝送シーケンス番号（TSN）を使用した偽の再送信の検出」、RFC 3708、2004年2月。
[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] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的選択的確認応答（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[EL04] Ekstrom, H. and R. Ludwig, The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport, In Proceedings of IEEE INFOCOM 04, March 2004.
[EL04] Ekstrom、H.、R。Ludwig、The Peak-Hopper：信頼できるユニキャスト転送のための新しいエンドツーエンドの再送信タイマー、IEEE INFOCOM 04、2004年3月の議事録。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]フロイド、S。、マダビ、J。、マティス、M。、およびM.ポドルスキー、「TCPの選択的確認（SACK）オプションの拡張」、RFC 2883、2000年7月
[GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm for TCP in a GPRS Network, In Proceedings of the European Wireless Conference, February 2002.
[GL02] Gurtov、A。、およびR. Ludwig、GPRSネットワークでのTCPのアイフェルアルゴリズムの評価、2002年2月の欧州ワイヤレス会議の議事録。
[GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts in TCP, In Proceedings of IEEE INFOCOM 03, April 2003.
[GL03] Gurtov、A。、およびR. Ludwig、TCPのスプリアスタイムアウトへの応答、IEEE INFOCOM 03の議事録、2003年4月。
[Jac88] Jacobson, V., Congestion Avoidance and Control, In Proceedings of ACM SIGCOMM 88.
[Jac88] Jacobson、V.、輻輳回避および制御、ACM SIGCOMM 88の議事録。
[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月。
[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月。
[SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP, Work in Progress, November 2004.
[SK04] Sarolahti、P.およびM. Kojo、F-RTO：TCPおよびSCTPを使用した偽の再送信タイムアウトを検出するためのアルゴリズム、Work in Progress、2004年11月。
[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 Illustrated、第2巻（実装）、Addison Wesley、1995年1月。
[Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings of ACM SIGCOMM 88.
[Zh86] Zhang、L.、TCPタイマーがうまく機能しない理由、ACM SIGCOMM 88の議事録。
Authors' Addresses
著者のアドレス
Reiner Ludwig Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath, Germany
Reiner Ludwig Ericsson Research（EDD）エリクソンアリー1 52134ヘルツォーゲンラート、ドイツ
EMail: Reiner.Ludwig@ericsson.com
メール：Reiner.Ludwig@ericsson.com
Andrei Gurtov Helsinki Institute for Information Technology (HIIT) P.O. Box 9800, FIN-02015 HUT, Finland
アンドレイ・グルトフヘルシンキ情報技術研究所（HIIT）P.O. Box 9800、FIN-02015 HUT、フィンランド
EMail: andrei.gurtov@cs.helsinki.fi Homepage: http://www.cs.helsinki.fi/u/gurtov
メール：andrei.gurtov@cs.helsinki.fiホームページ：http://www.cs.helsinki.fi/u/gurtov
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書は、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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 IETFドキュメントの権利に関するIETFの手順に関する情報は、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.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。