Network Working Group P. Sarolahti
Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki
August 2005
Network Working Group P. Sarolahti
Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki
August 2005
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
前向RTO恢复（F-RTO）：一种使用TCP和流控制传输协议（SCTP）检测虚假重传超时的算法
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP).
虚假的重新传输超时会导致次优的TCP性能，因为它们通常会导致不必要地重新传输最后一个数据窗口。本文档描述了用于检测虚假TCP重传超时的F-RTO检测算法。F-RTO是一种仅限TCP发送方的算法，不需要任何TCP选项即可运行。在重新传输由超时触发的第一个未确认的段后，TCP发送方的F-RTO算法监视传入的确认，以确定超时是否是虚假的。然后决定是发送新段还是重新传输未确认的段。该算法有效地避免了额外的不必要的重传，从而提高了伪超时情况下的TCP性能。F-RTO算法也可以应用于流控制传输协议（SCTP）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . 4
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Algorithm . . . . . . . . . . . . . . . . . . . 5
2.2. Discussion . . . . . . . . . . . . . . . . . . . . 6
3. SACK-Enhanced Version of the F-RTO Algorithm . . . . . . 8
4. Taking Actions after Detecting Spurious RTO . . . . . . . 10
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References. . . . . . . . . . . . . . . . 12
8.2. Informative References. . . . . . . . . . . . . . . 13
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . 15
Appendix B: SACK-Enhanced F-RTO and Fast Recovery . . . . . . 20
Appendix C: Discussion of Window-Limited Cases . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . 4
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Algorithm . . . . . . . . . . . . . . . . . . . 5
2.2. Discussion . . . . . . . . . . . . . . . . . . . . 6
3. SACK-Enhanced Version of the F-RTO Algorithm . . . . . . 8
4. Taking Actions after Detecting Spurious RTO . . . . . . . 10
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References. . . . . . . . . . . . . . . . 12
8.2. Informative References. . . . . . . . . . . . . . . 13
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . 15
Appendix B: SACK-Enhanced F-RTO and Fast Recovery . . . . . . 20
Appendix C: Discussion of Window-Limited Cases . . . . . . . 21
The Transmission Control Protocol (TCP) [Pos81] has two methods for triggering retransmissions. First, the TCP sender relies on incoming duplicate ACKs, which indicate that the receiver is missing some of the data. After a required number of successive duplicate ACKs have arrived at the sender, it retransmits the first unacknowledged segment [APS99] and continues with a loss recovery algorithm such as NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the TCP sender maintains a retransmission timer which triggers retransmission of segments, if they have not been acknowledged before the retransmission timeout (RTO) expires. When the retransmission timeout occurs, the TCP sender enters the RTO recovery where the congestion window is initialized to one segment and unacknowledged segments are retransmitted using the slow-start algorithm. The retransmission timer is adjusted dynamically, based on the measured round-trip times [PA00].
传输控制协议（TCP）[Pos81]有两种触发重传的方法。首先，TCP发送方依赖于传入的重复ACK，这表明接收方丢失了一些数据。在所需数量的连续重复确认到达发送方后，它将重新传输第一个未确认的段[APS99]，并继续使用丢失恢复算法，如NewReno[FHG04]或基于SACK的丢失恢复[BAFW03]。其次，TCP发送方维护一个重传计时器，如果在重传超时（RTO）到期之前未确认段，则该计时器将触发段的重传。当发生重新传输超时时，TCP发送方进入RTO恢复，其中拥塞窗口初始化为一个段，未确认的段使用慢启动算法重新传输。根据测量的往返时间[PA00]，动态调整重传计时器。
It has been pointed out that the retransmission timer can expire spuriously and cause unnecessary retransmissions when no segments have been lost [LK00, GL02, LM03]. After a spurious retransmission timeout, the late acknowledgments of the original segments arrive at the sender, usually triggering unnecessary retransmissions of a whole window of segments during the RTO recovery. Furthermore, after a spurious retransmission timeout, a conventional TCP sender increases the congestion window on each late acknowledgment in slow start. This injects a large number of data segments into the network within one round-trip time, thus violating the packet conservation principle [Jac88].
已经指出，当没有丢失任何段时，重传定时器可能会错误地过期并导致不必要的重传[LK00，GL02，LM03]。在伪重传超时之后，原始段的延迟确认到达发送方，通常在RTO恢复期间触发整个段窗口的不必要重传。此外，在伪重传超时之后，传统TCP发送方在慢启动中增加每个延迟确认的拥塞窗口。这会在一个往返时间内将大量数据段注入网络，从而违反数据包保护原则[Jac88]。
There are a number of potential reasons for spurious retransmission timeouts. First, some mobile networking technologies involve sudden delay spikes on transmission because of actions taken during a hand-off. Second, given a low-bandwidth link or some other change in available bandwidth, arrival of competing traffic (possibly with higher priority) can cause a sudden increase of round-trip time. This may trigger a spurious retransmission timeout. A persistently reliable link layer can also cause a sudden delay when a data frame and several retransmissions of it are lost for some reason. This document does not distinguish between the different causes of such a delay spike. Rather, it discusses the spurious retransmission timeouts caused by a delay spike in general.
虚假的重新传输超时有许多潜在原因。首先，一些移动网络技术由于在切换过程中采取的行动而导致传输突然出现延迟峰值。其次，给定低带宽链路或可用带宽的其他变化，竞争流量（可能具有更高优先级）的到达可能会导致往返时间突然增加。这可能会触发虚假的重新传输超时。当一个数据帧及其多次重传因某种原因丢失时，持续可靠的链路层也可能导致突然延迟。本文件不区分此类延迟峰值的不同原因。相反，它讨论了由延迟尖峰引起的伪重传超时。
This document describes the F-RTO detection algorithm. It is based on the detection mechanism of the "Forward RTO-Recovery" (F-RTO) algorithm [SKR03] that is used for detecting spurious retransmission timeouts and thus avoids unnecessary retransmissions following the retransmission timeout. When the timeout is not spurious, the F-RTO algorithm reverts back to the conventional RTO recovery algorithm, and therefore has similar behavior and performance. In contrast to alternative algorithms proposed for detecting unnecessary retransmissions (Eifel [LK00], [LM03] and DSACK-based algorithms [BA04]), F-RTO does not require any TCP options for its operation, and it can be implemented by modifying only the TCP sender. The Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious timeout upon arrival of the first acknowledgment after the retransmission. The DSACK-based algorithms require that the TCP Selective Acknowledgment Option [MMFR96], with the DSACK extension [FMMP00], is in use. With DSACK, the TCP receiver can report if it has received a duplicate segment, enabling the sender to detect afterwards whether it has retransmitted segments unnecessarily. The F-RTO algorithm only attempts to detect and avoid unnecessary retransmissions after an RTO. Eifel and DSACK can also be used for detecting unnecessary retransmissions caused by other events, such as packet reordering.
本文档描述了F-RTO检测算法。它基于“前向RTO恢复”（F-RTO）算法[SKR03]的检测机制，该算法用于检测伪重传超时，从而避免重传超时后不必要的重传。当超时不是伪超时时，F-RTO算法恢复为传统RTO恢复算法，因此具有类似的行为和性能。与用于检测不必要重传的备选算法（Eifel[LK00]、[LM03]和基于DSACK的算法[BA04]）相比，F-RTO的操作不需要任何TCP选项，并且可以通过修改TCP发送方来实现。Eifel算法使用TCP时间戳[BBJ92]在重传后到达第一个确认时检测虚假超时。基于DSACK的算法要求使用TCP选择性确认选项[MMFR96]和DSACK扩展[FMMP00]。通过DSACK，TCP接收方可以报告是否收到了重复的段，从而使发送方能够在事后检测是否不必要地重新传输了段。F-RTO算法仅尝试在RTO后检测并避免不必要的重传。Eifel和DSACK还可用于检测由其他事件（如数据包重新排序）引起的不必要的重新传输。
When an RTO expires, the F-RTO sender retransmits the first unacknowledged segment as usual [APS99]. Deviating from the normal operation after a timeout, it then tries to transmit new, previously unsent data, for the first acknowledgment that arrives after the timeout, given that the acknowledgment advances the window. If the second acknowledgment that arrives after the timeout advances the window (i.e., acknowledges data that was not retransmitted), the F-RTO sender declares the timeout spurious and exits the RTO recovery. However, if either of these two acknowledgments is a duplicate ACK, there will not be sufficient evidence of a spurious timeout. Therefore, the F-RTO sender retransmits the unacknowledged segments in slow start similarly to the traditional algorithm. With a
当RTO过期时，F-RTO发送方会像往常一样重新传输第一个未确认的段[APS99]。与超时后的正常操作不同，它随后尝试传输新的、以前未发送的数据，以用于超时后到达的第一个确认，前提是确认使窗口提前。如果超时后到达的第二次确认使窗口提前（即确认未重新传输的数据），则F-RTO发送方声明超时为伪超时，并退出RTO恢复。但是，如果这两个确认中的任何一个都是重复的确认，则没有足够的证据表明存在虚假超时。因此，与传统算法类似，F-RTO发送方以慢启动方式重新传输未确认的段。用一个
SACK-enhanced version of the F-RTO algorithm, spurious timeouts may be detected even if duplicate ACKs arrive after an RTO retransmission.
SACK增强版的F-RTO算法，即使RTO重新传输后出现重复的ACK，也可能检测到虚假超时。
The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP) [Ste00], because SCTP has acknowledgment and packet retransmission concepts similar to TCP. For convenience, this document mostly refers to TCP, but the algorithms and other discussion are valid for SCTP as well.
F-RTO算法也可应用于流控制传输协议（SCTP）[Ste00]，因为SCTP具有类似于TCP的确认和数据包重传概念。为方便起见，本文档主要涉及TCP，但算法和其他讨论也适用于SCTP。
This document is organized as follows. Section 2 describes the basic F-RTO algorithm. Section 3 outlines an optional enhancement to the F-RTO algorithm that takes advantage of the TCP SACK option. Section 4 discusses the possible actions to be taken after detecting a spurious RTO. Section 5 gives considerations on applying F-RTO with SCTP, and Section 6 discusses the security considerations.
本文件的组织结构如下。第2节描述了基本的F-RTO算法。第3节概述了利用TCP SACK选项对F-RTO算法的可选增强。第4节讨论了检测到虚假RTO后可能采取的措施。第5节给出了在SCTP中应用F-RTO的注意事项，第6节讨论了安全注意事项。
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]中的说明进行解释。
A timeout is considered spurious if it would have been avoided had the sender waited longer for an acknowledgment to arrive [LM03]. F-RTO affects the TCP sender behavior only after a retransmission timeout. Otherwise, the TCP behavior remains the same. When the RTO expires, the F-RTO algorithm monitors incoming acknowledgments and if the TCP sender gets an acknowledgment for a segment that was not retransmitted due to timeout, the F-RTO algorithm declares a timeout spurious. The actions taken in response to a spurious timeout are not specified in this document, but we discuss some alternatives in Section 4. This section introduces the algorithm and then discusses the different steps of the algorithm in more detail.
如果发送方等待确认到达的时间更长，则可以避免超时，则认为超时是虚假的[LM03]。F-RTO仅在重传超时后影响TCP发送方行为。否则，TCP行为将保持不变。当RTO过期时，F-RTO算法将监视传入的确认，如果TCP发送方收到由于超时而未重新传输的段的确认，F-RTO算法将声明一个假超时。本文档中未指定响应虚假超时所采取的操作，但我们将在第4节中讨论一些替代方法。本节介绍了该算法，然后详细讨论了该算法的不同步骤。
Following the practice used with the Eifel Detection algorithm [LM03], we use the "SpuriousRecovery" variable to indicate whether the retransmission is declared spurious by the sender. This variable can be used as an input for a corresponding response algorithm. With F-RTO, the value of SpuriousRecovery can be either SPUR_TO (indicating a spurious retransmission timeout) or FALSE (indicating that the timeout is not declared spurious), and the TCP sender should follow the conventional RTO recovery algorithm.
按照与Eifel检测算法[LM03]一起使用的实践，我们使用“SpusiousRecovery”变量来指示发送方是否宣布重传为虚假。该变量可用作相应响应算法的输入。对于F-RTO，伪恢复的值可以是SPUR_TO（表示伪重传超时）或FALSE（表示超时未声明为伪超时），TCP发送方应遵循传统的RTO恢复算法。
A TCP sender MAY implement the basic F-RTO algorithm. If it chooses to apply the algorithm, the following steps MUST be taken after the retransmission timer expires. If the sender implements some loss recovery algorithm other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT be entered when earlier fast recovery is underway.
TCP发送方可以实现基本的F-RTO算法。如果选择应用该算法，则必须在重传计时器过期后执行以下步骤。如果发送方实施了除Reno或NewReno[FHG04]以外的某些损失恢复算法，则在进行早期快速恢复时不应输入F-RTO算法。
1) When RTO expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. Also, store the highest sequence number transmitted so far in variable "recover".
1) 当RTO过期时，重新传输第一个未确认的段，并将SpusiousRecovery设置为FALSE。此外，将迄今为止传输的最高序列号存储在变量“recover”中。
2) When the first acknowledgment after the RTO retransmission arrives at the sender, the sender chooses one of the following actions, depending on whether the ACK advances the window or whether it is a duplicate ACK.
2) 当RTO重传后的第一个确认到达发送方时，发送方根据ACK是否进入窗口或是否为重复ACK，选择以下操作之一。
a) If the acknowledgment is a duplicate ACK OR it acknowledges a sequence number equal to the value of "recover" OR it does not acknowledge all of the data that was retransmitted in step 1, revert to the conventional RTO recovery and continue by retransmitting unacknowledged data in slow start. Do not enter step 3 of this algorithm. The SpuriousRecovery variable remains as FALSE.
a) 如果确认是一个重复的确认，或者它确认一个等于“recover”值的序列号，或者它不确认在步骤1中重新传输的所有数据，则恢复到传统的RTO恢复，并通过缓慢启动重新传输未确认的数据来继续。不要进入此算法的步骤3。伪恢复变量仍为FALSE。
b) Else, if the acknowledgment advances the window AND it is below the value of "recover", transmit up to two new (previously unsent) segments and enter step 3 of this algorithm. If the TCP sender does not have enough unsent data, it can send only one segment. In addition, the TCP sender MAY override the Nagle algorithm [Nag84] and immediately send a segment if needed. Note that sending two segments in this step is allowed by TCP congestion control requirements [APS99]: An F-RTO TCP sender simply chooses different segments to transmit.
b) 否则，如果确认使窗口提前，并且它低于“恢复”的值，则最多传输两个新的（以前未发送的）段，并进入此算法的步骤3。如果TCP发送方没有足够的未发送数据，它只能发送一个段。此外，TCP发送方可以覆盖Nagle算法[Nag84]，并在需要时立即发送一个段。请注意，TCP拥塞控制要求[APS99]允许在此步骤中发送两个段：F-RTO TCP发送方只需选择不同的段进行传输。
If the TCP sender does not have any new data to send, or the advertised window prohibits new transmissions, the recommended action is to skip step 3 of this algorithm and continue with slow start retransmissions, following the conventional RTO recovery algorithm. However, alternative ways of handling the window-limited cases that could result in better performance are discussed in Appendix C.
如果TCP发送方没有任何新数据要发送，或者播发的窗口禁止新的传输，建议的操作是跳过此算法的步骤3，并按照传统RTO恢复算法继续慢启动重传。然而，附录C中讨论了处理窗口受限情况的替代方法，这些方法可能会产生更好的性能。
3) When the second acknowledgment after the RTO retransmission arrives at the sender, the TCP sender either declares the timeout spurious, or starts retransmitting the unacknowledged segments.
3) 当RTO重新传输后的第二次确认到达发送方时，TCP发送方要么宣布超时为伪超时，要么开始重新传输未确认的段。
a) If the acknowledgment is a duplicate ACK, set the congestion window to no more than 3 * MSS, and continue with the slow start algorithm retransmitting unacknowledged segments. The congestion window can be set to 3 * MSS, because two round-trip times have elapsed since the RTO, and a conventional TCP sender would have increased cwnd to 3 during the same time. Leave SpuriousRecovery set to FALSE.
a) 如果确认为重复确认，则将拥塞窗口设置为不超过3*ms，并继续使用慢启动算法重新传输未确认的段。拥塞窗口可以设置为3*MSS，因为自RTO以来已经经过了两次往返时间，并且传统TCP发送方会在同一时间将cwnd增加到3。将伪恢复设置为FALSE。
b) If the acknowledgment advances the window (i.e., if it acknowledges data that was not retransmitted after the timeout), declare the timeout spurious, set SpuriousRecovery to SPUR_TO, and set the value of the "recover" variable to SND.UNA (the oldest unacknowledged sequence number [Pos81]).
b) 如果确认使窗口提前（即，如果确认超时后未重新传输的数据），则声明超时为伪超时，将伪恢复设置为SPUR_to，并将“recover”变量的值设置为SND.UNA（最早的未确认序列号[Pos81]）。
The F-RTO sender takes cautious actions when it receives duplicate acknowledgments after a retransmission timeout. Because duplicate ACKs may indicate that segments have been lost, reliably detecting a spurious timeout is difficult due to the lack of additional information. Therefore, it is prudent to follow the conventional TCP recovery in those cases.
当F-RTO发送方在重传超时后收到重复确认时，会采取谨慎措施。由于重复的ACK可能表明段已丢失，因此由于缺少额外信息，很难可靠地检测虚假超时。因此，在这些情况下，遵循传统的TCP恢复是谨慎的。
If the first acknowledgment after the RTO retransmission covers the "recover" point at algorithm step (2a), there is not enough evidence that a non-retransmitted segment has arrived at the receiver after the timeout. This is a common case when a fast retransmission is lost and has been retransmitted again after an RTO, while the rest of the unacknowledged segments were successfully delivered to the TCP receiver before the retransmission timeout. Therefore, the timeout cannot be declared spurious in this case.
如果RTO重传后的第一个确认覆盖了算法步骤（2a）的“恢复”点，则没有足够的证据表明在超时之后未重传的段已经到达接收器。这是一种常见情况，即快速重传丢失，并在RTO后再次重传，而其余未确认的段在重传超时之前已成功传递给TCP接收器。因此，在这种情况下，不能将超时声明为伪超时。
If the first acknowledgment after the RTO retransmission does not acknowledge all of the data that was retransmitted in step 1, the TCP sender reverts to the conventional RTO recovery. Otherwise, a malicious receiver acknowledging partial segments could cause the sender to declare the timeout spurious in a case where data was lost.
如果RTO重新传输后的第一次确认没有确认步骤1中重新传输的所有数据，TCP发送方将恢复到常规RTO恢复。否则，在数据丢失的情况下，确认部分段的恶意接收方可能会导致发送方声明超时是虚假的。
The TCP sender is allowed to send two new segments in algorithm branch (2b) because the conventional TCP sender would transmit two segments when the first new ACK arrives after the RTO retransmission. If sending new data is not possible in algorithm branch (2b), or if the receiver window limits the transmission, the TCP sender has to send something in order to prevent the TCP transfer from stalling. If no segments were sent, the pipe between sender and receiver might run out of segments, and no further acknowledgments would arrive. Therefore, in the window-limited case, the recommendation is to
允许TCP发送方在算法分支（2b）中发送两个新段，因为传统TCP发送方在RTO重传后第一个新ACK到达时将发送两个段。如果无法在算法分支（2b）中发送新数据，或者如果接收器窗口限制了传输，则TCP发送方必须发送一些信息以防止TCP传输暂停。如果没有发送段，发送方和接收方之间的管道可能会用尽段，并且不会收到进一步的确认。因此，在窗口有限的情况下，建议
revert to the conventional RTO recovery with slow start retransmissions. Appendix C discusses some alternative solutions for window-limited situations.
通过慢启动重传恢复到传统RTO恢复。附录C讨论了窗口受限情况下的一些替代解决方案。
If the retransmission timeout is declared spurious, the TCP sender sets the value of the "recover" variable to SND.UNA in order to allow fast retransmit [FHG04]. The "recover" variable was proposed for avoiding unnecessary, multiple fast retransmits when RTO expires during fast recovery with NewReno TCP. Because the sender retransmits only the segment that triggered the timeout, the problem of unnecessary multiple fast retransmits [FHG04] cannot occur. Therefore, if three duplicate ACKs arrive at the sender after the timeout, they probably indicate a packet loss, and thus fast retransmit should be used to allow efficient recovery. If there are not enough duplicate ACKs arriving at the sender after a packet loss, the retransmission timer expires again and the sender enters step 1 of this algorithm.
如果重传超时被声明为虚假，TCP发送方将“recover”变量的值设置为SND.UNA，以允许快速重传[FHG04]。“recover”变量用于避免在使用NewReno TCP进行快速恢复期间RTO过期时发生不必要的多次快速重传。由于发送方仅重新传输触发超时的段，因此不必要的多次快速重新传输[FHG04]的问题不会发生。因此，如果三个重复的ack在超时后到达发送方，它们可能表示数据包丢失，因此应该使用快速重传来实现高效恢复。如果在数据包丢失后没有足够的重复ack到达发送方，则重传计时器再次过期，发送方进入该算法的步骤1。
When the timeout is declared spurious, the TCP sender cannot detect whether the unnecessary RTO retransmission was lost. In principle, the loss of the RTO retransmission should be taken as a congestion signal. Thus, there is a small possibility that the F-RTO sender will violate the congestion control rules, if it chooses to fully revert congestion control parameters after detecting a spurious timeout. The Eifel detection algorithm has a similar property, while the DSACK option can be used to detect whether the retransmitted segment was successfully delivered to the receiver.
当超时被声明为伪超时时，TCP发送方无法检测不必要的RTO重传是否丢失。原则上，RTO重传的丢失应视为拥塞信号。因此，如果F-RTO发送方在检测到虚假超时后选择完全恢复拥塞控制参数，则F-RTO发送方违反拥塞控制规则的可能性很小。Eifel检测算法具有类似的特性，而DSACK选项可用于检测重传段是否成功交付给接收机。
The F-RTO algorithm has a side-effect on the TCP round-trip time measurement. Because the TCP sender can avoid most of the unnecessary retransmissions after detecting a spurious timeout, the sender is able to take round-trip time samples on the delayed segments. If the regular RTO recovery was used without TCP timestamps, this would not be possible due to the retransmission ambiguity. As a result, the RTO is likely to have more accurate and larger values with F-RTO than with the regular TCP after a spurious timeout that was triggered due to delayed segments. We believe this is an advantage in the networks that are prone to delay spikes.
F-RTO算法对TCP往返时间测量有副作用。由于TCP发送方可以在检测到虚假超时后避免大多数不必要的重新传输，因此发送方能够在延迟段上获取往返时间样本。如果在没有TCP时间戳的情况下使用常规RTO恢复，则由于重传的不确定性，这是不可能的。因此，在由于延迟段而触发虚假超时后，使用F-RTO的RTO值可能比使用常规TCP的RTO值更准确、更大。我们认为，这在容易出现延迟峰值的网络中是一个优势。
There are some situations where the F-RTO algorithm may not avoid unnecessary retransmissions after a spurious timeout. If packet reordering or packet duplication occurs on the segment that triggered the spurious timeout, the F-RTO algorithm may not detect the spurious timeout due to incoming duplicate ACKs. Additionally, if a spurious timeout occurs during fast recovery, the F-RTO algorithm often cannot detect the spurious timeout because the segments that were transmitted before the fast recovery trigger duplicate ACKs. However, we consider these cases rare, and note that in cases where
在某些情况下，F-RTO算法可能无法避免虚假超时后不必要的重新传输。如果在触发伪超时的段上发生数据包重新排序或数据包重复，则F-RTO算法可能无法检测到由于传入重复确认而导致的伪超时。此外，如果在快速恢复期间出现虚假超时，F-RTO算法通常无法检测到虚假超时，因为在快速恢复之前传输的段会触发重复的ACK。然而，我们认为这些情况很少见，并且注意到在
F-RTO fails to detect the spurious timeout, it retransmits the unacknowledged segments in slow start, and thus performs similarly to the regular RTO recovery.
F-RTO无法检测到虚假超时，它以慢启动重新传输未确认的段，因此执行类似于常规RTO恢复的操作。
This section describes an alternative version of the F-RTO algorithm that uses the TCP Selective Acknowledgment Option [MMFR96]. By using the SACK option, the TCP sender detects spurious timeouts in most of the cases when packet reordering or packet duplication is present. If the SACK blocks acknowledge new data that was not transmitted after the RTO retransmission, the sender may declare the timeout spurious, even when duplicate ACKs follow the RTO.
本节介绍使用TCP选择性确认选项[MMFR96]的F-RTO算法的替代版本。通过使用SACK选项，在大多数情况下，当存在数据包重新排序或数据包重复时，TCP发送方会检测到虚假超时。如果SACK块确认RTO重新传输后未传输的新数据，则发送方可能会宣布超时为伪超时，即使RTO之后有重复的ACK。
Given that the TCP Selective Acknowledgment Option [MMFR96] is enabled for a TCP connection, a TCP sender MAY implement the SACK-enhanced F-RTO algorithm. If the sender applies the SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This algorithm SHOULD NOT be applied if the TCP sender is already in SACK loss recovery when retransmission timeout occurs. However, when retransmission timeout occurs during existing loss recovery, it should be possible to apply the principle of F-RTO within certain limitations. This is a topic for further research. Appendix B briefly discusses the related issues.
鉴于TCP连接启用了TCP选择性确认选项[MMFR96]，TCP发送方可以实现SACK增强的F-RTO算法。如果发送方应用SACK增强型F-RTO算法，则必须遵循以下步骤。如果TCP发送方在发生重传超时时已处于SACK丢失恢复中，则不应应用此算法。然而，当在现有的丢失恢复过程中发生重传超时时，应该可以在某些限制内应用F-RTO原则。这是一个有待进一步研究的课题。附录B简要讨论了相关问题。
The steps of the SACK-enhanced version of the F-RTO algorithm are as follows.
SACK增强版F-RTO算法的步骤如下所示。
1) When the RTO expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. Set variable "recover" to indicate the highest segment transmitted so far. Following the recommendation in SACK specification [MMFR96], reset the SACK scoreboard.
1) 当RTO过期时，重新传输第一个未确认的段，并将SpusiousRecovery设置为FALSE。设置变量“recover”以指示迄今为止传输的最高段。按照SACK规范[MMFR96]中的建议，重置SACK记分板。
2) Wait until the acknowledgment of the data retransmitted due to the timeout arrives at the sender. If duplicate ACKs arrive before the cumulative acknowledgment for retransmitted data, adjust the scoreboard according to the incoming SACK information. Stay in step 2 and wait for the next new acknowledgment. If RTO expires again, go to step 1 of the algorithm.
2) 等待由于超时而重新传输的数据的确认到达发送方。如果重复确认在重新传输数据的累积确认之前到达，则根据传入的SACK信息调整记分板。继续执行步骤2，等待下一个新的确认。如果RTO再次过期，请转至算法的步骤1。
a) if a cumulative ACK acknowledges a sequence number equal to "recover", revert to the conventional RTO recovery and set the congestion window to no more than 2 * MSS, like a regular TCP would do. Do not enter step 3 of this algorithm.
a) 如果累积ACK确认序列号等于“recover”，则恢复到传统RTO恢复，并将拥塞窗口设置为不超过2*ms，就像常规TCP一样。不要进入此算法的步骤3。
b) else, if a cumulative ACK acknowledges a sequence number (smaller than "recover", but larger than SND.UNA) transmit up to two new (previously unsent) segments and proceed to step 3. If the TCP sender is not able to transmit any previously unsent data -- either due to receiver window limitation, or because it does not have any new data to send -- the recommended action is to refrain from entering step 3 of this algorithm. Rather, continue with slow start retransmissions following the conventional RTO recovery algorithm.
b) 否则，如果累积ACK确认序列号（小于“recover”，但大于SND.UNA），则发送最多两个新的（先前未发送的）段并继续步骤3。如果TCP发送方无法传输任何以前未发送的数据（由于接收方窗口限制，或由于没有任何新数据要发送），建议不要进入此算法的步骤3。相反，按照传统RTO恢复算法继续慢启动重传。
It is also possible to apply some of the alternatives for handling window-limited cases discussed in Appendix C. In this case, the TCP sender should follow the recommendations concerning acknowledgments of retransmitted segments given in Appendix B.
也可以应用一些备选方案来处理附录C中讨论的窗口受限情况。在这种情况下，TCP发送方应遵循附录B中给出的关于重新传输段确认的建议。
3) The next acknowledgment arrives at the sender. Either a duplicate ACK or a new cumulative ACK (advancing the window) applies in this step.
3) 下一个确认到达发送方。在此步骤中应用重复确认或新累积确认（推进窗口）。
a) if the ACK acknowledges a sequence number above "recover", either in SACK blocks or as a cumulative ACK, set the congestion window to no more than 3 * MSS and proceed with the conventional RTO recovery, retransmitting unacknowledged segments. Take this branch also when the acknowledgment is a duplicate ACK and it does not acknowledge any new, previously unacknowledged data below "recover" in the SACK blocks. Leave SpuriousRecovery set to FALSE.
a) 如果ACK在SACK块中或作为累积ACK确认“recover”以上的序列号，则将拥塞窗口设置为不超过3*ms，并继续进行常规RTO恢复，重新传输未确认的段。当确认是一个重复的确认并且它不确认SACK块中“recover”（恢复）下面的任何新的、以前未确认的数据时，也执行此分支。将伪恢复设置为FALSE。
b) if the ACK does not acknowledge sequence numbers above "recover" AND it acknowledges data that was not acknowledged earlier (either with cumulative acknowledgment or using SACK blocks), declare the timeout spurious and set SpuriousRecovery to SPUR_TO. The retransmission timeout can be declared spurious, because the segment acknowledged with this ACK was transmitted before the timeout.
b) 如果ACK不确认“recover”（恢复）以上的序列号，并且确认先前未确认的数据（使用累积确认或使用SACK块），则声明超时为Spurouse（伪恢复），并将SpurousRecovery设置为Spuru（伪恢复）。重传超时可能被宣布为虚假，因为使用此ACK确认的段是在超时之前传输的。
If there are unacknowledged holes between the received SACK blocks, those segments are retransmitted similarly to the conventional SACK recovery algorithm [BAFW03]. If the algorithm exits with SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus allowing fast recovery on incoming duplicate acknowledgments.
如果接收到的SACK块之间存在未确认的空穴，则与传统SACK恢复算法[BAFW03]类似，重新传输这些段。如果算法退出时将SpurousRecovery设置为SPUR_to，“recover”设置为SND.UNA，从而允许对传入的重复确认进行快速恢复。
Upon retransmission timeout, a conventional TCP sender assumes that outstanding segments are lost and starts retransmitting the unacknowledged segments. When the retransmission timeout is detected to be spurious, the TCP sender should not continue retransmitting based on the timeout. For example, if the sender was in congestion avoidance phase transmitting new, previously unsent segments, it should continue transmitting previously unsent segments after detecting a spurious RTO. This document does not describe the response to spurious timeouts, but a response algorithm is described in RFC 4015 [LG04].
在重新传输超时时，传统TCP发送方假定未完成的段丢失，并开始重新传输未确认的段。当检测到重传超时是虚假的时，TCP发送方不应基于该超时继续重传。例如，如果发送方在拥塞避免阶段传输新的、以前未发送的段，则在检测到虚假RTO后，它应继续传输以前未发送的段。本文档未描述对虚假超时的响应，但RFC 4015[LG04]中描述了响应算法。
Additionally, different response variants to spurious retransmission timeout have been discussed in various research papers [SKR03, GL03, Sar03] and IETF documents [SL03]. The different response alternatives vary in whether the spurious retransmission timeout should be taken as a congestion signal, thus causing the congestion window or slow start threshold to be reduced at the sender, or whether the congestion control state should be fully reverted to the state valid prior to the retransmission timeout.
此外，各种研究论文[SKR03、GL03、Sar03]和IETF文件[SL03]中讨论了对伪重传超时的不同响应变体。不同的响应备选方案在伪重传超时是否应被视为拥塞信号，从而导致发送方的拥塞窗口或慢启动阈值减小，或者拥塞控制状态是否应完全恢复到重传超时之前的有效状态方面有所不同。
SCTP has similar retransmission algorithms and congestion control to TCP. The SCTP T3-rtx timer for one destination address is maintained in the same way as the TCP retransmission timer, and after a T3-rtx expires, an SCTP sender retransmits unacknowledged data chunks in slow start like TCP does. Therefore, SCTP is vulnerable to the negative effects of the spurious retransmission timeouts similarly to TCP. Due to similar RTO recovery algorithms, F-RTO algorithm logic can be applied also to SCTP. Since SCTP uses selective acknowledgments, the SACK-based variant of the algorithm is recommended, although the basic version can also be applied to SCTP. However, SCTP contains features that are not present with TCP that need to be discussed when applying the F-RTO algorithm.
SCTP具有与TCP相似的重传算法和拥塞控制。一个目标地址的SCTP T3 rtx计时器的维护方式与TCP重传计时器的维护方式相同，并且在T3 rtx过期后，SCTP发送方会像TCP一样以慢启动的方式重新传输未确认的数据块。因此，SCTP与TCP一样容易受到伪重传超时的负面影响。由于类似的RTO恢复算法，F-RTO算法逻辑也可以应用于SCTP。由于SCTP使用选择性确认，因此建议使用基于SACK的算法变体，尽管基本版本也可以应用于SCTP。但是，SCTP包含TCP不具备的功能，在应用F-RTO算法时需要讨论这些功能。
SCTP associations can be multi-homed. The current retransmission policy states that retransmissions should go to alternative addresses. If the retransmission was due to spurious timeout caused by a delay spike, it is possible that the acknowledgment for the retransmission arrives back at the sender before the acknowledgments of the original transmissions arrive. If this happens, a possible loss of the original transmission of the data chunk that was retransmitted due to the spurious timeout may remain undetected when applying the F-RTO algorithm. Because the timeout was caused by a delay spike, and it was spurious in that respect, a suitable response is to continue by sending new data. However, if the original
SCTP关联可以是多宿主的。当前的重新传输政策规定，重新传输应转到其他地址。如果重新传输是由于延迟尖峰引起的虚假超时，则重新传输的确认可能在原始传输的确认到达之前到达发送方。如果发生这种情况，则在应用F-RTO算法时，由于伪超时而导致的重新传输的数据块的原始传输的可能丢失可能仍然未被检测到。因为超时是由延迟尖峰引起的，并且在这方面是虚假的，所以合适的响应是通过发送新数据来继续。但是，如果原
transmission was lost, fully reverting the congestion control parameters is too aggressive. Therefore, taking conservative actions on congestion control is recommended, if the SCTP association is multi-homed and retransmissions go to alternative addresses. The information in duplicate TSNs can be then used for reverting congestion control, if desired [BA04].
传输丢失，完全恢复拥塞控制参数过于激进。因此，如果SCTP关联是多宿的，并且重新传输到其他地址，则建议对拥塞控制采取保守措施。如果需要，可以使用重复TSN中的信息恢复拥塞控制[BA04]。
Note that the forward transmissions made in F-RTO algorithm step (2b) should be destined to the primary address, since they are not retransmissions.
注意，在F-RTO算法步骤（2b）中进行的前向传输应该被发送到主地址，因为它们不是重传。
When making a retransmission, an SCTP sender can bundle a number of unacknowledged data chunks and include them in the same packet. This needs to be considered when implementing F-RTO for SCTP. The basic principle of F-RTO still holds: in order to declare the timeout spurious, the sender must get an acknowledgment for a data chunk that was not retransmitted after the retransmission timeout. In other words, acknowledgments of data chunks that were bundled in RTO retransmission must not be used for declaring the timeout spurious.
在进行重传时，SCTP发送方可以捆绑许多未确认的数据块，并将它们包含在同一数据包中。在为SCTP实现F-RTO时需要考虑这一点。F-RTO的基本原理仍然适用：为了声明超时是虚假的，发送方必须获得在重新传输超时后未重新传输的数据块的确认。换句话说，在RTO重新传输中捆绑的数据块的确认不能用于声明假超时。
The main security threat regarding F-RTO is the possibility that a receiver could mislead the sender into setting too large a congestion window after an RTO. There are two possible ways a malicious receiver could trigger a wrong output from the F-RTO algorithm. First, the receiver can acknowledge data that it has not received. Second, it can delay acknowledgment of a segment it has received earlier, and acknowledge the segment after the TCP sender has been deluded to enter algorithm step 3.
关于F-RTO的主要安全威胁是接收方可能误导发送方在RTO后设置过大的拥塞窗口。恶意接收器有两种可能的方式触发F-RTO算法的错误输出。首先，接收器可以确认它没有接收到的数据。第二，它可以延迟对先前收到的段的确认，并在TCP发送方被欺骗进入算法步骤3后确认该段。
If the receiver acknowledges a segment it has not really received, the sender can be led to declare spurious timeout in the F-RTO algorithm, step 3. However, because the sender will have an incorrect state, it cannot retransmit the segment that has never reached the receiver. Therefore, this attack is unlikely to be useful for the receiver to maliciously gain a larger congestion window.
如果接收器确认其未真正接收到的段，则可引导发送器在F-RTO算法（步骤3）中声明虚假超时。但是，由于发送方的状态不正确，因此无法重新传输从未到达接收方的段。因此，这种攻击不太可能有助于接收方恶意获得更大的拥塞窗口。
A common case for a retransmission timeout is that a fast retransmission of a segment is lost. If all other segments have been received, the RTO retransmission causes the whole window to be acknowledged at once. This case is recognized in F-RTO algorithm branch (2a). However, if the receiver only acknowledges one segment after receiving the RTO retransmission, and then the rest of the segments, it could cause the timeout to be declared spurious when it is not. Therefore, it is suggested that, when an RTO expires during
重传超时的常见情况是丢失段的快速重传。如果已接收到所有其他段，则RTO重新传输会导致立即确认整个窗口。这种情况在F-RTO算法分支（2a）中得到识别。但是，如果接收器在接收到RTO重传后仅确认一个段，然后确认其余的段，则可能会导致超时被宣布为虚假超时，而实际上并非如此。因此，建议当RTO在
fast recovery phase, the sender would not fully revert the congestion window even if the timeout was declared spurious. Instead, the sender would reduce the congestion window to 1.
在快速恢复阶段，即使超时被宣布为伪超时，发送方也不会完全恢复拥塞窗口。相反，发送方会将拥塞窗口减少到1。
If there is more than one segment missing at the time of a retransmission timeout, the receiver does not benefit from misleading the sender to declare a spurious timeout because the sender would have to go through another recovery period to retransmit the missing segments, usually after an RTO has elapsed.
如果在重新传输超时时丢失了多个段，则接收器不能从误导发送方声明虚假超时中获益，因为发送方必须经历另一个恢复期来重新传输丢失的段，通常是在RTO已过之后。
We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Samu Kontinen, and Kostas Pentikousis for the discussion and feedback contributed to this text.
我们感谢Reiner Ludwig、Andrei Gurtov、Josh Blanton、Mark Allman、Sally Floyd、Yogesh Swami、Mika Liljeberg、Ivan Arias Rodriguez、Sourabh Ladha、Martin Duke、Motoharu Miyake、Ted Faber、Samu Kontinen和Kostas Pentikousis对本文的讨论和反馈。
[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月。
[BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[BAFW03]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 35172003年4月。
[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月。
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[FHG04]Floyd，S.，Henderson，T.，和A.Gurtov，“TCP快速恢复算法的NewReno修改”，RFC 3782，2004年4月。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[MMFR96]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[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月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[Ste00] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[Ste00]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[ABF01]Allman，M.，Balakrishnan，H.，和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[BA04] 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.
[BA04]Blanton，E.和M.Allman，“使用TCP重复选择确认（DSACKs）和流控制传输协议（SCTP）重复传输序列号（TSN）来检测虚假重传”，RFC 37082004年2月。
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[BBJ92]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[FMMP00]Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for TCP in a GPRS Network. In Proc. of European Wireless, Florence, Italy, February 2002.
[GL02]A.古尔托夫和R.路德维希。评估GPRS网络中TCP的Eifel算法。在过程中。2002年2月，意大利佛罗伦萨，欧洲无线通信公司。
[GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, CA, USA, March 2003.
[GL03]A.Gurtov和R.Ludwig，对TCP中的虚假超时做出响应。在IEEE ICOFCOM 03，旧金山，CA，美国，2003年3月。
[Jac88] V. Jacobson. Congestion Avoidance and Control. In Proceedings of ACM SIGCOMM 88.
[Jac88]诉雅各布森。拥塞避免和控制。在ACM SIGCOMM 88的诉讼中。
[LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[LG04]Ludwig，R.和A.Gurtov，“TCP的Eifel响应算法”，RFC 4015，2005年2月。
[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM SIGCOMM Computer Communication Review, 30(1), January 2000.
[LK00]R.路德维希和R.H.卡茨。Eifel算法：使TCP对伪重传具有鲁棒性。ACM SIGCOMM计算机通信评论，30（1），2000年1月。
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[LM03]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
[Nag84]Nagle，J.，“IP/TCP网络中的拥塞控制”，RFC 896，1984年1月。
[SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An Enhanced Recovery Algorithm for TCP Retransmission Timeouts. ACM SIGCOMM Computer Communication Review, 33(2), April 2003.
[SKR03]P.Sarolahti、M.Kojo和K.Raatikainen。F-RTO：一种增强的TCP重传超时恢复算法。ACM SIGCOMM计算机通信评论，33（2），2003年4月。
[Sar03] P. Sarolahti. Congestion Control on Spurious TCP Retransmission Timeouts. In Proceedings of IEEE Globecom 2003, San Francisco, CA, USA. December 2003.
[Sar03]P.Sarolahti。虚假TCP重传超时的拥塞控制。在IEEE Global 2003，CA，旧金山，美国2003年12月的诉讼。
[SL03] Y. Swami and K. Le, "DCLOR: De-correlated Loss Recovery using SACK Option for Spurious Timeouts", work in progress, September 2003.
[SL03]Y.Swami和K.Le，“DCLOR：使用SACK选项对虚假超时进行去相关损失恢复”，正在进行的工作，2003年9月。
Appendix A: Scenarios
附录A：情景
This section discusses different scenarios where RTOs occur and how the basic F-RTO algorithm performs in those scenarios. The interesting scenarios are: a sudden delay triggering retransmission timeout, loss of a retransmitted packet during fast recovery, link outage causing the loss of several packets, and packet reordering. A performance evaluation with a more thorough analysis on a real implementation of F-RTO is given in [SKR03].
本节讨论RTO出现的不同场景以及基本F-RTO算法在这些场景中的执行情况。有趣的场景包括：触发重传超时的突然延迟、在快速恢复期间丢失重传的数据包、导致多个数据包丢失的链路中断以及数据包重新排序。[SKR03]中给出了对F-RTO的实际实现进行更全面分析的性能评估。
The main motivation behind the F-RTO algorithm is to improve TCP performance when a delay spike triggers a spurious retransmission timeout. The example below illustrates the segments and acknowledgments transmitted by the TCP end hosts when a spurious timeout occurs, but no packets are lost. For simplicity, delayed acknowledgments are not used in the example. The example below applies the Eifel Response Algorithm [LG04] after detecting a spurious timeout.
F-RTO算法背后的主要动机是在延迟尖峰触发虚假重传超时时提高TCP性能。下面的示例说明了当出现虚假超时但没有数据包丢失时，TCP终端主机发送的数据段和确认。为简单起见，本例中不使用延迟确认。以下示例在检测到虚假超时后应用Eifel响应算法[LG04]。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. |
[delay]
|
[RTO]
[F-RTO step (1)]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 6> --->
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
<earlier xmitted SEG 7> --->
10. <---------------------------- ACK 8
[F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. |
[delay]
|
[RTO]
[F-RTO step (1)]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 6> --->
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
<earlier xmitted SEG 7> --->
10. <---------------------------- ACK 8
[F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
11. SEND 14 ----------------------------> (cwnd = 7, ssthresh = 6, FlightSize = 7) 12. <---------------------------- ACK 9 13. SEND 15 ----------------------------> (cwnd = 7, ssthresh = 6, FlightSize = 7) 14. <---------------------------- ACK 10 15. SEND 16 ----------------------------> (cwnd = 7, ssthresh = 6, FlightSize = 7) ...
11. 发送14----------------------------------------->（cwnd=7，ssthresh=6，FlightSize=7）12.<------------------------------------确认9 13。发送15----------------------------------------->（cwnd=7，ssthresh=6，FlightSize=7）14.<------------------------------------确认10 15。发送16----------------------------------------->（cwnd=7，ssthresh=6，FlightSize=7）。。。
When a sudden delay (long enough to trigger timeout) occurs at step 5, the TCP sender retransmits the first unacknowledged segment (step 6). The next ACK covers the RTO retransmission because the originally transmitted segment 6 arrived at the receiver, and the TCP sender continues by sending two new data segments (steps 8, 9). Note that on F-RTO steps (1) and (2b), congestion window and FlightSize are not yet reset because in the case of spurious timeout, the segments sent before the timeout are still in the network. However, the sender should still be equally aggressive toward conventional TCP. Because the second acknowledgment arriving after the RTO retransmission acknowledges data that was not retransmitted due to timeout (step 10), the TCP sender declares the timeout to be spurious and continues by sending new data on the next acknowledgments. Also, the congestion control state is reversed, as required by the Eifel Response Algorithm.
当在步骤5发生突然延迟（长到足以触发超时）时，TCP发送方重新传输第一个未确认的段（步骤6）。下一个ACK覆盖RTO重传，因为最初发送的段6到达接收器，并且TCP发送器通过发送两个新的数据段继续（步骤8、9）。请注意，在F-RTO步骤（1）和（2b）中，拥塞窗口和FlightSize尚未重置，因为在虚假超时的情况下，超时之前发送的段仍在网络中。然而，发送方仍然应该对传统TCP具有同样的攻击性。由于RTO重新传输后到达的第二个确认确认由于超时而未重新传输的数据（步骤10），TCP发送方将超时声明为伪超时，并通过在下一个确认时发送新数据继续。此外，根据Eifel响应算法的要求，拥塞控制状态被反转。
If a retransmitted segment is lost, the only way to retransmit it is to wait for the timeout to trigger the retransmission. Once the segment is successfully received, the receiver usually acknowledges several segments at once, because other segments in the same window have been successfully delivered before the retransmission arrives at the receiver. The example below shows a scenario where retransmission (of segment 6) is lost, as well as a later segment (segment 9) in the same window. The limited transmit [ABF01] or SACK TCP [MMFR96] enhancements are not in use in this example.
如果重新传输的段丢失，重新传输它的唯一方法是等待超时触发重新传输。一旦成功接收到该段，接收机通常一次确认多个段，因为在重发到达接收机之前，同一窗口中的其他段已经成功交付。下面的示例显示了一个场景，其中（段6）的重传丢失，以及同一窗口中的后续段（段9）丢失。本例中未使用受限传输[ABF01]或SACK TCP[MMFR96]增强功能。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segment 6 lost>
<segment 9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segment 6 lost>
<segment 9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. <---------------------------- ACK 6
6. <---------------------------- ACK 6
7. <---------------------------- ACK 6
8. SEND 6 --------------X
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<segment 6 lost>
9. <---------------------------- ACK 6
10. SEND 12 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
11. <---------------------------- ACK 6
12. SEND 13 ---------------------------->
(cwnd = 8, ssthresh = 3, FlightSize = 8)
[RTO]
13. SEND 6 ---------------------------->
(cwnd = 8, ssthresh = 2, FlightSize = 8)
14. <---------------------------- ACK 9
[F-RTO step (2b)]
15. SEND 14 ---------------------------->
16. SEND 15 ---------------------------->
(cwnd = 7, ssthresh = 2, FlightSize = 7)
17. <---------------------------- ACK 9
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 2, FlightSize = 7)
18. SEND 9 ---------------------------->
19. SEND 10 ---------------------------->
20. SEND 11 ---------------------------->
...
5. <---------------------------- ACK 6
6. <---------------------------- ACK 6
7. <---------------------------- ACK 6
8. SEND 6 --------------X
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<segment 6 lost>
9. <---------------------------- ACK 6
10. SEND 12 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
11. <---------------------------- ACK 6
12. SEND 13 ---------------------------->
(cwnd = 8, ssthresh = 3, FlightSize = 8)
[RTO]
13. SEND 6 ---------------------------->
(cwnd = 8, ssthresh = 2, FlightSize = 8)
14. <---------------------------- ACK 9
[F-RTO step (2b)]
15. SEND 14 ---------------------------->
16. SEND 15 ---------------------------->
(cwnd = 7, ssthresh = 2, FlightSize = 7)
17. <---------------------------- ACK 9
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 2, FlightSize = 7)
18. SEND 9 ---------------------------->
19. SEND 10 ---------------------------->
20. SEND 11 ---------------------------->
...
In the example above, segment 6 is lost and the sender retransmits it after three duplicate ACKs in step 8. However, the retransmission is also lost, and the sender has to wait for the RTO to expire before retransmitting it again. Because the first ACK following the RTO retransmission acknowledges the RTO retransmission (step 14), the sender transmits two new segments. The second ACK in step 17 does not acknowledge any previously unacknowledged data. Therefore, the F-RTO sender enters the slow start and sets cwnd to 3 * MSS. The congestion window can be set to three segments, because two round-trips have elapsed after the retransmission timeout. Finally, the receiver acknowledges all segments transmitted prior to entering recovery and the sender can continue transmitting new data in congestion avoidance.
在上面的示例中，段6丢失，发送方在步骤8的三次重复确认后重新传输它。但是，重新传输也会丢失，发送方必须等待RTO过期后再重新传输。由于RTO重传后的第一个ACK确认RTO重传（步骤14），发送方发送两个新段。步骤17中的第二确认不确认任何先前未确认的数据。因此，F-RTO发送器进入慢启动并将cwnd设置为3*MSS。拥塞窗口可以设置为三个区段，因为在重新传输超时之后已经经过了两次往返。最后，接收方确认在进入恢复之前发送的所有数据段，发送方可以在拥塞避免中继续发送新数据。
The example below illustrates the F-RTO behavior when 4 consecutive packets are lost in the network causing the TCP sender to fall back to RTO recovery. Limited transmit and SACK are not used in this example.
下面的示例说明了在网络中丢失4个连续数据包导致TCP发送方退回RTO恢复时F-RTO的行为。本例中未使用受限传输和SACK。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segments 6-9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. <---------------------------- ACK 6
|
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
10. <---------------------------- ACK 7
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 3, FlightSize = 7)
11. SEND 7 ---------------------------->
12. SEND 8 ---------------------------->
13. SEND 9 ---------------------------->
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segments 6-9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. <---------------------------- ACK 6
|
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
10. <---------------------------- ACK 7
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 3, FlightSize = 7)
11. SEND 7 ---------------------------->
12. SEND 8 ---------------------------->
13. SEND 9 ---------------------------->
Again, F-RTO sender transmits two new segments (steps 8 and 9) after the RTO retransmission is acknowledged. Because the next ACK does not acknowledge any data that was not retransmitted after the retransmission timeout (step 10), the F-RTO sender proceeds with conventional recovery and slow start retransmissions.
同样，在确认RTO重传之后，F-RTO发送方发送两个新段（步骤8和9）。由于下一个ACK不确认在重传超时（步骤10）之后未重传的任何数据，因此F-RTO发送方继续进行常规恢复和慢启动重传。
Because F-RTO modifies the TCP sender behavior only after a retransmission timeout and it is intended to avoid unnecessary retransmissions only after spurious timeout, we limit the discussion on the effects of packet reordering on F-RTO behavior to the cases where it occurs immediately after the retransmission timeout. When
由于F-RTO仅在重传超时后修改TCP发送方行为，并且其目的是仅在伪超时后避免不必要的重传，因此我们将对数据包重排序对F-RTO行为的影响的讨论限制在重传超时后立即发生的情况。什么时候
the TCP receiver gets an out-of-order segment, it generates a duplicate ACK. If the TCP sender implements the basic F-RTO algorithm, this may prevent the sender from detecting a spurious timeout.
TCP接收器获得一个无序段，它生成一个重复的ACK。如果TCP发送方实现了基本的F-RTO算法，这可以防止发送方检测到虚假超时。
However, if the TCP sender applies the SACK-enhanced F-RTO, it is possible to detect a spurious timeout when packet reordering occurs. Below, we illustrate the behavior of SACK-enhanced F-RTO when segment 8 arrives before segments 6 and 7, and segments starting from segment 6 are delayed in the network. In this example the TCP sender reduces the congestion window and slow start threshold in response to spurious timeout.
但是，如果TCP发送方应用SACK增强型F-RTO，则在数据包重新排序时可能检测到虚假超时。下面，我们将说明SACK增强型F-RTO的行为，当第8段在第6段和第7段之前到达，并且从第6段开始的段在网络中延迟。在本例中，TCP发送方减少拥塞窗口和慢启动阈值，以响应虚假超时。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
5. |
[delay]
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 8> --->
7. <---------------------------- ACK 6
[SACK 8]
[SACK F-RTO stays in step 2]
8. <earlier xmitted SEG 6> --->
9. <---------------------------- ACK 7
[SACK 8]
[SACK F-RTO step (2b)]
10. SEND 12 ---------------------------->
11. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
12. <earlier xmitted SEG 7> --->
13. <---------------------------- ACK 9
[SACK F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
14. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
15. <---------------------------- ACK 10
16. SEND 15 ---------------------------->
...
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
5. |
[delay]
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 8> --->
7. <---------------------------- ACK 6
[SACK 8]
[SACK F-RTO stays in step 2]
8. <earlier xmitted SEG 6> --->
9. <---------------------------- ACK 7
[SACK 8]
[SACK F-RTO step (2b)]
10. SEND 12 ---------------------------->
11. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
12. <earlier xmitted SEG 7> --->
13. <---------------------------- ACK 9
[SACK F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
14. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
15. <---------------------------- ACK 10
16. SEND 15 ---------------------------->
...
After RTO expires and the sender retransmits segment 6 (step 6), the receiver gets segment 8 and generates duplicate ACK with SACK for segment 8. In response to the acknowledgment, the TCP sender does not send anything but stays in F-RTO step 2. Because the next acknowledgment advances the cumulative ACK point (step 9), the sender can transmit two new segments according to SACK-enhanced F-RTO. The next segment acknowledges new data between 7 and 11 that was not acknowledged earlier (segment 7), so the F-RTO sender declares the timeout spurious.
RTO到期且发送方重新传输段6（步骤6）后，接收方获得段8，并使用SACK为段8生成重复的ACK。作为对确认的响应，TCP发送方不发送任何内容，而是停留在F-RTO步骤2中。由于下一次确认将提前累积确认点（步骤9），发送方可以根据SACK增强型F-RTO发送两个新段。下一段确认7和11之间的新数据，而之前没有确认（第7段），因此F-RTO发送方声明超时为伪超时。
Appendix B: SACK-enhanced F-RTO and Fast Recovery
附录B：SACK增强型F-RTO和快速恢复
We believe that a slightly modified, SACK-enhanced F-RTO algorithm can be used to detect spurious timeouts also when RTO expires while an earlier loss recovery is underway. However, there are issues that need to be considered if F-RTO is applied in this case.
我们相信，当RTO到期，而较早的丢失恢复正在进行时，一种稍加修改、SACK增强的F-RTO算法也可用于检测虚假超时。然而，如果在这种情况下应用F-RTO，则需要考虑一些问题。
In step 3, the original SACK-based F-RTO algorithm requires that an ACK acknowledges previously unacknowledged non-retransmitted data between SND.UNA and send_high. If RTO expires during earlier (SACK-based) loss recovery, the F-RTO sender must use only acknowledgments for non-retransmitted segments transmitted before the SACK-based loss recovery started. This means that in order to declare timeout spurious, the TCP sender must receive an acknowledgment for non-retransmitted segment between SND.UNA and RecoveryPoint in algorithm step 3. RecoveryPoint is defined in conservative SACK-recovery algorithm [BAFW03], and it is set to indicate the highest segment transmitted so far when SACK-based loss recovery begins. In other words, if the TCP sender receives acknowledgment for a segment that was transmitted more than one RTO ago, it can declare the timeout spurious. Defining an efficient algorithm for checking these conditions remains a future work item.
在步骤3中，原始的基于SACK的F-RTO算法要求ACK确认SND.UNA和send_high之间先前未确认的未重传数据。如果RTO在较早的（基于SACK的）丢失恢复期间过期，则F-RTO发送方必须仅对基于SACK的丢失恢复开始之前传输的未重传段使用确认。这意味着，为了声明超时虚假，TCP发送方必须在算法步骤3中接收SND.UNA和RecoveryPoint之间未重传段的确认。RecoveryPoint在保守的SACK恢复算法[BAFW03]中定义，它被设置为在基于SACK的丢失恢复开始时指示迄今为止传输的最高段。换句话说，如果TCP发送方收到一个段的确认，该段在一个以上的RTO之前传输，它可以声明超时是虚假的。定义检查这些条件的有效算法仍然是未来的工作项目。
When spurious timeout is detected according to the rules given above, it may be possible that the response algorithm needs to consider this case separately, for example, in terms of which segments to retransmit after RTO expires, and whether it is safe to revert the congestion control parameters. This is considered a topic for future research.
当根据上面给出的规则检测伪超时时，响应算法可能需要单独考虑该情况，例如，在RTO到期之后哪些段要重传，以及是否恢复拥塞控制参数是安全的。这被认为是未来研究的主题。
Appendix C: Discussion of Window-Limited Cases
附录C：关于窗口限制案例的讨论
When the advertised window limits the transmission of two new previously unsent segments, or there are no new data to send, it is recommended in F-RTO algorithm step (2b) that the TCP sender continue with the conventional RTO recovery algorithm. The disadvantage is that the sender may continue unnecessary retransmissions due to possible spurious timeout. This section briefly discusses the options that can potentially improve performance when transmitting previously unsent data is not possible.
当播发的窗口限制两个新的先前未发送的段的传输，或者没有新的数据要发送时，在F-RTO算法步骤（2b）中建议TCP发送方继续使用传统的RTO恢复算法。缺点是，由于可能的虚假超时，发送方可能继续不必要的重新传输。本节简要讨论在无法传输以前未发送的数据时可能提高性能的选项。
- The TCP sender could reserve an unused space of a size of one or two segments in the advertised window to ensure the use of algorithms such as F-RTO or Limited Transmit [ABF01] in window-limited situations. On the other hand, while doing this, the TCP sender should ensure that the window of outstanding segments is large enough for proper utilization of the available pipe.
- TCP发送方可以在公布的窗口中保留一个或两个段大小的未使用空间，以确保在窗口受限的情况下使用诸如F-RTO或受限传输[ABF01]之类的算法。另一方面，在执行此操作时，TCP发送方应确保未完成段的窗口足够大，以便正确利用可用管道。
- Use additional information if available, e.g., TCP timestamps with the Eifel Detection algorithm, for detecting a spurious timeout. However, Eifel detection may yield different results from F-RTO when ACK losses and an RTO occur within the same round-trip time [SKR03].
- 使用附加信息（如果可用），例如，带有Eifel检测算法的TCP时间戳，用于检测虚假超时。然而，当ACK丢失和RTO发生在同一往返时间内时，Eifel检测可能产生与F-RTO不同的结果[SKR03]。
- Retransmit data from the tail of the retransmission queue and continue with step 3 of the F-RTO algorithm. It is possible that the retransmission will be made unnecessarily. Thus, this option is not encouraged, except for hosts that are known to operate in an environment that is prone to spurious timeouts. On the other hand, with this method it is possible to limit unnecessary retransmissions due to spurious timeout to one retransmission.
- 从重传队列的尾部重传数据，并继续执行F-RTO算法的步骤3。可能会进行不必要的重新传输。因此，不鼓励使用此选项，但已知在容易出现虚假超时的环境中运行的主机除外。另一方面，通过该方法，可以将由于虚假超时而导致的不必要的重传限制为一次重传。
- Send a zero-sized segment below SND.UNA, similar to TCP Keep-Alive probe, and continue with step 3 of the F-RTO algorithm. Because the receiver replies with a duplicate ACK, the sender is able to detect whether the timeout was spurious from the incoming acknowledgment. This method does not send data unnecessarily, but it delays the recovery by one round-trip time in cases where the timeout was not spurious. Therefore, this method is not encouraged.
- 在SND.UNA下面发送一个零大小的段，类似于TCP Keep Alive probe，并继续执行F-RTO算法的步骤3。因为接收者回复了一个重复的ACK，发送者能够从传入的确认中检测超时是否是虚假的。此方法不会不必要地发送数据，但在超时不是虚假的情况下，它会将恢复延迟一个往返时间。因此，不鼓励采用这种方法。
- In receiver-limited cases, send one octet of new data, regardless of the advertised window limit, and continue with step 3 of the F-RTO algorithm. It is possible that the receiver will have free buffer space to receive the data by the time the segment has propagated through the network, in which case no harm is done. If the receiver is not capable of receiving the segment, it rejects the segment and sends a duplicate ACK.
- 在接收器有限的情况下，发送一个八位字节的新数据，而不考虑公布的窗口限制，并继续执行F-RTO算法的步骤3。当数据段通过网络传播时，接收器可能有空闲的缓冲区空间来接收数据，在这种情况下不会造成伤害。如果接收器不能接收该段，它将拒绝该段并发送一个重复的ACK。
Authors' Addresses
作者地址
Pasi Sarolahti Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland
诺基亚研究中心邮政信箱407 FIN-00045芬兰诺基亚集团
Phone: +358 50 4876607
EMail: pasi.sarolahti@nokia.com
http://www.cs.helsinki.fi/u/sarolaht/
Phone: +358 50 4876607
EMail: pasi.sarolahti@nokia.com
http://www.cs.helsinki.fi/u/sarolaht/
Markku Kojo University of Helsinki Department of Computer Science P.O. Box 68 FIN-00014 UNIVERSITY OF HELSINKI Finland
芬兰赫尔辛基大学计算机科学系P.O盒68 FIF-000 014赫尔辛基大学
Phone: +358 9 191 51305
EMail: kojo@cs.helsinki.fi
Phone: +358 9 191 51305
EMail: kojo@cs.helsinki.fi
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。