Network Working Group S. Floyd
Request for Comments: 2582 ACIRI
Category: Experimental T. Henderson
U.C. Berkeley
April 1999
Network Working Group S. Floyd
Request for Comments: 2582 ACIRI
Category: Experimental T. Henderson
U.C. Berkeley
April 1999
The NewReno Modification to TCP's Fast Recovery Algorithm
TCP快速恢复算法的NewReno改进
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].
RFC 2001[RFC2001]记录了以下四种相互交织的TCP拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复。RFC 2581[RFC2581]明确允许对这些算法进行某些修改，包括使用TCP选择性确认（SACK）选项[MMFR96]的修改，以及在没有SACK的情况下响应“部分确认”（包括新数据的确认，但不是检测到丢失时所有未完成的数据）的修改。本文档描述了一种用于响应部分确认的特定算法，称为NewReno。这种对部分承认的回应最初是由Janey Hoe在[Hoe95]中提出的。
For the typical implementation of the TCP Fast Recovery algorithm described in [RFC2581] (first implemented in the 1990 BSD Reno release, and referred to as the Reno algorithm in [FF96]), the TCP data sender only retransmits a packet after a retransmit timeout has occurred, or after three duplicate acknowledgements have arrived triggering the Fast Retransmit algorithm. A single retransmit timeout might result in the retransmission of several data packets, but each invocation of the Reno Fast Retransmit algorithm leads to the retransmission of only a single data packet.
对于[RFC2581]中描述的TCP快速恢复算法的典型实现（首先在1990年BSD Reno版本中实现，在[FF96]中称为Reno算法），TCP数据发送方仅在发生重新传输超时后重新传输数据包，或者在三次重复确认到达后触发快速重传算法。单个重传超时可能会导致多个数据包的重传，但每次调用雷诺快速重传算法都只会导致单个数据包的重传。
Problems can arise, therefore, when multiple packets have been dropped from a single window of data and the Fast Retransmit and Fast Recovery algorithms are invoked. In this case, if the SACK option is available, the TCP sender has the information to make intelligent decisions about which packets to retransmit and which packets not to retransmit during Fast Recovery. This document applies only for TCP connections that are unable to use the TCP Selective Acknowledgement (SACK) option.
因此，当从单个数据窗口丢弃多个数据包并调用快速重传和快速恢复算法时，可能会出现问题。在这种情况下，如果SACK选项可用，TCP发送方就可以在快速恢复期间智能地决定哪些数据包要重新传输，哪些数据包不需要重新传输。本文档仅适用于无法使用TCP选择性确认（SACK）选项的TCP连接。
In the absence of SACK, there is little information available to the TCP sender in making retransmission decisions during Fast Recovery. From the three duplicate acknowledgements, the sender infers a packet loss, and retransmits the indicated packet. After this, the data sender could receive additional duplicate acknowledgements, as the data receiver acknowledges additional data packets that were already in flight when the sender entered Fast Retransmit.
在没有SACK的情况下，TCP发送方在快速恢复期间做出重传决策时几乎没有可用的信息。从三个重复确认中，发送方推断出数据包丢失，并重新传输所指示的数据包。在此之后，数据发送方可以接收额外的重复确认，因为数据接收方确认发送方进入快速重传时已经在传输中的额外数据包。
In the case of multiple packets dropped from a single window of data, the first new information available to the sender comes when the sender receives an acknowledgement for the retransmitted packet (that is the packet retransmitted when Fast Retransmit was first entered). If there had been a single packet drop, then the acknowledgement for this packet will acknowledge all of the packets transmitted before Fast Retransmit was entered (in the absence of reordering). However, when there were multiple packet drops, then the acknowledgement for the retransmitted packet will acknowledge some but not all of the packets transmitted before the Fast Retransmit. We call this packet a partial acknowledgment.
在从单个数据窗口丢弃多个数据包的情况下，当发送方接收到对重传数据包的确认时，发送方可用的第一个新信息出现（即，当首次输入快速重传时重传的数据包）。如果存在单个数据包丢弃，则该数据包的确认将确认在输入快速重传之前传输的所有数据包（在没有重新排序的情况下）。然而，当存在多个分组丢弃时，则对重传分组的确认将确认在快速重传之前发送的部分但不是全部分组。我们称此数据包为部分确认。
Along with several other suggestions, [Hoe95] suggested that during Fast Recovery the TCP data sender respond to a partial acknowledgment by inferring that the indicated packet has been lost, and retransmitting that packet. This document describes a modification to the Fast Recovery algorithm in Reno TCP that incorporates a response to partial acknowledgements received during Fast Recovery. We call this modified Fast Recovery algorithm NewReno, because it is a slight but significant variation of the basic Reno algorithm. This document does not discuss the other suggestions in [Hoe95] and [Hoe96], such as a change to the ssthresh parameter during Slow-Start, or the proposal to send a new packet for every two duplicate acknowledgements during Fast Recovery. The version of NewReno in this document also draws on other discussions of NewReno in the literature [LM97].
与其他一些建议一样，[Hoe95]建议在快速恢复期间，TCP数据发送方通过推断指示的数据包已丢失并重新传输该数据包来响应部分确认。本文档描述了对Reno TCP中快速恢复算法的修改，该算法包含对快速恢复期间接收到的部分确认的响应。我们称这种改进的快速恢复算法为NewReno，因为它是基本Reno算法的一个微小但显著的变化。本文件不讨论[Hoe95]和[Hoe96]中的其他建议，例如在慢速启动期间更改ssthresh参数，或建议在快速恢复期间每两次重复确认发送一个新数据包。本文中的NewReno版本还借鉴了文献[LM97]中对NewReno的其他讨论。
We do not claim that the NewReno version of Fast Recovery described here is an optimal modification of Fast Recovery for responding to partial acknowledgements, for TCPs that are unable to use SACK. Based on our experiences with the NewReno modification in the NS
对于无法使用SACK的TCP，我们并不声称此处描述的NewReno版本的快速恢复是对快速恢复的最佳修改，用于响应部分确认。根据我们在NS中的NewReno改造经验
simulator [NS], we believe that this modification improves the performance of the Fast Retransmit and Fast Recovery algorithms in a wide variety of scenarios, and we are simply documenting it for the benefit of the IETF community. We encourage the use of this modification to Fast Recovery, and we further encourage feedback about operational experiences with this or related modifications.
模拟器[NS]，我们相信，这一修改提高了各种场景中快速重传和快速恢复算法的性能，我们只是为了IETF社区的利益对其进行记录。我们鼓励使用此修改来实现快速恢复，并进一步鼓励反馈有关此修改或相关修改的操作经验。
This document assumes that the reader is familiar with the terms MAXIMUM SEGMENT SIZE (MSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE (FlightSize) defined in [RFC2581]. FLIGHT SIZE is defined as in [RFC2581] as follows:
本文件假设读者熟悉[RFC2581]中定义的术语最大航段大小（MSS）、拥挤窗口（cwnd）和航班大小（FlightSize）。航班大小定义见[RFC2581]，如下所示：
FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged.
航班大小：已发送但尚未确认的数据量。
The standard implementation of the Fast Retransmit and Fast Recovery algorithms is given in [RFC2581]. The NewReno modification of these algorithms is given below. This NewReno modification differs from the implementation in [RFC2581] only in the introduction of the variable "recover" in step 1, and in the response to a partial or new acknowledgement in step 5. The modification defines a "Fast Recovery procedure" that begins when three duplicate ACKs are received and ends when either a retransmission timeout occurs or an ACK arrives that acknowledges all of the data up to and including the data that was outstanding when the Fast Recovery procedure began.
[RFC2581]中给出了快速重传和快速恢复算法的标准实现。下面给出了这些算法的NewReno修改。此NewReno修改与[RFC2581]中的实现不同之处在于，在步骤1中引入了变量“recover”，并在步骤5中响应部分或新确认。该修改定义了一个“快速恢复过程”，该过程在收到三个重复的ACK时开始，在发生重传超时或ACK到达时结束，ACK确认所有数据，包括快速恢复过程开始时未完成的数据。
1. When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, set ssthresh to no more than the value given in equation 1 below. (This is equation 3 from [RFC2581]).
1. 当接收到第三个重复ACK且发送方尚未处于快速恢复过程中时，将ssthresh设置为不大于下面等式1中给出的值。（这是[RFC2581]中的方程式3）。
ssthresh = max (FlightSize / 2, 2*MSS) (1)
ssthresh = max (FlightSize / 2, 2*MSS) (1)
Record the highest sequence number transmitted in the variable "recover".
记录变量“recover”中传输的最高序列号。
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered.
2. 重新传输丢失的段，并将cwnd设置为ssthresh加上3*MSS。这会通过离开网络并由接收方缓冲的段数（三个）人为地“膨胀”拥塞窗口。
3. For each additional duplicate ACK received, increment cwnd by MSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.
3. 对于接收到的每个额外的重复ACK，MSS增加cwnd。这会人为地增大拥塞窗口，以反映已离开网络的附加网段。
4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window.
4. 如果cwnd的新值和接收器的播发窗口允许，则发送一个段。
5. When an ACK arrives that acknowledges new data, this ACK could be the acknowledgment elicited by the retransmission from step 2, or elicited by a later retransmission.
5. 当确认新数据的ACK到达时，该ACK可以是由步骤2的重新传输引起的确认，或者由稍后的重新传输引起的确认。
If this ACK acknowledges all of the data up to and including "recover", then the ACK acknowledges all the intermediate segments sent between the original transmission of the lost segment and the receipt of the third duplicate ACK. Set cwnd to either (1) min (ssthresh, FlightSize + MSS); or (2) ssthresh, where ssthresh is the value set in step 1; this is termed "deflating" the window. (We note that "FlightSize" in step 1 referred to the amount of data outstanding in step 1, when Fast Recovery was entered, while "FlightSize" in step 5 refers to the amount of data outstanding in step 5, when Fast Recovery is exited.) If the second option is selected, the implementation should take measures to avoid a possible burst of data, in case the amount of data outstanding in the network was much less than the new congestion window allows [HTH98]. Exit the Fast Recovery procedure.
如果此ACK确认“恢复”之前（包括“恢复”）的所有数据，则ACK确认在丢失段的原始传输和第三个重复ACK的接收之间发送的所有中间段。将cwnd设置为一（1）分钟（ssthresh、FlightSize+MSS）；或（2）ssthresh，其中ssthresh是在步骤1中设置的值；这被称为“放气”窗口。（我们注意到，步骤1中的“FlightSize”指的是进入快速恢复时步骤1中未完成的数据量，而步骤5中的“FlightSize”指的是退出快速恢复时步骤5中未完成的数据量。）如果选择了第二个选项，实施应采取措施避免可能的数据突发，如果网络中未完成的数据量远远小于新拥塞窗口允许的数据量[HTH98]。退出快速恢复过程。
If this ACK does *not* acknowledge all of the data up to and including "recover", then this is a partial ACK. In this case, retransmit the first unacknowledged segment. Deflate the congestion window by the amount of new data acknowledged, then add back one MSS and send a new segment if permitted by the new value of cwnd. This "partial window deflation" attempts to ensure that, when Fast Recovery eventually ends, approximately ssthresh amount of data will be outstanding in the network. Do not exit the Fast Recovery procedure (i.e., if any duplicate ACKs subsequently arrive, execute Steps 3 and 4 above).
如果此确认*未*确认“恢复”之前（包括“恢复”）的所有数据，则此确认为部分确认。在这种情况下，重新传输第一个未确认的段。根据确认的新数据量对拥塞窗口进行放气，然后加回一个MSS，如果cwnd的新值允许，则发送一个新段。这种“部分窗口压缩”试图确保，当快速恢复最终结束时，网络中大约有ssthresh数量的数据将处于未处理状态。不要退出快速恢复过程（即，如果任何重复的ACK随后到达，请执行上述步骤3和4）。
For the first partial ACK that arrives during Fast Recovery, also reset the retransmit timer.
对于在快速恢复期间到达的第一个部分ACK，也重置重传计时器。
Note that in Step 5, the congestion window is deflated when a partial acknowledgement is received. The congestion window was likely to have been inflated considerably when the partial acknowledgement was received. In addition, depending on the original pattern of packet losses, the partial acknowledgement might acknowledge nearly a window of data. In this case, if the congestion window was not deflated, the data sender might be able to send nearly a window of data back-to-back.
注意，在步骤5中，当接收到部分确认时，拥塞窗口被缩小。当接收到部分确认时，拥塞窗口很可能已经大大膨胀。此外，根据分组丢失的原始模式，部分确认可能确认几乎一个数据窗口。在这种情况下，如果拥塞窗口没有缩小，那么数据发送方可能能够背靠背地发送几乎一个数据窗口。
There are several possible variants to the simple response to partial
对于部分响应的简单响应，有几种可能的变体
acknowledgements described above. First, there is a question of when to reset the retransmit timer after a partial acknowledgement. This is discussed further in Section 4 below.
上述确认。首先，存在在部分确认之后何时重置重传计时器的问题。下文第4节将对此进行进一步讨论。
There is a related question of how many packets to retransmit after each partial acknowledgement. The algorithm described above retransmits a single packet after each partial acknowledgement. This is the most conservative alternative, in that it is the least likely to result in an unnecessarily-retransmitted packet. A variant that would recover faster from a window with many packet drops would be to effectively Slow-Start, requiring less than N roundtrip times to recover from N losses [Hoe96]. With this slightly-more-aggressive response to partial acknowledgements, it would be advantageous to reset the retransmit timer after each retransmission. Because we have not experimented with this variant in our simulator, we do not discuss this variant further in this document.
还有一个相关的问题，即在每次部分确认之后要重新传输多少数据包。上述算法在每个部分确认之后重新传输单个分组。这是最保守的选择，因为它最不可能导致不必要的重传数据包。一种能从具有多个丢包的窗口中更快恢复的变体是有效地降低启动速度，需要不到N次的往返时间才能从N次丢失中恢复[Hoe96]。对于部分确认的这种稍微更积极的响应，在每次重传之后重置重传计时器将是有利的。因为我们没有在模拟器中试验过这种变体，所以在本文档中不再进一步讨论这种变体。
A third question involves avoiding multiple Fast Retransmits caused by the retransmission of packets already received by the receiver. This is discussed in Section 5 below. Avoiding multiple Fast Retransmits is particularly important if more aggressive responses to partial acknowledgements are implemented, because in this case the sender is more likely to retransmit packets already received by the receiver.
第三个问题涉及避免由接收器已经接收的分组的重传引起的多个快速重传。下文第5节对此进行了讨论。如果对部分确认实施了更积极的响应，则避免多次快速重传尤其重要，因为在这种情况下，发送方更有可能重传接收方已经接收到的数据包。
As a final note, we would observe that in the absence of the SACK option, the data sender is working from limited information. One could spend a great deal of time considering exactly which variant of Fast Recovery is optimal for which scenario in this case. When the issue of recovery from multiple dropped packets from a single window of data is of particular importance, the best alternative would be to use the SACK option.
最后，我们注意到，在没有SACK选项的情况下，数据发送者使用的是有限的信息。在这种情况下，您可能会花费大量时间来考虑哪种快速恢复变体最适合于哪种场景。当从单个数据窗口的多个丢弃数据包中恢复的问题特别重要时，最好的替代方法是使用SACK选项。
4. Resetting the retransmit timer.
4. 重置重传计时器。
The algorithm in Section 3 resets the retransmit timer only after the first partial ACK. In this case, if a large number of packets were dropped from a window of data, the TCP data sender's retransmit timer will ultimately expire, and the TCP data sender will invoke Slow-Start. (This is illustrated on page 12 of [F98].) We call this the Impatient variant of NewReno.
第3节中的算法仅在第一次部分确认之后重置重传计时器。在这种情况下，如果从数据窗口丢弃了大量数据包，TCP数据发送方的重传计时器将最终过期，TCP数据发送方将调用慢速启动。（见[F98]第12页）我们称之为NewReno的不耐烦变体。
In contrast, the NewReno simulations in [FF96] illustrate the algorithm described above, with the modification that the retransmit timer is reset after each partial acknowledgement. We call this the Slow-but-Steady variant of NewReno. In this case, for a window with a large number of packet drops, the TCP data sender retransmits at most one packet per roundtrip time. (This behavior is illustrated in
相比之下，[FF96]中的NewReno模拟说明了上述算法，修改后的重传计时器在每次部分确认后重置。我们称之为NewReno缓慢但稳定的变体。在这种情况下，对于具有大量丢包的窗口，TCP数据发送方在每次往返时间最多重新传输一个数据包。（此行为如中所示
the New-Reno TCP simulation of Figure 5 in [FF96], and on page 11 of [F98].)
[FF96]和[F98]第11页图5的新雷诺TCP模拟。）
For TCP implementations where the Retransmission Timeout Value (RTO) is generally not much larger than the round-trip time (RTT), the Impatient variant can result in a retransmit timeout even in a scenario with a small number of packet drops. For TCP implementations where the Retransmission Timeout Value (RTO) is usually considerably larger than the round-trip time (RTT), the Slow-but-Steady variant can remain in Fast Recovery for a long time when multiple packets have been dropped from a window of data. Neither of these variants are optimal; one possibility for a more optimal algorithm might be one that recovered more quickly from multiple packet drops, and combined this with the Slow-but-Steady variant in terms of resetting the retransmit timers. We note, however, that there is a limitation to the potential performance in this case in the absence of the SACK option.
对于重传超时值（RTO）通常不远大于往返时间（RTT）的TCP实现，即使在丢包次数较少的情况下，不耐烦的变体也可能导致重传超时。对于重传超时值（RTO）通常远大于往返时间（RTT）的TCP实现，当从数据窗口丢弃多个数据包时，缓慢但稳定的变量可以在很长一段时间内保持快速恢复。这两种变体都不是最优的；一种更为优化的算法可能是从多个数据包丢失中更快地恢复，并将其与重置重传计时器方面的缓慢但稳定的变化相结合。然而，我们注意到，在没有SACK选项的情况下，这种情况下的潜在性能受到限制。
In the absence of the SACK option, a duplicate acknowledgement carries no information to identify the data packet or packets at the TCP data receiver that triggered that duplicate acknowledgement. The TCP data sender is unable to distinguish between a duplicate acknowledgement that results from a lost or delayed data packet, and a duplicate acknowledgement that results from the sender's retransmission of a data packet that had already been received at the TCP data receiver. Because of this, multiple segment losses from a single window of data can sometimes result in unnecessary multiple Fast Retransmits (and multiple reductions of the congestion window) [Flo94].
在没有SACK选项的情况下，重复确认不携带识别触发该重复确认的TCP数据接收器处的数据分组的信息。TCP数据发送方无法区分丢失或延迟数据包导致的重复确认和发送方重新传输TCP数据接收方已接收的数据包导致的重复确认。因此，单个数据窗口的多段丢失有时会导致不必要的多次快速重传（以及拥塞窗口的多次减少）[Flo94]。
With the Fast Retransmit and Fast Recovery algorithms in Reno or NewReno TCP, the performance problems caused by multiple Fast Retransmits are relatively minor (compared to the potential problems with Tahoe TCP, which does not implement Fast Recovery). Nevertheless, unnecessary Fast Retransmits can occur with Reno or NewReno TCP, particularly if a Retransmit Timeout occurs during Fast Recovery. (This is illustrated for Reno on page 6 of [F98], and for NewReno on page 8 of [F98].) With NewReno, the data sender remains in Fast Recovery until either a Retransmit Timeout, or until all of the data outstanding when Fast Retransmit was entered has been acknowledged. Thus with NewReno, the problem of multiple Fast Retransmits from a single window of data can only occur after a Retransmit Timeout.
使用Reno或NewReno TCP中的快速重传和快速恢复算法，多次快速重传造成的性能问题相对较小（与Tahoe TCP的潜在问题相比，后者不实现快速恢复）。然而，Reno或NewReno TCP可能会发生不必要的快速重传，特别是在快速恢复期间发生重传超时时。（对于[F98]第6页上的Reno和[F98]第8页上的NewReno，都说明了这一点。）对于NewReno，数据发送方将保持快速恢复状态，直到重新传输超时或确认输入快速重新传输时所有未完成的数据。因此，对于NewReno，从单个数据窗口多次快速重传的问题只能在重传超时后发生。
The following modification to the algorithms in Section 3 eliminates the problem of multiple Fast Retransmits. (This modification is
以下对第3节中算法的修改消除了多次快速重传的问题。（此修改是
called "bugfix" in [F98], and is illustrated on pages 7 and 9.) This modification uses a new variable "send_high", whose initial value is the initial send sequence number. After each retransmit timeout, the highest sequence numbers transmitted so far is recorded in the variable "send_high".
在[F98]中称为“bugfix”，如第7页和第9页所示。）此修改使用新变量“send_high”，其初始值为初始发送序列号。每次重新传输超时后，迄今为止传输的最高序列号记录在变量“send_high”中。
If, after a retransmit timeout, the TCP data sender retransmits three consecutive packets that have already been received by the data receiver, then the TCP data sender will receive three duplicate acknowledgements that do not acknowledge "send_high". In this case, the duplicate acknowledgements are not an indication of a new instance of congestion. They are simply an indication that the sender has unnecessarily retransmitted at least three packets.
如果在重新传输超时后，TCP数据发送方重新传输数据接收方已经接收到的三个连续数据包，则TCP数据发送方将收到三个不确认“发送高”的重复确认。在这种情况下，重复确认并不表示新的拥塞实例。它们只是表明发送方不必要地重新传输了至少三个数据包。
We note that if the TCP data sender receives three duplicate acknowledgements that do not acknowledge "send_high", the sender does not know whether these duplicate acknowledgements resulted from a new packet drop or not. For a TCP that implements the bugfix described in this section for avoiding multiple fast retransmits, the sender does not infer a packet drop from duplicate acknowledgements in these circumstances. As always, the retransmit timer is the backup mechanism for inferring packet loss in this case.
我们注意到，如果TCP数据发送方收到三个不确认“send_high”的重复确认，则发送方不知道这些重复确认是否由新的数据包丢弃引起。对于实现本节中描述的错误修复以避免多次快速重传的TCP，发送方在这些情况下不会从重复确认推断数据包丢失。一如既往，在这种情况下，重传计时器是推断数据包丢失的备份机制。
The modification to Fast Retransmit for avoiding multiple Fast Retransmits replaces Step 1 in Section 3 with Step 1A below. In addition, the modification adds Step 6 below:
为避免多次快速重传而对快速重传的修改将第3节中的步骤1替换为下面的步骤1A。此外，修改增加了以下步骤6：
1A. When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, check to see if those duplicate ACKs cover more than "send_high". If they do, then set ssthresh to no more than the value given in equation 1, record the the highest sequence number transmitted in the variable "recover", and go to Step 2. If the duplicate ACKs don't cover "send_high", then do nothing. That is, do not enter the Fast Retransmit and Fast Recovery procedure, do not change ssthresh, do not go to Step 2 to retransmit the "lost" segment, and do not execute Step 3 upon subsequent duplicate ACKs.
1A。当收到第三个重复ACK且发送方尚未处于快速恢复过程中时，检查这些重复ACK是否超过“发送高”。如果是，则将ssthresh设置为不超过等式1中给出的值，记录变量“recover”中传输的最高序列号，并转至步骤2。如果复制的ACK没有覆盖“发送高”，则什么也不做。也就是说，不要进入快速重传和快速恢复过程，不要更改ssthresh，不要转到步骤2重传“丢失”的段，并且不要在后续重复确认时执行步骤3。
Steps 2-5 are the same as those steps in Section 3 above.
步骤2-5与上述第3节中的步骤相同。
6. After a retransmit timeout, record the highest sequence number transmitted in the variable "send_high" and exit the Fast Recovery procedure if applicable.
6. 在重新传输超时后，记录变量“send_high”中传输的最高序列号，并退出快速恢复程序（如果适用）。
Step 1A above, in checking whether the duplicate ACKs cover *more* than "send_high", is the Careful variant of this algorithm. Another possible variant would be to require simply that the three duplicate
上面的步骤1A，在检查重复ACKs是否覆盖*多于*而不是“send_high”时，是该算法的谨慎变体。另一个可能的变体是只要求三个重复的
acknowledgements *cover* "send_high" before initiating another Fast Retransmit. We call this the Less Careful variant to Fast Retransmit.
确认*覆盖*“发送高”，然后启动另一个快速重新传输。我们称之为不太小心的快速重传变体。
There are two separate scenarios in which the TCP sender could receive three duplicate acknowledgements acknowledging "send_high" but no more than "send_high". One scenario would be that the data sender transmitted four packets with sequence numbers higher than "send_high", that the first packet was dropped in the network, and the following three packets triggered three duplicate acknowledgements acknowledging "send_high". The second scenario would be that the sender unnecessarily retransmitted three packets below "send_high", and that these three packets triggered three duplicate acknowledgements acknowledging "send_high". In the absence of SACK, the TCP sender in unable to distinguish between these two scenarios.
有两种不同的情况，在这两种情况下，TCP发送方可以收到三个重复的确认，确认“发送\u高”，但不超过“发送\u高”。一种情况是，数据发送方发送了四个序列号高于“send_high”的数据包，第一个数据包在网络中被丢弃，接下来的三个数据包触发了确认“send_high”的三次重复确认。第二种情况是，发送方不必要地重新传输了“send_high”以下的三个数据包，并且这三个数据包触发了确认“send_high”的三个重复确认。在没有SACK的情况下，中的TCP发送方无法区分这两种情况。
For the Careful variant of Fast Retransmit, the data sender would have to wait for a retransmit timeout in the first scenario, but would not have an unnecessary Fast Retransmit in the second scenario. For the Less Careful variant to Fast Retransmit, the data sender would Fast Retransmit as desired in the first scenario, and would unnecessarily Fast Retransmit in the second scenario. The NS simulator has implemented the Less Careful variant of NewReno, and the TCP implementation in Sun's Solaris 7 implements the Careful variant. This document recommends the Careful variant given in Step 1A above.
对于快速重传的谨慎变体，在第一个场景中，数据发送方必须等待重传超时，但在第二个场景中不会有不必要的快速重传。对于不太小心的快速重传变体，数据发送方将在第一个场景中按照所需进行快速重传，而在第二个场景中不必要地进行快速重传。NS模拟器实现了不太谨慎的NewReno变体，Sun的Solaris 7中的TCP实现实现了谨慎的变体。本文件建议采用上述步骤1A中给出的谨慎变体。
6. Implementation issues for the data receiver.
6. 数据接收器的实现问题。
[RFC2001] specifies that "Out-of-order data segments SHOULD be acknowledged immediately, in order to trigger the fast retransmit algorithm." Neal Cardwell has noted [C98] that some data receivers do not send an immediate acknowledgement when they send a partial acknowledgment, but instead wait first for their delayed acknowledgement timer to expire. As [C98] notes, this severely limits the potential benefit from NewReno by delaying the receipt of the partial acknowledgement at the data sender. Our recommendation is that the data receiver send an immediate acknowledgement for an out-of-order segment, even when that out-of-order segment fills a hole in the buffer.
[RFC2001]规定“应立即确认无序数据段，以触发快速重传算法。”Neal Cardwell指出[C98]，一些数据接收器在发送部分确认时不发送即时确认，而是先等待延迟的确认计时器过期。正如[C98]所指出的，这严重限制了NewReno的潜在好处，因为它延迟了数据发送方对部分确认的接收。我们的建议是，数据接收器立即发送对无序段的确认，即使该无序段填满了缓冲区中的一个洞。
Simulations with NewReno are illustrated with the validation test "tcl/test/test-all-newreno" in the NS simulator. The command "../../ns test-suite-newreno.tcl reno" shows a simulation with Reno TCP, illustrating the data sender's lack of response to a partial
通过NS模拟器中的验证测试“tcl/test/test all NewReno”说明了NewReno的模拟。命令“../../ns test-suite-newreno.tcl-reno”显示了使用reno TCP的模拟，说明了数据发送方对部分错误没有响应
acknowledgement. In contrast, the command "../../ns test-suite-newreno.tcl newreno_B" shows a simulation with the same scenario using the NewReno algorithms described in this paper.
确认相反，命令“../../ns test-suite-newreno.tcl newreno_B”显示了使用本文描述的newreno算法对相同场景的模拟。
The tests "../../ns test-suite-newreno.tcl newreno1_B0" and "../../ns test-suite-newreno.tcl newreno1_B" show the Slow-but-Steady and the Impatient variants of NewReno, respectively.
测试“../../ns test-suite-newreno.tcl newreno1_B0”和“../../ns test-suite-newreno.tcl newreno1_B”分别显示了newreno的缓慢但稳定和不耐烦的变体。
Our recommendation is that TCP implementations include the NewReno modification to the Fast Recovery algorithm given in Section 3, along with the modification for avoiding multiple Fast Retransmits given in Section 5. The NewReno modification given in Section 3 can be important even for TCP implementations that support the SACK option, because the SACK option can only be used for TCP connections when both TCP end-nodes support the SACK option. The NewReno modification given in Section 3 implements the Impatient rather than the Slow-but-Steady variant of NewReno.
我们建议TCP实现包括第3节中给出的对快速恢复算法的NewReno修改，以及第5节中给出的避免多次快速重传的修改。即使对于支持SACK选项的TCP实现，第3节中给出的NewReno修改也可能很重要，因为只有当两个TCP端节点都支持SACK选项时，SACK选项才能用于TCP连接。第3节中给出的NewReno修改实现了NewReno的不耐烦变体，而不是缓慢但稳定的变体。
While this document mentions several possible variations to the NewReno algorithm, we have not explored all of these possible variations, and therefore are unable to make recommendations about some of them. Our belief is that the differences between any two variants of NewReno are small compared to the differences between Reno and NewReno. That is, the important thing is to implement NewReno instead of Reno, for a TCP invocation without SACK; it is less important exactly which variant of NewReno is implemented.
虽然本文件提到了NewReno算法的几种可能的变化，但我们尚未探讨所有这些可能的变化，因此无法对其中一些变化提出建议。我们相信，与雷诺和NewReno之间的差异相比，NewReno的任何两种变体之间的差异都很小。也就是说，重要的是实现NewReno而不是Reno，因为TCP调用没有SACK；确切地说，实现哪个NewReno变体并不重要。
Many thanks to Anil Agarwal, Mark Allman, Vern Paxson, Kacheong Poon, and Bernie Volz for detailed feedback on this document.
非常感谢Anil Agarwal、Mark Allman、Vern Paxson、Kacheong Poon和Bernie Volz对本文件的详细反馈。
[C98] Neal Cardwell, "delayed ACKs for retransmitted packets: ouch!". November 1998. Email to the tcpimpl mailing list, Message-ID "Pine.LNX.4.02A.9811021421340.26785- 100000@sake.cs.washington.edu", archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[C98]Neal Cardwell，“重传数据包的延迟确认：哎哟！”。1998年11月。发送至tcpimpl邮件列表的电子邮件，邮件ID“Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu，存档于http://tcp-impl.lerc.nasa.gov/tcp-impl".
[F98] Sally Floyd. Revisions to RFC 2001. Presentation to the TCPIMPL Working Group, August 1998. URLs "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".
[F98]萨莉·弗洛伊德。对RFC 2001的修订。向TCPIMPL工作组的介绍，1998年8月。“网址”ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps“和”ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".
[FF96] Kevin Fall and Sally Floyd. Simulation-based
[FF96]凯文·法尔和萨莉·弗洛伊德。基于仿真的
Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996. URL "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
Tahoe、Reno和SACK TCP的比较。《计算机通信评论》，1996年7月。URL“ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. URL "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[Flo94]S.Floyd、TCP和连续快速重传。技术报告，1994年10月。URL“ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[Hen98] Tom Henderson, Re: NewReno and the 2001 Revision. September 1998. Email to the tcpimpl mailing list, Message ID "Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU", archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[Hen98]Tom Henderson，Re:NewReno和2001年修订版。1998年9月。发送至tcpimpl邮件列表的电子邮件，邮件ID“Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU，存档于http://tcp-impl.lerc.nasa.gov/tcp-impl".
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995. URL "http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps".
[Hoe95]J.Hoe，TCP拥塞控制和避免方案的启动动力学。硕士论文，麻省理工学院，1995年。URL“http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps".
[Hoe96] J. Hoe, "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", In ACM SIGCOMM, August 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".
[Hoe96]J.Hoe，“改进TCP拥塞控制方案的启动行为”，载于ACM SIGCOMM，1996年8月。URL“http://www.acm.org/sigcomm/sigcomm96/program.html".
[HTH98] Hughes, A., Touch, J. and J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress, March 1998.
[HTH98]Hughes，A.，Touch，J.和J.Heidemann，“空闲后TCP缓慢启动重启的问题”，正在进行的工作，1998年3月。
[LM97] Dong Lin and Robert Morris, "Dynamics of Random Early Detection", SIGCOMM 97, September 1997. URL "http://www.acm.org/sigcomm/sigcomm97/program.html".
[LM97]Dong Lin和Robert Morris，“随机早期检测的动力学”，SIGCOMM 97，1997年9月。URL“http://www.acm.org/sigcomm/sigcomm97/program.html".
[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月。
[NS] The UCB/LBNL/VINT Network Simulator (NS). URL "http://www-mash.cs.berkeley.edu/ns/".
[NS]UCB/LBNL/VINT网络模拟器（NS）。URL“http://www-mash.cs.berkeley.edu/ns/".
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001]Stevens，W.“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
[RFC2581] Stevens, W., Allman, M. and V. Paxson, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Stevens，W.，Allman，M.和V.Paxson，“TCP拥塞控制”，RFC 25811999年4月。
RFC 2581 discusses general security considerations concerning TCP congestion control. This document describes a specific algorithm that conforms with the congestion control requirements of RFC 2581, and so those considerations apply to this algorithm, too. There are no known additional security concerns for this specific algorithm.
RFC2581讨论了有关TCP拥塞控制的一般安全注意事项。本文档描述了一种符合RFC 2581拥塞控制要求的特定算法，因此这些注意事项也适用于该算法。此特定算法没有已知的其他安全问题。
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
萨莉·弗洛伊德美国电话电报公司ICSI互联网研究中心（ACIRI）
Phone: +1 (510) 642-4274 x189
EMail: floyd@acm.org
URL: http://www.aciri.org/floyd/
Phone: +1 (510) 642-4274 x189
EMail: floyd@acm.org
URL: http://www.aciri.org/floyd/
Tom Henderson University of California at Berkeley
亨德森加州大学伯克利分校
Phone: +1 (510) 642-8919
EMail: tomh@cs.berkeley.edu
URL: http://www.cs.berkeley.edu/~tomh/
Phone: +1 (510) 642-8919
EMail: tomh@cs.berkeley.edu
URL: http://www.cs.berkeley.edu/~tomh/
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。