RFC 2988 - Computing TCP's Retransmission Timer 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2988
タイトル : RFC 2988 - TCPの再送信タイマーを計算します
翻訳編集 : 自動生成

[要約] RFC 2988は、TCPの再送タイマーを計算する方法についての標準化された手法を提供しています。その目的は、ネットワークの遅延やパケットの損失を考慮して、効果的な再送タイミングを確保することです。

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

TCPの再送信タイマーを計算します

Status of this Memo

本文書の位置付け

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

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

著作権表示

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の議論で拡張され、アルゴリズムをasから必見までサポートする要件をアップグレードします。

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のディスカッションで展開され、アルゴリズムを必要とする必要があるという要件をアップグレードします。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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 <-3秒（RFC 1122 [BRA89]）を設定する必要がありますが、「バックオフ」は（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.5秒から3秒の間の値が得られる「ハートビート」タイマーを使用する場合があることに注意してください。したがって、2.5秒の下限も許容され、タイマーが2.5秒より速く期限切れになることはありません。gの粒度を備えたハートビートタイマーを使用した実装は、タイマーを2.5 g秒未満に設定する必要はありません。

(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の値は、2番目の割り当てを使用してSRTT自体を更新する前の値です。つまり、RTTVARとSRTTの更新は、上記の順序で計算する必要があります。

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

上記は、alpha = 1/8およびbeta = 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.

（2.4）RTOが計算されるたびに、1秒未満の場合、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.

従来、TCPの実装は、粗い穀物時計を使用してRTTを測定し、RTOをトリガーし、RTOに大きな最小値を課しています。調査によると、TCP保守的な状態を維持し、偽りの再送信を避けるためには、大きな最小RTOが必要であることが示唆されています[AP99]。したがって、この仕様には保守的なアプローチとして大きな最小RTOが必要ですが、同時に、将来の時点で、研究がより少ない最小RTOが許容できるか優れていることを調査する可能性があることを認めています。

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

（2.5）少なくとも60秒である場合、RTOに最大値を配置できます。

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サンプルを採取するためにKarnのアルゴリズム[KP87]を使用する必要があります。つまり、RTTサンプルは、再送信されたセグメントを使用して作成してはなりません（したがって、回答がパケットの最初のインスタンスであったのか、それとも後のインスタンスの場合のかどうかはあいまいです）。TCPが再送信セグメントからRTTサンプルを安全に採取できる場合の唯一のケースは、TCPタイムスタンプオプション[JBB92]が使用されるときです。

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の実装は、一度に1つのRTT測定値を取得していました（通常、RTTごとに1回）。ただし、タイムスタンプオプションを使用する場合、各ACKはRTTサンプルとして使用できます。RFC 1323 [JBB92]は、大きな渋滞ウィンドウを使用するTCP接続は、推定RTTのエイリアス効果を回避するために、データのウィンドウごとに多くのRTTサンプルを採取することを示唆しています。TCP実装では、RTTごとに少なくとも1つのRTT測定値を取得する必要があります（Karnのアルゴリズムごとに不可能な場合を除く）。

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

RTT測定と異なる状態変数の計算に使用されるクロック粒度Gには要件はありません。ただし、RTO計算のk*rttvar項がゼロに等しい場合、分散項はg秒に丸められる必要があります（つまり、ステップ2.3で与えられた方程式を使用します）。

       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.

実装は、セグメントが早すぎること、つまりそのセグメントの以前の送信後の1つ未満の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).

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

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）再送信タイマーを開始します。これにより、RTOの数秒後に期限切れになります（5.5で概説された2倍の操作の後の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の計算を含むセクション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).

TCPの実装は、この状況では現在のSRTTとRTTVARが偽物である可能性が高いため、タイマーを複数回後退させた後、SRTTとRTTVARをクリアする可能性があることに注意してください。SRTTとRTTVARがクリアされると、（2.3）を使用するのではなく、（2.2）あたり（2.2）に採取した次のRTTサンプルで初期化する必要があります。

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] Allman、M。およびV. Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、Sigcomm 99。

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

[APS99] Allman、M.、Paxson V.およびW. Stevens、「TCP輻輳制御」、RFC 2581、1999年4月。

[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.

[BRA89] Braden、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Jacobson、V。、「混雑の回避と管理」、コンピューターコミュニケーションレビュー、Vol。18、いいえ。4、pp。314-329、1988年8月。

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

[JK88] Jacobson、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] Karn、P。およびC. Partridge、「信頼できる輸送プロトコルにおける往復時間推定の改善」、Sigcomm 87。

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

[POS81] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。

Author's Addresses

著者のアドレス

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

Vern Paxson Aciri / Icsi 1947 Center Street Suite 600 Berkeley、CA 94704-1198

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

電話：510-666-2882 FAX：510-643-7684メール：vern@aciri.org http://www.aciri.org/ververn/

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

マークオールマンナサグレンリサーチセンター/BBNテクノロジーズルイスフィールド21000 Brookpark Rd。MS 54-2クリーブランド、OH 44135

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

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。