Network Working Group                                          V. Paxson
Request for Comments: 2988                                         ACIRI
Category: Standards Track                                      M. Allman
                                                            NASA GRC/BBN
                                                           November 2000
        

                  Computing TCP's Retransmission Timer
        

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 (2000). All Rights Reserved.

著作権（C）インターネット協会（2000）。全著作権所有。

Abstract

抽象

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.

この文書では、伝送制御プロトコル（TCP）送信者は、その再送タイマを計算し、管理するのに使用するために必要な標準アルゴリズムを定義します。これは、RFC 1122のセクション4.2.3.1で議論を展開するとMUSTにSHOULDからアルゴリズムをサポートする要件をアップグレードします。

1 Introduction

1はじめに

The Transmission Control Protocol (TCP) [Pos81] uses a retransmission timer to ensure data delivery in the absence of any feedback from the remote data receiver. The duration of this timer is referred to as RTO (retransmission timeout). RFC 1122 [Bra89] specifies that the RTO should be calculated as outlined in [Jac88].

伝送制御プロトコル（TCP）[Pos81]は、リモート・データ受信機からのフィードバックの非存在下でのデータ配信を保証するために、再送タイマーを使用します。このタイマーの持続時間は、RTO（再送タイムアウト）と呼ばれます。 RFC 1122 [Bra89] [Jac88]に概説されるようにRTOを算出するように指定します。

This document codifies the algorithm for setting the RTO. In addition, this document expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. RFC 2581 [APS99] outlines the algorithm TCP uses to begin sending after the RTO expires and a retransmission is sent. This document does not alter the behavior outlined in RFC 2581 [APS99].

この文書では、RTOを設定するためのアルゴリズムを成文化。また、この文書はRFC 1122のセクション4.2.3.1での議論を拡張し、MUSTにSHOULDからアルゴリズムをサポートする要件をアップグレードします。 RFC 2581 [APS99]は、アルゴリズムのTCPがRTOの有効期限が切れると再送信が送られた後に送信を開始するために使用しています概説します。この文書は、RFC 2581 [APS99]で概説した動作を変更しません。

In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow.

TCPの送信者は、この文書に詳述されたアルゴリズムが許すよりも、より保守的であるためにはいくつかの状況では有益であろう。しかし、TCPは、以下のアルゴリズムが許すよりも、より積極的にすることはできません。

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]に記載されているように解釈されます。

2 The Basic Algorithm

2基本的なアルゴリズム

To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). In addition, we assume a clock granularity of G seconds.

現在のRTOを計算するには、TCPの送信者は、2つの状態変数、SRTT（平滑化往復時間）とRTTVAR（往復の時間変化）を維持します。また、当社は、G秒のクロック精度を前提としています。

The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:

次のようにSRTT、RTTVAR、およびRTOの計算を管理する規則は、以下のとおりです。

(2.1) Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD set RTO <- 3 seconds (per RFC 1122 [Bra89]), though the "backing off" on repeated retransmission discussed in (5.5) still applies.

（2.1）ラウンドトリップ時間（RTT）測定は、送信者が<RTOを設定すべきである、送信者と受信者の間で送信されるセグメントのためになされたものまで - 「バックオフ」が、（RFC 1122あたり【Bra89]）3秒（5.5）で議論を繰り返し再送信にはまだ適用されます。

            Note that some implementations may use a "heartbeat" timer
            that in fact yield a value between 2.5 seconds and 3
            seconds.  Accordingly, a lower bound of 2.5 seconds is also
            acceptable, providing that the timer will never expire
            faster than 2.5 seconds.  Implementations using a heartbeat
            timer with a granularity of G SHOULD not set the timer below
            2.5 + G seconds.
        

(2.2) When the first RTT measurement R is made, the host MUST set

（2.2）最初のRTT計測Rが行われると、ホストが設定しなければなりません

            SRTT <- R
            RTTVAR <- R/2
            RTO <- SRTT + max (G, K*RTTVAR)
        

where K = 4.

ここで、K = 4。

(2.3) When a subsequent RTT measurement R' is made, a host MUST set

（2.3）、その後のRTT計測R」が行われると、ホストが設定しなければなりません

            RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
            SRTT <- (1 - alpha) * SRTT + alpha * R'
        

The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. That is, updating RTTVAR and SRTT MUST be computed in the above order.

RTTVARの更新に使用されるSRTTの値は、第二の割り当てを使用してSRTT自身を更新する前にその値です。すなわち、上記の順序で計算されなければならないRTTVARとSRTTを更新する、です。

The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]).

上記アルファ= 1/8、ベータ= 1/4（[JK88]で提案されているような）を使用して計算されるべきです。

After the computation, a host MUST update RTO <- SRTT + max (G, K*RTTVAR)

計算後、ホストは更新しなければならないRTO < - SRTT + MAX（G、K * RTTVAR）

(2.4) Whenever RTO is computed, if it is less than 1 second then the RTO SHOULD be rounded up to 1 second.

RTOが計算されるたびに、それが1秒未満である場合（2.4）、次いで、RTOは1秒に切り上げされるべきです。

         Traditionally, TCP implementations use coarse grain clocks to
         measure the RTT and trigger the RTO, which imposes a large
         minimum value on the RTO.  Research suggests that a large
         minimum RTO is needed to keep TCP conservative and avoid
         spurious retransmissions [AP99].  Therefore, this
         specification requires a large minimum RTO as a conservative
         approach, while at the same time acknowledging that at some
         future point, research may show that a smaller minimum RTO is
         acceptable or superior.
        

(2.5) A maximum value MAY be placed on RTO provided it is at least 60 seconds.

（2.5）の最大値は、RTO上に配置することができるが、それは、少なくとも60秒が提供されます。

3 Taking RTT Samples

3つの撮影RTTサンプル

TCP MUST use Karn's algorithm [KP87] for taking RTT samples. That is, RTT samples MUST NOT be made using segments that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance). The only case when TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is employed, since the timestamp option removes the ambiguity regarding which instance of the data segment triggered the acknowledgment.

TCPは、RTTのサンプルを採取するために[KP87]カーンのアルゴリズムを使用しなければなりません。すなわち、RTTサンプルが再送されたセグメントを使用して作製されてはいけません（したがって、そのため、応答パケット以降のインスタンスの最初のインスタンスのためだったかどうか曖昧である）、です。 TCPタイムスタンプオプションが[JBB92]使用されたときにタイムスタンプオプションは、データセグメントのインスタンスは、肯定応答をトリガかに関する曖昧さを除去するので、TCPが安全に再送セグメントからRTTサンプルを取ることができる場合のみです。

Traditionally, TCP implementations have taken one RTT measurement at a time (typically once per RTT). However, when using the timestamp option, each ACK can be used as an RTT sample. RFC 1323 [JBB92] suggests that TCP connections utilizing large congestion windows should take many RTT samples per window of data to avoid aliasing effects in the estimated RTT. A TCP implementation MUST take at least one RTT measurement per RTT (unless that is not possible per Karn's algorithm).

伝統的に、TCPの実装は、（典型的には、一度RTTごとに）一度に一つのRTT測定値をとっています。タイムスタンプオプションを使用する場合しかし、各ACKは、RTTサンプルとして使用することができます。 RFC 1323 [JBB92]大混雑の窓を利用したTCP接続が推定RTTにおけるエイリアシング効果を回避するために、データの窓あたりの多くのRTTサンプルを取るべきであることを示唆しています。 （それはカーンのアルゴリズムあたりのことができない場合を除く）TCPの実装では、RTTごとに少なくとも1回のRTT測定を取る必要があります。

For fairly modest congestion window sizes research suggests that timing each segment does not lead to a better RTT estimator [AP99]. Additionally, when multiple samples are taken per RTT the alpha and beta defined in section 2 may keep an inadequate RTT history. A method for changing these constants is currently an open research question.

かなり控えめな輻輳ウィンドウのための研究は、各セグメントのタイミングが良くRTT推定[AP99]につながらないことを示唆しているサイズ。複数のサンプルがRTTごとに取得された場合に加えて、セクション2で定義されたαおよびβは、不十分なRTTの履歴を保持することができます。これらの定数を変更するための方法は、現在開いている研究課題です。

4 Clock Granularity

4クロック粒度

There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables. However, if the K*RTTVAR term in the RTO calculation equals zero, the variance term MUST be rounded to G seconds (i.e., use the equation given in step 2.3).

Gは、RTT測定値と異なる状態変数を計算するために使用されるクロックの粒度のための必要はありません。 RTO算出におけるK * RTTVAR項がゼロに等しい場合は、分散という用語は、G秒（すなわち、ステップ2.3で与えられた式を使用）に丸めなければなりません。

RTO <- SRTT + max (G, K*RTTVAR)

RTO < - SRTT + MAX（G、K * RTTVAR）

Experience has shown that finer clock granularities (<= 100 msec) perform somewhat better than more coarse granularities.

経験は、より細かいクロック粒度（<= 100ミリ秒）より粗い粒度よりも幾分良好に機能することが示されています。

Note that [Jac88] outlines several clever tricks that can be used to obtain better precision from coarse granularity timers. These changes are widely implemented in current TCP implementations.

【Jac88】粗い粒度のタイマーより良い精度を得るために使用することができるいくつかの巧妙なトリックを概説することに留意されたいです。これらの変更は、現在広く普及しているTCP実装で実装されています。

5 Managing the RTO Timer

5 RTOタイマーを管理します

An implementation MUST manage the retransmission timer(s) in such a way that a segment is never retransmitted too early, i.e. less than one RTO after the previous transmission of that segment.

実装は、セグメントは、そのセグメントの前の送信後、早すぎるすなわち未満のRTOを再送信されることはありませんように再送タイマ（複数可）を管理しなければなりません。

The following is the RECOMMENDED algorithm for managing the retransmission timer:

以下は、再送タイマーを管理するための推奨アルゴリズムです。

(5.1) Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).

タイマーが実行されていない場合（5.1）（再送信を含む）データを含むパケットが送信されるたびに、それは（RTOの現在値のため）RTO秒後に期限切れになるように、それが実行を開始。

(5.2) When all outstanding data has been acknowledged, turn off the retransmission timer.

（5.2）は、すべての未処理のデータが認識されている場合には、再送タイマーをオフにしてください。

(5.3) When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire after RTO seconds (for the current value of RTO).

ACKが新しいデータを認識し、その受信した場合、それは（RTOの現在値のため）RTO秒後に期限切れになるように、（5.3）は、再送タイマを再起動します。

When the retransmission timer expires, do the following:

再送タイマが満了したときは、次の手順を実行します。

(5.4) Retransmit the earliest segment that has not been acknowledged by the TCP receiver.

（5.4）TCP受信機によって肯定応答されていない最も早いセグメントを再送します。

(5.5) The host MUST set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in (2.5) above may be used to provide an upper bound to this doubling operation.

（5.5）ホストは<RTOを設定しなければなりません - RTO * 2（ "バックオフタイマー"）。上記（2.5）で説明した最大値は、この倍増操作に上限を提供するために使用され得ます。

(5.6) Start the retransmission timer, such that it expires after RTO seconds (for the value of RTO after the doubling operation outlined in 5.5).

（5.6）は（5.5で概説さ倍増操作後のRTOの値のための）RTO秒後に期限切れになるように、再送タイマーを起動します。

Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in section 2 are performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to exponential backoff (rule 5.5).

再送信後、一旦新しいRTT測定がRTOを「崩壊」をもたらす可能性がRTOの計算、を含む、セクション2で概説した計算が行われ、（新たなデータが送信され、承認された場合にのみ発生する可能性がある）が得られることに注意してくださいバックそれは指数バックオフ（規則5.5）を受けた後にダウン。

Note that a TCP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared they should be initialized with the next RTT sample taken per (2.2) rather than using (2.3).

現在のSRTTとRTTVARは、このような状況では偽であると思われるようTCP実装は、タイマーをオフにバックアップした後、複数回SRTTとRTTVARをクリアすることがあります。 SRTTとRTTVARがクリアされると、それらは次のRTT（2.2）ごとに採取したサンプルではなく、使用して（2.3）で初期化する必要があります。

6 Security Considerations

6セキュリティについての考慮事項

This document requires a TCP to wait for a given interval before retransmitting an unacknowledged segment. An attacker could cause a TCP sender to compute a large value of RTO by adding delay to a timed packet's latency, or that of its acknowledgment. However, the ability to add delay to a packet's latency often coincides with the ability to cause the packet to be lost, so it is difficult to see what an attacker might gain from such an attack that could cause more damage than simply discarding some of the TCP connection's packets.

この文書では、未確認のセグメントを再送信する前に、一定間隔を待つためにTCPが必要です。攻撃者は、TCPの送信者が、時限パケットの遅延、またはその承認のものに遅延を追加することにより、RTOの大きな値を計算する可能性があります。しかし、パケットのレイテンシーに遅延を追加する機能は、多くの場合、パケットが失われ能力と一致しているので、攻撃者は、単にの一部を捨てるよりも多くの損傷を引き起こす可能性があり、そのような攻撃から得る可能性があるかを確認することは困難ですTCPコネクションのパケット。

The Internet to a considerable degree relies on the correct implementation of the RTO algorithm (as well as those described in RFC 2581) 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 acknowledgments for segments before the receiver has actually received the data, thus lowering RTO to an unsafe value. But to do so requires spoofing the acknowledgments correctly, which is difficult unless the attacker can monitor traffic along the path between the sender and the receiver. In addition, even if the attacker can cause the sender's RTO to reach too small a value, it appears the attacker cannot leverage this into much of an attack (compared to the other damage they can do if they can spoof packets belonging to the connection), since the sending TCP will still back off its timer in the face of an incorrectly transmitted packet's loss due to actual congestion.

かなりの程度まで、インターネットは、正しいRTOアルゴリズムの実装（およびRFC 2581に記載されているものなど）、ネットワークの安定性を維持し、輻輳崩壊を回避するために、に依存しています。攻撃者は、TCPエンドポイントは、受信機は、実際にこのように危険な値にRTOを下げ、データを受信した前のセグメントの確認応答を鍛造することで輻輳の顔に、より積極的に対応する可能性があります。しかし、そうすることは、攻撃者が送信者と受信者との間の経路に沿ってトラフィックを監視することができない限り困難である、正しく確認応答をスプーフィングが必要です。また、攻撃者は送信者のRTOが小さすぎる値に到達させることができたとしても、攻撃者が（彼らは、接続に属するパケットを偽装できるかどうか、彼らが行うことができ、他の損傷と比較して）攻撃の多くにこれを活用することはできません表示されます、送信TCP以来まだによる実際の混雑に間違って送信したパケットの損失に直面して、そのタイマーをオフにバックアップします。

Acknowledgments

謝辞

The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].

このメモに記載RTOアルゴリズムは[Jac88]にバン・ジェイコブソンによって発信されました。

References

リファレンス

[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.

「エンドツーエンドのネットワークパスのプロパティの推定について」[AP99]オールマン、M.およびV.パクソン、SIGCOMM 99。

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

[APS99]オールマン、M.、パクソンV.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。

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

[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.

[Jac88]ジェーコブソン、V.、「輻輳回避とコントロール」、コンピュータコミュニケーションレビュー、巻。 18、ありません。 4、頁314から329まで、1988年8月。

[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[JK88]ジェーコブソン、V.とM. Karels、 "輻輳回避と制御"、ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z。

[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.

[KP87]カーン、P.とC.ヤマウズラ、「信頼性の高いトランスポートプロトコルにおける改善のラウンドトリップ時間の見積り」、SIGCOMM 87。

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

【Pos81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。

Author's Addresses

著者のアドレス

Vern Paxson ACIRI / ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198

バーン・パクソンACIRI / ICSI 1947センターストリートスイート600バークレー、CA 94704から1198

Phone: 510-666-2882 Fax: 510-643-7684 EMail: vern@aciri.org http://www.aciri.org/vern/

電話：510-666-2882ファックス：510-643-7684 Eメール：vern@aciri.org http://www.aciri.org/vern/

Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135

マーク・オールマンNASAグレンリサーチセンター/ BBNテクノロジーズルイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135

Phone: 216-433-6586 Fax: 216-433-8705 EMail: mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman

電話：216-433-6586ファックス：216-433-8705 Eメール：mallman@grc.nasa.gov http://roland.grc.nasa.gov/~mallman

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

著作権（C）インターネット協会（2000）。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。