Network Working Group R. Ludwig
Request for Comments: 4015 Ericsson Research
Category: Standards Track A. Gurtov
HIIT
February 2005
Network Working Group R. Ludwig
Request for Comments: 4015 Ericsson Research
Category: Standards Track A. Gurtov
HIIT
February 2005
The Eifel Response Algorithm for TCP
TCP的Eifel响应算法
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.translate error, please retry
The Eifel response algorithm relies on a detection algorithm such as the Eifel detection algorithm, defined in [RFC3522]. That document contains informative background and motivation context that may be useful for implementers of the Eifel response algorithm, but it is not necessary to read [RFC3522] in order to implement the Eifel response algorithm. Note that alternative response algorithms have been proposed [BA02] that could also rely on the Eifel detection algorithm, and alternative detection algorithms have been proposed [RFC3708], [SK04] that could work together with the Eifel response algorithm.
Eifel响应算法依赖于检测算法，如[RFC3522]中定义的Eifel检测算法。该文件包含可能对Eifel响应算法实施者有用的信息背景和动机背景，但实施Eifel响应算法不需要阅读[RFC3522]。注意，已经提出了替代响应算法[BA02]，该算法也可以依赖Eifel检测算法，并且已经提出了替代检测算法[RFC3708]，[SK04]，该算法可以与Eifel响应算法一起工作。
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid
基于适当的检测算法，Eifel响应算法为TCP发送方响应检测到的虚假超时提供了一种方法。它调整重传计时器以避免
further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
进一步的虚假超时和（取决于检测算法）可以避免通常不必要的回退N重传，否则将被发送。此外，Eifel响应算法以避免分组突发的方式恢复拥塞控制状态。
Note: A previous version of the Eifel response algorithm also included a response to a detected spurious fast retransmit. However, as a consensus was not reached about how to adapt the duplicate acknowledgement threshold in that case, that part of the algorithm was removed for the time being.
注：以前版本的Eifel响应算法还包括对检测到的虚假快速重传的响应。然而，在这种情况下，由于没有就如何调整重复确认阈值达成共识，因此暂时删除了算法的这一部分。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
We refer to the first-time transmission of an octet as the 'original transmit'. A subsequent transmission of the same octet is referred to as a 'retransmit'. In most cases, this terminology can also be applied to data segments. However, when repacketization occurs, a segment can contain both first-time transmissions and retransmissions of octets. In that case, this terminology is only consistent when applied to octets. For the Eifel detection and response algorithms, this makes no difference, as they also operate correctly when repacketization occurs.
我们将八位字节的首次传输称为“原始传输”。同一八位组的后续传输称为“重传”。在大多数情况下，此术语也可以应用于数据段。然而，当发生重新打包时，一个段可以包含八位字节的首次传输和重新传输。在这种情况下，这个术语只有在应用于八位字节时才是一致的。对于Eifel检测和响应算法，这没有什么区别，因为它们在重新打包时也能正确运行。
We use the term 'acceptable ACK' as defined in [RFC793]. That is an ACK that acknowledges previously unacknowledged data. We use the term 'bytes_acked' to refer to the amount (in terms of octets) of previously unacknowledged data that is acknowledged by the most recently received acceptable ACK. We use the TCP sender state variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA holds the segment sequence number of the oldest outstanding segment. SND.NXT holds the segment sequence number of the next segment the TCP sender will (re-)transmit. In addition, we define as 'SND.MAX' the segment sequence number of the next original transmit to be sent. The definition of SND.MAX is equivalent to the definition of 'snd_max' in [WS95].
我们使用[RFC793]中定义的术语“可接受的确认”。这是一个确认以前未确认的数据的应答。我们使用术语“bytes_Acknowed”来指由最近接收到的可接受ACK确认的先前未确认数据的数量（以八位字节为单位）。我们使用[RFC793]中定义的TCP发送方状态变量“SND.UNA”和“SND.NXT”。SND.UNA保存最早未完成段的段序列号。SND.NXT保存TCP发送方将（重新）传输的下一段的段序列号。此外，我们将要发送的下一个原始传输的段序列号定义为“SND.MAX”。SND.MAX的定义等同于[WS95]中“SND_MAX”的定义。
We use the TCP sender state variables 'cwnd' (congestion window), and 'ssthresh' (slow-start threshold), and the term 'FlightSize' as defined in [RFC2581]. FlightSize is the amount (in terms of octets) of outstanding data at a given point in time. We use the term 'Initial Window' (IW) as defined in [RFC3390]. The IW is the size of the sender's congestion window after the three-way handshake is completed. We use the TCP sender state variables 'SRTT' and
我们使用TCP发送方状态变量“cwnd”（拥塞窗口）和“ssthresh”（慢启动阈值）以及[RFC2581]中定义的术语“FlightSize”。FlightSize是给定时间点上未完成数据的数量（以八位字节为单位）。我们使用[RFC3390]中定义的术语“初始窗口”（IW）。IW是三方握手完成后发送方拥塞窗口的大小。我们使用TCP发送方状态变量“SRTT”和
'RTTVAR', and the terms 'RTO' and 'G' as defined in [RFC2988]. G is the clock granularity of the retransmission timer. In addition, we assume that the TCP sender maintains the value of the latest round-trip time (RTT) measurement in the (local) variable 'RTT-SAMPLE'.
“RTTVAR”，以及[RFC2988]中定义的术语“RTO”和“G”。G是重传计时器的时钟粒度。此外，我们假设TCP发送方在（本地）变量“RTT-SAMPLE”中维护最新往返时间（RTT）测量值。
We use the TCP sender state variable 'T_last', and the term 'tcpnow' as used in [RFC2861]. T_last holds the system time when the TCP sender sent the last data segment, whereas tcpnow is the TCP sender's current system time.
我们使用TCP发送方状态变量“T_last”，以及[RFC2861]中使用的术语“tcpnow”。T_last保存TCP发送方发送最后一个数据段时的系统时间，而tcpnow是TCP发送方的当前系统时间。
If the Eifel response algorithm is implemented at the TCP sender, it MUST be implemented together with a detection algorithm that is specified in a standards track or experimental RFC.
如果Eifel响应算法在TCP发送方实现，则必须与标准跟踪或实验RFC中指定的检测算法一起实现。
Designers of detection algorithms who want their algorithms to work together with the Eifel response algorithm should reuse the variable "SpuriousRecovery" with the semantics and defined values specified in [RFC3522]. In addition, we define the constant LATE_SPUR_TO (set equal to -1) as another possible value of the variable SpuriousRecovery. Detection algorithms should set the value of SpuriousRecovery to LATE_SPUR_TO if the detection of a spurious retransmit is based on the ACK for the retransmit (as opposed to an ACK for an original transmit). For example, this applies to detection algorithms that are based on the DSACK option [RFC3708].
如果检测算法的设计者希望其算法与Eifel响应算法协同工作，则应使用[RFC3522]中规定的语义和定义值重新使用变量“伪恢复”。此外，我们将常数LATE_SPUR_TO（设置为-1）定义为变量SpusioRecovery的另一个可能值。如果虚假重传的检测基于重传的ACK（与原始传输的ACK相反），则检测算法应将虚假恢复的值设置为LATE_SPUR_。例如，这适用于基于DSACK选项[RFC3708]的检测算法。
The complete algorithm is specified in section 3.1. In sections 3.2 - 3.6, we discuss the different steps of the algorithm.
第3.1节规定了完整的算法。在第3.2-3.6节中，我们讨论了算法的不同步骤。
Given that a TCP sender has enabled a detection algorithm that complies with the requirements set in Section 2, a TCP sender MAY use the Eifel response algorithm as defined in this subsection.
鉴于TCP发送方启用了符合第2节要求的检测算法，TCP发送方可以使用本小节中定义的Eifel响应算法。
If the Eifel response algorithm is used, the following steps MUST be taken by the TCP sender, but only upon initiation of a timeout-based loss recovery. That is when the first timeout-based retransmit is sent. The algorithm MUST NOT be reinitiated after a timeout-based loss recovery has already been started but not completed. In particular, it may not be reinitiated upon subsequent timeouts for the same segment, or upon retransmitting segments other than the oldest outstanding segment.
如果使用Eifel响应算法，TCP发送方必须执行以下步骤，但仅在启动基于超时的丢失恢复时执行。即发送第一次基于超时的重传时。基于超时的丢失恢复已启动但尚未完成后，不得重新初始化算法。特别是，在同一段的后续超时时，或在重新传输除最旧未完成段以外的段时，可能不会重新初始化。
(0) Before the variables cwnd and ssthresh get updated when loss recovery is initiated, set a "pipe_prev" variable as follows: pipe_prev <- max (FlightSize, ssthresh)
(0) 在启动损失恢复时更新变量cwnd和ssthresh之前，按如下方式设置“pipe_prev”变量：pipe_prev<-max（FlightSize，ssthresh）
Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as follows: SRTT_prev <- SRTT + (2 * G) RTTVAR_prev <- RTTVAR
设置一个“SRTT_prev”变量和一个“RTTVAR_prev”变量如下：SRTT_prev<-SRTT+（2*G）RTTVAR_prev<-RTTVAR
(DET) This is a placeholder for a detection algorithm that must be executed at this point, and that sets the variable SpuriousRecovery as outlined in Section 2. If [RFC3522] is used as the detection algorithm, steps (1) - (6) of that algorithm go here.
（DET）这是此时必须执行的检测算法的占位符，用于设置第2节中概述的变量SpusiousRecovery。如果使用[RFC3522]作为检测算法，则该算法的步骤（1）-（6）如下所示。
(7) If SpuriousRecovery equals SPUR_TO, then proceed to step (8);
(7) 如果伪恢复等于SPUR_TO，则转至步骤（8）；
else if SpuriousRecovery equals LATE_SPUR_TO, then proceed to step (9);
否则，如果伪恢复等于延迟刺激，则继续步骤（9）；
else proceed to step (DONE).
否则继续执行步骤（完成）。
(8) Resume the transmission with previously unsent data:
(8) 使用以前未发送的数据恢复传输：
Set SND.NXT <- SND.MAX
设置SND.NXT<-SND.MAX
(9) Reverse the congestion control state:
(9) 反转拥塞控制状态：
If the acceptable ACK has the ECN-Echo flag [RFC3168] set, then proceed to step (DONE);
如果可接受的ACK设置了ECN回波标志[RFC3168]，则进入步骤（完成）；
else set cwnd <- FlightSize + min (bytes_acked, IW) ssthresh <- pipe_prev
否则设置cwnd<-FlightSize+min（已确认字节，IW）ssthresh<-pipe\U prev
Proceed to step (DONE).
转至步骤（完成）。
(10) Interworking with Congestion Window Validation:
（10） 与拥塞窗口验证的交互：
If congestion window validation is implemented according to [RFC2861], then set T_last <- tcpnow
如果根据[RFC2861]执行拥塞窗口验证，则设置T_last<-tcpnow
(11) Adapt the conservativeness of the retransmission timer:
（11） 调整重传计时器的保守性：
Upon the first RTT-SAMPLE taken from new data; i.e., the first RTT-SAMPLE that can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred,
从新数据中获取第一个RTT样本时；i、 例如，第一个RTT-SAMPLE，它可以从一个可接受的ACK中导出，该ACK用于在伪超时发生时先前未发送的数据，
if the retransmission timer is implemented according to [RFC2988], then set SRTT <- max (SRTT_prev, RTT-SAMPLE) RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2) RTO <- SRTT + max (G, 4*RTTVAR)
如果根据[RFC2988]实现重传计时器，则设置SRTT<-max（SRTT_-prev，RTT-SAMPLE）RTTVAR<-max（RTTVAR_-prev，RTT-SAMPLE/2）RTO<-SRTT+max（G，4*RTTVAR）
Run the bounds check on the RTO (rules (2.4) and (2.5) in [RFC2988]), and restart the retransmission timer;
在RTO上运行边界检查（规则[RFC2988]中的（2.4）和（2.5）），并重新启动重传计时器；
else appropriately adapt the conservativeness of the retransmission timer that is implemented.
else appropriately adapt the conservativeness of the retransmission timer that is implemented.translate error, please retry
(DONE) No further processing.
（完成）无需进一步处理。
The TCP sender stores in pipe_prev what is considered a safe slow-start threshold (ssthresh) before loss recovery is initiated; i.e., before the loss indication is taken into account. This is either the current FlightSize, if the TCP sender is in congestion avoidance, or the current ssthresh, if the TCP sender is in slow-start. If the TCP sender later detects that it has entered loss recovery unnecessarily, then pipe_prev is used in step (9) to reverse the congestion control state. Thus, until the loss recovery phase is terminated, pipe_prev maintains a memory of the congestion control state of the time right before the loss recovery phase was initiated. A similar approach is proposed in [RFC2861], where this state is stored in ssthresh directly after a TCP sender has become idle or application limited.
TCP发送方在启动丢失恢复之前，将安全慢启动阈值（ssthresh）存储在pipe_prev中；i、 e.在考虑损失指示之前。如果TCP发送方处于拥塞避免状态，则为当前FlightSize；如果TCP发送方处于慢速启动状态，则为当前ssthresh。如果TCP发送方后来检测到它不必要地进入了丢失恢复，则在步骤（9）中使用pipe_prev来反转拥塞控制状态。因此，在丢失恢复阶段终止之前，pipe_prev将保留丢失恢复阶段启动之前的阻塞控制状态的内存。[RFC2861]中提出了类似的方法，在TCP发送方空闲或应用程序受限后，该状态直接存储在ssthresh中。
There had been debates about whether the value of pipe_prev should be decayed over time; e.g., upon subsequent timeouts for the same outstanding segment. We do not require decaying pipe_prev for the Eifel response algorithm and do not believe that such a conservative approach should be in place. Instead, we follow the idea of revalidating the congestion window through slow-start, as suggested in [RFC2861]. That is, in step (9), the cwnd is reset to a value that avoids large packet bursts, and ssthresh is reset to the value of pipe_prev. Note that [RFC2581] and [RFC2861] also do not require
关于pipe_prev的价值是否应该随着时间的推移而衰减，一直存在争论；e、 例如，在同一未完成段的后续超时时。对于Eifel响应算法，我们不需要衰减的pipe_prev，也不认为应该采用这种保守的方法。相反，我们按照[RFC2861]中的建议，通过慢速启动重新验证拥塞窗口。即，在步骤（9）中，将cwnd重置为避免大数据包突发的值，并且将ssthresh重置为pipe_prev的值。注意，[RFC2581]和[RFC2861]也不需要
a decaying of ssthresh after it has been reset in response to a loss indication, or after a TCP sender has become idle or application limited.
在响应丢失指示而重置ssthresh后，或TCP发送器空闲或应用程序受限后，ssthresh的衰减。
Without the use of the TCP timestamps option [RFC1323], the TCP sender suffers from the retransmission ambiguity problem [Zh86], [KP87]. Therefore, when the first acceptable ACK arrives after a spurious timeout, the TCP sender must assume that this ACK was sent in response to the retransmit when in fact it was sent in response to an original transmit. Furthermore, the TCP sender must further assume that all other segments that were outstanding at that point were lost.
如果不使用TCP时间戳选项[RFC1323]，TCP发送方会遇到重传模糊问题[Zh86]，[KP87]。因此，当第一个可接受的ACK在虚假超时后到达时，TCP发送方必须假设此ACK是响应重新传输而发送的，而实际上它是响应原始传输而发送的。此外，TCP发送方必须进一步假设在该点上未完成的所有其他段都丢失了。
Note: Except for certain cases where original ACKs were lost, the first acceptable ACK cannot carry a DSACK option [RFC2883].
注：除了原始ACK丢失的某些情况外，第一个可接受的ACK不能带有DSACK选项[RFC2883]。
Consequently, once the TCP sender's state has been updated after the first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is what causes the often unnecessary go-back-N retransmits. From that point on every arriving acceptable ACK that was sent in response to an original transmit will advance SND.NXT. But as long as SND.NXT is smaller than the value that SND.MAX had when the timeout occurred, those ACKs will clock out retransmits, whether or not the corresponding original transmits were lost.
因此，一旦TCP发送方的状态在第一个可接受的ACK到达后被更新，SND.NXT等于SND.UNA。这就是导致经常不必要的回退N重传的原因。从这一点开始，为响应原始传输而发送的每个到达的可接受ACK将前进SND.NXT。但是，只要SND.NXT小于发生超时时SND.MAX的值，这些ack就将取消重新传输，无论相应的原始传输是否丢失。
In fact, during this phase the TCP sender breaks 'packet conservation' [Jac88]. This is because the go-back-N retransmits are sent during slow-start. For each original transmit leaving the network, two retransmits are sent into the network as long as SND.NXT does not equal SND.MAX (see [LK00] for more detail).
事实上，在这个阶段，TCP发送方破坏了“数据包保护”[Jac88]。这是因为回退N重传是在慢启动期间发送的。对于离开网络的每个原始传输，只要SND.NXT不等于SND.MAX（有关更多详细信息，请参见[LK00]），就会向网络发送两次重传。
Once a spurious timeout has been detected (upon receipt of an ACK for an original transmit), it is safe to let the TCP sender resume the transmission with previously unsent data. Thus, the Eifel response algorithm changes the TCP sender's state by setting SND.NXT to SND.MAX. Note that this step is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a detection algorithm such as the Eifel detection algorithm [RFC3522] or the F-RTO algorithm [SK04] that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
一旦检测到虚假超时（在收到原始传输的ACK后），可以安全地让TCP发送方使用以前未发送的数据恢复传输。因此，Eifel响应算法通过将SND.NXT设置为SND.MAX来更改TCP发送方的状态。注意，该步骤仅在变量SpurousRecovery等于SPUR_TO时执行，这反过来需要检测算法，如Eifel检测算法[RFC3522]或F-RTO算法[SK04]，该算法基于接收原始传输的ACK来检测虚假重传（与重传的ACK[RFC3708]相反）.
When a TCP sender enters loss recovery, it reduces cwnd and ssthresh. However, once the TCP sender detects that the loss recovery has been falsely triggered, this reduction proves unnecessary. We therefore believe that it is safe to revert to the previous congestion control state, following the approach of revalidating the congestion window as outlined below. This is unless the acceptable ACK signals congestion through the ECN-Echo flag [RFC3168]. In that case, the TCP sender MUST refrain from reversing congestion control state.
当TCP发送方进入丢失恢复时，它会减少cwnd和ssthresh。但是，一旦TCP发送方检测到错误触发了丢失恢复，则证明这种减少是不必要的。因此，我们认为，按照下述重新验证拥塞窗口的方法，恢复到以前的拥塞控制状态是安全的。这是除非可接受的ACK通过ECN回波标志[RFC3168]发出拥塞信号。在这种情况下，TCP发送方必须避免反转拥塞控制状态。
If the ECN-Echo flag is not set, cwnd is reset to the sum of the current FlightSize and the minimum of bytes_acked and IW. In some cases, this can mean that the first few acceptable ACKs that arrive will not clock out any data segments. Recall that bytes_acked is the number of bytes that have been acknowledged by the acceptable ACK. Note that the value of cwnd must not be changed any further for that ACK, and that the value of FlightSize at this point in time may be different from the value of FlightSize in step (0). The value of IW puts a limit on the size of the packet burst that the TCP sender may send into the network after the Eifel response algorithm has terminated. The value of IW is considered an acceptable burst size. It is the amount of data that a TCP sender may send into a yet "unprobed" network at the beginning of a connection.
如果未设置ECN Echo标志，cwnd将重置为当前FlightSize与已确认字节和IW的最小字节之和。在某些情况下，这可能意味着到达的前几个可接受的ack不会打卡任何数据段。回想一下，bytes_acked是可接受的ACK已确认的字节数。请注意，对于该ACK，不得进一步更改cwnd的值，并且此时的FlightSize的值可能不同于步骤（0）中的FlightSize的值。IW的值限制了TCP发送方在Eifel响应算法终止后可能发送到网络中的数据包突发的大小。IW的值被认为是可接受的突发大小。它是TCP发送方在连接开始时可能发送到尚未“未绑定”网络的数据量。
Then ssthresh is reset to the value of pipe_prev. As a result, the TCP sender either immediately resumes probing the network for more bandwidth in congestion avoidance, or it slow-starts to what is considered a safe operating point for the congestion window.
然后将ssthresh重置为pipe_prev的值。因此，TCP发送方要么立即恢复探测网络以获得更多带宽以避免拥塞，要么缓慢启动到拥塞窗口的安全工作点。
An implementation of the Congestion Window Validation (CWV) algorithm [RFC2861] could potentially misinterpret a delay spike that caused a spurious timeout as a phase where the TCP sender had been idle. Therefore, T_last is reset to prevent the triggering of the CWV algorithm in this case.
拥塞窗口验证（CWV）算法[RFC2861]的实现可能会将导致虚假超时的延迟峰值误解为TCP发送方空闲的阶段。因此，T_last被重置，以防止在这种情况下触发CWV算法。
Note: The term 'idle' implies that the TCP sender has no data outstanding; i.e., all data sent has been acknowledged [Jac88]. According to this definition, a TCP sender is not idle while it is waiting for an acceptable ACK after a timeout. Unfortunately, the pseudo-code in [RFC2861] does not include a check for the condition "idle" (SND.UNA == SND.MAX). We therefore had to add step (10) to the Eifel response algorithm.
注意：术语“空闲”表示TCP发送方没有未处理的数据；i、 例如，已确认发送的所有数据[Jac88]。根据此定义，TCP发送方在超时后等待可接受的ACK时不是空闲的。不幸的是，[RFC2861]中的伪代码没有包括对条件“idle”（SND.UNA==SND.MAX）的检查。因此，我们必须将步骤（10）添加到Eifel响应算法中。
There is currently only one retransmission timer standardized for TCP [RFC2988]. We therefore only address that timer explicitly. Future standards that might define alternatives to [RFC2988] should propose similar measures to adapt the conservativeness of the retransmission timer.
目前只有一个标准化的TCP重新传输计时器[RFC2988]。因此，我们只显式地处理该计时器。可能定义[RFC2988]替代方案的未来标准应提出类似措施，以适应重传计时器的保守性。
A spurious timeout often results from a delay spike, which is a sudden increase of the RTT that usually cannot be predicted. After a delay spike, the RTT may have changed permanently; e.g., due to a path change, or because the available bandwidth on a bandwidth-dominated path has decreased. This may often occur with wide-area wireless access links. In this case, the RTT estimators (SRTT and RTTVAR) should be reinitialized from the first RTT-SAMPLE taken from new data according to rule (2.2) of [RFC2988]. That is, from the first RTT-SAMPLE that can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
虚假超时通常由延迟尖峰引起，这是RTT的突然增加，通常无法预测。在延迟尖峰之后，RTT可能已经永久改变；e、 例如，由于路径改变，或者由于带宽占主导地位的路径上的可用带宽减少。这通常会发生在广域无线接入链路上。在这种情况下，RTT估计器（SRTT和RTTVAR）应根据[RFC2988]的规则（2.2）从新数据中获取的第一个RTT样本重新初始化。也就是说，从第一个RTT-SAMPLE开始，该RTT-SAMPLE可以从之前在伪超时发生时未发送的数据的可接受ACK中派生。
However, a delay spike may only indicate a transient phase, after which the RTT returns to its previous range of values, or even to smaller values. Also, a spurious timeout may occur because the TCP sender's RTT estimators were only inaccurate enough that the retransmission timer expires "a tad too early". We believe that two times the clock granularity of the retransmission timer (2 * G) is a reasonable upper bound on "a tad too early". Thus, when the new RTO is calculated in step (11), we ensure that it is at least (2 * G) greater (see also step (0)) than the RTO was before the spurious timeout occurred.
然而，延迟尖峰可能仅指示瞬态阶段，在此之后RTT返回到其先前的值范围，甚至更小的值。此外，由于TCP发送方的RTT估计器不够准确，导致重传计时器“稍微提前”过期，因此可能会出现虚假超时。我们认为，重传定时器的时钟粒度（2*G）的两倍是“有点太早”的合理上限。因此，当在步骤（11）中计算新的RTO时，我们确保它至少比伪超时发生之前的RTO大（2*G）（另请参见步骤（0））。
Note that other TCP sender processing will usually take place between steps (10) and (11). During this phase (i.e., before step (11) has been reached), the RTO is managed according to the rules of [RFC2988]. We believe that this is sufficiently conservative for the following reasons. First, the retransmission timer is restarted upon the acceptable ACK that was used to detect the spurious timeout. As a result, the delay spike is already implicitly factored in for segments outstanding at that time. This is discussed in more detail in [EL04], where this effect is called the "RTO offset". Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE can be derived from that acceptable ACK. This RTT-SAMPLE must be relatively large, as it includes the delay spike that caused the spurious timeout. Consequently, the RTT estimators will be updated rather conservatively. Without timestamps the RTO will stay conservatively backed-off due to Karn's algorithm [RFC2988] until the first RTT-SAMPLE can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
请注意，其他TCP发送方处理通常在步骤（10）和（11）之间进行。在此阶段（即，在达到步骤（11）之前），根据[RFC2988]的规则管理RTO。我们认为这是足够保守的，原因如下。首先，重传计时器在用于检测虚假超时的可接受ACK时重新启动。因此，对于当时未完成的段，延迟尖峰已经隐含地考虑在内。[EL04]对此进行了更详细的讨论，其中这种影响称为“RTO偏移”。此外，如果启用了时间戳，则可以从该可接受的ACK导出新的有效RTT-SAMPLE。此RTT样本必须相对较大，因为它包括导致虚假超时的延迟峰值。因此，RTT估算值将进行相当保守的更新。在没有时间戳的情况下，由于Karn的算法[RFC2988]，RTO将保持保守的后退，直到第一个RTT-SAMPLE可以从一个可接受的ACK中得到，该ACK用于发生虚假超时时之前未发送的数据。
For the new RTO to become effective, the retransmission timer has to be restarted. This is consistent with [RFC2988], which recommends restarting the retransmission timer with the arrival of an acceptable ACK.
要使新RTO生效，必须重新启动重传计时器。这与[RFC2988]一致，后者建议在到达可接受的ACK时重新启动重传计时器。
We have studied environments where spurious timeouts and multiple losses from the same flight of packets often coincide [GL02], [GL03]. In such a case, the oldest outstanding segment arrives at the TCP receiver, but one or more packets from the remaining outstanding flight are lost. In those environments, end-to-end performance suffers if the Eifel response algorithm is operated without an advanced loss recovery scheme such as a SACK-based scheme [RFC3517] or NewReno [RFC3782]. The reason is TCP-Reno's aggressiveness after a spurious timeout. Even though TCP-Reno breaks 'packet conservation' (see Section 3.3) when blindly retransmitting all outstanding segments, it usually recovers all packets lost from that flight within a single round-trip time. On the contrary, the more conservative TCP-Reno-with-Eifel is often forced into another timeout. Thus, we recommend that the Eifel response algorithm always be operated in combination with [RFC3517] or [RFC3782]. Additional robustness is achieved with the Limited Transmit and Early Retransmit algorithms [RFC3042], [AAAB04].
我们研究了假超时和来自同一数据包传输的多个丢失经常重合的环境[GL02]，[GL03]。在这种情况下，最早的未完成段到达TCP接收器，但来自剩余未完成航班的一个或多个数据包丢失。在这些环境中，如果Eifel响应算法在没有高级损失恢复方案（如基于SACK的方案[RFC3517]或NewReno[RFC3782]）的情况下运行，则端到端性能会受到影响。原因是TCP雷诺在假暂停后的攻击性。尽管TCP Reno在盲目地重新传输所有未完成的段时会破坏“数据包保护”（见第3.3节），但它通常会在一次往返时间内恢复该航班丢失的所有数据包。相反，使用Eifel的更保守的TCP Reno通常会被迫进入另一个超时。因此，我们建议Eifel响应算法始终与[RFC3517]或[RFC3782]结合使用。通过有限的传输和早期重传算法[RFC3042]、[AAAB04]实现了额外的鲁棒性。
Note: The SACK-based scheme we used for our simulations in [GL02] and [GL03] is different from the SACK-based scheme that later got standardized [RFC3517]. The key difference is that [RFC3517] is more robust to multiple losses from the same flight. It is less conservative in declaring that a packet has left the network, and is therefore less dependent on timeouts to recover genuine packet losses.
注：我们在[GL02]和[GL03]中用于模拟的基于SACK的方案不同于后来标准化的基于SACK的方案[RFC3517]。关键区别在于[RFC3517]对同一航班的多次损失更为稳健。它在声明数据包已离开网络时不太保守，因此不太依赖超时来恢复真正的数据包丢失。
If the NewReno algorithm [RFC3782] is used in combination with the Eifel response algorithm, step (1) of the NewReno algorithm SHOULD be modified as follows, but only if SpuriousRecovery equals SPUR_TO:
如果NewReno算法[RFC3782]与Eifel响应算法结合使用，则NewReno算法的步骤（1）应修改如下，但前提是伪恢复等于SPUR_至：
(1) Three duplicate ACKs: When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, go to step 1A.
(1) 三次重复确认：当收到第三次重复确认且发送方尚未处于快速恢复过程中时，转至步骤1A。
That is, the entire step 1B of the NewReno algorithm is obsolete because step (8) of the Eifel response algorithm avoids the case where three duplicate ACKs result from unnecessary go-back-N retransmits after a timeout. Step (8) of the Eifel response algorithm avoids such unnecessary go-back-N retransmits in the first place. However, recall that step (8) is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a
也就是说，NewReno算法的整个步骤1B是过时的，因为Eifel响应算法的步骤（8）避免了超时后不必要的回退N重传导致三个重复ack的情况。Eifel响应算法的步骤（8）首先避免了这种不必要的回退N重传。然而，回想一下，步骤（8）仅在变量SpurousRecovery等于SPUR_TO时执行，这反过来需要
detection algorithm, such as the Eifel detection algorithm [RFC3522] or the F-RTO algorithm [SK04], that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
检测算法，例如Eifel检测算法[RFC3522]或F-RTO算法[SK04]，其基于接收到原始传输的ACK（与重传的ACK[RFC3708]相反）来检测虚假重传。
There is a risk that a detection algorithm is fooled by spoofed ACKs that make genuine retransmits appear to the TCP sender as spurious retransmits. When such a detection algorithm is run together with the Eifel response algorithm, this could effectively disable congestion control at the TCP sender. Should this become a concern, the Eifel response algorithm SHOULD only be run together with detection algorithms that are known to be safe against such "ACK spoofing attacks".
存在检测算法被欺骗的风险，欺骗的ack使真正的重传在TCP发送方看来是虚假的重传。当这种检测算法与Eifel响应算法一起运行时，可以有效地禁用TCP发送方的拥塞控制。如果这成为一个问题，Eifel响应算法应仅与已知可安全抵御此类“ACK欺骗攻击”的检测算法一起运行。
For example, the safe variant of the Eifel detection algorithm [RFC3522], is a reliable method to protect against this risk.
例如，Eifel检测算法[RFC3522]的安全变体是防止这种风险的可靠方法。
Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions that contributed to this work.
非常感谢Keith Sklower、Randy Katz、Michael Meyer、Stephan Baucke、Sally Floyd、Vern Paxson、Mark Allman、Ethan Blanton、Pasi Sarolahti、Alexey Kuznetsov和Yogesh Swami为这项工作所做的许多讨论。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]Floyd，S.，Henderson，T.，和A.Gurtov，“TCP快速恢复算法的NewReno修改”，RFC 3782，2004年4月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]Handley，M.，Padhye，J.，和S.Floyd，“TCP拥塞窗口验证”，RFC 28612000年6月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.，和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[AAAB04] Allman, M., Avrachenkov, K., Ayesta, U., and J. Blanton, Early Retransmit for TCP and SCTP, Work in Progress, July 2004.
[AAAB04]Allman，M.，Avrachenkov，K.，Ayesta，U.，和J.Blanton，TCP和SCTP的早期重传，正在进行的工作，2004年7月。
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to Packet Reordering, ACM Computer Communication Review, Vol. 32, No. 1, January 2002.
[BA02]Blanton，E.和M.Allman，关于使TCP对数据包重新排序更具鲁棒性，ACM计算机通信评论，第32卷，第1期，2002年1月。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, February 2004.
[RFC3708]Blanton，E.和M.Allman，“使用TCP重复选择确认（DSACKs）和流控制传输协议（SCTP）重复传输序列号（TSN）来检测虚假重传”，RFC 3708，2004年2月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[EL04] Ekstrom, H. and R. Ludwig, The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport, In Proceedings of IEEE INFOCOM 04, March 2004.
[EL04]Ekstrom，H.和R.Ludwig，《峰值漏斗：用于可靠单播传输的新端到端重传计时器》，载于《IEEE信息通信学报》，2004年3月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm for TCP in a GPRS Network, In Proceedings of the European Wireless Conference, February 2002.
[GL02]Gurtov，A.和R.Ludwig，评估GPRS网络中TCP的Eifel算法，欧洲无线会议论文集，2002年2月。
[GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts in TCP, In Proceedings of IEEE INFOCOM 03, April 2003.
[GL03]Gurtov，A.和R.Ludwig，回应TCP中的虚假超时，发表于《IEEE信息通信会议录》，2003年4月。
[Jac88] Jacobson, V., Congestion Avoidance and Control, In Proceedings of ACM SIGCOMM 88.
[Jac88]Jacobson，V.，拥塞避免和控制，ACM SIGCOMM 88诉讼。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[KP87] Karn, P. and C. Partridge, Improving Round-Trip Time Estimates in Reliable Transport Protocols, In Proceedings of ACM SIGCOMM 87.
[KP87]Karn，P.和C.Partridge，《改进可靠传输协议中的往返时间估计》，载于ACM SIGCOMM 87会议录。
[LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions, ACM Computer Communication Review, Vol. 30, No. 1, January 2000.
[LK00]Ludwig，R.和R.H.Katz，《Eifel算法：使TCP对伪重传具有鲁棒性》，ACM计算机通信评论，第30卷，第1期，2000年1月。
[SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP, Work in Progress, November 2004.
[SK04]Sarolahti，P.和M.Kojo，F-RTO：使用TCP和SCTP检测虚假重传超时的算法，正在进行的工作，2004年11月。
[WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, Volume 2 (The Implementation), Addison Wesley, January 1995.
[WS95]Wright，G.R.和W.R.Stevens，TCP/IP图解，第2卷（实现），Addison-Wesley，1995年1月。
[Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings of ACM SIGCOMM 88.
[Zh86]Zhang，L.，为什么TCP定时器不能很好地工作，在ACM SIGCOM88会议记录中。
Authors' Addresses
作者地址
Reiner Ludwig Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath, Germany
Reiner Ludwig Ericsson Research（EDD）爱立信Allee 1 52134 Herzogenrath，德国
EMail: Reiner.Ludwig@ericsson.com
EMail: Reiner.Ludwig@ericsson.com
Andrei Gurtov Helsinki Institute for Information Technology (HIIT) P.O. Box 9800, FIN-02015 HUT, Finland
Andrei Gurtov赫尔辛基信息技术研究所（HIIT）邮政信箱9800，芬兰FIN-02015小屋
EMail: andrei.gurtov@cs.helsinki.fi
Homepage: http://www.cs.helsinki.fi/u/gurtov
EMail: andrei.gurtov@cs.helsinki.fi
Homepage: http://www.cs.helsinki.fi/u/gurtov
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。