Internet Engineering Task Force (IETF) V. Paxson
Request for Comments: 6298 ICSI/UC Berkeley
Obsoletes: 2988 M. Allman
Updates: 1122 ICSI
Category: Standards Track J. Chu
ISSN: 2070-1721 Google
M. Sargent
CWRU
June 2011
Internet Engineering Task Force (IETF) V. Paxson
Request for Comments: 6298 ICSI/UC Berkeley
Obsoletes: 2988 M. Allman
Updates: 1122 ICSI
Category: Standards Track J. Chu
ISSN: 2070-1721 Google
M. Sargent
CWRU
June 2011
Computing TCP's Retransmission Timer
计算TCP的重传计时器
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. This document obsoletes RFC 2988.
本文档定义了传输控制协议（TCP）发送方在计算和管理其重传计时器时需要使用的标准算法。它扩展了RFC 1122第4.2.3.1节中的讨论，并将支持算法的要求从“应该”升级为“必须”。本文件淘汰了RFC 2988。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6298.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6298.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 5681 [APB09] 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 5681 [APB09].
本文件对设置RTO的算法进行了编码。此外，本文件扩展了RFC 1122第4.2.3.1节中的讨论，并将支持算法的要求从“应该”升级为“必须”。RFC 5681[APB09]概述了TCP在RTO过期并发送重传后开始发送的算法。本文件不改变RFC 5681[APB09]中概述的行为。
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. This document obsoletes RFC 2988 [PA00].
在某些情况下，TCP发送方可能比本文中详细介绍的算法更保守。但是，TCP的攻击性不得超过以下算法所允许的。本文件废除了RFC 2988[PA00]。
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]中所述进行解释。
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 <- 1 second, though the "backing off" on repeated retransmission discussed in (5.5) still applies.
（2.1）在对发送方和接收方之间发送的段进行往返时间（RTT）测量之前，发送方应将RTO设置为小于-1秒，尽管（5.5）中讨论的重复重传“后退”仍然适用。
Note that the previous version of this document used an initial RTO of 3 seconds [PA00]. A TCP implementation MAY still use this value (or any other value > 1 second). This change in the lower bound on the initial RTO is discussed in further detail in Appendix A.
请注意，本文档的早期版本使用了3秒[PA00]的初始RTO。TCP实现仍然可以使用此值（或任何其他大于1秒的值）。附录A进一步详细讨论了初始RTO下限的变化。
(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
传统上，TCP实现使用粗粒度时钟来测量RTT并触发RTO，这会对RTO施加较大的最小值。研究表明，需要一个大的最小RTO来保持TCP的保守性并避免虚假的重新传输[AP99]。因此，作为一种保守的方法，本规范需要一个较大的最小RTO，而
at the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior.
同时承认，在未来的某个时刻，研究可能表明较小的最小RTO是可以接受的或优于RTO。
(2.5) A maximum value MAY be placed on RTO provided it is at least 60 seconds.
（2.5）RTO上的最大值应至少为60秒。
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历史。改变这些常数的方法目前是一个开放的研究问题。
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 coarser 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实现中得到了广泛的实现。
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值）。
(5.7) If the timer expires awaiting the ACK of a SYN segment and the TCP implementation is using an RTO less than 3 seconds, the RTO MUST be re-initialized to 3 seconds when data transmission begins (i.e., after the three-way handshake completes).
（5.7）如果等待SYN段确认的计时器过期，并且TCP实现使用RTO的时间少于3秒，则当数据传输开始时（即，在三向握手完成后），RTO必须重新初始化为3秒。
This represents a change from the previous version of this document [PA00] and is discussed in Appendix A.
这表示对本文件[PA00]先前版本的变更，并在附录a中讨论。
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 back off (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）。
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 5681) 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 5681中描述的算法）的正确实现，以保持网络稳定性并避免拥塞崩溃。攻击者可以在接收方实际收到数据之前伪造段确认，从而使TCP端点在遇到拥塞时做出更积极的响应，从而将RTO降低到不安全的值。但要做到这一点，需要正确地欺骗确认，这是很困难的，除非攻击者能够监视发送方和接收方之间路径上的通信量。此外，即使攻击者可以使发送方的RTO达到太小的值，攻击者似乎也无法利用此值进行大部分攻击（与他们可以欺骗属于连接的数据包所造成的其他伤害相比），由于实际拥塞导致错误传输的数据包丢失，发送TCP仍将退出其计时器。
The security considerations in RFC 5681 [APB09] are also applicable to this document.
RFC 5681[APB09]中的安全注意事项也适用于本文件。
This document reduces the initial RTO from the previous 3 seconds [PA00] to 1 second, unless the SYN or the ACK of the SYN is lost, in which case the default RTO is reverted to 3 seconds before data transmission begins.
本文件将初始RTO从前3秒[PA00]减少到1秒，除非SYN或SYN的ACK丢失，在这种情况下，默认RTO恢复到数据传输开始前3秒。
The RTO algorithm described in this memo was originated by Van Jacobson in [Jac88].
本备忘录中描述的RTO算法由Van Jacobson在[Jac88]中提出。
Much of the data that motivated changing the initial RTO from 3 seconds to 1 second came from Robert Love, Andre Broido, and Mike Belshe.
促使将初始RTO从3秒更改为1秒的大部分数据来自Robert Love、Andre Broido和Mike Belshe。
[APB09] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[APB09]Allman，M.，Paxson，V.，和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[Bra89] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]Braden，R.，Ed.“互联网主机的要求-通信层”，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月。
[JBB92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[JBB92]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[AP99]Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，SIGCOMM 99。
[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century", http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf, July 2009.
[Chu09]Chu，J.，“为21世纪调整TCP参数”，http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf，2009年7月。
[SLS09] Schulman, A., Levin, D., and Spring, N., "CRAWDAD data set umd/sigcomm2008 (v. 2009-03-02)", http://crawdad.cs.dartmouth.edu/umd/sigcomm2008, March, 2009.
[SLS09]Schulman，A.，Levin，D.，和Spring，N.，“CRAWDAD数据集umd/sigcomm2008（v.2009-03-02）”，http://crawdad.cs.dartmouth.edu/umd/sigcomm2008，2009年3月。
[HKA04] Henderson, T., Kotz, D., and Abyzov, I., "CRAWDAD trace dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)", http://crawdad.cs.dartmouth.edu/dartmouth/campus/ tcpdump/fall03, November 2004.
[HKA04]Henderson，T.，Kotz，D.，和Abyzov，I.，“CRAWDAD trace dartmouth/campus/tcpdump/fall03（v.2004-11-09）”，http://crawdad.cs.dartmouth.edu/dartmouth/campus/ tcpdump/fall03，2004年11月。
[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。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[PA00]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
Choosing a reasonable initial RTO requires balancing two competing considerations:
选择合理的初始RTO需要平衡两个相互竞争的因素：
1. The initial RTO should be sufficiently large to cover most of the end-to-end paths to avoid spurious retransmissions and their associated negative performance impact.
1. 初始RTO应足够大，以覆盖大多数端到端路径，以避免虚假重传及其相关的负面性能影响。
2. The initial RTO should be small enough to ensure a timely recovery from packet loss occurring before an RTT sample is taken.
2. 初始RTO应足够小，以确保在采集RTT样本之前及时恢复数据包丢失。
Traditionally, TCP has used 3 seconds as the initial RTO [Bra89] [PA00]. This document calls for lowering this value to 1 second using the following rationale:
传统上，TCP使用3秒作为初始RTO[Bra89][PA00]。本文件要求使用以下基本原理将该值降低至1秒：
- Modern networks are simply faster than the state-of-the-art was at the time the initial RTO of 3 seconds was defined.
- 现代网络的速度比最初定义3秒RTO时的最先进速度要快。
- Studies have found that the round-trip times of more than 97.5% of the connections observed in a large scale analysis were less than 1 second [Chu09], suggesting that 1 second meets criterion 1 above.
- 研究发现，在大规模分析中观察到的超过97.5%的连接的往返时间小于1秒[Chu09]，表明1秒符合上述标准1。
- In addition, the studies observed retransmission rates within the three-way handshake of roughly 2%. This shows that reducing the initial RTO has benefit to a non-negligible set of connections.
- 此外，研究还观察到三方握手中的重传率约为2%。这表明减少初始RTO对一组不可忽略的连接有好处。
- However, roughly 2.5% of the connections studied in [Chu09] have an RTT longer than 1 second. For those connections, a 1 second initial RTO guarantees a retransmission during connection establishment (needed or not).
- 然而，在[Chu09]中研究的连接中，大约有2.5%的RTT超过1秒。对于这些连接，1秒初始RTO保证在连接建立期间（无论是否需要）重新传输。
When this happens, this document calls for reverting to an initial RTO of 3 seconds for the data transmission phase. Therefore, the implications of the spurious retransmission are modest: (1) an extra SYN is transmitted into the network, and (2) according to RFC 5681 [APB09] the initial congestion window will be limited to 1 segment. While (2) clearly puts such connections at a disadvantage, this document at least resets the RTO such that the connection will not continually run into problems with a short timeout. (Of course, if the RTT is more than 3 seconds, the connection will still encounter difficulties. But that is not a new issue for TCP.)
发生这种情况时，本文档要求在数据传输阶段恢复到3秒的初始RTO。因此，伪重传的影响不大：（1）额外的SYN被传输到网络中，（2）根据RFC 5681[APB09]，初始拥塞窗口将被限制为1段。虽然（2）明显地使这种连接处于不利地位，但本文档至少重置了RTO，从而使连接不会在短时间内持续出现问题。（当然，如果RTT超过3秒，连接仍然会遇到困难。但这对于TCP来说不是新问题。）
In addition, we note that when using timestamps, TCP will be able to take an RTT sample even in the presence of a spurious retransmission, facilitating convergence to a correct RTT estimate when the RTT exceeds 1 second.
此外，我们注意到，当使用时间戳时，即使存在伪重传，TCP也将能够获取RTT样本，从而在RTT超过1秒时有助于收敛到正确的RTT估计。
As an additional check on the results presented in [Chu09], we analyzed packet traces of client behavior collected at four different vantage points at different times, as follows:
作为对[Chu09]中结果的补充检查，我们分析了在不同时间在四个不同有利位置收集的客户行为的数据包跟踪，如下所示：
Name Dates Pkts. Cnns. Clnts. Servs.
--------------------------------------------------------
LBL-1 Oct/05--Mar/06 292M 242K 228 74K
LBL-2 Nov/09--Feb/10 1.1B 1.2M 1047 38K
ICSI-1 Sep/11--18/07 137M 2.1M 193 486K
ICSI-2 Sep/11--18/08 163M 1.9M 177 277K
ICSI-3 Sep/14--21/09 334M 3.1M 170 253K
ICSI-4 Sep/11--18/10 298M 5M 183 189K
Dartmouth Jan/4--21/04 1B 4M 3782 132K
SIGCOMM Aug/17--21/08 11.6M 133K 152 29K
Name Dates Pkts. Cnns. Clnts. Servs.
--------------------------------------------------------
LBL-1 Oct/05--Mar/06 292M 242K 228 74K
LBL-2 Nov/09--Feb/10 1.1B 1.2M 1047 38K
ICSI-1 Sep/11--18/07 137M 2.1M 193 486K
ICSI-2 Sep/11--18/08 163M 1.9M 177 277K
ICSI-3 Sep/14--21/09 334M 3.1M 170 253K
ICSI-4 Sep/11--18/10 298M 5M 183 189K
Dartmouth Jan/4--21/04 1B 4M 3782 132K
SIGCOMM Aug/17--21/08 11.6M 133K 152 29K
The "LBL" data was taken at the Lawrence Berkeley National Laboratory, the "ICSI" data from the International Computer Science Institute, the "SIGCOMM" data from the wireless network that served the attendees of SIGCOMM 2008, and the "Dartmouth" data was collected from Dartmouth College's wireless network. The latter two datasets are available from the CRAWDAD data repository [HKA04] [SLS09]. The table lists the dates of the data collections, the number of packets collected, the number of TCP connections observed, the number of local clients monitored, and the number of remote servers contacted. We consider only connections initiated near the tracing vantage point.
“LBL”数据来自劳伦斯伯克利国家实验室，“ICSI”数据来自国际计算机科学研究所，“SIGCOMM”数据来自为SIGCOM2008与会者提供服务的无线网络，“达特茅斯”数据来自达特茅斯学院的无线网络。后两个数据集可从CRAWDAD数据存储库[HKA04][SLS09]获取。该表列出了数据收集的日期、收集的数据包数、观察到的TCP连接数、监视的本地客户端数以及联系的远程服务器数。我们只考虑在跟踪优势点附近引发的连接。
Analysis of these datasets finds the prevalence of retransmitted SYNs to be between 0.03% (ICSI-4) to roughly 2% (LBL-1 and Dartmouth).
对这些数据集的分析发现，重传SYN的流行率在0.03%（ICSI-4）到大约2%（LBL-1和达特茅斯）之间。
We then analyzed the data to determine the number of additional and spurious retransmissions that would have been incurred if the initial RTO was assumed to be 1 second. In most of the datasets, the proportion of connections with spurious retransmits was less than 0.1%. However, in the Dartmouth dataset, approximately 1.1% of the connections would have sent a spurious retransmit with a lower initial RTO. We attribute this to the fact that the monitored network is wireless and therefore susceptible to additional delays from RF effects.
然后，我们分析数据，以确定如果假设初始RTO为1秒，可能会发生的额外和虚假重传次数。在大多数数据集中，具有虚假重传的连接比例小于0.1%。然而，在Dartmouth数据集中，大约1.1%的连接会以较低的初始RTO发送虚假的重新传输。我们将此归因于受监控网络是无线的，因此容易受到射频效应的额外延迟。
Finally, there are obviously performance benefits from retransmitting lost SYNs with a reduced initial RTO. Across our datasets, the percentage of connections that retransmitted a SYN and would realize at least a 10% performance improvement by using the smaller initial RTO specified in this document ranges from 43% (LBL-1) to 87% (ICSI-4). The percentage of connections that would realize at least a 50% performance improvement ranges from 17% (ICSI-1 and SIGCOMM) to 73% (ICSI-4).
最后，通过减少初始RTO重新传输丢失的SYN，明显提高了性能。在我们的数据集中，通过使用本文档中指定的较小初始RTO，重新传输SYN并将实现至少10%性能改进的连接百分比从43%（LBL-1）到87%（ICSI-4）不等。实现至少50%性能改进的连接百分比从17%（ICSI-1和SIGCOMM）到73%（ICSI-4）不等。
From the data to which we have access, we conclude that the lower initial RTO is likely to be beneficial to many connections, and harmful to relatively few.
从我们可以访问的数据中，我们得出结论，较低的初始RTO可能对许多连接有利，而对相对较少的连接有害。
Authors' Addresses
作者地址
Vern Paxson ICSI/UC Berkeley 1947 Center Street Suite 600 Berkeley, CA 94704-1198
Vern Paxson ICSI/UC Berkeley 1947加州伯克利中心街600号套房，邮编94704-1198
Phone: 510-666-2882
EMail: vern@icir.org
http://www.icir.org/vern/
Phone: 510-666-2882
EMail: vern@icir.org
http://www.icir.org/vern/
Mark Allman ICSI 1947 Center Street Suite 600 Berkeley, CA 94704-1198
马克·奥尔曼ICSI 1947加利福尼亚州伯克利中心街600号套房94704-1198
Phone: 440-235-1792
EMail: mallman@icir.org
http://www.icir.org/mallman/
Phone: 440-235-1792
EMail: mallman@icir.org
http://www.icir.org/mallman/
H.K. Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
H.K.Jerry Chu Google，Inc.1600圆形剧场公园路山景城，加利福尼亚州94043
Phone: 650-253-3010 EMail: hkchu@google.com
电话：650-253-3010电子邮件：hkchu@google.com
Matt Sargent Case Western Reserve University Olin Building 10900 Euclid Avenue Room 505 Cleveland, OH 44106
马特·萨金特·凯斯西部保护区大学奥林大厦10900欧几里德大道505室，俄亥俄州克利夫兰44106
Phone: 440-223-5932 EMail: mts71@case.edu
电话：440-223-5932电子邮件：mts71@case.edu