Network Working Group M. Handley
Request for Comments: 2861 J. Padhye
Category: Experimental S. Floyd
ACIRI
June 2000
Network Working Group M. Handley
Request for Comments: 2861 J. Padhye
Category: Experimental S. Floyd
ACIRI
June 2000
TCP Congestion Window Validation
TCP拥塞窗口验证
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.
TCP的拥塞窗口控制TCP流在任何时候在网络中可能拥有的数据包数量。然而，当发送方空闲或应用程序受限时，长时间的拥塞窗口可能会失效，因为拥塞窗口不再反映有关网络状态的当前信息。本文档描述了对TCP拥塞控制算法的简单修改，以在从足够长的应用程序限制期过渡后衰减拥塞窗口cwnd，同时使用慢速启动阈值ssthresh保存有关拥塞窗口先前值的信息。
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD.
当拥塞窗口在应用程序限制期间增加时（即TCP的慢启动或拥塞避免阶段），也会导致无效的拥塞窗口，此时拥塞窗口的先前值可能从未被充分利用。我们建议，当TCP发送方受到应用程序限制（因此没有充分利用当前的拥塞窗口）时，TCP发送方不应增加拥塞窗口。我们通过仿真和FreeBSD实现的实验探索了这些算法。
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 [B97].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[B97]中的说明进行解释。
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. The congestion window is set using an Additive-Increase, Multiplicative-Decrease (AIMD) mechanism that probes for available bandwidth, dynamically adapting to changing network conditions. This AIMD mechanism works well when the sender continually has data to send, as is typically the case for TCP used for bulk-data transfer. In contrast, for TCP used with telnet applications, the data sender often has little or no data to send, and the sending rate is often determined by the rate at which data is generated by the user. With the advent of the web, including developments such as TCP senders with dynamically-created data and HTTP 1.1 with persistent-connection TCP, the interaction between application-limited periods (when the sender sends less than is allowed by the congestion or receiver windows) and network-limited periods (when the sender is limited by the TCP window) becomes increasingly important. More precisely, we define a network-limited period as any period when the sender is sending a full window of data.
TCP的拥塞窗口控制TCP流在任何时候在网络中可能拥有的数据包数量。拥塞窗口是使用加法递增乘法递减（AIMD）机制设置的，该机制探测可用带宽，动态地适应不断变化的网络条件。当发送方持续发送数据时，这种AIMD机制工作得很好，这是用于批量数据传输的TCP的典型情况。相反，对于与telnet应用程序一起使用的TCP，数据发送方通常只有很少或没有数据要发送，发送速率通常由用户生成数据的速率决定。随着web的出现，包括具有动态创建数据的TCP发送者和具有持久连接TCP的HTTP 1.1等开发，应用程序有限期（发送者发送的数据少于拥塞或接收方窗口允许的时间）和网络有限期之间的交互（当发送方受到TCP窗口的限制时）变得越来越重要。更准确地说，我们将网络限制时间定义为发送方发送完整数据窗口的任何时间段。
Long periods when the sender is application-limited can lead to the invalidation of the congestion window. During periods when the TCP sender is network-limited, the value of the congestion window is repeatedly "revalidated" by the successful transmission of a window of data without loss. When the TCP sender is network-limited, there is an incoming stream of acknowledgements that "clocks out" new data, giving concrete evidence of recent available bandwidth in the network. In contrast, during periods when the TCP sender is application-limited, the estimate of available capacity represented by the congestion window may become steadily less accurate over time. In particular, capacity that had once been used by the network-limited connection might now be used by other traffic.
发送方受到应用程序限制的时间过长可能导致拥塞窗口无效。在TCP发送方受到网络限制的期间，拥塞窗口的值通过在不丢失的情况下成功传输数据窗口来重复“重新验证”。当TCP发送方受到网络限制时，会有一个传入的确认流“时钟”掉新数据，提供网络中最近可用带宽的具体证据。相反，在TCP发送方受到应用程序限制的期间，由拥塞窗口表示的可用容量的估计可能随着时间的推移逐渐变得不准确。特别是，曾经由网络有限连接使用的容量现在可能由其他流量使用。
Current TCP implementations have a range of behaviors for starting up after an idle period. Some current TCP implementations slow-start after an idle period longer than the RTO estimate, as suggested in [RFC2581] and in the appendix of [VJ88], while other implementations don't reduce their congestion window after an idle period. RFC 2581 [RFC2581] recommends the following: "a TCP SHOULD set cwnd to no more than RW [the initial window] before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout." A proposal for TCP's slow-start after idle has also been discussed in [HTH98]. The issue of validation of congestion information during idle periods has also been addressed in contexts other than TCP and IP, for example in "Use-it or Lose-it" mechanisms for ATM networks [J96,J95].
当前的TCP实现有一系列在空闲时间后启动的行为。正如[RFC2581]和[VJ88]附录中所建议的，当前的一些TCP实现在比RTO估计值更长的空闲时间后缓慢启动，而其他实现在空闲时间后不会减少拥塞窗口。RFC 2581[RFC2581]建议如下：“如果TCP没有在超过重传超时的时间间隔内发送数据，则在开始传输之前，TCP应将cwnd设置为不超过RW[初始窗口]。[HTH98]中还讨论了TCP在空闲后缓慢启动的建议。空闲期间拥塞信息的验证问题也在TCP和IP以外的上下文中得到了解决，例如在ATM网络的“使用或丢失”机制中[J96，J95]。
To address the revalidation of the congestion window after a application-limited period, we propose a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period (i.e., at least one roundtrip time) to a network-limited period. In particular, we propose that after an idle period, the TCP sender should reduce its congestion window by half for every RTT that the flow has remained idle.
为了解决在应用程序有限期后重新验证拥塞窗口的问题，我们提出了对TCP拥塞控制算法的简单修改，以在从足够长的应用程序有限期（即至少一个往返时间）过渡到网络有限期后衰减拥塞窗口cwnd。特别是，我们建议在空闲时间之后，对于流保持空闲的每个RTT，TCP发送方应将其拥塞窗口减少一半。
When the congestion window is reduced, the slow-start threshold ssthresh remains as "memory" of the recent congestion window. Specifically, ssthresh is never decreased when cwnd is reduced after an application-limited period; before cwnd is reduced, ssthresh is set to the maximum of its current value, and half-way between the old and the new values of cwnd. This use of ssthresh allows a TCP sender increasing its sending rate after an application-limited period to quickly slow-start to recover most of the previous value of the congestion window. To be more precise, if ssthresh is less than 3/4 cwnd when the congestion window is reduced after an application-limited period, then ssthresh is increased to 3/4 cwnd before the reduction of the congestion window.
当拥塞窗口减小时，慢启动阈值ssthresh将保留为最近拥塞窗口的“内存”。具体而言，当cwnd在应用限制期后减少时，ssthresh从不减少；在减少cwnd之前，ssthresh设置为其当前值的最大值，介于cwnd的旧值和新值之间。ssthresh的这种使用允许TCP发送方在应用程序限制期后增加其发送速率，以快速减慢启动速度，从而恢复拥塞窗口的大部分先前值。更准确地说，如果在应用程序限制期后减少拥塞窗口时，ssthresh小于3/4 cwnd，则在减少拥塞窗口之前，ssthresh将增加到3/4 cwnd。
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. As far as we know, all current TCP implementations increase the congestion window when an acknowledgement arrives, if allowed by the receiver's advertised window and the slow-start or congestion avoidance window increase algorithm, without checking to see if the previous value of the congestion window has in fact been used. This document proposes that the window increase algorithm not be invoked during application-limited periods [MSML99]. In particular, the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). This restriction prevents the congestion window from growing arbitrarily large, in the absence of evidence that the congestion window can be supported by the network. From [MSML99, Section 5.2]: "This restriction assures that [cwnd] only grows as long as TCP actually succeeds in injecting enough data into the network to test the path."
当拥塞窗口在应用程序限制期间增加时（即TCP的慢启动或拥塞避免阶段），也会导致无效的拥塞窗口，此时拥塞窗口的先前值可能从未被充分利用。据我们所知，如果接收方的广告窗口和慢速启动或拥塞避免窗口增加算法允许，所有当前TCP实现在确认到达时都会增加拥塞窗口，而不检查拥塞窗口的先前值是否已实际使用。本文件建议在应用程序限制期间不调用窗口增加算法[MSML99]。特别是，当TCP发送方受到应用程序限制（因此没有完全使用当前拥塞窗口）时，TCP发送方不应增加拥塞窗口。在没有证据表明网络可以支持拥塞窗口的情况下，该限制防止拥塞窗口任意增大。来自[MSML99，第5.2节]：“此限制确保[cwnd]只在TCP实际成功向网络注入足够数据以测试路径时才会增长。”
A somewhat-orthogonal problem associated with maintaining a large congestion window after an application-limited period is that the sender, with a sudden large amount of data to send after a quiescent period, might immediately send a full congestion window of back-to-back packets. This problem of sending large bursts of packets back-to-back can be effectively handled using rate-based pacing (RBP,
与在应用程序限制期之后维持大拥塞窗口相关的一个有点正交的问题是，发送方在静止期之后突然要发送大量数据，可能会立即发送背对背数据包的完全拥塞窗口。使用基于速率的调整（RBP）可以有效地处理背靠背发送大量数据包的问题，
[VH97]), or using a maximum burst size control [FF96]. We would contend that, even with mechanisms for limiting the sending of back-to-back packets or pacing packets out over the period of a roundtrip time, an old congestion window that has not been fully used for some time can not be trusted as an indication of the bandwidth currently available for that flow. We would contend that the mechanisms to pace out packets allowed by the congestion window are largely orthogonal to the algorithms used to determine the appropriate size of the congestion window.
[VH97]），或使用最大突发大小控制[FF96]。我们认为，即使有限制背靠背数据包的发送或在往返时间内调整数据包的发送速度的机制，一段时间未完全使用的旧拥塞窗口也不能作为该流当前可用带宽的指示。我们认为，拥塞窗口允许的分组速度调整机制在很大程度上与用于确定拥塞窗口适当大小的算法正交。
When a TCP sender has sufficient data available to fill the available network capacity for that flow, cwnd and ssthresh get set to appropriate values for the network conditions. When a TCP sender stops sending, the flow stops sampling the network conditions, and so the value of the congestion window may become inaccurate. We believe the correct conservative behavior under these circumstances is to decay the congestion window by half for every RTT that the flow remains inactive. The value of half is a very conservative figure based on how quickly multiplicative decrease would have decayed the window in the presence of loss.
当TCP发送方有足够的可用数据来填充该流的可用网络容量时，cwnd和ssthresh将设置为适合网络条件的适当值。当TCP发送方停止发送时，流停止对网络状况进行采样，因此拥塞窗口的值可能变得不准确。我们认为，在这些情况下，正确的保守行为是将流量保持不活动的每个RTT的拥塞窗口衰减一半。一半的值是一个非常保守的数字，这是基于在存在损失的情况下乘法减少会使窗口衰减的速度。
Another possibility is that the sender may not stop sending, but may become application-limited rather than network-limited, and offer less data to the network than the congestion window allows to be sent. In this case the TCP flow is still sampling network conditions, but is not offering sufficient traffic to be sure that there is still sufficient capacity in the network for that flow to send a full congestion window. Under these circumstances we believe the correct conservative behavior is for the sender to keep track of the maximum amount of the congestion window used during each RTT, and to decay the congestion window each RTT to midway between the current cwnd value and the maximum value used.
另一种可能性是发送方可能不会停止发送，但可能会受到应用程序的限制而不是网络的限制，并且向网络提供的数据少于拥塞窗口允许发送的数据。在这种情况下，TCP流仍在对网络状况进行采样，但没有提供足够的流量，以确保网络中仍有足够的容量供该流发送完全拥塞窗口。在这些情况下，我们认为正确的保守行为是发送方跟踪每个RTT期间使用的拥塞窗口的最大数量，并将每个RTT的拥塞窗口衰减到当前cwnd值和使用的最大值之间的中间。
Before the congestion window is reduced, ssthresh is set to the maximum of its current value and 3/4 cwnd. If the sender then has more data to send than the decayed cwnd allows, the TCP will slow-start (perform exponential increase) at least half-way back up to the old value of cwnd.
在减少拥塞窗口之前，ssthresh设置为其当前值和3/4 cwnd的最大值。如果发送方随后有比衰减的cwnd允许的更多的数据要发送，TCP将使启动速度减慢（执行指数增长）至少一半，恢复到cwnd的旧值。
The justification for this value of "3/4 cwnd" is that 3/4 cwnd is a conservative estimate of the recent average value of the congestion window, and the TCP should safely be able to slow-start at least up to this point. For a TCP in steady-state that has been reducing its congestion window each time the congestion window reached some maximum value `maxwin', the average congestion window has been 3/4 maxwin. On average, when the connection becomes application-limited,
“3/4 cwnd”这个值的理由是3/4 cwnd是拥塞窗口最近平均值的保守估计，TCP应该至少能够安全地将启动速度减慢到这一点。对于在每次拥塞窗口达到某个最大值“maxwin”时一直在减少其拥塞窗口的稳态TCP，平均拥塞窗口为3/4 maxwin。平均而言，当连接受到应用程序限制时，
cwnd will be 3/4 maxwin, and in this case cwnd itself represents the average value of the congestion window. However, if the connection happens to become application-limited when cwnd equals maxwin, then the average value of the congestion window is given by 3/4 cwnd.
cwnd将是3/4 maxwin，在这种情况下，cwnd本身表示拥塞窗口的平均值。但是，如果当cwnd等于maxwin时连接恰好受到应用程序限制，则拥塞窗口的平均值由3/4 cwnd给出。
An alternate possibility would be to set ssthresh to the maximum of the current value of ssthresh, and the old value of cwnd, allowing TCP to slow-start all of the way back up to the old value of cwnd. Further experimentation can be used to evaluate these two options for setting ssthresh.
另一种可能性是将ssthresh设置为ssthresh的当前值和cwnd的旧值中的最大值，从而允许TCP将启动速度一直减慢到cwnd的旧值。进一步的实验可用于评估这两种设置ssthresh的选项。
For the separate issue of the increase of the congestion window in response to an acknowledgement, we believe the correct behavior is for the sender to increase the congestion window only if the window was full when the acknowledgment arrived.
对于响应确认而增加拥塞窗口的单独问题，我们认为正确的行为是发送方仅在确认到达时窗口已满时才增加拥塞窗口。
We term this set of modifications to TCP Congestion Window Validation (CWV) because they are related to ensuring the congestion window is always a valid reflection of the current network state as probed by the connection.
我们将这组修改称为TCP拥塞窗口验证（CWV），因为它们与确保拥塞窗口始终是连接探测到的当前网络状态的有效反映有关。
A key issue in the CWV algorithm is to determine how to apply the guideline of reducing the congestion window once for every roundtrip time that the flow is application-limited. We use TCP's retransmission timer (RTO) as a reasonable upper bound on the roundtrip time, and reduce the congestion window roughly once per RTO.
CWV算法中的一个关键问题是确定如何在流量受到应用程序限制的每个往返时间内应用减少拥塞窗口一次的准则。我们使用TCP的重传计时器（RTO）作为往返时间的合理上限，并且每个RTO大约减少一次拥塞窗口。
This basic algorithm could be implemented in TCP as follows: When TCP sends a new packet it checks to see if more than RTO seconds have elapsed since the previous packet was sent. If RTO has elapsed, ssthresh is set to the maximum of 3/4 cwnd and the current value of ssthresh, and then the congestion window is halved for every RTO that elapsed since the previous packet was sent. In addition, T_prev is set to the current time, and W_used is reset to zero. T_prev will be used to determine the elapsed time since the sender last was network-limited or had reduced cwnd after an idle period. When the sender is application-limited, W_used holds the maximum congestion window actually used since the sender was last network-limited.
这个基本算法可以在TCP中实现如下：当TCP发送一个新的数据包时，它会检查上一个数据包发送后是否超过RTO秒。如果RTO已过，则ssthresh设置为最大值3/4 cwnd和ssthresh的当前值，然后，自上一个数据包发送以来，每经过一个RTO，拥塞窗口将减半。此外，T_prev设置为当前时间，W_used重置为零。T_prev将用于确定自发送方上次受到网络限制或在空闲时间后减少cwnd以来经过的时间。当发送方受应用程序限制时，W_used将保留自发送方上次受网络限制以来实际使用的最大拥塞窗口。
The mechanism for determining the number of RTOs in the most recent idle period could also be implemented by using a timer that expires every RTO after the last packet was sent instead of a check per packet - efficiency constraints on different operating systems may dictate which is more efficient to implement.
用于确定最近空闲时间段内RTO数量的机制也可以通过使用在发送最后一个数据包后使每个RTO过期的计时器来实现，而不是每个数据包进行检查-不同操作系统上的效率约束可能决定哪个更有效。
After TCP sends a packet, it also checks to see if that packet filled the congestion window. If so, the sender is network-limited, and sets the variable T_prev to the current TCP clock time, and the variable W_used to zero.
TCP发送数据包后，它还检查该数据包是否填满了拥塞窗口。如果是，则发送方受网络限制，并将变量T_prev设置为当前TCP时钟时间，将变量W_设置为零。
When TCP sends a packet that does not fill the congestion window, and the TCP send queue is empty, then the sender is application-limited. The sender checks to see if the amount of unacknowledged data is greater than W_used; if so, W_used is set to the amount of unacknowledged data. In addition TCP checks to see if the elapsed time since T_prev is greater than RTO. If so, then the TCP has not just reduced its congestion window following an idle period. The TCP has been application-limited rather than network-limited for at least an entire RTO interval, but for less than two RTO intervals. In this case, TCP sets ssthresh to the maximum of 3/4 cwnd and the current value of ssthresh, and reduces its congestion window to (cwnd+W_used)/2. W_used is then set to zero, and T_prev is set to the current time, so a further reduction will not take place until at least another RTO period has elapsed. Thus, during an application-limited period the CWV algorithm reduces the congestion window once per RTO.
当TCP发送的数据包未填满拥塞窗口，且TCP发送队列为空时，则发送方受应用程序限制。发送方检查未确认的数据量是否大于所使用的数据量；如果是，则将W_used设置为未确认的数据量。此外，TCP会检查自T_prev以来经过的时间是否大于RTO。如果是这样，那么TCP不仅仅是在空闲时间之后减少了拥塞窗口。TCP至少在整个RTO时间间隔内受到应用程序限制，而不是网络限制，但不到两个RTO时间间隔。在这种情况下，TCP将ssthresh设置为最大值3/4 cwnd和ssthresh的当前值，并将其拥塞窗口减少为（cwnd+W_used）/2。然后，W_used设置为零，T_prev设置为当前时间，因此在至少另一个RTO周期过去之前，不会发生进一步的减少。因此，在应用程序有限的时间内，CWV算法每RTO减少一次拥塞窗口。
Initially:
T_last = tcpnow, T_prev = tcpnow, W_used = 0
Initially:
T_last = tcpnow, T_prev = tcpnow, W_used = 0
After sending a data segment:
If tcpnow - T_last >= RTO
(The sender has been idle.)
ssthresh = max(ssthresh, 3*cwnd/4)
For i=1 To (tcpnow - T_last)/RTO
win = min(cwnd, receiver's declared max window)
cwnd = max(win/2, MSS)
T_prev = tcpnow
W_used = 0
After sending a data segment:
If tcpnow - T_last >= RTO
(The sender has been idle.)
ssthresh = max(ssthresh, 3*cwnd/4)
For i=1 To (tcpnow - T_last)/RTO
win = min(cwnd, receiver's declared max window)
cwnd = max(win/2, MSS)
T_prev = tcpnow
W_used = 0
T_last = tcpnow
T_last = tcpnow
If window is full
T_prev = tcpnow
W_used = 0
Else
If no more data is available to send
W_used = max(W_used, amount of unacknowledged data)
If tcpnow - T_prev >= RTO
(The sender has been application-limited.)
ssthresh = max(ssthresh, 3*cwnd/4)
If window is full
T_prev = tcpnow
W_used = 0
Else
If no more data is available to send
W_used = max(W_used, amount of unacknowledged data)
If tcpnow - T_prev >= RTO
(The sender has been application-limited.)
ssthresh = max(ssthresh, 3*cwnd/4)
win = min(cwnd, receiver's declared max window)
cwnd = (win + W_used)/2
T_prev = tcpnow
W_used = 0
win = min(cwnd, receiver's declared max window)
cwnd = (win + W_used)/2
T_prev = tcpnow
W_used = 0
The CWV proposal has been implemented as an option in the network simulator NS [NS]. The simulations in the validation test suite for CWV can be run with the command "./test-all-tcp" in the directory "tcl/test". The simulations show the use of CWV to reduce the congestion window after a period when the TCP connection was application-limited, and to limit the increase in the congestion window when a transfer is application-limited. As the simulations illustrate, the use of ssthresh to maintain connection history is a critical part of the Congestion Window Validation algorithm. [HPF99] discusses these simulations in more detail.
CWV方案已作为网络模拟器NS[NS]中的一个选项实施。CWV验证测试套件中的模拟可以使用目录“tcl/test”中的“/test all tcp”命令运行。仿真表明，在TCP连接受到应用程序限制的一段时间后，使用CWV可以减少拥塞窗口，并在传输受到应用程序限制时限制拥塞窗口的增加。仿真表明，使用ssthresh来维护连接历史是拥塞窗口验证算法的关键部分。[HPF99]更详细地讨论了这些模拟。
We have implemented the CWV mechanism in the TCP implementation in FreeBSD 3.2. [HPF99] discusses these experiments in more detail.
我们在FreeBSD3.2的TCP实现中实现了CWV机制。[HPF99]更详细地讨论了这些实验。
The first experiment examines the effects of the Congestion Window Validation mechanisms for limiting cwnd increases during application-limited periods. The experiment used a real ssh connection through a modem link emulated using Dummynet [Dummynet]. The link speed is 30Kb/s and the link has five packet buffers available. Today most modem banks have more buffering available than this, but the more buffer-limited situation sometimes occurs with older modems. In the first half of the transfer, the user is typing away over the connection. About half way through the time, the user lists a moderately large file, which causes a large burst of traffic to be transmitted.
第一个实验考察了拥塞窗口验证机制在应用程序受限期间限制cwnd增加的效果。该实验通过使用Dummynet[Dummynet]模拟的调制解调器链路使用了一个真正的ssh连接。链路速度为30Kb/s，链路有五个可用的数据包缓冲区。今天，大多数调制解调器组都有比这更多的可用缓冲区，但较旧的调制解调器有时会出现缓冲区更有限的情况。在传输的前半部分，用户通过连接不断地输入。在大约一半的时间里，用户列出了一个中等大小的文件，这会导致传输大量流量。
For the unmodified TCP, every returning ACK during the first part of the transfer results in an increase in cwnd. As a result, the large burst of data arriving from the application to the transport layer is sent as many back-to-back packets, most of which get lost and subsequently retransmitted.
对于未修改的TCP，在传输的第一部分期间，每次返回ACK都会导致cwnd的增加。结果，从应用程序到达传输层的大量数据突发被发送为多个背对背数据包，其中大部分数据包丢失并随后重新传输。
For the modified TCP with Congestion Window Validation, the congestion window is not increased when the window is not full, and has been decreased during application-limited periods closer to what the user actually used. The burst of traffic is now constrained by the congestion window, resulting in a better-behaved flow with
对于带有拥塞窗口验证的修改TCP，当窗口未满时，拥塞窗口不会增加，而在应用程序限制期间，拥塞窗口会在更接近用户实际使用的时间段内减少。流量的突发现在受到拥塞窗口的约束，从而产生了性能更好的流量
minimal loss. The end result is that the transfer happens approximately 30% faster than the transfer without CWV, due to avoiding retransmission timeouts.
损失最小。最终的结果是，由于避免了重传超时，传输速度比不使用CWV的传输快约30%。
The second experiment uses a real ssh connection over a real dialup ppp connection, where the modem bank has much more buffering. For the unmodified TCP, the initial burst from the large file does not cause loss, but does cause the RTT to increase to approximately 5 seconds, where the connection becomes bounded by the receiver's window.
第二个实验使用真正的ssh连接，而不是真正的拨号ppp连接，其中调制解调器组有更多的缓冲。对于未修改的TCP，来自大文件的初始突发不会导致丢失，但会导致RTT增加到大约5秒，此时连接会受到接收器窗口的限制。
For the modified TCP with Congestion Window Validation, the flow is much better behaved, and produces no large burst of traffic. In this case the linear increase for cwnd results in a slow increase in the RTT as the buffer slowly fills.
对于带有拥塞窗口验证的改进TCP，该流表现得更好，并且不会产生大的流量突发。在这种情况下，随着缓冲区慢慢填满，cwnd的线性增加导致RTT缓慢增加。
For the second experiment, both the modified and the unmodified TCP finish delivering the data at precisely the same time. This is because the link has been fully utilized in both cases due to the modem buffer being larger than the receiver window. Clearly a modem buffer of this size is undesirable due to its effect on the RTT of competing flows, but it is necessary with current TCP implementations that produce bursts similar to those shown in the top graph.
在第二个实验中，修改后的和未修改的TCP都在同一时间完成数据传输。这是因为在这两种情况下，由于调制解调器缓冲区大于接收器窗口，链路已被充分利用。显然，由于其对竞争流的RTT的影响，这种大小的调制解调器缓冲区是不可取的，但对于产生类似于上图所示的突发的当前TCP实现来说，这是必要的。
This document has presented several TCP algorithms for Congestion Window Validation, to be employed after an idle period or a period in which the sender was application-limited, and before an increase of the congestion window. The goal of these algorithms is for TCP's congestion window to reflect recent knowledge of the TCP connection about the state of the network path, while at the same time keeping some memory (i.e., in ssthresh) about the earlier state of the path. We believe that these modifications will be of benefit to both the network and to the TCP flows themselves, by preventing unnecessary packet drops due to the TCP sender's failure to update its information (or lack of information) about current network conditions. Future work will document and investigate the benefit provided by these algorithms, using both simulations and experiments. Additional future work will describe a more complex version of the CWV algorithm for TCP implementations where the sender does not have an accurate estimate of the TCP roundtrip time.
本文档介绍了几种用于拥塞窗口验证的TCP算法，这些算法将在空闲期或发送方受到应用程序限制的期间之后以及拥塞窗口增加之前使用。这些算法的目标是使TCP的拥塞窗口反映有关网络路径状态的TCP连接的最新知识，同时保留一些关于路径早期状态的内存（即，在ssthresh中）。我们相信，这些修改将有利于网络和TCP流本身，防止由于TCP发送方未能更新其关于当前网络状况的信息（或缺少信息）而导致不必要的数据包丢失。未来的工作将使用模拟和实验记录和研究这些算法提供的好处。未来的其他工作将描述用于TCP实现的CWV算法的更复杂版本，其中发送方无法准确估计TCP往返时间。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21. URL "http://www.aciri.org/floyd/papers.html".
[FF96]K.Fall和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。URL“http://www.aciri.org/floyd/papers.html".
[HPF99] Mark Handley, Jitendra Padhye, Sally Floyd, TCP Congestion Window Validation, UMass CMPSCI Technical Report 99-77, September 1999. URL "ftp://www-net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".
[HPF99]Mark Handley，Jitendra Padhye，Sally Floyd，TCP拥塞窗口验证，麻省大学CMPSCI技术报告99-77，1999年9月。URL“ftp://www-net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".
[HTH98] Amy Hughes, Joe Touch, John Heidemann, "Issues in TCP Slow-Start Restart After Idle", Work in Progress.
[HTH98]Amy Hughes，Joe Touch，John Heidemann，“空闲后TCP慢启动重启中的问题”，正在进行的工作。
[J88] Jacobson, V., Congestion Avoidance and Control, Originally from Proceedings of SIGCOMM '88 (Palo Alto, CA, Aug. 1988), and revised in 1992. URL "http://www-nrg.ee.lbl.gov/nrg-papers.html".
[J88]Jacobson，V.，拥塞避免和控制，最初摘自SIGCOMM'88诉讼（加州帕洛阿尔托，1988年8月），并于1992年修订。URL“http://www-nrg.ee.lbl.gov/nrg-papers.html".
[JKBFL96] Raj Jain, Shiv Kalyanaraman, Rohit Goyal, Sonia Fahmy, and Fang Lu, Comments on "Use-it or Lose-it", ATM Forum Document Number: ATM Forum/96-0178, URL "http://www.netlab.ohio-state.edu/~jain/atmf/af_rl5b2.htm".
[JKBFL96]Raj Jain、Shiv Kalyanaraman、Rohit Goyal、Sonia Fahmy和Fang Lu，关于“使用它或失去它”的评论，ATM论坛文件编号：ATM论坛/96-0178，URL“http://www.netlab.ohio-state.edu/~jain/atmf/af_rl5b2.htm”。
[JKGFL95] R. Jain, S. Kalyanaraman, R. Goyal, S. Fahmy, and F. Lu, A Fix for Source End System Rule 5, AF-TM 95-1660, December 1995, URL "http://www.netlab.ohio-state.edu/~jain/atmf/af_rl52.htm".
[JKGFL95]R.Jain、S.Kalyanaraman、R.Goyal、S.Fahmy和F.Lu，源端系统规则5的修复，AF-TM 95-16601995年12月，URL“http://www.netlab.ohio-state.edu/~jain/atmf/af_rl52.htm”。
[MSML99] Matt Mathis, Jeff Semke, Jamshid Mahdavi, and Kevin Lahey, The Rate-Halving Algorithm for TCP Congestion Control, June 1999. URL "http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt".
[MSML99]Matt Mathis、Jeff Semke、Jamshid Mahdavi和Kevin Lahey，《TCP拥塞控制速率减半算法》，1999年6月。URL“http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt".
[NS] NS, the UCB/LBNL/VINT Network Simulator. URL "http://www-mash.cs.berkeley.edu/ns/".
[NS]NS，UCB/LBNL/VINT网络模拟器。URL“http://www-mash.cs.berkeley.edu/ns/".
[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月。
[VH97] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections, Technical Report 97-661, University of Southern California, November, 1997.
[VH97]Vikram Visweswaraiah和John Heidemann。改进空闲TCP连接的重新启动，技术报告97661，南加州大学，1997年11月。
[Dummynet] Luigi Rizzo, "Dummynet and Forward Error Correction", Freenix 98, June 1998, New Orleans. URL "http://info.iet.unipi.it/~luigi/ip_dummynet/".
[Dummynet]Luigi Rizzo，“Dummynet和前向纠错”，Freenix 981998年6月，新奥尔良。URL“http://info.iet.unipi.it/~luigi/ip_dummynet/”。
General security considerations concerning TCP congestion control are discussed in RFC 2581. This document describes a algorithm for one aspect of those congestion control procedures, and so the considerations described in RFC 2581 apply to this algorithm also. There are no known additional security concerns for this specific algorithm.
RFC 2581中讨论了有关TCP拥塞控制的一般安全注意事项。本文档描述了这些拥塞控制过程的一个方面的算法，因此RFC 2581中描述的注意事项也适用于该算法。此特定算法没有已知的其他安全问题。
Mark Handley AT&T Center for Internet Research at ICSI (ACIRI)
ICSI的马克·汉德利AT&T互联网研究中心（ACIRI）
Phone: +1 510 666 2946
EMail: mjh@aciri.org
URL: http://www.aciri.org/mjh/
Phone: +1 510 666 2946
EMail: mjh@aciri.org
URL: http://www.aciri.org/mjh/
Jitendra Padhye AT&T Center for Internet Research at ICSI (ACIRI)
美国电话电报公司ICSI互联网研究中心（ACIRI）
Phone: +1 510 666 2887
EMail: padhye@aciri.org
URL: http://www-net.cs.umass.edu/~jitu/
Phone: +1 510 666 2887
EMail: padhye@aciri.org
URL: http://www-net.cs.umass.edu/~jitu/
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
萨莉·弗洛伊德美国电话电报公司ICSI互联网研究中心（ACIRI）
Phone: +1 510 666 2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Phone: +1 510 666 2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。