Network Working Group M. Allman
Request for Comments: 2581 NASA Glenn/Sterling Software
Obsoletes: 2001 V. Paxson
Category: Standards Track ACIRI / ICSI
W. Stevens
Consultant
April 1999
TCP Congestion Control
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.
スロースタート、輻輳回避、高速再送、高速回復：このドキュメントでは、TCPの4つの絡み合った輻輳制御アルゴリズムを定義します。また、ドキュメントは、TCPが比較的長いアイドル期間の後に送信を開始、並びに種々の確認生成方法を議論する方法を指定します。
This document specifies four TCP [Pos81] congestion control algorithms: slow start, congestion avoidance, fast retransmit and fast recovery. These algorithms were devised in [Jac88] and [Jac90]. Their use with TCP is standardized in [Bra89].
スロースタート、輻輳回避、高速再送と高速リカバリ：この文書では、4 TCP [Pos81]輻輳制御アルゴリズムを指定します。これらのアルゴリズムは、[Jac90] [Jac88]および考案されました。 TCPでのこれらの使用は[Bra89]で標準化されています。
This document is an update of [Ste97]. In addition to specifying the congestion control algorithms, this document specifies what TCP connections should do after a relatively long idle period, as well as specifying and clarifying some of the issues pertaining to TCP ACK generation.
この文書では、[Ste97]のアップデートです。輻輳制御アルゴリズムを指定するだけでなく、この文書には、TCP接続が指定し、TCP ACK生成に関連する問題のいくつかを明確にするだけでなく、比較的長いアイドル期間の後に何をすべきかを指定します。
Note that [Ste94] provides examples of these algorithms in action and [WS95] provides an explanation of the source code for the BSD implementation of these algorithms.
[Ste94]アクションおよび[WS95]でこれらのアルゴリズムの例を提供することに注意することは、これらのアルゴリズムのBSD実装のソースコードの説明を提供します。
This document is organized as follows. Section 2 provides various definitions which will be used throughout the document. Section 3 provides a specification of the congestion control algorithms. Section 4 outlines concerns related to the congestion control algorithms and finally, section 5 outlines security considerations.
次のようにこの文書は、組織化されています。第2節では、文書全体で使用される様々な定義を提供します。セクション3は、輻輳制御アルゴリズムの仕様を提供します。第4節では、輻輳制御アルゴリズムに関連した懸念を概説し、最終的に、セクション5は、セキュリティ上の考慮事項の概要を説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【Bra97]に記載されているように解釈されます。
This section provides the definition of several terms that will be used throughout the remainder of this document.
このセクションでは、この文書の残りの部分の全体にわたって使用されるいくつかの用語の定義を提供します。
SEGMENT: A segment is ANY TCP/IP data or acknowledgment packet (or both).
SEGMENT：セグメントは、任意のTCP / IPデータ又は確認応答パケット（またはその両方）です。
SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the largest segment that the sender can transmit. This value can be based on the maximum transmission unit of the network, the path MTU discovery [MD90] algorithm, RMSS (see next item), or other factors. The size does not include the TCP/IP headers and options.
SENDER最大セグメントサイズ（SMSS）：SMSSは、送信者が送信できる最大セグメントサイズです。この値は、ネットワークの最大転送単位、パスMTU探索[MD90]アルゴリズム、RMSS（次の項目を参照）、または他の要因に基づくことができます。サイズは、TCP / IPヘッダおよびオプションが含まれていません。
RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup. Or, if the MSS option is not used, 536 bytes [Bra89]. The size does not include the TCP/IP headers and options.
受信最大セグメントサイズ（RMSS）：RMSSは、受信機が受け入れる意志がある最大セグメントサイズです。これは、接続の起動時に受信機によって送信されたMSSオプションで指定した値です。または、MSSオプションが使用されていない場合は、536バイト[Bra89]。サイズは、TCP / IPヘッダおよびオプションが含まれていません。
FULL-SIZED SEGMENT: A segment that contains the maximum number of data bytes permitted (i.e., a segment containing SMSS bytes of data).
フルサイズのセグメント：許可されたデータバイトの最大数を含むセグメント（すなわち、データのSMSSバイトを含むセグメント）。
RECEIVER WINDOW (rwnd) The most recently advertised receiver window.
RECEIVER WINDOW（RWND）最近宣伝受信ウィンドウ。
CONGESTION WINDOW (cwnd): A TCP state variable that limits the amount of data a TCP can send. At any given time, a TCP MUST NOT send data with a sequence number higher than the sum of the highest acknowledged sequence number and the minimum of cwnd and rwnd.
輻輳ウィンドウ（CWND）：TCPが送信できるデータの量を制限するTCPステート変数。任意の時点で、TCPは最高認めシーケンス番号とのcwndとRWNDの最小値の合計よりも高いシーケンス番号のデータを送ってはいけません。
INITIAL WINDOW (IW): The initial window is the size of the sender's congestion window after the three-way handshake is completed.
INITIAL WINDOW（IW）：3ウェイハンドシェイクが完了した後、最初のウィンドウは、送信者の輻輳ウィンドウのサイズです。
LOSS WINDOW (LW): The loss window is the size of the congestion window after a TCP sender detects loss using its retransmission timer.
損失WINDOW（LW）：TCPの送信側がその再送タイマを使用して損失を検出した後、ロス・ウィンドウは、輻輳ウィンドウのサイズです。
RESTART WINDOW (RW): The restart window is the size of the congestion window after a TCP restarts transmission after an idle period (if the slow start algorithm is used; see section 4.1 for more discussion).
RESTARTのウィンドウ（RW）：リスタートウィンドウは、TCPがアイドル期間の後に送信を再開した後に、輻輳ウィンドウのサイズである（スロースタートアルゴリズムが使用される場合、より多くの議論のためのセクション4.1を参照します）。
FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged.
FLIGHTサイズ：送信されたがまだ認識されているデータの量。
This section defines the four congestion control algorithms: slow start, congestion avoidance, fast retransmit and fast recovery, developed in [Jac88] and [Jac90]. In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms allow, however a TCP MUST NOT be more aggressive than the following algorithms allow (that is, MUST NOT send data when the value of cwnd computed by the following algorithms would not allow the data to be sent).
スロースタート、輻輳回避、高速再送と高速リカバリ、で開発された[Jac88]と[Jac90]：このセクションでは、4つの輻輳制御アルゴリズムを定義します。いくつかの状況では、アルゴリズムは、しかしながら、TCPは、次のアルゴリズムがCWNDの値は、以下によって計算するとき（すなわち、データを送ってはいけません許可よりも積極的であってはなりません許可より保守的であることがTCP送信者のために有益であり得ますアルゴリズム）は、データが送信されることを許可しません。
The slow start and congestion avoidance algorithms MUST be used by a TCP sender to control the amount of outstanding data being injected into the network. To implement these algorithms, two variables are added to the TCP per-connection state. The congestion window (cwnd) is a sender-side limit on the amount of data the sender can transmit into the network before receiving an acknowledgment (ACK), while the receiver's advertised window (rwnd) is a receiver-side limit on the amount of outstanding data. The minimum of cwnd and rwnd governs data transmission.
スロースタートと輻輳回避アルゴリズムは、ネットワークに注入される未処理データの量を制御するために、TCP送信者によって使用されなければなりません。これらのアルゴリズムを実装するには、二つの変数は、TCPコネクションごとの状態に追加されます。受信機の広告ウィンドウ（RWNDが）の量に受信側の限界である輻輳ウィンドウ（CWND）は、送信側が確認応答（ACK）を受信する前にネットワークに送信できるデータの量に、送信者側の限界であります優れたデータ。 CWNDおよびRWNDの最小値は、データ送信を司ります。
Another state variable, the slow start threshold (ssthresh), is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission, as discussed below.
後述するように別の状態変数、スロースタート閾値（SSTHRESH）は、スロースタートや輻輳回避アルゴリズムは、データ伝送を制御するために使用されているかどうかを決定するために使用されます。
Beginning transmission into a network with unknown conditions requires TCP to slowly probe the network to determine the available capacity, in order to avoid congesting the network with an inappropriately large burst of data. The slow start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer.
未知の条件でネットワークへの送信を開始すると、データの不適切な大規模なバーストでネットワークを輻輳を避けるために、ゆっくりと利用可能な容量を決定するためにネットワークをプローブするTCPが必要です。スロースタートアルゴリズムは、転送の開始時、または再送タイマによって検出された損失を修復した後、この目的のために使用されます。
IW, the initial value of cwnd, MUST be less than or equal to 2*SMSS bytes and MUST NOT be more than 2 segments.
IW、CWNDの初期値未満又は2に等しくなければならない* SMSSバイトと2つの以上のセグメントであってはいけません。
We note that a non-standard, experimental TCP extension allows that a TCP MAY use a larger initial window (IW), as defined in equation 1 [AFP98]:
我々は、非標準は、実験的なTCP拡張は、式1 [AFP98]で定義されるように、TCPは、より大きな初期ウィンドウ（IW）を使用することができることができることに注意してください。
IW = min (4*SMSS, max (2*SMSS, 4380 bytes)) (1)
IW =分（4 *のSMSS、MAX（2 * SMSS、4380バイト））（1）
With this extension, a TCP sender MAY use a 3 or 4 segment initial window, provided the combined size of the segments does not exceed 4380 bytes. We do NOT allow this change as part of the standard defined by this document. However, we include discussion of (1) in the remainder of this document as a guideline for those experimenting with the change, rather than conforming to the present standards for TCP congestion control.
この拡張により、TCP送信者は、3または4セグメント初期ウィンドウを使用して4380のバイトを超えていないセグメントの合計サイズを提供してもよい（MAY）。私たちは、この文書で定義された標準の一環として、この変更を許可していません。しかし、我々はなくTCP輻輳制御のために、本規格に準拠より変化を実験それらのガイドラインとして、この文書の残りの部分（1）の議論を含みます。
The initial value of ssthresh MAY be arbitrarily high (for example, some implementations use the size of the advertised window), but it may be reduced in response to congestion. The slow start algorithm is used when cwnd < ssthresh, while the congestion avoidance algorithm is used when cwnd > ssthresh. When cwnd and ssthresh are equal the sender may use either slow start or congestion avoidance.
SSTHRESHの初期値は、（例えば、いくつかの実装は、広告ウィンドウのサイズを使用する）任意に高いかもしれないが、それは輻輳に応答して減少させることができます。 SSTHRESH <輻輳回避アルゴリズムは場合CWND使用されている間SSTHRESH、>場合CWNDスロースタートアルゴリズムが使用されます。 CWNDおよびSSTHRESHが等しい場合、送信者は、スロースタートや輻輳回避のいずれかを使用することができます。
During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data. Slow start ends when cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted above) or when congestion is observed.
スロースタート時には、各ACKのための最もSMSSバイトででcwndをTCPの増分はそれが新しいデータを認識しました。スロースタートは、（上述のように、それは、それに到達したときに、必要に応じて、または、）CWNDがSSTHRESHを超えたときに終了するか、輻輳が観察された場合。
During congestion avoidance, cwnd is incremented by 1 full-sized segment per round-trip time (RTT). Congestion avoidance continues until congestion is detected. One formula commonly used to update cwnd during congestion avoidance is given in equation 2:
輻輳回避中、CWNDは、ラウンドトリップ時間（RTT）ごとに1フルサイズのセグメントだけインクリメントされます。輻輳が検出されるまで輻輳回避は継続します。一般輻輳回避中にcwndを更新するために使用される一つの式は、式2で与えられます。
cwnd += SMSS*SMSS/cwnd (2)
CWND + = SMSSの*のSMSS / CWND（2）
This adjustment is executed on every incoming non-duplicate ACK. Equation (2) provides an acceptable approximation to the underlying principle of increasing cwnd by 1 full-sized segment per RTT. (Note that for a connection in which the receiver acknowledges every data segment, (2) proves slightly more aggressive than 1 segment per RTT, and for a receiver acknowledging every-other packet, (2) is less aggressive.)
この調整は、すべての着信非重複ACK上で実行されます。式（2）はRTTごとに1フルサイズセグメントによってCWND増加の根底にある原理に許容される近似を提供します。 （（2）（2）あまり積極的で、RTTあたり1つのセグメントよりもわずかにより積極的な証明、およびすべて、他のパケットを承認するための受信機、受信機は、すべてのデータ・セグメントを承認する接続のためのことに注意してください。）
Implementation Note: Since integer arithmetic is usually used in TCP implementations, the formula given in equation 2 can fail to increase cwnd when the congestion window is very large (larger than SMSS*SMSS). If the above formula yields 0, the result SHOULD be rounded up to 1 byte.
実装注：整数演算は、通常、TCPの実装に使用されるので、式2で与えられた式は、輻輳ウィンドウは、（SMSS * SMSSより大きい）が非常に大きい場合にcwndを増加させるために失敗する可能性があります。上記式収量0の場合、結果は1バイトに切り上げされるべきです。
Implementation Note: older implementations have an additional additive constant on the right-hand side of equation (2). This is incorrect and can actually lead to diminished performance [PAD+98].
実装注：古い実装は、式（2）の右辺に追加の添加剤定数を有します。これは間違っていると、実際にパフォーマンスの低下[PAD + 98]につながることができます。
Another acceptable way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. (A drawback of this implementation is that it requires maintaining an additional state variable.) When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes. Note that during congestion avoidance, cwnd MUST NOT be increased by more than the larger of either 1 full-sized segment per RTT, or the value computed using equation 2.
輻輳回避中にcwndをを向上させるもう一つの許容可能な方法は、新しいデータのためのACKによって承認されたバイト数を数えることです。 （この実施の欠点は、追加の状態変数を維持する必要があることである。）を認めたバイトの数がCWNDに達すると、その後CWNDがSMSSバイトまでインクリメントすることができます。輻輳回避中、CWNDが1フルサイズRTTあたりのセグメント、又は式2を用いて計算された値のいずれか大きい方を超えて増加してはならないことに注意してください。
Implementation Note: some implementations maintain cwnd in units of bytes, while others in units of full-sized segments. The latter will find equation (2) difficult to use, and may prefer to use the counting approach discussed in the previous paragraph.
実装注：いくつかの実装では、フルサイズのセグメントの単位で他ながら、バイト単位でCWNDを維持します。後者は、式（2）困難使用するでしょう、そして前の段落で説明した計数アプローチを使用することを好むかもしれません。
When a TCP sender detects segment loss using the retransmission timer, the value of ssthresh MUST be set to no more than the value given in equation 3:
TCP送信側が再送タイマーを使用してセグメントの損失を検出した場合、SSTHRESHの値は、式3で与えられた値以下に設定する必要があります。
ssthresh = max (FlightSize / 2, 2*SMSS) (3)
SSTHRESH = MAX（FlightSize / 2、2 * SMSS）（3）
As discussed above, FlightSize is the amount of outstanding data in the network.
上述したように、FlightSizeは、ネットワーク内の未処理データの量です。
Implementation Note: an easy mistake to make is to simply use cwnd, rather than FlightSize, which in some implementations may incidentally increase well beyond rwnd.
実装上の注意：簡単な間違い作るためには、単にいくつかの実装では偶然にもRWNDを超えて増加可能性がある、というよりもFlightSize、cwndのを使用することです。
Furthermore, upon a timeout cwnd MUST be set to no more than the loss window, LW, which equals 1 full-sized segment (regardless of the value of IW). Therefore, after retransmitting the dropped segment the TCP sender uses the slow start algorithm to increase the window from 1 full-sized segment to the new value of ssthresh, at which point congestion avoidance again takes over.
また、タイムアウトCWND時（かかわらず、IWの値）1フルサイズのセグメントに等しい損失ウィンドウ、LW、超えないように設定しなければなりません。従って、ドロップされたセグメントを再送した後にTCP送信者は、ポイント輻輳回避が再び引き継ぐれるSSTHRESHの新しい値に1フルサイズセグメントからウィンドウを増加させるためにスロースタートアルゴリズムを使用します。
A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected. From the sender's perspective, duplicate ACKs can be caused by a number of network problems. First, they can be caused by dropped segments. In this case, all segments after the dropped segment will trigger duplicate ACKs. Second, duplicate ACKs can be caused by the re-ordering of data segments by the network (not a rare event along some network paths [Pax97]). Finally, duplicate ACKs can be caused by replication of ACK or data segments by the network. In addition, a TCP receiver SHOULD send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space. This will generate more timely information for a sender recovering from a loss through a retransmission timeout, a fast retransmit, or an experimental loss recovery algorithm, such as NewReno [FH98].
アウトオブオーダーセグメントが到着したときにTCP受信機は即座に重複ACKを送るべきです。このACKの目的は、セグメントは、アウト・オブ・オーダー受信及びシーケンス番号が期待された送信者に通知することです。送信者の視点から、重複ACKは、ネットワークの問題の数によって引き起こされる場合があります。まず、彼らはドロップセグメントによって引き起こされる場合があります。この場合、ドロップされたセグメントの後のすべてのセグメントは重複ACKをトリガします。第二に、重複ACKは、ネットワーク（一部のネットワークパス[Pax97]に沿っていない稀な事象）によるデータセグメントの再配列によって引き起こされ得ます。最後に、重複ACKは、ネットワークによってACK又はデータセグメントの複製によって引き起こされ得ます。着信セグメントは、配列空間中のギャップの全て又は一部を埋める場合に加えて、TCP受信機は、即時ACKを送信すべきです。これは、NewRenoの[FH98]として再送タイムアウトによる損失、高速再送、または実験損失回復アルゴリズム、送信者からの回復のためのより多くの情報をタイムリーに生成されます。
The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire.
TCPの送信者は、着信重複ACKをもとに、「高速再送」を検出するアルゴリズムと修理損失を、使用すべきです。高速再送アルゴリズムは、セグメントが失われた指標として（任意の他の介在パケットの到着せず4つの同一のACK）3個の重複ACKの到着を使用します。 3つの重複ACKを受信した後、TCPが満了するの再送タイマーを待たずに、失われたセグメントと思われるものの再送信を行います。
After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives. The reason for not performing slow start is that the receipt of the duplicate ACKs not only indicates that a segment has been lost, but also that segments are most likely leaving the network (although a massive segment duplication by the network can invalidate this conclusion). In other words, since the receiver can only generate a duplicate ACK when a segment has arrived, that segment has left the network and is in the receiver's buffer, so we know it is no longer consuming network resources. Furthermore, since the ACK "clock" [Jac88] is preserved, the TCP sender can continue to transmit new segments (although transmission must continue using a reduced cwnd).
高速再送アルゴリズムは失われたセグメントと思われるものを送信した後、非重複ACKが到着するまで、「高速回復」アルゴリズムは、新たなデータの伝送を管理します。スロースタートを行わない理由は、重複ACKの受信がセグメントが失われたことを示していないだけでなく、（ネットワークによる大規模なセグメントの重複がこの結論を無効にすることができるが）セグメントが最も可能性の高いネットワークを残していることです。セグメントが到着したとき、受信機が唯一の重複ACKを生成することができますので、言い換えれば、そのセグメントはネットワークを残しているし、受信側のバッファにあるので、我々は、それはもはやネットワークリソースを消費している知っていません。 ACK「クロック」[Jac88]保存されるので、TCP送信者は、（送信を低減CWNDを使用し続けなければならないが）新しいセグメントを送信し続けることができます。
The fast retransmit and fast recovery algorithms are usually implemented together as follows.
次のように高速再送と高速回復アルゴリズムは、通常、一緒に実装されています。
1. When the third duplicate ACK is received, set ssthresh to no more than the value given in equation 3.
1.第三の重複ACKが受信されると、式（3）で与えられた値以下にSSTHRESHを設定します。
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered.
2. SSTHRESHプラス3 *のSMSSする失われたセグメントとセットにcwndを再送信します。これは、人工的に、受信機がバッファリングしているネットワークとを残しているセグメント（3）の数で輻輳ウィンドウを「膨張します」。
3. For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.
ACKが受信された各追加の重複3.、SMSSによりcwndを増加。これは人為的にネットワークから離脱した追加のセグメントを反映するために、輻輳ウィンドウを膨張させます。
4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window.
CWNDの新しい値と受信機の広告ウィンドウによって許可されている場合4.セグメントを送信します。
5. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window.
次のACKがその新しいデータを認識到着すると5.は、（ステップ1で設定した値）をSSTHRESHするCWNDを設定します。これは、ウィンドウを「収縮」と呼ばれています。
This ACK should be the acknowledgment elicited by the
retransmission from step 1, one RTT after the retransmission
(though it may arrive sooner in the presence of significant out-
of-order delivery of data segments at the receiver).
Additionally, this ACK should acknowledge all the intermediate
segments sent between the lost segment and the receipt of the
third duplicate ACK, if none of these were lost.
Note: This algorithm is known to generally not recover very efficiently from multiple losses in a single flight of packets [FF96]. One proposed set of modifications to address this problem can be found in [FH98].
注：このアルゴリズムは、一般的に、パケット[FF96]の単一飛行中に複数の損失から非常に効率的に回復しないことが知られています。この問題に対処する修正の一の提案セットは[FH98]に見出すことができます。
A known problem with the TCP congestion control algorithms described above is that they allow a potentially inappropriate burst of traffic to be transmitted after TCP has been idle for a relatively long period of time. After an idle period, TCP cannot use the ACK clock to strobe new segments into the network, as all the ACKs have drained from the network. Therefore, as specified above, TCP can potentially send a cwnd-size line-rate burst into the network after an idle period.
上述したTCPの輻輳制御アルゴリズムの既知の問題は、それらがTCPが比較的長時間にわたってアイドルであった後にトラフィックの潜在的に不適切なバーストが送信されることを可能にすることです。アイドル期間の後、TCPは、すべてのACKがネットワークから流出したように、ネットワークに新しいセグメントをストローブするためにACKクロックを使用することはできません。したがって、上記指定されているように、TCPは、潜在的にCWNDサイズのラインレートがアイドル期間の後にネットワークにバーストを送信することができます。
[Jac88] recommends that a TCP use slow start to restart transmission after a relatively long idle period. Slow start serves to restart the ACK clock, just as it does at the beginning of a transfer. This mechanism has been widely deployed in the following manner. When TCP has not received a segment for more than one retransmission timeout, cwnd is reduced to the value of the restart window (RW) before transmission begins.
[Jac88] TCPが比較的長いアイドル期間の後に送信を再開するためにスロースタートを使用することをお勧めします。スロースタートは、それが転送の開始時に同じよう、ACKクロックを再開するのに役立ちます。このメカニズムは広く、次のように展開されています。 TCPは複数の再送信タイムアウトのためのセグメントを受信していない場合、CWNDは、送信が開始される前にリスタートウィンドウ（RW）の値まで低減されます。
For the purposes of this standard, we define RW = IW.
この規格の目的のために、私たちはRW = IWを定義します。
We note that the non-standard experimental extension to TCP defined in [AFP98] defines RW = min(IW, cwnd), with the definition of IW adjusted per equation (1) above.
我々は、[AFP98]で定義されたTCPの非標準実験拡張（1）上記の式当り調整IWの定義で、RW =分（IW、CWND）を規定することに注意してください。
Using the last time a segment was received to determine whether or not to decrease cwnd fails to deflate cwnd in the common case of persistent HTTP connections [HTH98]. In this case, a WWW server receives a request before transmitting data to the WWW browser. The reception of the request makes the test for an idle connection fail, and allows the TCP to begin transmission with a possibly inappropriately large cwnd.
CWNDを減少させるか否かを判定するセグメントが受信された最後の時間を使用することにより、持続的なHTTP接続[HTH98]の一般的な場合にCWNDを収縮することができません。この場合、WWWサーバは、WWWブラウザにデータを送信する前に、要求を受信します。要求の受信が失敗アイドル接続のためのテストを行い、TCPはおそらく不適切に大きいCWNDで送信を開始することを可能にします。
Therefore, a TCP SHOULD set cwnd to no more than RW before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout.
したがって、TCPはTCPの再送タイムアウトを超える間隔でデータを送信していない場合は、送信を開始する前に、RWを超えないようにcwndを設定すべきです。
The delayed ACK algorithm specified in [Bra89] SHOULD be used by a TCP receiver. When used, a TCP receiver MUST NOT excessively delay acknowledgments. Specifically, an ACK SHOULD be generated for at least every second full-sized segment, and MUST be generated within 500 ms of the arrival of the first unacknowledged packet.
【Bra89]で指定された遅延ACKアルゴリズムはTCP受信機によって使用されるべきです。使用する場合、TCP受信機は過度に確認応答を遅らせるてはなりません。具体的には、ACKは、少なくとも毎秒フルサイズのセグメントに対して生成されるべきであり、最初の未確認パケットの到着の500ミリ秒以内に生成されなければなりません。
The requirement that an ACK "SHOULD" be generated for at least every second full-sized segment is listed in [Bra89] in one place as a SHOULD and another as a MUST. Here we unambiguously state it is a SHOULD. We also emphasize that this is a SHOULD, meaning that an implementor should indeed only deviate from this requirement after careful consideration of the implications. See the discussion of "Stretch ACK violation" in [PAD+98] and the references therein for a discussion of the possible performance problems with generating ACKs less frequently than every second full-sized segment.
ACK要求少なくとも毎秒フルサイズのセグメントがべきでなければならないので、別のように、1つの場所で[Bra89]に記載されているために発生すること「は、SHOULD」。ここでは明確にそれを明記してくださいです。また、実装者が実際に唯一の影響を慎重に検討した後、この要件から逸脱しなければならないことを意味し、これはSHOULDであることを強調します。 [PAD + 98]の「ストレッチACK違反」の議論とそれほど頻繁毎秒フルサイズのセグメントよりACKを生成するとにより、パフォーマンスの問題の議論のために、その中の参考文献を参照。
In some cases, the sender and receiver may not agree on what constitutes a full-sized segment. An implementation is deemed to comply with this requirement if it sends at least one acknowledgment every time it receives 2*RMSS bytes of new data from the sender, where RMSS is the Maximum Segment Size specified by the receiver to the sender (or the default value of 536 bytes, per [Bra89], if the receiver does not specify an MSS option during connection establishment). The sender may be forced to use a segment size less than RMSS due to the maximum transmission unit (MTU), the path MTU discovery algorithm or other factors. For instance, consider the case when the receiver announces an RMSS of X bytes but the sender ends up using a segment size of Y bytes (Y < X) due to path MTU discovery (or the sender's MTU size). The receiver will generate stretch ACKs if it waits for 2*X bytes to arrive before an ACK is sent. Clearly this will take more than 2 segments of size Y bytes. Therefore, while a specific algorithm is not defined, it is desirable for receivers to attempt to prevent this situation, for example by acknowledging at least every second segment, regardless of size. Finally, we repeat that an ACK MUST NOT be delayed for more than 500 ms waiting on a second full-sized segment to arrive.
いくつかのケースでは、送信者と受信者は、フルサイズのセグメントを構成するものに一致しないことがあります。それはRMSSは、送信側に受信機によって指定された最大セグメントサイズ（またはデフォルト値である送信者からの新しいデータの2つの* RMSSバイトを受信するたびに少なくとも一つの肯定応答を送信する場合、実装は、この要件を満たすと認められます536バイトの）受信機は、接続確立時にMSSオプションが指定されていない場合、[Bra89]あたり。送信者による最大伝送単位（MTU）、パスMTU発見アルゴリズムまたは他の要因に以下RMSSよりセグメントサイズを使用するように強制されてもよいです。受信機はRMSS Xのバイトを発表が、送信者が起因パスMTUディスカバリ（又は送信者のMTUサイズ）にYバイト（Y <X）のセグメントサイズを使用してしまう場合、例えば、ケースを考えます。それは2を待つ場合、受信機は、ACKが送信される前に到達するXバイト*ストレッチACKを生成します。これは明らかにサイズYバイトの2つの以上のセグメントを取るであろう。特定のアルゴリズムが定義されていないながら、受信機はサイズに関係なく、少なくとも毎秒セグメントを承認することによって、例えば、このような状況を防止しようとするため、それが望ましいです。最後に、私たちは、ACKが到着する2番目の、フルサイズのセグメントで待機している500以上のミリ秒遅らせてはならないことを繰り返します。
Out-of-order data segments SHOULD be acknowledged immediately, in order to accelerate loss recovery. To trigger the fast retransmit algorithm, the receiver SHOULD send an immediate duplicate ACK when it receives a data segment above a gap in the sequence space. To provide feedback to senders recovering from losses, the receiver SHOULD send an immediate ACK when it receives a data segment that fills in all or part of a gap in the sequence space.
アウトオブオーダデータセグメントが損失回復を促進するために、すぐに承認されるべきです。それは、配列空間中のギャップ上のデータセグメントを受信したときに高速再送アルゴリズムをトリガするために、受信機は、即時重複ACKを送信すべきです。それは、配列空間中のギャップの全て又は一部を埋めるデータセグメントを受信したときの損失から回復送信者にフィードバックを提供するために、受信機は、即時ACKを送信すべきです。
A TCP receiver MUST NOT generate more than one ACK for every incoming segment, other than to update the offered window as the receiving application consumes new data [page 42, Pos81][Cla82].
受信側アプリケーションが新しいデータ消費として提供ウィンドウを更新するよりも、TCP受信機は[Cla82] [ページ42 Pos81、他のすべての受信セグメントに複数のACKを生成してはいけません。
A number of loss recovery algorithms that augment fast retransmit and fast recovery have been suggested by TCP researchers. While some of these algorithms are based on the TCP selective acknowledgment (SACK) option [MMFR96], such as [FF96,MM96a,MM96b], others do not require SACKs [Hoe96,FF96,FH98]. The non-SACK algorithms use "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) to trigger retransmissions. While this document does not standardize any of the specific algorithms that may improve fast retransmit/fast recovery, these enhanced algorithms are implicitly allowed, as long as they follow the general principles of the basic four algorithms outlined above.
高速再送と高速リカバリを強化損失回復アルゴリズムの数は、TCPの研究者によって示唆されています。これらのアルゴリズムのいくつかは、このような[FF96、MM96a、MM96b]としてTCP選択的確認応答（SACK）オプション[MMFR96]、に基づいているが、他の人はサックス[Hoe96、FF96、FH98]を必要としません。非SACKアルゴリズムは、再送信をトリガするために、「部分的確認応答」（新データをカバーするのACKはなく、損失が検出されたときに優れたすべてのデータ）を使用します。この文書は高速再送/高速回復を改善することがあり、特定のアルゴリズムのいずれかを標準化していませんが、これらの強化されたアルゴリズムは、暗黙のうちに、彼らは上記で概説した基本的な4つのアルゴリズムの一般的な原則に従っている限り、許可されています。
Therefore, when the first loss in a window of data is detected, ssthresh MUST be set to no more than the value given by equation (3). Second, until all lost segments in the window of data in question are repaired, the number of segments transmitted in each RTT MUST be no more than half the number of outstanding segments when the loss was detected. Finally, after all loss in the given window of segments has been successfully retransmitted, cwnd MUST be set to no more than ssthresh and congestion avoidance MUST be used to further increase cwnd. Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case.
データのウィンドウ内の最初の損失が検出されたときしたがって、SSTHRESHは、式（3）で与えられる値を超えないように設定しなければなりません。第二に、問題のデータのウィンドウ内のすべての失われたセグメントが修復されるまで、各RTTで送信セグメントの数は、損失が検出された優れたセグメントの半分以下の数でなければなりません。セグメントの所定のウィンドウ内のすべての損失が正常に再送信された後、最後に、CWNDはさらにCWNDを増加させるために使用されなければならないSSTHRESHと輻輳回避を超えないように設定しなければなりません。二つの連続するデータのウィンドウ、または再送の損失の損失は、従って、CWND（およびSSTHRESH）は、この場合には二回低下するなければならない2つの輻輳の指標と、のように解釈されるべきです。
The algorithms outlined in [Hoe96,FF96,MM96a,MM6b] follow the principles of the basic four congestion control algorithms outlined in this document.
[Hoe96、FF96、MM96a、MM6b]に概説されたアルゴリズムは、本書で概説基本的な4つの輻輳制御アルゴリズムの原則に従います。
This document requires a TCP to diminish its sending rate in the presence of retransmission timeouts and the arrival of duplicate acknowledgments. An attacker can therefore impair the performance of a TCP connection by either causing data packets or their acknowledgments to be lost, or by forging excessive duplicate acknowledgments. Causing two congestion control events back-to-back will often cut ssthresh to its minimum value of 2*SMSS, causing the connection to immediately enter the slower-performing congestion avoidance phase.
この文書では、再送タイムアウトの存在と重複確認応答の到着にその送信レートを減少させるためにTCPが必要です。攻撃者はこのため失われた、または過度の重複確認応答を鍛造するためにどちらかの原因となったデータ・パケットまたはその確認応答により、TCPコネクションの性能を損なうことができます。バックツーバック2つの輻輳制御イベントを発生させるには、多くの場合、即座に遅い実行輻輳回避フェーズを入力するように接続を引き起こし、2 * SMSSのその最小値にSSTHRESHをカットします。
The Internet to a considerable degree relies on the correct implementation of these algorithms in order to preserve network stability and avoid congestion collapse. An attacker could cause TCP endpoints to respond more aggressively in the face of congestion by forging excessive duplicate acknowledgments or excessive acknowledgments for new data. Conceivably, such an attack could drive a portion of the network into congestion collapse.
かなりの程度まで、インターネットは、ネットワークの安定性を維持し、輻輳崩壊を避けるために、これらのアルゴリズムの正しい実装に依存しています。攻撃者は、TCPエンドポイントは、新しいデータのための過度の重複確認応答や過度の承認を鍛造することで輻輳の顔に、より積極的に対応する可能性があります。おそらく、このような攻撃は、輻輳崩壊にネットワークの一部を運転できます。
This document has been extensively rewritten editorially and it is not feasible to itemize the list of changes between the two documents. The intention of this document is not to change any of the recommendations given in RFC 2001, but to further clarify cases that were not discussed in detail in 2001. Specifically, this document suggests what TCP connections should do after a relatively long idle period, as well as specifying and clarifying some of the issues pertaining to TCP ACK generation. Finally, the allowable upper bound for the initial congestion window has also been raised from one to two segments.
この文書では、広範囲に編集者に書き直されており、2つの文書の変更のリストを箇条書きにすることは不可能です。このドキュメントの意図はRFC 2001で与えられた勧告のいずれかを変更することではなく、さらに具体的に、2001年に詳細に議論されなかった例を明確にすることはありませんが、このドキュメントでは、TCP接続のように、比較的長いアイドル期間の後に何をすべきかを提案しますだけでなく、TCP ACK生成に関連する問題のいくつかを指定し、明確化。最後に、初期の輻輳ウィンドウの許容上限は、2つのセグメントに1から引き上げられました。
Acknowledgments
謝辞
The four algorithms that are described were developed by Van Jacobson.
記載されている4つのアルゴリズムは、バン・ジェイコブソンによって開発されました。
Some of the text from this document is taken from "TCP/IP Illustrated, Volume 1: The Protocols" by W. Richard Stevens (Addison-Wesley, 1994) and "TCP/IP Illustrated, Volume 2: The Implementation" by Gary R. Wright and W. Richard Stevens (Addison-Wesley, 1995). This material is used with the permission of Addison-Wesley.
W.リチャードスティーヴンス（アジソン・ウェズリー、1994）によると：ゲイリーRによる「TCP / IPイラスト、2巻実装」：このドキュメントからテキストの一部は、「プロトコルTCP / IPイラスト、第1巻」から取られます。ライトとW.リチャードスティーヴンス（アジソン・ウェズリー、1995）。この材料は、アディソン・ウェスリーの許可を得て使用されます。
Neal Cardwell, Sally Floyd, Craig Partridge and Joe Touch contributed a number of helpful suggestions.
ニールカードウェル、サリー・フロイド、クレイグ・パートリッジとジョー・タッチは、役立つ情報の数を貢献しました。
References
リファレンス
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window Size, RFC 2414, September 1998.
[AFP98]オールマン、M.、フロイド、S.とC.ヤマウズラ、「TCPの初期ウィンドウサイズの増加、RFC 2414、1998年9月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Cla82] Clark, D., "Window and Acknowledgment Strategy in TCP", RFC 813, July 1982.
[Cla82]クラーク、D.、 "TCPでウィンドウと謝辞戦略"、RFC 813、1982年7月。
[FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, July 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[FF96]秋、K.およびS.フロイド、コンピュータコミュニケーションレビュー、1996年7月ftp://ftp.ee.lbl.gov/papers/sacks.ps「タホ、リノとSACK TCPのシミュレーションベースの比較」 .Z。
[FH98] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[FH98]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[Flo94] Floyd, S., "TCP and Successive Fast Retransmits. Technical report", October 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Flo94]フロイド、S.、 "TCPおよび連続高速再送します。報告書"、1994年10月ftp://ftp.ee.lbl.gov/papers/fastretrans.ps。
[Hoe96] Hoe, J., "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", In ACM SIGCOMM, August 1996.
[Hoe96]鍬、J.、ACM SIGCOMM、1996年8月には、「TCP輻輳制御方式のスタート・アップ挙動を改善」。
[HTH98] Hughes, A., Touch, J. and J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress.
[HTH98]ヒューズ、A.、タッチ、J.とJ. Heidemann、「アイドルの後にTCPスロースタートの再起動で問題」が進行中で働いています。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[Jac88]ジェーコブソン、V.、「輻輳回避とコントロール」、コンピュータコミュニケーションレビュー、巻。 18、ありません。 4、頁314から329 8月1988 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z。
[Jac90] Jacobson, V., "Modified TCP Congestion Avoidance Algorithm", end2end-interest mailing list, April 30, 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.
[Jac90]ジェーコブソン、V.、 "修飾TCPの輻輳回避アルゴリズム"、end2end金利メーリングリスト、4月30日、1990年ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail。
[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MD90]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[MM96a] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: Refining TCP Congestion Control", Proceedings of SIGCOMM'96, August, 1996, Stanford, CA. Available fromhttp://www.psc.edu/networking/papers/papers.html
[MM96a]マシス、M.とJ. Mahdavi、 "フォワード謝辞：精錬TCP輻輳制御"、SIGCOMM'96、8月、1996年、スタンフォード大学、カリフォルニアの議事録利用可能なfromhttp：//www.psc.edu/networking/papers/papers.html
[MM96b] Mathis, M. and J. Mahdavi, "TCP Rate-Halving with Bounding Parameters", Technical report. Available from http://www.psc.edu/networking/papers/FACKnotes/current.
[MM96b]マシス、M.とJ. Mahdavi、 "バウンディングパラメータを指定したTCPレート-半減"、技術報告書。 http://www.psc.edu/networking/papers/FACKnotes/currentから入手できます。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
【MMFR96]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[PAD+98] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[PAD + 98]パクソン、V.、オールマン、M.、ドーソン、S.、フェナー、W.、Griner、J.、天、I.、レイヒー、K.、Semke、J.およびB.フォルツ、 "既知のTCP実装の問題」、RFC 2525、1999年3月。
[Pax97] Paxson, V., "End-to-End Internet Packet Dynamics", Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[Pax97]パクソン、V.、「エンドツーエンドのインターネットパケットダイナミクス」、SIGCOMM '97の議事録、カンヌ、フランス、1997年9月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
【Pos81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]スティーブンス、W.、 "TCP / IPイラスト、第1巻：プロトコル"、アディソン・ウェズリー、1994。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[Ste97]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。
[WS95] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1995.
[WS95]ライト、G.とW.スティーブンス、 "TCP / IPイラスト、2巻：インプリメンテーション"、アディソン・ウェズリー、1995。
Authors' Addresses
著者のアドレス
Mark Allman NASA Glenn Research Center/Sterling Software Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135 216-433-6586
マーク・オールマンNASAグレンリサーチセンター/スターリングソフトウェアルイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135 216-433-6586
EMail: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
メールアドレス：mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman
Vern Paxson ACIRI / ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
バーン・パクソンACIRI / ICSI 1947センターストリートスイート600バークレー、CA 94704から1198
Phone: +1 510/642-4274 x302 EMail: vern@aciri.org
電話：+1 510/642から4274 X302メール：vern@aciri.org
W. Richard Stevens 1202 E. Paseo del Zorro Tucson, AZ 85718 520-297-9416
Ｗ。 りちゃｒｄ Ｓてゔぇんｓ １２０２ え。 ぱせお でｌ ぞっろ つｃそん、 あＺ ８５７１８ ５２０ー２９７ー９４１６
EMail: rstevens@kohala.com http://www.kohala.com/~rstevens
メールアドレス：rstevens@kohala.com http://www.kohala.com/~rstevens
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。