Network Working Group M. Allman
Request for Comments: 2414 NASA Lewis/Sterling Software
Category: Experimental S. Floyd
LBNL
C. Partridge
BBN Technologies
September 1998
Network Working Group M. Allman
Request for Comments: 2414 NASA Lewis/Sterling Software
Category: Experimental S. Floyd
LBNL
C. Partridge
BBN Technologies
September 1998
Increasing TCP's Initial Window
增加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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP.
本文档指定将TCP允许的初始窗口从一个段增加到大约4K字节。本文讨论了这种改变的优点和缺点，概述了表明TCP改变的成本和好处的实验结果。
Terminology
术语
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document specifies an increase in the permitted upper bound for TCP's initial window from one segment to between two and four segments. In most cases, this change results in an upper bound on the initial window of roughly 4K bytes (although given a large segment size, the permitted initial window of two segments could be significantly larger than 4K bytes). The upper bound for the initial window is given more precisely in (1):
本文件规定将TCP初始窗口的允许上限从一个段增加到两到四个段之间。在大多数情况下，此更改导致初始窗口的上限约为4K字节（尽管给定了较大的段大小，但允许的两个段的初始窗口可能明显大于4K字节）。初始窗口的上限在（1）中给出得更精确：
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
最小值（4*MSS，最大值（2*MSS，4380字节））（1）
Equivalently, the upper bound for the initial window size is based on the maximum segment size (MSS), as follows:
等效地，初始窗口大小的上限基于最大段大小（MSS），如下所示：
If (MSS <= 1095 bytes)
then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes)
then win <= 4380;
If (2190 bytes <= MSS)
then win <= 2 * MSS;
If (MSS <= 1095 bytes)
then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes)
then win <= 4380;
If (2190 bytes <= MSS)
then win <= 2 * MSS;
This increased initial window is optional: that a TCP MAY start with a larger initial window, not that it SHOULD.
这个增加的初始窗口是可选的：TCP可以从一个更大的初始窗口开始，而不是应该从一个更大的初始窗口开始。
This upper bound for the initial window size represents a change from RFC 2001 [S97], which specifies that the congestion window be initialized to one segment. If implementation experience proves successful, then the intent is for this change to be incorporated into a revision to RFC 2001.
初始窗口大小的上限表示RFC 2001[S97]的变化，RFC 2001[S97]指定将拥塞窗口初始化为一个段。如果实施经验证明是成功的，那么目的是将这一变更纳入RFC 2001的修订版中。
This change applies to the initial window of the connection in the first round trip time (RTT) of transmission following the TCP three-way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in the three-way handshake should increase the initial window size above that outlined in equation (1). If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment.
此更改适用于TCP三方握手后传输的第一个往返时间（RTT）中连接的初始窗口。三向握手中的SYN/ACK及其确认（ACK）都不应将初始窗口大小增加到方程（1）中所述的大小以上。如果SYN或SYN/ACK丢失，发送方在正确传输SYN后使用的初始窗口必须为一段。
TCP implementations use slow start in as many as three different ways: (1) to start a new connection (the initial window); (2) to restart a transmission after a long idle period (the restart window); and (3) to restart after a retransmit timeout (the loss window). The change proposed in this document affects the value of the initial window. Optionally, a TCP MAY set the restart window to the minimum of the value used for the initial window and the current value of cwnd (in other words, using a larger value for the restart window should never increase the size of cwnd). These changes do NOT change the loss window, which must remain 1 segment (to permit the lowest possible window size in the case of severe congestion).
TCP实现使用慢启动的方式多达三种：（1）启动新连接（初始窗口）；（2） 在长时间闲置后重新启动变速箱（重新启动窗口）；以及（3）在重新传输超时（丢失窗口）后重新启动。本文档中建议的更改会影响初始窗口的值。或者，TCP可以将重新启动窗口设置为初始窗口使用的值和cwnd的当前值中的最小值（换句话说，为重新启动窗口使用较大的值不应增加cwnd的大小）。这些更改不会更改丢失窗口，丢失窗口必须保持为1段（以便在严重拥挤的情况下允许最小的窗口大小）。
When larger initial windows are implemented along with Path MTU Discovery [MD90], and the MSS being used is found to be too large, the congestion window `cwnd' SHOULD be reduced to prevent large bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced by the ratio of the old segment size to the new segment size.
当较大的初始窗口与路径MTU发现[MD90]一起实施时，并且发现所使用的MSS太大，则应减少拥塞窗口“cwnd”，以防止较小段的大突发。具体而言，“cwnd”应按旧段大小与新段大小的比率减少。
When larger initial windows are implemented along with Path MTU Discovery [MD90], alternatives are to set the "Don't Fragment" (DF) bit in all segments in the initial window, or to set the "Don't Fragment" (DF) bit in one of the segments. It is an open question which of these two alternatives is best; we would hope that implementation experiences will shed light on this. In the first case of setting the DF bit in all segments, if the initial packets are too large, then all of the initial packets will be dropped in the network. In the second case of setting the DF bit in only one segment, if the initial packets are too large, then all but one of the initial packets will be fragmented in the network. When the second case is followed, setting the DF bit in the last segment in the initial window provides the least chance for needless retransmissions when the initial segment size is found to be too large, because it minimizes the chances of duplicate ACKs triggering a Fast Retransmit. However, more attention needs to be paid to the interaction between larger initial windows and Path MTU Discovery.
当较大的初始窗口与路径MTU发现[MD90]一起实施时，替代方法是在初始窗口的所有段中设置“不分段”（DF）位，或在其中一段中设置“不分段”（DF）位。这两个选择中哪一个是最好的，这是一个悬而未决的问题；我们希望，执行经验将对此有所启示。在第一种情况下，在所有段中设置DF位，如果初始数据包太大，则所有初始数据包将在网络中丢弃。在仅在一个段中设置DF位的第二种情况下，如果初始数据包太大，则除了一个初始数据包之外，所有初始数据包都将在网络中被分段。当遵循第二种情况时，在初始窗口的最后一个段中设置DF位，当发现初始段大小太大时，提供不必要的重新传输的机会最小，因为它将重复ACK触发快速重新传输的机会降至最低。然而，需要更多地关注较大初始窗口和路径MTU发现之间的交互。
The larger initial window proposed in this document is not intended as an encouragement for web browsers to open multiple simultaneous TCP connections all with large initial windows. When web browsers open simultaneous TCP connections to the same destination, this works against TCP's congestion control mechanisms [FF98], regardless of the size of the initial window. Combining this behavior with larger initial windows further increases the unfairness to other traffic in the network.
本文档中建议的较大初始窗口并不是为了鼓励web浏览器同时打开多个TCP连接，所有这些连接都具有较大的初始窗口。当web浏览器同时打开到同一目的地的TCP连接时，无论初始窗口大小如何，这都会对TCP的拥塞控制机制[FF98]起作用。将此行为与较大的初始窗口相结合，会进一步增加对网络中其他流量的不公平性。
1. When the initial window is one segment, a receiver employing delayed ACKs [Bra89] is forced to wait for a timeout before generating an ACK. With an initial window of at least two segments, the receiver will generate an ACK after the second data segment arrives. This eliminates the wait on the timeout (often up to 200 msec).
1. 当初始窗口为一段时，采用延迟ACK[Bra89]的接收器在生成ACK之前被迫等待超时。对于至少两个段的初始窗口，接收器将在第二个数据段到达后生成ACK。这消除了超时等待（通常高达200毫秒）。
2. For connections transmitting only a small amount of data, a larger initial window reduces the transmission time (assuming at most moderate segment drop rates). For many email (SMTP [Pos82]) and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less than 4K bytes, the larger initial window would reduce the data transfer time to a single RTT.
2. 对于仅传输少量数据的连接，较大的初始窗口会缩短传输时间（假设段丢失率最多为中等）。对于许多小于4K字节的电子邮件（SMTP[Pos82]）和网页（HTTP[BLFN96，FJGFBL97]）传输，较大的初始窗口会将数据传输时间缩短到单个RTT。
3. For connections that will be able to use large congestion windows, this modification eliminates up to three RTTs and a delayed ACK timeout during the initial slow-start phase. This
3. 对于能够使用大拥塞窗口的连接，此修改在初始慢速启动阶段消除了多达三个RTT和延迟的ACK超时。这
would be of particular benefit for high-bandwidth large-propagation-delay TCP connections, such as those over satellite links.
对于高带宽、大传播延迟的TCP连接，例如通过卫星链路的连接，将特别有利。
4. Disadvantages of Larger Initial Windows for the Individual Connection
4. 单个连接的初始窗口较大的缺点
In high-congestion environments, particularly for routers that have a bias against bursty traffic (as in the typical Drop Tail router queues), a TCP connection can sometimes be better off starting with an initial window of one segment. There are scenarios where a TCP connection slow-starting from an initial window of one segment might not have segments dropped, while a TCP connection starting with an initial window of four segments might experience unnecessary retransmits due to the inability of the router to handle small bursts. This could result in an unnecessary retransmit timeout. For a large-window connection that is able to recover without a retransmit timeout, this could result in an unnecessarily-early transition from the slow-start to the congestion-avoidance phase of the window increase algorithm. These premature segment drops are unlikely to occur in uncongested networks with sufficient buffering or in moderately-congested networks where the congested router uses active queue management (such as Random Early Detection [FJ93, RFC2309]).
在高拥塞环境中，尤其是对突发流量有偏见的路由器（如典型的掉尾路由器队列），TCP连接有时最好从一个段的初始窗口开始。在某些情况下，从一个段的初始窗口开始的TCP连接速度较慢，可能不会丢弃段，而从四个段的初始窗口开始的TCP连接可能会由于路由器无法处理小突发而经历不必要的重新传输。这可能会导致不必要的重新传输超时。对于能够在无需重新传输超时的情况下恢复的大窗口连接，这可能会导致不必要的提前过渡，从窗口增加算法的慢速启动过渡到拥塞避免阶段。这些过早的段丢失不太可能发生在具有足够缓冲的未阻塞网络中，或者在拥塞路由器使用主动队列管理（例如随机早期检测[FJ93，RFC2309]）的中度拥塞网络中。
Some TCP connections will receive better performance with the higher initial window even if the burstiness of the initial window results in premature segment drops. This will be true if (1) the TCP connection recovers from the segment drop without a retransmit timeout, and (2) the TCP connection is ultimately limited to a small congestion window by either network congestion or by the receiver's advertised window.
一些TCP连接在较高的初始窗口下将获得更好的性能，即使初始窗口的突发性导致过早的段丢失。如果（1）TCP连接在没有重新传输超时的情况下从段丢失中恢复，并且（2）TCP连接最终被网络拥塞或接收器的播发窗口限制在一个小的拥塞窗口内，则这将是正确的。
In terms of the potential for congestion collapse, we consider two separate potential dangers for the network. The first danger would be a scenario where a large number of segments on congested links were duplicate segments that had already been received at the receiver. The second danger would be a scenario where a large number of segments on congested links were segments that would be dropped later in the network before reaching their final destination.
在拥塞崩溃的可能性方面，我们考虑了两个不同的潜在危险的网络。第一种危险是，拥塞链路上的大量段是接收器已经接收到的重复段。第二个危险是拥塞链路上的大量段是在到达最终目的地之前在网络中稍后丢弃的段。
In terms of the negative effect on other traffic in the network, a potential disadvantage of larger initial windows would be that they increase the general packet drop rate in the network. We discuss these three issues below.
就对网络中其他流量的负面影响而言，较大初始窗口的一个潜在缺点是它们会增加网络中的一般分组丢弃率。我们将在下面讨论这三个问题。
Duplicate segments:
重复段：
As described in the previous section, the larger initial window could occasionally result in a segment dropped from the initial window, when that segment might not have been dropped if the sender had slow-started from an initial window of one segment. However, Appendix A shows that even in this case, the larger initial window would not result in the transmission of a large number of duplicate segments.
如前一节所述，较大的初始窗口偶尔会导致从初始窗口中删除段，如果发送方从一个段的初始窗口缓慢启动，则该段可能不会被删除。然而，附录A显示，即使在这种情况下，较大的初始窗口也不会导致大量重复段的传输。
Segments dropped later in the network:
稍后在网络中删除的段：
How much would the larger initial window for TCP increase the number of segments on congested links that would be dropped before reaching their final destination? This is a problem that can only occur for connections with multiple congested links, where some segments might use scarce bandwidth on the first congested link along the path, only to be dropped later along the path.
TCP的初始窗口越大，拥塞链路上在到达最终目的地之前丢弃的段数会增加多少？这是一个仅在具有多个拥塞链路的连接中才会出现的问题，其中一些网段可能在路径上的第一个拥塞链路上使用稀缺带宽，但随后会在路径上丢弃。
First, many of the TCP connections will have only one congested link along the path. Segments dropped from these connections do not "waste" scarce bandwidth, and do not contribute to congestion collapse.
首先，许多TCP连接在路径上只有一个拥塞的链路。从这些连接断开的网段不会“浪费”稀缺的带宽，也不会导致拥塞崩溃。
However, some network paths will have multiple congested links, and segments dropped from the initial window could use scarce bandwidth along the earlier congested links before ultimately being dropped on subsequent congested links. To the extent that the drop rate is independent of the initial window used by TCP segments, the problem of congested links carrying segments that will be dropped before reaching their destination will be similar for TCP connections that start by sending four segments or one segment.
然而，一些网络路径将有多个拥塞链路，从初始窗口丢弃的段可能会使用早期拥塞链路上的稀缺带宽，然后最终在后续拥塞链路上丢弃。由于丢包率与TCP段使用的初始窗口无关，拥塞链路承载的段在到达目的地之前将被丢包的问题对于发送四个段或一个段开始的TCP连接类似。
An increased packet drop rate:
增加的数据包丢弃率：
For a network with a high segment drop rate, increasing the TCP initial window could increase the segment drop rate even further. This is in part because routers with Drop Tail queue management have difficulties with bursty traffic in times of congestion. However, given uncorrelated arrivals for TCP connections, the larger TCP initial window should not significantly increase the segment drop rate. Simulation-based explorations of these issues are discussed in Section 7.2.
对于具有高段丢弃率的网络，增加TCP初始窗口可能会进一步增加段丢弃率。这部分是因为具有掉尾队列管理的路由器在拥塞时难以处理突发流量。然而，考虑到TCP连接的不相关到达，较大的TCP初始窗口不应显著增加段丢失率。第7.2节讨论了这些问题的模拟探索。
These potential dangers for the network are explored in simulations and experiments described in the section below. Our judgement would be, while there are dangers of congestion collapse in the current Internet (see [FF98] for a discussion of the dangers of congestion collapse from an increased deployment of UDP connections without end-to-end congestion control), there is no such danger to the network from increasing the TCP initial window to 4K bytes.
这些网络的潜在危险将在以下部分描述的模拟和实验中探讨。我们的判断是，虽然当前互联网存在拥塞崩溃的危险（有关在没有端到端拥塞控制的情况下增加部署UDP连接导致拥塞崩溃的危险的讨论，请参见[FF98]），但将TCP初始窗口增加到4K字节对网络没有这种危险。
6. Typical Levels of Burstiness for TCP Traffic.
6. TCP流量的典型突发性级别。
Larger TCP initial windows would not dramatically increase the burstiness of TCP traffic in the Internet today, because such traffic is already fairly bursty. Bursts of two and three segments are already typical of TCP [Flo97]; A delayed ACK (covering two previously unacknowledged segments) received during congestion avoidance causes the congestion window to slide and two segments to be sent. The same delayed ACK received during slow start causes the window to slide by two segments and then be incremented by one segment, resulting in a three-segment burst. While not necessarily typical, bursts of four and five segments for TCP are not rare. Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK to cover four previously unacknowledged segments. During congestion avoidance this leads to a four-segment burst and during slow start a five-segment burst is generated.
较大的TCP初始窗口不会显著增加当前Internet中TCP流量的突发性，因为此类流量已经相当突发。两段和三段的突发已经是TCP的典型特征[Flo97]；在拥塞避免期间接收到的延迟确认（覆盖两个以前未确认的段）会导致拥塞窗口滑动并发送两个段。慢速启动期间接收到的相同延迟ACK会导致窗口滑动两段，然后增加一段，从而导致三段突发。虽然不一定是典型的，但TCP的四段和五段突发并不罕见。假设延迟确认，单个丢弃的确认将导致后续确认覆盖四个先前未确认的段。在避免拥塞期间，这将导致四段突发，而在缓慢启动期间，将生成五段突发。
There are also changes in progress that reduce the performance problems posed by moderate traffic bursts. One such change is the deployment of higher-speed links in some parts of the network, where a burst of 4K bytes can represent a small quantity of data. A second change, for routers with sufficient buffering, is the deployment of queue management mechanisms such as RED, which is designed to be tolerant of transient traffic bursts.
还有一些正在进行中的更改，可以减少由中等流量突发造成的性能问题。其中一个变化是在网络的某些部分部署了高速链路，其中4K字节的突发可以表示少量数据。对于具有足够缓冲的路由器来说，第二个变化是部署诸如RED之类的队列管理机制，该机制旨在容忍瞬时流量突发。
This section surveys simulations and experiments that have been used to explore the effect of larger initial windows on the TCP connection using that larger window. The first set of experiments explores performance over satellite links. Larger initial windows have been shown to improve performance of TCP connections over satellite channels [All97b]. In this study, an initial window of four segments (512 byte MSS) resulted in throughput improvements of up to 30% (depending upon transfer size). [KAGT98] shows that the use of larger initial windows results in a decrease in transfer time in HTTP tests over the ACTS satellite system. A study involving simulations
本节介绍了用于探索较大初始窗口对使用该较大窗口的TCP连接的影响的模拟和实验。第一组实验探索了卫星链路的性能。较大的初始窗口可以提高卫星信道上TCP连接的性能[All97b]。在这项研究中，四个段（512字节MSS）的初始窗口导致吞吐量提高高达30%（取决于传输大小）。[KAGT98]表明，使用较大的初始窗口会减少ACTS卫星系统HTTP测试的传输时间。涉及模拟的研究
of a large number of HTTP transactions over hybrid fiber coax (HFC) indicates that the use of larger initial windows decreases the time required to load WWW pages [Nic97].
通过混合光纤同轴电缆（HFC）实现的大量HTTP事务表明，使用较大的初始窗口减少了加载WWW页面所需的时间[Nic97]。
A second set of experiments has explored TCP performance over dialup modem links. In experiments over a 28.8 bps dialup channel [All97a, AHO98], a four-segment initial window decreased the transfer time of a 16KB file by roughly 10%, with no accompanying increase in the drop rate. A particular area of concern has been TCP performance over low speed tail circuits (e.g., dialup modem links) with routers with small buffers. A simulation study [SP97] investigated the effects of using a larger initial window on a host connected by a slow modem link and a router with a 3 packet buffer. The study concluded that for the scenario investigated, the use of larger initial windows was not harmful to TCP performance. Questions have been raised concerning the effects of larger initial windows on the transfer time for short transfers in this environment, but these effects have not been quantified. A question has also been raised concerning the possible effect on existing TCP connections sharing the link.
第二组实验探索了拨号调制解调器链路上的TCP性能。在一个28.8 bps的拨号通道[All97a，AHO98]上进行的实验中，四段初始窗口将16KB文件的传输时间减少了约10%，而丢弃率没有随之增加。一个特别值得关注的领域是TCP在低速尾部电路（例如拨号调制解调器链路）上的性能，路由器具有较小的缓冲区。一项模拟研究[SP97]调查了在通过低速调制解调器链路连接的主机和具有3个数据包缓冲区的路由器上使用较大初始窗口的影响。该研究得出结论，对于所研究的场景，使用较大的初始窗口不会对TCP性能造成损害。在这种环境下，较大的初始窗口对短传输的传输时间的影响提出了问题，但这些影响尚未量化。还提出了一个问题，即对共享链路的现有TCP连接可能产生的影响。
This section surveys simulations and experiments investigating the impact of the larger window on other TCP connections sharing the path. Experiments in [All97a, AHO98] show that for 16 KB transfers to 100 Internet hosts, four-segment initial windows resulted in a small increase in the drop rate of 0.04 segments/transfer. While the drop rate increased slightly, the transfer time was reduced by roughly 25% for transfers using the four-segment (512 byte MSS) initial window when compared to an initial window of one segment.
本节将介绍模拟和实验，研究较大窗口对共享路径的其他TCP连接的影响。[All97a，AHO98]中的实验表明，对于100台Internet主机的16 KB传输，四段初始窗口导致0.04段/传输的下降率略有增加。虽然下降率略有增加，但与一个段的初始窗口相比，使用四段（512字节MSS）初始窗口的传输时间减少了约25%。
One scenario of concern is heavily loaded links. For instance, a couple of years ago, one of the trans-Atlantic links was so heavily loaded that the correct congestion window size for a connection was about one segment. In this environment, new connections using larger initial windows would be starting with windows that were four times too big. What would the effects be? Do connections thrash?
一个令人担忧的场景是重负载链接。例如，几年前，一条跨大西洋航线负载过重，正确的拥塞窗口大小大约为一段。在这种环境下，使用较大初始窗口的新连接将从四倍大的窗口开始。会有什么影响？你的关系有问题吗？
A simulation study in [PN98] explores the impact of a larger initial window on competing network traffic. In this investigation, HTTP and FTP flows share a single congested gateway (where the number of HTTP and FTP flows varies from one simulation set to another). For each simulation set, the paper examines aggregate link utilization and packet drop rates, median web page delay, and network power for the FTP transfers. The larger initial window generally resulted in increased throughput, slightly-increased packet drop rates, and an increase in overall network power. With the exception of one scenario, the larger initial window resulted in an increase in the
[PN98]中的一项模拟研究探讨了较大初始窗口对竞争网络流量的影响。在本研究中，HTTP和FTP流共享一个拥塞网关（其中HTTP和FTP流的数量因模拟集而异）。对于每个模拟集，本文检查FTP传输的聚合链路利用率和丢包率、中间网页延迟和网络功率。较大的初始窗口通常会增加吞吐量，略微增加丢包率，并增加总体网络功率。除一种情况外，较大的初始窗口导致
drop rate of less than 1% above the loss rate experienced when using a one-segment initial window; in this scenario, the drop rate increased from 3.5% with one-segment initial windows, to 4.5% with four-segment initial windows. The overall conclusions were that increasing the TCP initial window to three packets (or 4380 bytes) helps to improve perceived performance.
下降率低于使用单段初始窗口时损失率的1%；在这种情况下，下降率从单段初始窗口的3.5%增加到四段初始窗口的4.5%。总体结论是，将TCP初始窗口增加到三个数据包（或4380字节）有助于提高感知性能。
Morris [Mor97] investigated larger initial windows in a very congested network with transfers of size 20K. The loss rate in networks where all TCP connections use an initial window of four segments is shown to be 1-2% greater than in a network where all connections use an initial window of one segment. This relationship held in scenarios where the loss rates with one-segment initial windows ranged from 1% to 11%. In addition, in networks where connections used an initial window of four segments, TCP connections spent more time waiting for the retransmit timer (RTO) to expire to resend a segment than was spent when using an initial window of one segment. The time spent waiting for the RTO timer to expire represents idle time when no useful work was being accomplished for that connection. These results show that in a very congested environment, where each connection's share of the bottleneck bandwidth is close to one segment, using a larger initial window can cause a perceptible increase in both loss rates and retransmit timeouts.
Morris[Mor97]研究了一个非常拥挤的网络中的较大初始窗口，传输大小为20K。所有TCP连接使用四段初始窗口的网络中的丢失率比所有连接使用一段初始窗口的网络中的丢失率高1-2%。这种关系在损失率为1%至11%的情况下保持不变。此外，在连接使用四个段的初始窗口的网络中，TCP连接等待重传计时器（RTO）过期以重新发送段的时间比使用一个段的初始窗口的时间要长。等待RTO计时器过期所花费的时间表示没有为该连接完成任何有用工作时的空闲时间。这些结果表明，在非常拥挤的环境中，每个连接的瓶颈带宽份额接近一个网段，使用较大的初始窗口会导致丢失率和重传超时明显增加。
This document discusses the initial congestion window permitted for TCP connections. Changing this value does not raise any known new security issues with TCP.
本文档讨论TCP连接允许的初始拥塞窗口。更改此值不会导致TCP出现任何已知的新安全问题。
This document proposes a small change to TCP that may be beneficial to short-lived TCP connections and those over links with long RTTs (saving several RTTs during the initial slow-start phase).
本文档建议对TCP进行一个小的更改，这可能有利于短寿命TCP连接和长RTT链路上的连接（在初始慢启动阶段节省几个RTT）。
We would like to acknowledge Vern Paxson, Tim Shepard, members of the End-to-End-Interest Mailing List, and members of the IETF TCP Implementation Working Group for continuing discussions of these issues for discussions and feedback on this document.
我们感谢Vern Paxson、Tim Shepard、端到端兴趣邮件列表的成员以及IETF TCP实施工作组的成员继续讨论这些问题，以便对本文件进行讨论和反馈。
[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting -- TCP Implementations WG. December, 1997. Washington, DC.
马克·奥尔曼。具有较大初始窗口的TCP评估。第40次IETF会议——TCP实施工作组。1997年12月。华盛顿特区。
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. Submitted to ACM Computer Communication Review. URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/ initwin.ps".
[AHO98]Mark Allman、Chris Hayes和Shawn Ostermann，对初始窗口较大的TCP的评估，1998年3月。提交给ACM计算机通信审查。URL:“http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps”。
[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
马克·奥尔曼。提高卫星信道上的TCP性能。俄亥俄大学硕士论文，1997年6月。
[BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[BLFN96]Berners Lee，T.，Fielding，R.，和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
[FF96]Fall，K.，和Floyd，S.，基于模拟的塔霍、雷诺和SACK TCP比较。《计算机通信评论》，26（3），1996年7月。
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking. URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".
萨莉·弗洛伊德，凯文·法尔。促进互联网端到端拥塞控制的使用。提交给IEEE网络事务。URL“http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".
[FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[FJGFBL97]菲尔丁，R.，莫卧儿，J.，盖蒂斯，J.，弗莱斯蒂克，H.，和T.伯纳斯·李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93]Floyd，S.，和Jacobson，V.，用于避免拥塞的随机早期检测网关。IEEE/ACM网络交易，第1节第4节，1993年8月，第页。397-413.
[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
[Flo94]Floyd，S.，TCP和显式拥塞通知。《计算机通信评论》，24（5）：1994年10月10日至23日。
[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
[Flo96]Floyd，S.，关于TCP与SACK的问题。技术报告，1996年1月。可从http://www-nrg.ee.lbl.gov/floyd/.
[Flo97] Floyd, S., Increasing TCP's Initial Window. Viewgraphs, 40th IETF Meeting - TCP Implementations WG. December, 1997. URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
[Flo97]Floyd，S.，增加TCP的初始窗口。Viewgraphs，第40届IETF会议-TCP实施工作组。1997年12月。URL“ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".
[KAGT98]汉斯·克鲁斯，马克·奥尔曼，吉姆·格林纳，陈迪普奇。地球静止卫星链路上的HTTP页面传输速率。1998年3月。第六届国际电信系统会议记录。URL“http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps”。
[MD90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MD90]Mogul，J.和S.Deering，“路径MTU发现”，RFC 1191191990年11月。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[Mor97] Robert Morris. Private communication, 1997. Cited for acknowledgement purposes only.
罗伯特·莫里斯。私人通信，1997年。引用仅供确认之用。
[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
凯瑟琳·尼科尔斯。利用反馈改进网络仿真。Com21公司技术报告。可从http://www.com21.com/pages/papers/068.pdf.
[PN98] Poduri, K., and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[PN98]Poduri，K.和K.Nichols，“增加初始TCP窗口大小的模拟研究”，RFC 2415，1998年9月。
[Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[Pos82]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RF97] Ramakrishnan, K., and S. Floyd, "A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress.
[RF97]Ramakrishnan，K.和S.Floyd，“向IPv6和TCP添加显式拥塞通知（ECN）的提案”，正在进行中。
[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月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[S97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[S97]Stevens，W.“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
[SP97] Shepard, T., and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP97]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Road MS 54-2 Cleveland, OH 44135
美国宇航局刘易斯研究中心/斯特林软件公司俄亥俄州克利夫兰布鲁克公园路21000号，邮编：54-2，邮编：44135
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Sally Floyd Lawrence Berkeley National Laboratory One Cyclotron Road Berkeley, CA 94720
加利福尼亚州伯克利回旋加速器路一号萨莉·弗洛伊德·劳伦斯·伯克利国家实验室，邮编94720
EMail: floyd@ee.lbl.gov
EMail: floyd@ee.lbl.gov
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138
Craig Partridge BBN Technologies马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: craig@bbn.com
EMail: craig@bbn.com
In the current environment (without Explicit Congestion Notification [Flo94] [RF97]), all TCPs use segment drops as indications from the network about the limits of available bandwidth. We argue here that the change to a larger initial window should not result in the sender retransmitting a large number of duplicate segments that have already been received at the receiver.
在当前环境中（没有明确的拥塞通知[Flo94][RF97]），所有TCP都使用段丢弃作为来自网络的可用带宽限制指示。我们认为，对较大初始窗口的更改不应导致发送方重新传输大量已在接收方接收到的重复段。
If one segment is dropped from the initial window, there are three different ways for TCP to recover: (1) Slow-starting from a window of one segment, as is done after a retransmit timeout, or after Fast Retransmit in Tahoe TCP; (2) Fast Recovery without selective acknowledgments (SACK), as is done after three duplicate ACKs in Reno TCP; and (3) Fast Recovery with SACK, for TCP where both the sender and the receiver support the SACK option [MMFR96]. In all three cases, if a single segment is dropped from the initial window, no duplicate segments (i.e., segments that have already been received at the receiver) are transmitted. Note that for a TCP sending four 512-byte segments in the initial window, a single segment drop will not require a retransmit timeout, but can be recovered from using the Fast Retransmit algorithm (unless the retransmit timer expires prematurely). In addition, a single segment dropped from an initial window of three segments might be repaired using the fast retransmit algorithm, depending on which segment is dropped and whether or not delayed ACKs are used. For example, dropping the first segment of a three segment initial window will always require waiting for a timeout. However, dropping the third segment will always allow recovery via the fast retransmit algorithm, as long as no ACKs are lost.
如果从初始窗口中删除一个段，TCP有三种不同的恢复方式：（1）从一个段的窗口缓慢启动，就像在重新传输超时后或在Tahoe TCP中快速重新传输后所做的那样；（2） 快速恢复，无需选择性确认（SACK），就像在Reno TCP中重复三次确认后所做的那样；（3）对于TCP，使用SACK进行快速恢复，其中发送方和接收方都支持SACK选项[MMFR96]。在所有三种情况下，如果从初始窗口删除单个段，则不会发送重复段（即，已在接收器处接收到的段）。请注意，对于在初始窗口中发送四个512字节段的TCP，单个段删除不需要重新传输超时，但可以通过使用快速重新传输算法进行恢复（除非重新传输计时器提前过期）。此外，根据丢弃的段以及是否使用延迟ack，可以使用快速重传算法修复从三个段的初始窗口丢弃的单个段。例如，删除三段初始窗口的第一段始终需要等待超时。但是，只要没有ACK丢失，丢弃第三段将始终允许通过快速重传算法进行恢复。
Next we consider scenarios where the initial window contains two to four segments, and at least two of those segments are dropped. If all segments in the initial window are dropped, then clearly no duplicate segments are retransmitted, as the receiver has not yet received any segments. (It is still a possibility that these dropped segments used scarce bandwidth on the way to their drop point; this issue was discussed in Section 5.)
接下来，我们考虑初始窗口包含两个到四个段的场景，并且至少两个片段被丢弃。如果删除了初始窗口中的所有段，那么显然不会重新传输重复的段，因为接收机尚未接收到任何段。（这些被丢弃的网段仍有可能在到达它们的丢弃点的途中使用了稀缺的带宽；第5节讨论了这个问题。）
When two segments are dropped from an initial window of three segments, the sender will only send a duplicate segment if the first two of the three segments were dropped, and the sender does not receive a packet with the SACK option acknowledging the third segment.
当从包含三个段的初始窗口中删除两个段时，如果删除了三个段中的前两个段，则发送方只会发送一个重复段，并且发送方不会收到SACK选项确认第三个段的数据包。
When two segments are dropped from an initial window of four segments, an examination of the six possible scenarios (which we don't go through here) shows that, depending on the position of the
当从一个包含四个片段的初始窗口中删除两个片段时，对六种可能的场景（我们在这里不讨论）的检查表明，这取决于片段的位置
dropped packets, in the absence of SACK the sender might send one duplicate segment. There are no scenarios in which the sender sends two duplicate segments.
丢弃的数据包，在没有SACK的情况下，发送方可能会发送一个重复的数据段。不存在发送方发送两个重复段的情况。
When three segments are dropped from an initial window of four segments, then, in the absence of SACK, it is possible that one duplicate segment will be sent, depending on the position of the dropped segments.
当从包含四个段的初始窗口中删除三个段时，在没有SACK的情况下，可能会发送一个重复段，具体取决于删除段的位置。
The summary is that in the absence of SACK, there are some scenarios with multiple segment drops from the initial window where one duplicate segment will be transmitted. There are no scenarios where more that one duplicate segment will be transmitted. Our conclusion is that the number of duplicate segments transmitted as a result of a larger initial window should be small.
总结是，在没有SACK的情况下，存在一些场景，在初始窗口中有多个段丢弃，其中一个重复段将被传输。不存在传输多个重复段的情况。我们的结论是，由于较大的初始窗口而传输的重复段的数量应该较小。
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。