RFC 4015 - The Eifel Response Algorithm for TCP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4015
タイトル : RFC 4015 - TCPのEIFEL応答アルゴリズム
翻訳編集 : 自動生成

[要約] RFC 4015は、TCPのためのEifel応答アルゴリズムについての要約と目的を提供しています。このアルゴリズムは、ネットワークの過負荷を検出し、パフォーマンスを向上させるために使用されます。

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

TCPのEIFEL応答アルゴリズム

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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 Recransmitsを避けることができます。さらに、eifel応答アルゴリズムは、パケットバーストが回避されるように、輻輳制御状態を復元します。

1. Introduction

1. はじめに

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検出アルゴリズムにも依存する可能性のある代替応答アルゴリズムが提案されており、代替検出アルゴリズムが提案されている[RFC3708]、[SK04]は、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応答アルゴリズムの以前のバージョンには、検出された偽の高速再送信に対する応答も含まれています。ただし、その場合、重複した謝辞のしきい値をどのように適応させるかについてコンセンサスに達したため、アルゴリズムの部分は当面が削除されました。

1.1. Terminology

1.1. 用語

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 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.

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 '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 Sender State変数「CWND」（輻輳ウィンドウ）、および「SSTHRESH」（スロースタートしきい値）を使用し、[RFC2581]で定義されている「フライトサイズ」という用語を使用します。フライトサイズは、特定の時点での未解決のデータの量（オクテットの点で）です。[RFC3390]で定義されている「初期ウィンドウ」（IW）という用語を使用します。IWは、3方向の握手が完了した後、送信者の輻輳窓のサイズです。TCP Sender State変数の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サンプル」で最新の往復時間（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.

[RFC2861]で使用されるTCP Sender State変数「T_Last」と「TCPNOW」という用語を使用します。T_LASTは、TCP送信者が最後のデータセグメントを送信したときのシステム時間を保持しますが、TCPNOWはTCP送信者の現在のシステム時間です。

2. Appropriate Detection Algorithms

2. 適切な検出アルゴリズム

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].

ALGORITHMSをEIFEL Responseアルゴリズムと連携することを望む検出アルゴリズムの設計者は、[RFC3522]で指定されたセマンティクスと定義値を使用して変数「SpouriousRecovery」を再利用する必要があります。さらに、一定のlate_spur_to（-1に等しく設定）を、変数SpouriousRecoveryの別の可能な値として定義します。検出アルゴリズムは、偽の再送信の検出が再送信のACKに基づいている場合（元の送信のACKとは対照的に）、SpouriousRecoveryの値をlate_spur_toに設定する必要があります。たとえば、これはDSACKオプション[RFC3708]に基づいた検出アルゴリズムに適用されます。

3. The Eifel Response Algorithm

3. EIFEL応答アルゴリズム

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では、アルゴリズムのさまざまな手順について説明します。

3.1. The Algorithm

3.1. アルゴリズム

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の前に、損失回復が開始されると更新されます。「PIPED_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

「srtt_prev」変数と「rttvar_prev」変数を次のように設定します：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で概説されている可変スプリアスレコアーを設定します。そのアルゴリズムのここに行きます。

(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);

それ以外の場合は、SpuriousRecoveryがlate_spur_toに等しい場合は、ステップ（9）に進みます。

else proceed to step (DONE).

それ以外の場合は、ステップ（完了）に進みます。

(8) Resume the transmission with previously unsent data:

(8) 以前に安全でないデータで送信を再開します。

Set SND.NXT <- SND.MAX

and.next < - and.max

(9) Reverse the congestion control state:

(9) 混雑制御状態を逆にします：

If the acceptable ACK has the ECN-Echo flag [RFC3168] set, then proceed to step (DONE);

許容可能なACKにECNエコーフラグ[RFC3168]が設定されている場合は、ステップ（完了）に進みます。

else set cwnd <- FlightSize + min (bytes_acked, IW) ssthresh <- pipe_prev

else set 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

輻輳ウィンドウの検証が[RFC2861]に従って実装されている場合は、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,

新しいデータから取得した最初のRTTサンプルに。すなわち、偽のタイムアウトが発生したときに以前に安全ではなかったデータの許容可能なACKから導き出すことができる最初のRTTサンプル、

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)

再送信タイマーが[rfc2988]に従って実装されている場合、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;

[RFC2988]のRTO（ルール（2.4）および（2.5））のバウンドチェックを実行し、再送信タイマーを再起動します。

else appropriately adapt the conservativeness of the retransmission timer that is implemented.

そうでなければ、実装されている再送信タイマーの保守性を適切に適合させます。

(DONE) No further processing.

（完了）それ以上の処理はありません。

3.2. Storing the Current Congestion Control State (Step 0)

3.2. 現在の輻輳制御状態の保存（ステップ0）

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.

Pipe_prevのTCP送信者は、損失回復が開始される前に安全なスロースタートしきい値（SSThresh）と見なされるもの。すなわち、損失兆候が考慮される前に。これは、TCP送信者が輻輳回避がある場合、TCP送信者がスロースタートしている場合、現在のフライトサイズ、または現在のsSthreshです。TCP送信者が後で損失回復を不必要に検出したことを検出した場合、PIPED_PREVはステップ（9）で使用され、混雑コントロール状態を逆転させます。したがって、損失回収フェーズが終了するまで、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 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.

Pipe_Prevの価値が時間の経過とともに崩壊するべきかどうかについて議論がありました。たとえば、同じ未解決のセグメントの後続のタイムアウト時。EIFEL応答アルゴリズムには、Pipe_Prevが減衰する必要はなく、そのような保守的なアプローチが整っているとは考えていません。代わりに、[RFC2861]で示唆されているように、スロースタートを介して混雑ウィンドウを再検証するという考えに従います。つまり、ステップ（9）では、CWNDは大きなパケットバーストを回避する値にリセットされ、SSthreshはpipe_prevの値にリセットされます。[RFC2581]および[RFC2861]は、損失の表示に応じてリセットされた後、またはTCP送信者がアイドルまたはアプリケーションリミテッドになった後、SSThreshの減衰を必要としないことに注意してください。

3.3. Suppressing the Unnecessary go-back-N Retransmits (Step 8)

3.3. 不必要なGo-Back-N Recransmitsの抑制（ステップ8）

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 Recransmitsを引き起こすものです。その時点から、元の送信に応じて送信されたすべての到着した許容可能な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送信者の状態を変更します。このステップは、可変スプアリアスレコーリーがSPUR_TOに等しい場合にのみ実行されることに注意してください。これは、EIFEL検出アルゴリズム[RFC3522]またはF-RTOアルゴリズム[SK04]などの検出アルゴリズムが必要であり、ACKを検出するF-RTOアルゴリズム[SK04]がACKを検出し、ACKを検出することで、ACKを検出しているため、ACKを受信してACKを検出します。元の送信（再送信のACKとは対照的に[RFC3708]）。

3.4. Reversing the Congestion Control State (Step 9)

3.4. 混雑制御状態の逆転（ステップ9）

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エコーフラグ[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エコーフラグが設定されていない場合、CWNDは現在のフライトサイズと最小BYTES_ACKEDおよびIWの合計にリセットされます。場合によっては、これは到着した最初の数少ない許容できるACKがデータセグメントを記録しないことを意味します。BYTES_ACKEDは、許容可能なACKによって認められたバイトの数であることを思い出してください。CWNDの値をそのACKのためにさらに変更してはならず、この時点でのフライトサイズの値は、ステップ（0）のフライトサイズの値とは異なる場合があることに注意してください。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送信者は、すぐに混雑回避の帯域幅を増やすためにネットワークを調査するか、混雑ウィンドウの安全な動作点と見なされるものにスロースタートします。

3.5. Interworking with the CWV Algorithm (Step 10)

3.5. CWVアルゴリズムとの相互作用（ステップ10）

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.

輻輳ウィンドウ検証（CWV）アルゴリズム[RFC2861]の実装は、TCP送信者がアイドル状態になったフェーズとして偽のタイムアウトを引き起こした遅延スパイクを誤って解釈する可能性があります。したがって、T_LASTはリセットされ、この場合のCWVアルゴリズムのトリガーを防ぎます。

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）のチェックは含まれていません。したがって、eifel応答アルゴリズムにステップ（10）を追加する必要がありました。

3.6. Adapting the Retransmission Timer (Step 11)

3.6. 再送信タイマーの適応（ステップ11）

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に標準化された再送信タイマーは1つだけです[RFC2988]。したがって、そのタイマーのみを明示的に扱います。[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サンプルから再活性化されるべきです。つまり、スプリアスタイムアウトが発生したときに以前に安全ではなかったデータの許容可能なACKから導き出すことができる最初のRTTサンプルからです。

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 * g）の2倍のクロック粒度は、「あまりにも早すぎる」の合理的な上限であると考えています。したがって、新しいRTOがステップ（11）で計算されると、SMORTIous Timeoutが発生する前よりも、RTOが少なくとも（2 * g）より大きくなることを確認します。

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サンプルを導き出すことができます。このRTTサンプルは、スプリアスタイムアウトを引き起こした遅延スパイクが含まれるため、比較的大きくなければなりません。その結果、RTT推定器はかなり保守的に更新されます。タイムスタンプがなければ、最初のRTTサンプルが、スプリアスタイムアウトが発生したときに以前は安全ではなかったデータの許容可能なACKから導き出すことができるまで、Karnのアルゴリズム[RFC2988]のため、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]と一致しており、許容可能なACKの到着時に再送信タイマーを再起動することを推奨しています。

4. Advanced Loss Recovery is Crucial for the Eifel Response Algorithm

4. 高度な損失回復は、eifel応答アルゴリズムにとって重要です

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]のシミュレーションに使用したサックベースのスキームは、後に標準化された[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）は次のように変更する必要がありますが、Spurious Recoveryが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]).

つまり、eifel応答アルゴリズムのステップ（8）がタイムアウト後の不必要なGO-BACK-N再送信から3つの重複ACKが生じる場合を回避するため、NewRenoアルゴリズムのステップ1B全体が時代遅れです。EIFEL応答アルゴリズムのステップ（8）は、そもそもこのような不必要なGo-Back-N Recransmitsを回避します。ただし、可変SpouriousRecoveryがSPUR_TOに等しい場合にのみステップ（8）が実行されることを思い出してください。元の送信のためにACKを受信することに基づいています（再送信のACKとは対照的に[RFC3708]）。

5. Security Considerations

5. セキュリティに関する考慮事項

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".

検出アルゴリズムが、TCP送信者に偽の再送信者に現れるようにするスプーフィングされたAcksによってだまされているというリスクがあります。このような検出アルゴリズムが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]の安全なバリアントは、このリスクから保護するための信頼できる方法です。

6. Acknowledgements

6. 謝辞

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.

キース・スクラワー、ランディ・カッツ、マイケル・マイヤー、ステファン・バウク、サリー・フロイド、ヴァーン・パクソン、マーク・オールマン、イーサン・ブラントン、パシ・サロラティ、アレクセイ・クズネツォフ、ヨゲシュ・スワミに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.

[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP渋滞制御」、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] Floyd、S.、Henderson、T。、およびA. Gurtov、「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混雑ウィンドウ検証」、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のEIFEL検出アルゴリズム」、RFC 3522、2003年4月。

[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月。

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC793] Postel、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] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。

7.2. Informative References

7.2. 参考引用

[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.

[RFC3042] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限定送信を使用した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の早期再送信、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コンピューター通信レビュー、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）を使用して、2004年2月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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「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、2002年2月の欧州ワイヤレス会議の議事録におけるGPRSネットワークのTCPのeifelアルゴリズムの評価。

[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は、2003年4月、IEEE Infocom 03の議事録におけるTCPのスプリアスタイムアウトに対応しています。

[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] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のための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、Eifel Algorithm：TCPをスプリアスレトランミッションに対して堅牢にする、ACMコンピューターコミュニケーションレビュー、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。and M. Kojo、F-RTO：TCPおよびSCTPを使用して偽りの再送信タイムアウトを検出するためのアルゴリズムは、2004年11月に進行中の作業。

[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 88.

[Zh86] Zhang、L。、ACM Sigcomm 88の議事録で、TCPタイマーがうまく機能しない理由。

Authors' Addresses

著者のアドレス

Reiner Ludwig Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath, Germany

Reiner Ludwig Ericsson Research（EDD）Ericsson Allee 1 52134 Herzogenrath、ドイツ

   EMail: Reiner.Ludwig@ericsson.com

Andrei Gurtov Helsinki Institute for Information Technology (HIIT) P.O. Box 9800, FIN-02015 HUT, Finland

Andrei Gurtov Helsinki Institute for Information Technology（HIIT）P.O。Box 9800、Fin-02015 Hut、フィンランド

   EMail: andrei.gurtov@cs.helsinki.fi
   Homepage: http://www.cs.helsinki.fi/u/gurtov

Full Copyright Statement

完全な著作権声明

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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。