[要約] RFC 2988は、TCPプロトコルにおいて再送タイマー（RTO）の値を動的に算出するための標準的なアルゴリズムを定義しています。往復時間（RTT）の計測、平滑化されたRTT（SRTT）の計算、および指数バックオフを含む具体的な手順を規定し、以前のRFC 793の一部を更新しました。ネットワークの遅延変動に適切に対応し、パケット損失発生時の効率的な再送とネットワーク崩壊の防止を実現することを目的としています。
Network Working Group V. Paxson
Request for Comments: 2988 ACIRI
Category: Standards Track M. Allman
NASA GRC/BBN
November 2000
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定し、改善に向けた議論や提案を求めます。このプロトコルの標準化段階と状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。このメモは無制限に配布できます。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
この文書は、Transmission Control Protocol（TCP）の送信側が再送タイマーを計算・管理するために使用する標準アルゴリズムを定義します。RFC 1122のセクション4.2.3.1の議論を拡張し、このアルゴリズムをサポートする要件を推奨 (SHOULD) から必須へ引き上げます。
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].
Transmission Control Protocol（TCP）[Pos81]は、相手側のデータ受信者から応答がない場合にもデータを届けるため、再送タイマーを使用します。このタイマーの時間をRTO（再送タイムアウト）と呼びます。RFC 1122 [Bra89]では、RTOを[Jac88]で示された方法で計算すべきとしています。
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の議論を拡張し、このアルゴリズムをサポートする要件を推奨 (SHOULD) から必須へ引き上げます。RFC 2581 [APS99]では、RTOの期限が切れて再送が行われた後にTCPが送信を再開するためのアルゴリズムを説明しています。この文書は、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が次のアルゴリズムで許される範囲より積極的に動作してはなりません (MUST NOT)。
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」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[Bra97]に記載された意味で解釈します。
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送信側はSRTT（平滑化された往復時間）とRTTVAR（往復時間の変動）の2つの状態変数を管理します。また、クロック粒度を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秒に設定すべきです (SHOULD)（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秒未満に設定すべきではありません (SHOULD NOT)。
(2.2) When the first RTT measurement R is made, the host MUST set
(2.2) 最初のRTT測定値Rを得たとき、ホストは次の値を設定しなければなりません (MUST)。
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'を得たとき、ホストは次の値を設定しなければなりません (MUST)。
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を計算しなければなりません (MUST)。
The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]).
上記の計算では、alpha=1/8、beta=1/4を使用すべきです (SHOULD)（[JK88]の提案に従います）。
After the computation, a host MUST update RTO <- SRTT + max (G, K*RTTVAR)
計算後、ホストは次の式でRTOを更新しなければなりません (MUST)。 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秒未満であれば1秒に切り上げるべきです (SHOULD)。
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) RTOの上限値は、60秒以上であれば設定してもかまいません (MAY)。
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.
RTTサンプルを取得する際、TCPはKarnのアルゴリズム[KP87]を使用しなければなりません (MUST)。すなわち、再送したセグメントを使ってRTTサンプルを取得してはなりません (MUST NOT)（応答がパケットの最初の送信に対するものか、後の再送に対するものか区別できないためです）。再送したセグメントから安全にRTTサンプルを取得できるのは、TCP timestamp option [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回です）。timestamp optionを使う場合は、各ACKをRTTサンプルとして使用できます。RFC 1323 [JBB92]では、大きな輻輳ウィンドウを使うTCP接続は、RTT推定値のエイリアシングを避けるため、データウィンドウごとに多数のRTTサンプルを取得すべきだとしています。TCP実装は、Karnのアルゴリズムにより不可能な場合を除き、RTTごとに少なくとも1回RTTを測定しなければなりません (MUST)。
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のalphaとbetaではRTTの履歴を十分に保持できない場合があります。これらの定数を変更する方法は、現在も研究課題です。
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の値が0の場合、分散項をG秒に丸めなければなりません (MUST)（すなわち、手順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 msec）のほうが、より粗い粒度よりも多少良好に動作します。
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実装で広く使用されています。
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が経過する前にそのセグメントを再送しないよう、再送タイマーを管理しなければなりません (MUST)。
The following is the RECOMMENDED algorithm for managing the retransmission timer:
再送タイマーを管理する手順として、次のアルゴリズムを推奨します (SHOULD)。
(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とし、タイマーをバックオフしなければなりません (MUST)。前述の(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測定値が得られた時点で、セクション2で説明した計算を実行します。新しいRTT測定値が得られるのは、新しいデータを送信して確認された場合だけです。RTOも再計算するため、規則(5.5)の指数バックオフで増加したRTOが、再び小さな値に戻る場合があります。
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の現在値が不正確になっている可能性が高いため、これらをクリアしてもかまいません (MAY)。クリア後は、(2.3)ではなく(2.2)に従って、次に取得したRTTサンプルで初期化すべきです。
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に記載されたアルゴリズム）が正しく実装されていることが大きく影響します。攻撃者は、受信側がデータを実際に受け取る前にセグメントのACKを偽造し、RTOを危険な値まで下げることで、輻輳時にTCP端点がより積極的に応答するよう仕向ける可能性があります。ただし、それにはACKを正しく偽造する必要があり、送信側と受信側の間の経路上でトラフィックを監視できない攻撃者には困難です。さらに、送信側のRTOを小さすぎる値にできたとしても、攻撃者が得られる利点は小さいと考えられます（接続のパケットを偽造できれば他の損害も与えられます）。実際の輻輳によって不適切に送信されたパケットが失われた場合でも、送信側のTCPはタイマーをバックオフするためです。
The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].
このメモで説明したRTOアルゴリズムは、Van Jacobsonが[Jac88]で提案したものです。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", 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. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
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/
Phone: 510-666-2882 Fax: 510-643-7684 EMail: 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
Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
この文書とその翻訳は、上記の著作権表示と本段落をすべての複製物および派生著作物に含めることを条件として、制限なく、他者に複製・提供できます。また、この文書についてコメントや説明を加える派生著作物、または実装を支援する派生著作物を、全体または一部について作成、複製、公開、配布できます。ただし、インターネット標準の策定に必要な場合（この場合はInternet Standards Processで定める著作権手続きに従う必要があります）、または英語以外の言語への翻訳に必要な場合を除き、この文書自体を、著作権表示やInternet Societyその他のインターネット組織への参照を削除するなど、いかなる方法でも変更してはなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与した限定的な許可は恒久的であり、Internet Society、その後継者または譲受人によって取り消されません。
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.
この文書とここに含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、明示的または黙示的な保証をすべて否認します。これには、ここに含まれる情報の使用が権利を侵害しないという保証や、商品性または特定目的への適合性に関する黙示的な保証が含まれますが、これらに限りません。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金は、現在Internet Societyが提供しています。