Network Working Group V. Paxson
Request for Comments: 2988 ACIRI
Category: Standards Track M. Allman
NASA GRC/BBN
November 2000
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）。本备忘录的分发不受限制。
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节中的讨论，并将支持算法的要求从“应该”升级为“必须”。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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发送方维护两个状态变量，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)
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'
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]).
应使用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施加较大的最小值。研究表明，需要一个大的最小RTO来保持TCP的保守性并避免虚假的重新传输[AP99]。因此，本规范要求将较大的最小RTO作为一种保守方法，同时承认在未来某个时候，研究可能表明较小的最小RTO是可以接受或优于的。
(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必须使用Karn算法[KP87]来采集RTT样本。也就是说，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实现一次测量一个RTT（通常每个RTT测量一次）。但是，当使用timestamp选项时，每个ACK都可以用作RTT样本。RFC 1323[JBB92]建议，利用大拥塞窗口的TCP连接应在每个数据窗口中采集许多RTT样本，以避免估计RTT中的混叠效应。TCP实现必须至少对每个RTT进行一次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)
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).
（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中概述的倍频操作后的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节中概述的计算，包括RTO的计算，这可能导致RTO在经历指数退避后“崩溃”退避（规则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.2）采集的下一个RTT样本进行初始化，而不是使用（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
互联网在很大程度上依赖于RTO算法（以及RFC 2581中描述的算法）的正确实现，以保持网络稳定性并避免拥塞崩溃。攻击者可以在接收方实际收到数据之前伪造段确认，从而使TCP端点在遇到拥塞时做出更积极的响应，从而将RTO降低到不安全的值。但要做到这一点，需要正确地欺骗确认，这是很困难的，除非攻击者能够监视发送方和接收方之间路径上的通信量。此外，即使
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达到太小的值，似乎攻击者无法利用此值进行大部分攻击（与他们可以欺骗属于连接的数据包所造成的其他伤害相比），由于实际拥塞导致错误传输的数据包丢失，发送TCP仍将退出其计时器。
Acknowledgments
致谢
The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].
本备忘录中描述的RTO算法由Van Jacobson在[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 25811999年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.，“拥塞避免和控制”，《计算机通信评论》，第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]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.，“传输控制协议”，标准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加利福尼亚州伯克利中心街600号套房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
马克·奥尔曼美国宇航局格伦研究中心/BBN技术刘易斯场俄亥俄州克利夫兰市布鲁克公园路21000号，邮编：44135
Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
Phone: 216-433-6586
Fax: 216-433-8705
EMail: 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编辑功能的资金目前由互联网协会提供。