Network Working Group S. Floyd
Request for Comments: 3782 ICSI
Obsoletes: 2582 T. Henderson
Category: Standards Track Boeing
A. Gurtov
TeliaSonera
April 2004
Network Working Group S. Floyd
Request for Comments: 3782 ICSI
Obsoletes: 2582 T. Henderson
Category: Standards Track Boeing
A. Gurtov
TeliaSonera
April 2004
The NewReno Modification to TCP's Fast Recovery Algorithm
TCP快速恢复算法的NewReno改进
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
本文档的目的是将NewReno TCP在RFC 2582中的快速重传和快速恢复算法从实验状态提升到标准状态。
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP.
与RFC 2582相比，本文档的主要变化是详细说明了NewReno的快速重传和快速恢复算法。RFC 2582中描述的基本算法没有试图避免超时后可能发生的不必要的多次快速重传。然而，RFC 2582还定义了避免这些不必要的快速重传的“小心”和“不太小心”变体，并建议使用小心变体。本文档指定先前命名的“小心”变体作为NewReno TCP的基本版本。
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 Fast Retransmit algorithm in RFC 2581 leads to the retransmission of only a single data packet.
对于[RFC2581]中描述的TCP快速恢复算法的典型实现（首先在1990年BSD Reno版本中实现，在[FF96]中称为Reno算法），TCP数据发送方仅在发生重新传输超时后重新传输数据包，或者在三次重复确认到达后触发快速重传算法。单个重传超时可能导致多个数据包的重传，但RFC 2581中快速重传算法的每次调用都只导致单个数据包的重传。
Problems can arise, therefore, when multiple packets are 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, either because the option is not locally supported or because the TCP peer did not indicate a willingness to use SACK.
因此，当从单个数据窗口丢弃多个数据包并调用快速重传和快速恢复算法时，可能会出现问题。在这种情况下，如果SACK选项可用，TCP发送方就可以在快速恢复期间智能地决定哪些数据包要重新传输，哪些数据包不需要重新传输。本文档仅适用于无法使用TCP选择性确认（SACK）选项的TCP连接，因为该选项在本地不受支持，或者TCP对等方未表示愿意使用SACK。
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 is a single packet drop and no reordering, then the acknowledgement for this packet will acknowledge all of the packets transmitted before Fast Retransmit was entered. However, if there are 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 acknowledgement a partial acknowledgment.
在从单个数据窗口丢弃多个分组的情况下，当发送方接收到对重传分组的确认时（即，当首次输入快速重传时重传的分组），发送方可用的第一个新信息出现。如果存在单个数据包丢弃且没有重新排序，则该数据包的确认将确认在输入快速重传之前发送的所有数据包。然而，如果存在多个分组丢弃，则对重传分组的确认将确认在快速重传之前发送的一些但不是全部分组。我们称此确认为部分确认。
Along with several other suggestions, [Hoe95] suggested that during Fast Recovery the TCP data sender responds to a partial acknowledgment by inferring that the next in-sequence packet has been lost, and retransmitting that packet. This document describes a modification to the Fast Recovery algorithm in RFC 2581 that incorporates a response to partial acknowledgements received during
与其他一些建议一样，[Hoe95]建议，在快速恢复期间，TCP数据发送方通过推断序列中的下一个数据包已丢失并重新传输该数据包来响应部分确认。本文档描述了对RFC 2581中的快速恢复算法的修改，该算法包含了对过程中接收到的部分确认的响应
Fast Recovery. We call this modified Fast Recovery algorithm NewReno, because it is a slight but significant variation of the basic Reno algorithm in RFC 2581. 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, Hen98].
快速恢复。我们称这种改进的快速恢复算法为NewReno，因为它是RFC2581中基本Reno算法的一个微小但显著的变化。本文件不讨论[Hoe95]和[Hoe96]中的其他建议，例如在慢速启动期间更改ssthresh参数，或建议在快速恢复期间每两次重复确认发送一个新数据包。本文件中的NewReno版本还借鉴了文献中对NewReno的其他讨论[LM97，Hen98]。
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 TCP connections that are unable to use SACK. Based on our experiences with the NewReno modification in the NS simulator [NS] and with numerous implementations of NewReno, we believe that this modification improves the performance of the Fast Retransmit and Fast Recovery algorithms in a wide variety of scenarios.
对于无法使用SACK的TCP连接，我们并不认为此处描述的NewReno版本的快速恢复是对快速恢复的最佳修改，用于响应部分确认。根据我们在NS模拟器[NS]中对NewReno进行修改的经验以及NewReno的大量实现，我们相信，这种修改可以提高各种场景中快速重传和快速恢复算法的性能。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. This RFC indicates requirement levels for compliant TCP implementations implementing the NewReno Fast Retransmit and Fast Recovery algorithms described in this document.
在本文件中，关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。该RFC指出了实现本文档中描述的NewReno快速重传和快速恢复算法的兼容TCP实现的要求级别。
This document assumes that the reader is familiar with the terms SENDER MAXIMUM SEGMENT SIZE (SMSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE (FlightSize) defined in [RFC2581]. FLIGHT SIZE is defined as in [RFC2581] as follows:
本文档假设读者熟悉[RFC2581]中定义的术语发送方最大航段大小（SMSS）、拥塞窗口（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]. This section specifies the basic NewReno algorithm. Sections 4 through 6 describe some optional variants, and the motivations behind them, that an implementor may want to consider when tuning performance for certain network scenarios. Sections 7 and 8 provide some guidance to implementors based on experience with NewReno implementations.
[RFC2581]中给出了快速重传和快速恢复算法的标准实现。本节规定了基本的NewReno算法。第4到6节描述了一些可选的变体，以及它们背后的动机，即实现者在调整某些网络场景的性能时可能需要考虑。第7节和第8节根据NewReno实施的经验为实施者提供了一些指导。
The NewReno modification concerns the 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
NewReno修改涉及快速恢复过程，该过程在收到三个重复的ACK时开始，在发生重传超时或确认所有数据的ACK到达时结束
of the data up to and including the data that was outstanding when the Fast Recovery procedure began.
包括快速恢复过程开始时未完成的数据。
The NewReno algorithm specified in this document differs from the implementation in [RFC2581] in the introduction of the variable "recover" in step 1, in the response to a partial or new acknowledgement in step 5, and in modifications to step 1 and the addition of step 6 for avoiding multiple Fast Retransmits caused by the retransmission of packets already received by the receiver.
本文件中规定的NewReno算法与[RFC2581]中的实现不同，在步骤1中引入变量“recover”，在步骤5中响应部分或新确认，以及在对步骤1的修改和步骤6的添加中，用于避免由接收机已经接收的分组的重传引起的多个快速重传。
The algorithm specified in this document uses a variable "recover", whose initial value is the initial send sequence number.
本文档中指定的算法使用变量“recover”，其初始值为初始发送序列号。
1) Three duplicate ACKs: When the third duplicate ACK is received and the sender is not already in the Fast Recovery procedure, check to see if the Cumulative Acknowledgement field covers more than "recover". If so, go to Step 1A. Otherwise, go to Step 1B.
1) 三次重复确认：当收到第三次重复确认且发送方尚未处于快速恢复过程中时，检查累积确认字段是否覆盖“恢复”以上的内容。如果是，则转至步骤1A。否则，转至步骤1B。
1A) Invoking Fast Retransmit: If so, then set ssthresh to no more than the value given in equation 1 below. (This is equation 3 from [RFC2581]).
1A）调用快速重传：如果是，则将ssthresh设置为不超过下面等式1中给出的值。（这是[RFC2581]中的方程式3）。
ssthresh = max (FlightSize / 2, 2*SMSS) (1)
ssthresh = max (FlightSize / 2, 2*SMSS) (1)
In addition, record the highest sequence number transmitted in the variable "recover", and go to Step 2.
此外，记录变量“recover”中传输的最高序列号，并转至步骤2。
1B) Not invoking Fast Retransmit: Do not enter the Fast Retransmit and Fast Recovery procedure. In particular, 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.
1B）不调用快速重传：不要进入快速重传和快速恢复过程。特别是，不要更改ssthresh，不要转到步骤2重新传输“丢失”的段，并且不要在后续重复ACK时执行步骤3。
2) Entering Fast Retransmit: Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and the receiver has buffered.
2) 进入快速重传：重传丢失的段，并将cwnd设置为ssthresh加3*SMSS。这通过离开网络且接收器缓冲的段数（三个）人为地“膨胀”拥塞窗口。
3) Fast Recovery: For each additional duplicate ACK received while in Fast Recovery, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.
3) 快速恢复：对于在快速恢复中收到的每一个额外的重复ACK，SMS增加cwnd。这会人为地增大拥塞窗口，以反映已离开网络的附加网段。
4) Fast Recovery, continued: 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的重新传输引起的确认，或者由稍后的重新传输引起的确认。
Full acknowledgements: 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 + SMSS) 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 is encouraged to take measures to avoid a possible burst of data, in case the amount of data outstanding in the network is much less than the new congestion window allows. A simple mechanism is to limit the number of data packets that can be sent in response to a single acknowledgement; this is known as "maxburst_" in the NS simulator. Exit the Fast Recovery procedure.
完全确认：如果此确认确认“恢复”之前（包括“恢复”）的所有数据，则该确认确认在丢失段的原始传输和第三次重复确认的接收之间发送的所有中间段。将cwnd设置为（1）min（ssthresh，FlightSize+SMSS）或（2）ssthresh，其中ssthresh是步骤1中设置的值；这被称为“放气”窗口。（我们注意到，步骤1中的“FlightSize”指的是输入快速恢复时步骤1中未完成的数据量，而步骤5中的“FlightSize”指的是退出快速恢复时步骤5中未完成的数据量。）如果选择了第二个选项，鼓励实施部门采取措施，避免可能的数据突发，以防网络中未完成的数据量远远小于新的拥塞窗口所允许的数据量。一个简单的机制是限制响应单个确认可以发送的数据包的数量；这在NS模拟器中称为“maxburst”。退出快速恢复过程。
Partial acknowledgements: 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 by the cumulative acknowledgement field. If the partial ACK acknowledges at least one SMSS of new data, then add back SMSS bytes to the congestion window. As in Step 3, this artificially inflates the congestion window in order to reflect the additional segment that has left the network. 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).
部分确认：如果此确认*不*确认“恢复”之前（包括“恢复”）的所有数据，则这是一个部分确认。在这种情况下，重新传输第一个未确认的段。通过累积确认字段确认的新数据量来缩小拥塞窗口。如果部分ACK确认至少一个SMS的新数据，则将SMS字节添加回拥塞窗口。与步骤3一样，这会人为地使拥塞窗口膨胀，以反映已离开网络的附加段。如果cwnd的新值允许，则发送新段。这种“部分窗口压缩”试图确保，当快速恢复最终结束时，网络中大约有ssthresh数量的数据将处于未处理状态。不要退出快速恢复过程（即，如果任何重复的ACK随后到达，请执行上述步骤3和4）。
For the first partial ACK that arrives during Fast Recovery, also reset the retransmit timer. Timer management is discussed in more detail in Section 4.
对于在快速恢复期间到达的第一个部分ACK，也重置重传计时器。第4节将更详细地讨论计时器管理。
6) Retransmit timeouts: After a retransmit timeout, record the highest sequence number transmitted in the variable "recover" and exit the Fast Recovery procedure if applicable.
6) 重新传输超时：在重新传输超时后，记录变量“recover”中传输的最高序列号，并退出快速恢复过程（如果适用）。
Step 1 specifies a check that the Cumulative Acknowledgement field covers more than "recover". Because the acknowledgement field contains the sequence number that the sender next expects to receive, the acknowledgement "ack_number" covers more than "recover" when:
步骤1指定检查累积确认字段覆盖的范围是否超过“恢复”。由于确认字段包含发送方下一步期望接收的序列号，因此在以下情况下，确认“ack_number”所涵盖的范围大于“recover”：
ack_number - 1 > recover;
ack_number - 1 > recover;
i.e., at least one byte more of data is acknowledged beyond the highest byte that was outstanding when Fast Retransmit was last entered.
i、 例如，在上次输入快速重传时未完成的最高字节之外，至少多确认一个字节的数据。
Note that in Step 5, the congestion window is deflated after 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中，在接收到部分确认之后，拥塞窗口被缩小。当接收到部分确认时，拥塞窗口很可能已经大大膨胀。此外，根据分组丢失的原始模式，部分确认可能确认几乎一个数据窗口。在这种情况下，如果拥塞窗口没有缩小，那么数据发送方可能能够背靠背地发送几乎一个数据窗口。
This document does not specify the sender's response to duplicate ACKs when the Fast Retransmit/Fast Recovery algorithm is not invoked. This is addressed in other documents, such as those describing the Limited Transmit procedure [RFC3042]. This document also does not address issues of adjusting the duplicate acknowledgement threshold, but assumes the threshold specified in the IETF standards; the current standard is RFC 2581, which specifies a threshold of three duplicate acknowledgements.
当未调用快速重传/快速恢复算法时，本文档未指定发送方对重复ACK的响应。其他文件（如描述有限传输程序的文件[RFC3042]）对此进行了说明。本文件也不涉及调整重复确认阈值的问题，但假设IETF标准中规定的阈值；当前的标准是RFC 2581，它指定了三个重复确认的阈值。
As a final note, we would observe that in the absence of the SACK option, the data sender is working from limited information. 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 in Response to Partial Acknowledgements
4. 重置重传计时器以响应部分确认
One possible variant to the response to partial acknowledgements specified in Section 3 concerns when to reset the retransmit timer after a partial acknowledgement. The algorithm in Section 3, Step 5, 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
第3节中规定的部分确认响应的一个可能变体涉及在部分确认后何时重置重传计时器。第3节步骤5中的算法仅在第一次部分确认之后重置重传计时器。在这种情况下，如果大量数据包从
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. We note that the Impatient variant in Section 3 doesn't follow the recommended algorithm in RFC 2988 of restarting the retransmit timer after every packet transmission or retransmission [RFC2988, Step 5.1].
数据，TCP数据发送方的重传计时器将最终过期，TCP数据发送方将调用慢速启动。（见[F98]第12页）我们称之为NewReno的不耐烦变体。我们注意到，第3节中的不耐烦变体没有遵循RFC 2988中的推荐算法，即在每次数据包传输或重传之后重新启动重传计时器[RFC2988，步骤5.1]。
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 the New-Reno TCP simulation of Figure 5 in [FF96], and on page 11 of [F98]).
相比之下，[FF96]中的NewReno模拟通过修改说明了上述算法，即在每次部分确认后重置重传计时器。我们称之为NewReno缓慢但稳定的变体。在这种情况下，对于具有大量丢包的窗口，TCP数据发送方在每次往返时间最多重新传输一个数据包。（该行为在[FF96]中图5的新雷诺TCP模拟和[F98]的第11页中进行了说明）。
When N packets have been dropped from a window of data for a large value of N, the Slow-but-Steady variant can remain in Fast Recovery for N round-trip times, retransmitting one more dropped packet each round-trip time; for these scenarios, the Impatient variant gives a faster recovery and better performance. The tests "ns test-suite-newreno.tcl impatient1" and "ns test-suite-newreno.tcl slow1" in the NS simulator illustrate such a scenario, where the Impatient variant performs better than the Slow-but-Steady variant. The Impatient variant can be particularly important for TCP connections with large congestion windows, as illustrated by the tests "ns test-suite-newreno.tcl impatient4" and "ns test-suite-newreno.tcl slow4" in the NS simulator.
当N个数据包从一个数据窗口中丢弃了较大的N个值时，缓慢但稳定的变体可以在N个往返时间内保持快速恢复，每个往返时间重新传输一个以上的丢弃的数据包；对于这些场景，不耐烦的变体提供了更快的恢复和更好的性能。ns模拟器中的测试“ns test-suite-newreno.tcl不耐烦1”和“ns test-suite-newreno.tcl slow1”说明了这种情况，其中不耐烦的变体比缓慢但稳定的变体性能更好。不耐烦变体对于具有大拥塞窗口的TCP连接尤其重要，如ns模拟器中的测试“ns test-suite-newreno.tcl不耐烦4”和“ns test-suite-newreno.tcl slow4”所示。
One can also construct scenarios where the Slow-but-Steady variant gives better performance than the Impatient variant. As an example, this occurs when only a small number of packets are dropped, the RTO is sufficiently small that the retransmit timer expires, and performance would have been better without a retransmit timeout. The tests "ns test-suite-newreno.tcl impatient2" and "ns test-suite-newreno.tcl slow2" in the NS simulator illustrate such a scenario.
我们还可以构建这样的场景：缓慢但稳定的变体比不耐烦的变体提供更好的性能。例如，当只有少量数据包被丢弃，RTO足够小以至于重传计时器过期，并且在没有重传超时的情况下性能会更好时，就会发生这种情况。ns模拟器中的测试“ns test-suite-newreno.tcl 2”和“ns test-suite-newreno.tcl slow2”说明了这种情况。
The Slow-but-Steady variant can also achieve higher goodput than the Impatient variant, by avoiding unnecessary retransmissions. This could be of special interest for cellular links, where every transmission costs battery power and money. The tests "ns test-suite-newreno.tcl impatient3" and "ns test-suite-newreno.tcl slow3" in the NS simulator illustrate such a scenario. The Slow-but-Steady variant can also be more robust to delay variation in the network, where a delay spike might force the Impatient variant into a timeout and go-back-N recovery.
通过避免不必要的重新传输，缓慢但稳定的变体也可以比不耐烦的变体获得更高的输出。这可能对蜂窝链路特别有意义，因为在蜂窝链路中，每一次传输都要消耗电池电量和金钱。ns模拟器中的测试“ns测试套件-newreno.tcl 3”和“ns测试套件-newreno.tcl slow3”说明了这种情况。缓慢但稳定的变体对网络中的延迟变化也更为鲁棒，延迟尖峰可能会迫使不耐烦的变体超时并返回N恢复。
Neither of the two variants discussed above are optimal. Our recommendation is for the Impatient variant, as specified in Section 3 of this document, because of the poor performance of the Slow-but-Steady variant for TCP connections with large congestion windows.
上面讨论的两种变体都不是最优的。我们的建议是针对本文件第3节中规定的不耐烦变体，因为对于具有大拥塞窗口的TCP连接，缓慢但稳定的变体性能较差。
One possibility for a more optimal algorithm would be one that recovered from multiple packet drops as quickly as does slow-start, while resetting the retransmit timers after each partial acknowledgement, as described in the section below. We note, however, that there is a limitation to the potential performance in this case in the absence of the SACK option.
更优化算法的一种可能性是，从多个数据包丢失中恢复的速度与慢速启动一样快，同时在每个部分确认之后重置重传计时器，如以下部分所述。然而，我们注意到，在没有SACK选项的情况下，这种情况下的潜在性能受到限制。
One possible variant to the response to partial acknowledgements specified in Section 3 would be to retransmit more than one packet after each partial acknowledgement, and to reset the retransmit timer after each retransmission. The algorithm specified in Section 3 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, retransmitting two packets after each partial acknowledgement. Such an approach would take less than N roundtrip times to recover from N losses [Hoe96]. However, in the absence of SACK, recovering as quickly as slow-start introduces the likelihood of unnecessarily retransmitting packets, and this could significantly complicate the recovery mechanisms.
第3节中规定的对部分确认的响应的一个可能变体是在每个部分确认之后重新发送多个分组，并且在每次重新发送之后重置重新发送计时器。第3节中指定的算法在每次部分确认后重新传输单个数据包。这是最保守的选择，因为它最不可能导致不必要的重传数据包。一种能从有许多数据包丢失的窗口中更快恢复的变体是有效地减慢启动速度，在每次部分确认后重新传输两个数据包。这种方法需要不到N次往返时间才能从N次损失中恢复[Hoe96]。但是，在没有SACK的情况下，以慢启动的速度进行恢复可能会导致不必要地重新传输数据包，这可能会使恢复机制变得非常复杂。
We note that the response to partial acknowledgements specified in Section 3 of this document and in RFC 2582 differs from the response in [FF96], even though both approaches only retransmit one packet in response to a partial acknowledgement. Step 5 of Section 3 specifies that the TCP sender responds to a partial ACK by deflating the congestion window by the amount of new data acknowledged, adding back SMSS bytes if the partial ACK acknowledges at least SMSS bytes of new data, and sending a new segment if permitted by the new value of cwnd. Thus, only one previously-sent packet is retransmitted in response to each partial acknowledgement, but additional new packets might be transmitted as well, depending on the amount of new data acknowledged by the partial acknowledgement. In contrast, the variant of NewReno illustrated in [FF96] simply set the congestion window to ssthresh when a partial acknowledgement was received. The approach in [FF96] is more conservative, and does not attempt to accurately track the actual number of outstanding packets after a partial acknowledgement is received. While either of these approaches gives acceptable performance, the variant specified in Section 3 recovers more smoothly when multiple packets are dropped
我们注意到，本文件第3节和RFC 2582中规定的对部分确认的响应与[FF96]中的响应不同，尽管这两种方法仅重新传输一个数据包以响应部分确认。第3节的步骤5规定，TCP发送方响应部分ACK的方法是：根据确认的新数据量缩小拥塞窗口，如果部分ACK确认至少SMSS字节的新数据，则添加回SMSS字节，如果cwnd的新值允许，则发送新段。因此，响应于每个部分确认，仅重新发送一个先前发送的分组，但是也可以发送额外的新分组，这取决于由部分确认确认的新数据量。相比之下，[FF96]中所示的NewReno的变体只是在接收到部分确认时将拥塞窗口设置为ssthresh。[FF96]中的方法更为保守，在接收到部分确认后，不会尝试准确跟踪未完成数据包的实际数量。虽然这两种方法中的任何一种都能提供可接受的性能，但当多个数据包被丢弃时，第3节中指定的变量恢复得更平稳
from a window of data. (The [FF96] behavior can be seen in the NS simulator by setting the variable "partial_window_deflation_" for "Agent/TCP/Newreno" to 0; the behavior specified in Section 3 is achieved by setting "partial_window_deflation_" to 1.)
从一个数据窗口。（通过将“Agent/TCP/Newreno”的变量“partial_window_Reduction_”设置为0，可以在NS模拟器中看到[FF96]行为；通过将“partial_window_Reduction_”设置为1，可以实现第3节中指定的行为。）
This section describes the motivation for the sender's state variable "recover", and discusses possible heuristics for distinguishing between a retransmitted packet that was dropped, and three duplicate acknowledgements from the unnecessary retransmission of three packets.
本节描述了发送方状态变量“recover”的动机，并讨论了区分丢弃的重传数据包和三个重复确认与三个数据包的不必要重传的可能启发式方法。
In the absence of the SACK option or timestamps, a duplicate acknowledgement carries no information to identify the data packet or packets at the TCP data receiver that triggered that duplicate acknowledgement. In this case, 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 unnecessary retransmission of a data packet that had already been received at the TCP data receiver. Because of this, with the Retransmit and Fast Recovery algorithms in Reno TCP, multiple segment losses from a single window of data can sometimes result in unnecessary multiple Fast Retransmits (and multiple reductions of the congestion window) [F94].
在没有SACK选项或时间戳的情况下，重复确认不携带识别触发该重复确认的TCP数据接收器处的一个或多个数据包的信息。在这种情况下，TCP数据发送方无法区分由丢失或延迟的数据包导致的重复确认和由发送方对TCP数据接收方已经接收到的数据包进行不必要的重新传输导致的重复确认。因此，使用Reno TCP中的重传和快速恢复算法，单个数据窗口的多段丢失有时会导致不必要的多次快速重传（以及拥塞窗口的多次减少）[F94]。
With the Fast Retransmit and Fast Recovery algorithms in Reno 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 TCP unless some explicit mechanism is added to avoid this, such as the use of the "recover" variable. (This modification is called "bugfix" in [F98], and is illustrated on pages 7 and 9 of that document. Unnecessary Fast Retransmits for Reno without "bugfix" is illustrated on page 6 of [F98].)
使用Reno TCP中的快速重传和快速恢复算法，与Tahoe TCP中不实现快速恢复的潜在问题相比，多次快速重传造成的性能问题相对较小。尽管如此，Reno TCP可能会发生不必要的快速重传，除非添加一些明确的机制来避免这种情况，例如使用“recover”变量。（此修改在[F98]中称为“错误修正”，并在该文件的第7页和第9页上进行了说明。在[F98]的第6页上说明了雷诺不必要的快速重新传输，但没有“错误修正”）
Section 3 of [RFC2582] defined a default variant of NewReno TCP that did not use the variable "recover", and did not check if duplicate ACKs cover the variable "recover" before invoking Fast Retransmit. With this default variant from RFC 2582, the problem of multiple Fast Retransmits from a single window of data can occur after a Retransmit Timeout (as in page 8 of [F98]) or in scenarios with reordering (as in the validation test "./test-all-newreno newreno5_noBF" in directory "tcl/test" of the NS simulator. This gives performance similar to that on page 8 of [F03].) RFC 2582 also defined Careful and Less Careful variants of the NewReno algorithm, and recommended the Careful variant.
[RFC2582]的第3节定义了NewReno TCP的默认变量，该变量未使用变量“recover”，并且在调用快速重传之前未检查重复的ACK是否覆盖变量“recover”。使用RFC 2582的此默认变体，在重新传输超时后（如[F98]第8页所示）或在重新排序的情况下（如目录“tcl/test”中的验证测试“/test all newreno newreno5_noBF”中），可能会出现从单个数据窗口多次快速重新传输的问题RFC 2582还定义了NewReno算法的谨慎变量和不谨慎变量，并推荐谨慎变量。
The algorithm specified in Section 3 of this document corresponds to the Careful variant of NewReno TCP from RFC 2582, and eliminates the problem of multiple Fast Retransmits. This algorithm uses the variable "recover", whose initial value is the initial send sequence number. After each retransmit timeout, the highest sequence number transmitted so far is recorded in the variable "recover".
本文件第3节中指定的算法对应于RFC 2582中NewReno TCP的仔细变体，并消除了多次快速重传的问题。该算法使用变量“recover”，其初始值为初始发送序列号。在每次重新传输超时后，迄今为止传输的最高序列号记录在变量“recover”中。
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 cover more than "recover". 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数据发送方将收到三个不超过“恢复”的重复确认。在这种情况下，重复确认并不表示新的拥塞实例。它们只是表明发送方不必要地重新传输了至少三个数据包。
However, when a retransmitted packet is itself dropped, the sender can also receive three duplicate acknowledgements that do not cover more than "recover". In this case, the sender would have been better off if it had initiated Fast Retransmit. For a TCP that implements the algorithm specified in Section 3 of this document, the sender does not infer a packet drop from duplicate acknowledgements in this scenario. As always, the retransmit timer is the backup mechanism for inferring packet loss in this case.
但是，当重新传输的数据包本身被丢弃时，发送方还可以收到三个重复的确认，这些确认不超过“恢复”。在这种情况下，如果发送方启动了快速重传，它的境况会更好。对于实现本文档第3节中指定的算法的TCP，在这种情况下，发送方不会从重复确认推断数据包丢弃。一如既往，在这种情况下，重传计时器是推断数据包丢失的备份机制。
There are several heuristics, based on timestamps or on the amount of advancement of the cumulative acknowledgement field, that allow the sender to distinguish, in some cases, between three duplicate acknowledgements following a retransmitted packet that was dropped, and three duplicate acknowledgements from the unnecessary retransmission of three packets [Gur03, GF04]. The TCP sender MAY use such a heuristic to decide to invoke a Fast Retransmit in some cases, even when the three duplicate acknowledgements do not cover more than "recover".
有几种基于时间戳或累积确认字段的前进量的启发式方法，在某些情况下，允许发送方区分丢弃的重传数据包之后的三个重复确认，以及来自三个数据包的不必要重传的三个重复确认[Gur03，GF04]。在某些情况下，TCP发送方可以使用这种启发式方法来决定调用快速重传，即使三个重复的确认不超过“恢复”。
For example, when three duplicate acknowledgements are caused by the unnecessary retransmission of three packets, this is likely to be accompanied by the cumulative acknowledgement field advancing by at least four segments. Similarly, a heuristic based on timestamps uses the fact that when there is a hole in the sequence space, the timestamp echoed in the duplicate acknowledgement is the timestamp of the most recent data packet that advanced the cumulative acknowledgement field [RFC1323]. If timestamps are used, and the sender stores the timestamp of the last acknowledged segment, then the timestamp echoed by duplicate acknowledgements can be used to distinguish between a retransmitted packet that was dropped and three duplicate acknowledgements from the unnecessary retransmission of three packets. The heuristics are illustrated in the NS simulator in the validation test "./test-all-newreno".
例如，当三个分组的不必要重传导致三个重复确认时，这可能伴随着累积确认字段前进至少四个段。类似地，基于时间戳的启发式使用这样的事实，即当序列空间中存在孔时，重复确认中回显的时间戳是推进累积确认字段[RFC1323]的最近数据分组的时间戳。如果使用了时间戳，并且发送方存储了最后确认的段的时间戳，那么由重复确认回显的时间戳可用于区分丢弃的重传分组和三个重复确认与三个分组的不必要重传。验证测试“/test all newreno”中的NS模拟器中说明了这些启发式方法。
If the ACK-based heuristic is used, then following the advancement of the cumulative acknowledgement field, the sender stores the value of the previous cumulative acknowledgement as prev_highest_ack, and stores the latest cumulative ACK as highest_ack. In addition, the following step is performed if Step 1 in Section 3 fails, before proceeding to Step 1B.
如果使用基于ACK的启发式，则在累积确认字段前进之后，发送方将先前累积确认的值存储为prev_highest_ACK，并将最近的累积ACK存储为highest_ACK。此外，如果第3节中的步骤1失败，则在继续执行步骤1B之前执行以下步骤。
1*) If the Cumulative Acknowledgement field didn't cover more than "recover", check to see if the congestion window is greater than SMSS bytes and the difference between highest_ack and prev_highest_ack is at most 4*SMSS bytes. If true, duplicate ACKs indicate a lost segment (proceed to Step 1A in Section 3). Otherwise, duplicate ACKs likely result from unnecessary retransmissions (proceed to Step 1B in Section 3).
1*）如果累计确认字段的覆盖范围不超过“恢复”，请检查拥塞窗口是否大于SMSS字节，并且最高确认和上一次最高确认之间的差值最多为4*SMSS字节。如果为真，则重复的ACK指示丢失的段（继续执行第3节中的步骤1A）。否则，重复的ack可能是由于不必要的重新传输造成的（转至第3节中的步骤1B）。
The congestion window check serves to protect against fast retransmit immediately after a retransmit timeout, similar to the "exitFastRetrans_" variable in NS. Examples of applying the ACK heuristic are in validation tests "./test-all-newreno newreno_rto_loss_ack" and "./test-all-newreno newreno_rto_dup_ack" in directory "tcl/test" of the NS simulator.
拥塞窗口检查用于防止在重传超时后立即进行快速重传，类似于NS中的“exitFastRetrans_u2;”变量。应用确认启发式的示例包括验证测试“/test all newreno newreno\u rto\u loss\u ACK”和NS模拟器目录“tcl/test”中的“/test all newreno newreno\u rto\u dup\u ACK”。
If several ACKs are lost, the sender can see a jump in the cumulative ACK of more than three segments, and the heuristic can fail. A validation test for this scenario is "./test-all-newreno newreno_rto_loss_ackf". RFC 2581 recommends that a receiver should send duplicate ACKs for every out-of-order data packet, such as a data packet received during Fast Recovery. The ACK heuristic is more likely to fail if the receiver does not follow this advice, because then a smaller number of ACK losses are needed to produce a sufficient jump in the cumulative ACK.
如果多个ACK丢失，发送方可以看到三个以上段的累积ACK中的跳跃，并且启发式可能失败。此场景的验证测试是“/test all newreno newreno\u rto\u loss\u ackf”。RFC 2581建议接收器应为每个无序数据包（例如在快速恢复期间接收的数据包）发送重复的ACK。如果接收器不遵循此建议，则ACK启发式更可能失败，因为此时需要较小数量的ACK丢失以在累积ACK中产生足够的跳跃。
If this heuristic is used, the sender stores the timestamp of the last acknowledged segment. In addition, the second paragraph of step 1 in Section 3 is replaced as follows:
如果使用此启发式，发送方将存储最后确认的段的时间戳。此外，第3节中步骤1的第二段替换如下：
1**) If the Cumulative Acknowledgement field didn't cover more than "recover", check to see if the echoed timestamp in the last non-duplicate acknowledgment equals the stored timestamp. If true, duplicate ACKs indicate a lost segment (proceed to Step 1A in Section 3). Otherwise, duplicate ACKs likely result from unnecessary retransmissions (proceed to Step 1B in Section 3).
1**）如果累计确认字段的覆盖范围不超过“恢复”，请检查最后一次非重复确认中的回显时间戳是否等于存储的时间戳。如果为真，则重复的ACK指示丢失的段（继续执行第3节中的步骤1A）。否则，重复的ack可能是由于不必要的重新传输造成的（转至第3节中的步骤1B）。
Examples of applying the timestamp heuristic are in validation tests "./test-all-newreno newreno_rto_loss_tsh" and "./test-all-newreno newreno_rto_dup_tsh". The timestamp heuristic works correctly, both when the receiver echoes timestamps as specified by [RFC1323], and by its revision attempts. However, if the receiver arbitrarily echoes timestamps, the heuristic can fail. The heuristic can also fail if a timeout was spurious and returning ACKs are not from retransmitted segments. This can be prevented by detection algorithms such as [RFC3522].
应用时间戳启发式的示例包括验证测试“/test all newreno newreno_rto_loss_tsh”和“/test all newreno newreno_rto_dup_tsh”。当接收器按照[RFC1323]的规定回显时间戳时，以及通过其修订尝试，时间戳启发式算法都能正常工作。然而，如果接收器任意回显时间戳，则启发式可能失败。如果超时是虚假的，并且返回的ack不是来自重新传输的段，则启发式也可能失败。这可以通过[RFC3522]等检测算法来防止。
[RFC2581] specifies that "Out-of-order data segments SHOULD be acknowledged immediately, in order to accelerate loss recovery." Neal Cardwell has noted 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 [C98]. As [C98] notes, this severely limits the potential benefit of NewReno by delaying the receipt of the partial acknowledgement at the data sender. Echoing RFC 2581, 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.
[RFC2581]规定“应立即确认无序数据段，以加速丢失恢复。”Neal Cardwell指出，一些数据接收器在发送部分确认时不立即发送确认，而是先等待延迟确认计时器过期[C98]。正如[C98]所指出的，这严重限制了NewReno的潜在好处，因为它延迟了数据发送方收到部分确认。响应RFC 2581，我们的建议是，数据接收器立即发送对无序段的确认，即使该无序段填充了缓冲区中的孔。
In Section 3, Step 5 above, it is noted that implementations should take measures to avoid a possible burst of data when leaving Fast Recovery, in case the amount of new data that the sender is eligible to send due to the new value of the congestion window is large. This can arise during NewReno when ACKs are lost or treated as pure window updates, thereby causing the sender to underestimate the number of new segments that can be sent during the recovery procedure. Specifically, bursts can occur when the FlightSize is much less than the new congestion window when exiting from Fast Recovery. One simple mechanism to avoid a burst of data when leaving Fast Recovery is to limit the number of data packets that can be sent in response to a single acknowledgment. (This is known as "maxburst_" in the ns simulator.) Other possible mechanisms for avoiding bursts include rate-based pacing, or setting the slow-start threshold to the resultant congestion window and then resetting the congestion window to FlightSize. A recommendation on the general mechanism to avoid excessively bursty sending patterns is outside the scope of this document.
在上面的第3节第5步中，需要注意的是，如果由于拥塞窗口的新值，发送方有资格发送的新数据量较大，则实现应采取措施避免在离开快速恢复时可能出现的数据突发。在NewReno期间，当ACK丢失或被视为纯窗口更新时，可能会出现这种情况，从而导致发送方低估了恢复过程中可以发送的新段数。具体来说，当退出快速恢复时，FlightSize远小于新的拥塞窗口时，可能会发生突发。在离开快速恢复时避免数据突发的一个简单机制是限制响应单个确认可以发送的数据包的数量。（这在ns模拟器中被称为“maxburst_”）。避免突发的其他可能机制包括基于速率的起搏，或将慢启动阈值设置为结果拥塞窗口，然后将拥塞窗口重置为FlightSize。关于避免过度突发发送模式的一般机制的建议超出了本文档的范围。
An implementation may want to use a separate flag to record whether or not it is presently in the Fast Recovery procedure. The use of the value of the duplicate acknowledgment counter for this purpose is
实现可能希望使用单独的标志来记录它当前是否处于快速恢复过程中。为此目的，重复确认计数器的值的使用是
not reliable because it can be reset upon window updates and out-of-order acknowledgments.
不可靠，因为它可以在窗口更新和无序确认时重置。
When not in Fast Recovery, the value of the state variable "recover" should be pulled along with the value of the state variable for acknowledgments (typically, "snd_una") so that, when large amounts of data have been sent and acked, the sequence space does not wrap and falsely indicate that Fast Recovery should not be entered (Section 3, step 1, last paragraph).
当不在快速恢复中时，状态变量“recover”的值应与状态变量的值一起用于确认（通常为“snd_una”），以便在发送和确认大量数据时，序列空间不会包装并错误指示不应输入快速恢复（第3节，步骤1，最后一段）。
It is important for the sender to respond correctly to duplicate ACKs received when the sender is no longer in Fast Recovery (e.g., because of a Retransmit Timeout). The Limited Transmit procedure [RFC3042] describes possible responses to the first and second duplicate acknowledgements. When three or more duplicate acknowledgements are received, the Cumulative Acknowledgement field doesn't cover more than "recover", and a new Fast Recovery is not invoked, it is important that the sender not execute the Fast Recovery steps (3) and (4) in Section 3. Otherwise, the sender could end up in a chain of spurious timeouts. We mention this only because several NewReno implementations had this bug, including the implementation in the NS simulator. (This bug in the NS simulator was fixed in July 2003, with the variable "exitFastRetrans_".)
当发送方不再处于快速恢复状态时（例如，由于重传超时），发送方正确响应收到的重复ACK非常重要。有限传输程序[RFC3042]描述了对第一次和第二次重复确认的可能响应。当收到三个或三个以上的重复确认时，累计确认字段的覆盖范围不超过“恢复”，并且不会调用新的快速恢复，重要的是发送方不要执行第3节中的快速恢复步骤（3）和（4）。否则，发送方可能会出现一连串虚假超时。我们之所以提到这一点，只是因为几个NewReno实现都有这个bug，包括NS模拟器中的实现。（NS模拟器中的此错误于2003年7月修复，变量为“exitFastRetrans_2;”。）
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 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模拟器中的验证测试“tcl/test/test all NewReno”说明了NewReno的模拟。命令“../../ns test-suite-newreno.tcl reno”显示了使用reno TCP的模拟，说明了数据发送方对部分确认没有响应。相反，命令“../../ns test-suite-newreno.tcl newreno_B”显示了使用本文描述的newreno算法对相同场景的模拟。
As we stated in the introduction, we believe that the NewReno modification described in this document improves the performance of the Fast Retransmit and Fast Recovery algorithms of Reno TCP in a wide variety of scenarios. This has been discussed in some depth in [FF96], which illustrates Reno TCP's poor performance when multiple packets are dropped from a window of data and also illustrates NewReno TCP's good performance in that scenario.
正如我们在导言中所述，我们相信本文中描述的NewReno修改改进了Reno TCP的快速重传和快速恢复算法在各种场景中的性能。[FF96]对此进行了深入讨论，它说明了当从一个数据窗口中丢弃多个数据包时，Reno TCP的性能较差，也说明了NewReno TCP在该场景中的良好性能。
We do, however, know of one scenario where Reno TCP gives better performance than NewReno TCP, that we describe here for the sake of completeness. Consider a scenario with no packet loss, but with sufficient reordering so that the TCP sender receives three duplicate
然而，我们知道有一种情况，Reno TCP比NewReno TCP提供更好的性能，为了完整性，我们在这里描述了这种情况。考虑没有丢包的情况，但有足够的重新排序，以便TCP发送器接收三个副本。
acknowledgements. This will trigger the Fast Retransmit and Fast Recovery algorithms. With Reno TCP or with Sack TCP, this will result in the unnecessary retransmission of a single packet, combined with a halving of the congestion window (shown on pages 4 and 6 of [F03]). With NewReno TCP, however, this reordering will also result in the unnecessary retransmission of an entire window of data (shown on page 5 of [F03]).
致谢。这将触发快速重传和快速恢复算法。对于Reno TCP或Sack TCP，这将导致不必要的单个数据包重传，同时拥塞窗口减半（见[F03]第4页和第6页）。然而，对于NewReno TCP，这种重新排序也会导致不必要的整个数据窗口的重新传输（如[F03]第5页所示）。
While Reno TCP performs better than NewReno TCP in the presence of reordering, NewReno's superior performance in the presence of multiple packet drops generally outweighs its less optimal performance in the presence of reordering. (Sack TCP is the preferred solution, with good performance in both scenarios.) This document recommends the Fast Retransmit and Fast Recovery algorithms of NewReno TCP instead of those of Reno TCP for those TCP connections that do not support SACK. We would also note that NewReno's Fast Retransmit and Fast Recovery mechanisms are widely deployed in TCP implementations in the Internet today, as documented in [PF01]. For example, tests of TCP implementations in several thousand web servers in 2001 showed that for those TCP connections where the web browser was not SACK-capable, more web servers used the Fast Retransmit and Fast Recovery algorithms of NewReno than those of Reno or Tahoe TCP [PF01].
尽管Reno TCP在重新排序时的性能优于NewReno TCP，但NewReno在存在多个数据包丢失时的优异性能通常超过其在重新排序时的较差性能。（Sack TCP是首选解决方案，在这两种情况下都具有良好的性能。）本文档建议对不支持Sack的TCP连接使用NewReno TCP的快速重传和快速恢复算法，而不是Reno TCP的算法。我们还需要注意的是，NewReno的快速重传和快速恢复机制目前广泛部署在互联网的TCP实现中，如[PF01]中所述。例如，2001年在数千台web服务器上对TCP实现的测试表明，对于那些web浏览器不支持SACK的TCP连接，使用NewReno的快速重传和快速恢复算法的web服务器比使用Reno或Tahoe TCP的要多[PF01]。
The purpose of this document is to advance the NewReno's Fast Retransmit and Fast Recovery algorithms in RFC 2582 to Standards Track.
本文档旨在将RFC 2582中的NewReno快速重传和快速恢复算法提升到标准轨道。
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout (described in more detail in the section above). However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno. As described below, this algorithm uses a variable "recover", whose initial value is the send sequence number.
与RFC 2582相比，本文档的主要变化是详细说明了NewReno的快速重传和快速恢复算法。RFC 2582中描述的基本算法没有试图避免超时后可能发生的不必要的多次快速重传（在上述部分中有更详细的描述）。然而，RFC 2582还定义了避免这些不必要的快速重传的“小心”和“不太小心”变体，并建议使用小心变体。本文档指定先前命名的“小心”变体作为NewReno的基本版本。如下所述，该算法使用变量“recover”，其初始值为发送序列号。
The algorithm specified in Section 3 checks whether the acknowledgement field of a partial acknowledgement covers *more* than "recover", as defined in Section 3. Another possible variant would be to simply require that the acknowledgement field covers *more than or equal to* "recover" before initiating another Fast Retransmit. We called this the Less Careful variant in RFC 2582.
第3节中指定的算法检查部分确认的确认字段是否覆盖*多于第3节中定义的“恢复”。另一种可能的变体是，在启动另一个快速重传之前，简单地要求确认字段覆盖*大于或等于*“恢复”。我们称之为RFC2582中不太小心的变体。
There are two separate scenarios in which the TCP sender could receive three duplicate acknowledgements acknowledging "recover" but no more than "recover". One scenario would be that the data sender transmitted four packets with sequence numbers higher than "recover", that the first packet was dropped in the network, and the following three packets triggered three duplicate acknowledgements acknowledging "recover". The second scenario would be that the sender unnecessarily retransmitted three packets below "recover", and that these three packets triggered three duplicate acknowledgements acknowledging "recover". In the absence of SACK, the TCP sender is unable to distinguish between these two scenarios.
在两种不同的情况下，TCP发送方可以收到三个重复的确认，确认“恢复”，但不超过“恢复”。一种情况是，数据发送方发送了四个序列号高于“recover”的数据包，第一个数据包在网络中被丢弃，接下来的三个数据包触发了三个重复的确认“recover”。第二种情况是，发送方不必要地在“recover”下面重新传输了三个数据包，并且这三个数据包触发了三个重复的确认“recover”。在没有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. This document only specifies the Careful variant in Section 3. Unnecessary Fast Retransmits with the Less Careful variant in scenarios with reordering are illustrated in page 8 of [F03].
对于快速重传的谨慎变体，在第一个场景中，数据发送方必须等待重传超时，但在第二个场景中不会有不必要的快速重传。对于不太小心的快速重传变体，数据发送方将在第一个场景中按照所需进行快速重传，而在第二个场景中不必要地进行快速重传。本文件仅规定了第3节中的详细变量。[F03]的第8页说明了在重新排序的情况下，不必要的快速重传以及不太小心的变体。
The document also specifies two heuristics that the TCP sender MAY use to decide to invoke Fast Retransmit even when the three duplicate acknowledgements do not cover more than "recover". These heuristics, an ACK-based heuristic and a timestamp heuristic, are described in Sections 6.1 and 6.2 respectively.
该文档还指定了两种试探法，TCP发送方可以使用这两种试探法来决定调用快速重传，即使三次重复确认的覆盖范围不超过“恢复”。这些启发式（基于ACK的启发式和时间戳启发式）分别在第6.1节和第6.2节中描述。
This document specifies the NewReno Fast Retransmit and Fast Recovery algorithms for TCP. This NewReno modification to TCP can even be important 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. NewReno performs better than Reno (RFC 2581) in a number of scenarios discussed herein.
本文档指定了用于TCP的NewReno快速重传和快速恢复算法。这种对TCP的NewReno修改甚至对支持SACK选项的TCP实现非常重要，因为只有当两个TCP端节点都支持SACK选项时，SACK选项才能用于TCP连接。在本文讨论的许多场景中，NewReno的性能优于Reno（RFC 2581）。
A number of options to the basic algorithm presented in Section 3 are also described. These include the handling of the retransmission timer (Section 4), the response to partial acknowledgments (Section 5), and the value of the congestion window when leaving Fast Recovery (section 3, step 5). Our belief is that the differences between these 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 connection without SACK; it is less important exactly which of the variants of NewReno is implemented.
第3节中介绍的基本算法的一些选项也被描述。这些包括重新传输计时器的处理（第4节）、对部分确认的响应（第5节）以及离开快速恢复时拥塞窗口的值（第3节，步骤5）。我们相信，与雷诺和NewReno之间的差异相比，NewReno的这些变体之间的差异很小。也就是说，对于没有SACK的TCP连接，重要的是实现NewReno而不是Reno；究竟实现了哪种NewReno变体并不那么重要。
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拥塞控制要求的特定算法，因此这些注意事项也适用于该算法。此特定算法没有已知的其他安全问题。
Many thanks to Anil Agarwal, Mark Allman, Armando Caro, Jeffrey Hsu, Vern Paxson, Kacheong Poon, Keyur Shah, and Bernie Volz for detailed feedback on this document or on its precursor, RFC 2582.
非常感谢Anil Agarwal、Mark Allman、Armando Caro、Jeffrey Hsu、Vern Paxson、Kacheong Poon、Keyur Shah和Bernie Volz对本文件或其前身RFC 2582的详细反馈。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 25821999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[C98] Cardwell, N., "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]Cardwell，N.，“重传数据包的延迟确认：哎哟！”。1998年11月，发送至tcpimpl邮件列表的电子邮件，邮件ID“Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu，存档于http://tcp-impl.lerc.nasa.gov/tcp-impl".
[F98] Floyd, S., 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]Floyd，S.，对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".
[F03] Floyd, S., "Moving NewReno from Experimental to Proposed Standard? Presentation to the TSVWG Working Group", March 2003. URLs "http://www.icir.org/floyd/talks/newreno-Mar03.ps" and "http://www.icir.org/floyd/talks/newreno-Mar03.pdf".
[F03]Floyd，S.，“将NewReno从实验性标准转变为拟议标准？向TSVWG工作组的介绍”，2003年3月。“网址”http://www.icir.org/floyd/talks/newreno-Mar03.ps“和”http://www.icir.org/floyd/talks/newreno-Mar03.pdf".
[FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, July 1996. URL "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[FF96]Fall，K.和S.Floyd，“基于模拟的塔霍、雷诺和萨克TCP的比较”，《计算机通信评论》，1996年7月。URL“ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[F94] Floyd, S., "TCP and Successive Fast Retransmits", Technical report, October 1994. URL "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[F94]Floyd，S.，“TCP和连续快速重传”，技术报告，1994年10月。URL“ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[GF04] Gurtov, A. and S. Floyd, "Resolving Acknowledgment Ambiguity in non-SACK TCP", Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN'04), February 2004. URL "http://www.cs.helsinki.fi/u/gurtov/papers/ heuristics.html".
[GF04]Gurtov，A.和S.Floyd，“解决非SACK TCP中的确认歧义”，下一代电信业务和有线/无线高级网络（NEW2AN'04），2004年2月。URL“http://www.cs.helsinki.fi/u/gurtov/papers/ “heuristics.html”。
[Gur03] Gurtov, A., "[Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N", email to the tsvwg mailing list, message ID <3F25B467.9020609@cs.helsinki.fi>, July 28, 2003. URL "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04334.html".
[Gur03]Gurtov，A.，“[Tsvwg]解决返回N中不必要的快速重传问题”，发送至Tsvwg邮件列表的电子邮件，邮件ID<3F25B467。9020609@cs.helsinki.fi>，2003年7月28日。URL“http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04334.html".
[Hen98] Henderson, T., 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".
[Henderson，T.，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] Hoe, J., "Startup Dynamics of TCP's Congestion Control and Avoidance Schemes", Master's Thesis, MIT, 1995.
[Hoe95]Hoe，J.，“TCP拥塞控制和避免方案的启动动力学”，硕士论文，麻省理工学院，1995年。
[Hoe96] Hoe, J., "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", ACM SIGCOMM, August 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".
[Hoe96]Hoe，J.“改进TCP拥塞控制方案的启动行为”，ACM SIGCOMM，1996年8月。URL“http://www.acm.org/sigcomm/sigcomm96/program.html".
[LM97] Lin, D. and R. Morris, "Dynamics of Random Early Detection", SIGCOMM 97, September 1997. URL "http://www.acm.org/sigcomm/sigcomm97/program.html".
[LM97]Lin，D.和R.Morris，“随机早期检测的动力学”，SIGCOMM 97，1997年9月。URL“http://www.acm.org/sigcomm/sigcomm97/program.html".
[NS] The Network Simulator (NS). URL "http://www.isi.edu/nsnam/ns/".
[NS]网络模拟器（NS）。URL“http://www.isi.edu/nsnam/ns/".
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior of Web Servers", June 2001, SIGCOMM 2001.
[PF01]Padhye，J.和S.Floyd，“识别Web服务器的TCP行为”，2001年6月，SIGCOMM 2001。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
Authors' Addresses
作者地址
Sally Floyd International Computer Science Institute
萨莉·弗洛伊德国际计算机科学研究所
Phone: +1 (510) 666-2989
EMail: floyd@acm.org
URL: http://www.icir.org/floyd/
Phone: +1 (510) 666-2989
EMail: floyd@acm.org
URL: http://www.icir.org/floyd/
Tom Henderson The Boeing Company
波音公司的汤姆·亨德森
EMail: thomas.r.henderson@boeing.com
EMail: thomas.r.henderson@boeing.com
Andrei Gurtov TeliaSonera
安德烈·古托夫·泰利亚索纳
EMail: andrei.gurtov@teliasonera.com
EMail: andrei.gurtov@teliasonera.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。