Internet Engineering Task Force (IETF) J. Chu
Request for Comments: 6928 N. Dukkipati
Category: Experimental Y. Cheng
ISSN: 2070-1721 M. Mathis
Google, Inc.
April 2013
Internet Engineering Task Force (IETF) J. Chu
Request for Comments: 6928 N. Dukkipati
Category: Experimental Y. Cheng
ISSN: 2070-1721 M. Mathis
Google, Inc.
April 2013
Increasing TCP's Initial Window
增加TCP的初始窗口
Abstract
摘要
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.
本文档提出了一个实验，将允许的TCP初始窗口（IW）从RFC 3390中规定的2到4个段增加到10个段，并在检测到性能问题时回退到现有建议。它讨论了增加的动机、较高初始窗口的优点和缺点，并给出了几个大规模实验的结果，表明较高初始窗口在不导致拥塞崩溃的情况下提高了许多web服务的总体性能。本文件最后讨论了IETF TCP维护和小型扩展（TCPM）工作组建议的用于进一步实验目的的使用和部署。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6928.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6928.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. TCP Modification ................................................4
3. Implementation Issues ...........................................5
4. Background ......................................................6
5. Advantages of Larger Initial Windows ............................7
5.1. Reducing Latency ...........................................7
5.2. Keeping Up with the Growth of Web Object Size ..............8
5.3. Recovering Faster from Loss on Under-Utilized or
Wireless Links .............................................8
6. Disadvantages of Larger Initial Windows for the Individual ......9
7. Disadvantages of Larger Initial Windows for the Network ........10
8. Mitigation of Negative Impact ..................................11
9. Interactions with the Retransmission Timer .....................11
10. Experimental Results From Large-Scale Cluster Tests ...........11
10.1. The Benefits .............................................11
10.2. The Cost .................................................12
11. Other Studies .................................................13
12. Usage and Deployment Recommendations ..........................14
13. Related Proposals .............................................15
14. Security Considerations .......................................16
15. Conclusion ....................................................16
16. Acknowledgments ...............................................16
17. References ....................................................16
17.1. Normative References .....................................16
17.2. Informative References ...................................17
Appendix A. List of Concerns and Corresponding Test Results .......21
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. TCP Modification ................................................4
3. Implementation Issues ...........................................5
4. Background ......................................................6
5. Advantages of Larger Initial Windows ............................7
5.1. Reducing Latency ...........................................7
5.2. Keeping Up with the Growth of Web Object Size ..............8
5.3. Recovering Faster from Loss on Under-Utilized or
Wireless Links .............................................8
6. Disadvantages of Larger Initial Windows for the Individual ......9
7. Disadvantages of Larger Initial Windows for the Network ........10
8. Mitigation of Negative Impact ..................................11
9. Interactions with the Retransmission Timer .....................11
10. Experimental Results From Large-Scale Cluster Tests ...........11
10.1. The Benefits .............................................11
10.2. The Cost .................................................12
11. Other Studies .................................................13
12. Usage and Deployment Recommendations ..........................14
13. Related Proposals .............................................15
14. Security Considerations .......................................16
15. Conclusion ....................................................16
16. Acknowledgments ...............................................16
17. References ....................................................16
17.1. Normative References .....................................16
17.2. Informative References ...................................17
Appendix A. List of Concerns and Corresponding Test Results .......21
This document proposes to raise the upper bound on TCP's initial window (IW) to 10 segments (maximum 14600 B). It is patterned after and borrows heavily from RFC 3390 [RFC3390] and earlier work in this area. Due to lingering concerns about possible side effects to other flows sharing the same network bottleneck, some of the recommendations are conditional on additional monitoring and evaluation.
本文件建议将TCP初始窗口（IW）的上限提高到10段（最大14600 B）。它模仿并大量借鉴了RFC 3390[RFC3390]和该领域的早期工作。由于对共享同一网络瓶颈的其他流可能产生的副作用的担忧挥之不去，一些建议取决于额外的监测和评估。
The primary argument in favor of raising IW follows from the evolving scale of the Internet. Ten segments are likely to fit into queue space available at any broadband access link, even when there are a reasonable number of concurrent connections.
支持提高信息战的主要论点来自互联网不断发展的规模。即使存在合理数量的并发连接，在任何宽带接入链路上都有十个段可能适合于可用的队列空间。
Lower speed links can be treated with environment-specific configurations, such that they can be protected from being overwhelmed by large initial window bursts without imposing a suboptimal initial window on the rest of the Internet.
低速链路可以使用特定于环境的配置进行处理，这样就可以保护它们不受大型初始窗口突发的影响，而不会在互联网的其余部分强加一个次优的初始窗口。
This document reviews the advantages and disadvantages of using a larger initial window and includes summaries of several large-scale experiments showing that an initial window of 10 segments (IW10) provides benefits across the board for a variety of bandwidth (BW), round-trip time (RTT), and bandwidth-delay product (BDP) classes. These results show significant benefits for increasing IW for users at much smaller data rates than had been previously anticipated. However, at initial windows larger than 10, the results are mixed. We believe that these mixed results are not intrinsic but are the consequence of various implementation artifacts, including overly aggressive applications employing many simultaneous connections.
本文件回顾了使用较大初始窗口的优缺点，并包括几项大规模实验的总结，这些实验表明，10段初始窗口（IW10）为各种带宽（BW）、往返时间（RTT）和带宽延迟产品（BDP）类别提供了全面的好处。这些结果表明，以比先前预期的小得多的数据速率增加用户的IW具有显著的好处。然而，当初始窗口大于10时，结果是好坏参半的。我们相信，这些混合的结果不是内在的，而是各种实现工件的结果，包括采用许多同时连接的过度激进的应用程序。
We recommend that all TCP implementations have a settable TCP IW parameter, as long as there is a reasonable effort to monitor for possible interactions with other Internet applications and services as described in Section 12. Furthermore, Section 10 details why 10 segments may be an appropriate value, and while that value may continue to rise in the future, this document does not include any supporting evidence for values of IW larger than 10.
我们建议所有TCP实现都有一个可设置的TCP IW参数，只要有合理的努力来监控与第12节所述的其他Internet应用程序和服务的可能交互。此外，第10节详细说明了为什么10段可能是一个合适的值，尽管该值在未来可能继续上升，但本文件不包括IW值大于10的任何支持证据。
In addition, we introduce a minor revision to RFC 3390 and RFC 5681 [RFC5681] to eliminate resetting the initial window when the SYN or SYN/ACK is lost.
此外，我们对RFC 3390和RFC 5681[RFC5681]进行了一次小的修订，以消除在SYN或SYN/ACK丢失时重置初始窗口的问题。
The document closes with a discussion of the consensus from the TCPM working group on the near-term usage and deployment of IW10 in the Internet.
本文件最后讨论了TCPM工作组就近期在互联网上使用和部署IW10达成的共识。
A complementary set of slides for this proposal can be found at [CD10].
本提案的一套补充幻灯片可在[CD10]上找到。
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 proposes an increase in the permitted upper bound for TCP's initial window (IW) to 10 segments, depending on the maximum segment size (MSS). This increase is optional: a TCP MAY start with an initial window that is smaller than 10 segments.
本文件建议将TCP初始窗口（IW）的允许上限增加到10个段，具体取决于最大段大小（MSS）。这种增加是可选的：TCP可以从小于10段的初始窗口开始。
More precisely, the upper bound for the initial window will be
更准确地说，初始窗口的上限为
min (10*MSS, max (2*MSS, 14600)) (1)
最小（10*MSS，最大（2*MSS，14600））（1）
This upper bound for the initial window size represents a change from RFC 3390 [RFC3390], which specified that the congestion window be initialized between 2 and 4 segments, depending on the MSS.
初始窗口大小的上限表示RFC 3390[RFC3390]的变化，RFC 3390[RFC3390]指定根据MSS在2到4段之间初始化拥塞窗口。
This change applies to the initial window of the connection in the first round-trip time (RTT) of data transmission during or following the TCP three-way handshake. Neither the SYN/ACK nor its ACK in the three-way handshake should increase the initial window size.
此更改适用于TCP三方握手期间或之后数据传输的第一个往返时间（RTT）中连接的初始窗口。SYN/ACK及其在三向握手中的ACK都不应增加初始窗口大小。
Note that all the test results described in this document were based on the regular Ethernet MTU of 1500 bytes. Future study of the effect of a different MTU may be needed to fully validate (1) above.
请注意，本文档中描述的所有测试结果均基于1500字节的常规以太网MTU。未来可能需要对不同MTU的影响进行研究，以充分验证上述（1）。
Furthermore, RFC 3390 states (and RFC 5681 [RFC5681] has similar text):
此外，RFC 3390声明（RFC 5681[RFC5681]具有类似文本）：
If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment consisting of MSS bytes.
如果SYN或SYN/ACK丢失，发送方在正确传输SYN后使用的初始窗口必须是一个由MSS字节组成的段。
The proposed change to reduce the default retransmission timeout (RTO) to 1 second [RFC6298] increases the chance for spurious SYN or SYN/ACK retransmission, thus unnecessarily penalizing connections with RTT > 1 second if their initial window is reduced to 1 segment. For this reason, it is RECOMMENDED that implementations refrain from resetting the initial window to 1 segment, unless there have been more than one SYN or SYN/ACK retransmissions or true loss detection has been made.
将默认重传超时（RTO）减少到1秒[RFC6298]的拟议更改增加了伪SYN或SYN/ACK重传的机会，因此，如果RTT>1秒的连接的初始窗口减少到1段，则不必要地惩罚这些连接。因此，建议不要将初始窗口重置为1段，除非有多个SYN或SYN/ACK重传或进行了真正的丢失检测。
TCP implementations use slow start in as many as three different ways: (1) to start a new connection (the initial window); (2) to restart transmission after a long idle period (the restart window); and (3) to restart transmission after a retransmit timeout (the loss window). The change specified 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 of MSS bytes (to permit the lowest possible window size in the case of severe congestion).
TCP实现使用慢启动的方式多达三种：（1）启动新连接（初始窗口）；（2） 长时间闲置后重新启动变速箱（重新启动窗口）；以及（3）在重新传输超时（丢失窗口）后重新启动传输。此文档中指定的更改会影响初始窗口的值。或者，TCP可以将重新启动窗口设置为初始窗口使用的值和cwnd的当前值中的最小值（换句话说，为重新启动窗口使用较大的值不应增加cwnd的大小）。这些更改不会更改丢失窗口，丢失窗口必须保留1段MSS字节（以便在严重拥塞的情况下允许最小的窗口大小）。
Furthermore, to limit any negative effect that a larger initial window may have on links with limited bandwidth or buffer space, implementations SHOULD fall back to RFC 3390 for the restart window (RW) if any packet loss is detected during either the initial window or a restart window, and more than 4 KB of data is sent. Implementations must also follow RFC 6298 [RFC6298] in order to avoid spurious RTO as described in Section 9.
此外，为了限制较大的初始窗口可能对带宽或缓冲区空间有限的链路产生的任何负面影响，如果在初始窗口或重新启动窗口期间检测到任何分组丢失，并且发送了超过4kb的数据，则重新启动窗口（RW）的实现应回到RFC 3390。实现还必须遵循RFC 6298[RFC6298]，以避免第9节所述的虚假RTO。
The HTTP 1.1 specification allows only two simultaneous connections per domain, while web browsers open more simultaneous TCP connections [Ste08], partly to circumvent the small initial window in order to speed up the loading of web pages as described above.
HTTP 1.1规范只允许每个域有两个同时连接，而web浏览器会打开更多的同时TCP连接[Ste08]，部分原因是为了绕过较小的初始窗口，以加速上述网页的加载。
When web browsers open simultaneous TCP connections to the same destination, they are working against TCP's congestion control mechanisms [FF99]. Combining this behavior with larger initial windows further increases the burstiness and unfairness to other traffic in the network. If a larger initial window causes harm to any other flows, then local application tuning will reveal that having fewer concurrent connections yields better performance for some users. Any content provider deploying IW10 in conjunction with content distributed across multiple domains is explicitly encouraged to perform measurement experiments to detect such problems, and to consider reducing the number of concurrent connections used to retrieve their content.
当web浏览器同时打开到同一目的地的TCP连接时，它们是在对抗TCP的拥塞控制机制[FF99]。将这种行为与较大的初始窗口相结合，会进一步增加网络中其他流量的突发性和不公平性。如果较大的初始窗口会对任何其他流造成损害，那么本地应用程序调优将表明，对于某些用户来说，并发连接较少会产生更好的性能。显式地鼓励与跨多个域分布的内容一起部署IW10的内容提供者执行测量实验来检测这些问题，并考虑减少用于检索其内容的并发连接的数量。
Some implementations advertise a small initial receive window (Table 2 in [Duk10]), effectively limiting how much window a remote host may use. In order to realize the full benefit of the large initial window, implementations are encouraged to advertise an initial receive window of at least 10 segments, except for the circumstances where a larger initial window is deemed harmful. (See Section 8 below.)
一些实现宣传了一个小的初始接收窗口（见[Duk10]中的表2），有效地限制了远程主机可以使用的窗口数量。为了实现大初始窗口的全部好处，鼓励实现宣传至少10个段的初始接收窗口，但较大初始窗口被视为有害的情况除外。（见下文第8节。）
The TCP Selective Acknowledgment (SACK) option [RFC2018] was thought to be required in order for the larger initial window to perform well. But measurements from both a testbed and live tests showed that IW=10 without the SACK option outperforms IW=3 with the SACK option [CW10].
TCP选择性确认（SACK）选项[RFC2018]被认为是需要的，以便更大的初始窗口能够正常运行。但是，测试台和现场测试的测量结果表明，不使用SACK选项的IW=10优于使用SACK选项的IW=3[CW10]。
The TCP congestion window was introduced as part of the congestion control algorithm by Van Jacobson in 1988 [Jac88]. The initial value of one segment was used as the starting point for newly established connections to probe the available bandwidth on the network.
TCP拥塞窗口是Van Jacobson在1988年提出的拥塞控制算法的一部分[Jac88]。一段的初始值用作新建立连接的起点，以探测网络上的可用带宽。
Today's Internet is dominated by web traffic running on top of short-lived TCP connections [IOR2009]. The relatively small initial window has become a limiting factor for the performance of many web applications.
今天的互联网主要由运行在短命TCP连接之上的web流量控制[IOR2009]。相对较小的初始窗口已成为许多web应用程序性能的限制因素。
The global Internet has continued to grow, both in speed and penetration. According to the latest report from Akamai [AKAM10], the global broadband (> 2 Mbps) adoption has surpassed 50%, propelling the average connection speed to reach 1.7 Mbps, while the narrowband (< 256 Kbps) usage has dropped to 5%. In contrast, TCP's initial window has remained 4 KB for a decade [RFC2414], corresponding to a bandwidth utilization of less than 200 Kbps per connection, assuming an RTT of 200 ms.
全球互联网的速度和普及率都在持续增长。根据Akamai[AKAM10]的最新报告，全球宽带（>2Mbps）的采用率已超过50%，推动平均连接速度达到1.7Mbps，而窄带（<256Kbps）的使用率已降至5%。相反，TCP的初始窗口在十年中一直保持4KB[RFC2414]，对应于每个连接的带宽利用率低于200Kbps，假设RTT为200ms。
A large proportion of flows on the Internet are short web
transactions over TCP and complete before exiting TCP slow start.
Speeding up the TCP flow startup phase, including circumventing the
initial window limit, has been an area of active research (see
[Sch08] and Section 3.4 of [RFC6077]). Numerous proposals exist
[LAJW07] [RFC4782] [PRAKS02] [PK98]. Some require router support
[RFC4782] [PK98], hence are not practical for the public Internet.
Others suggested bold, but often radical ideas, likely requiring more
years of research before standardization and deployment.
A large proportion of flows on the Internet are short web
transactions over TCP and complete before exiting TCP slow start.
Speeding up the TCP flow startup phase, including circumventing the
initial window limit, has been an area of active research (see
[Sch08] and Section 3.4 of [RFC6077]). Numerous proposals exist
[LAJW07] [RFC4782] [PRAKS02] [PK98]. Some require router support
[RFC4782] [PK98], hence are not practical for the public Internet.
Others suggested bold, but often radical ideas, likely requiring more
years of research before standardization and deployment.
In the mean time, applications have responded to TCP's "slow" start. Web sites use multiple subdomains [Bel10] to circumvent HTTP 1.1 regulation on two connections per physical host [RFC2616]. As of today, major web browsers open multiple connections to the same site (up to six connections per domain [Ste08] and the number is growing). This trend is to remedy HTTP serialized download to achieve parallelism and higher performance. But it also implies that today most access links are severely under-utilized, hence having multiple TCP connections improves performance most of the time. While raising the initial congestion window may cause congestion for certain users of these browsers, we argue that the browsers and other application
与此同时，应用程序对TCP的“缓慢”启动做出了响应。网站使用多个子域[Bel10]来规避HTTP 1.1对每个物理主机两个连接的规定[RFC2616]。到目前为止，主要的web浏览器都会打开到同一站点的多个连接（每个域最多有六个连接[Ste08]，而且这个数字还在增长）。这种趋势是补救HTTP序列化下载以实现并行性和更高的性能。但这也意味着，目前大多数访问链路的利用率严重不足，因此拥有多个TCP连接在大多数情况下都可以提高性能。虽然提高初始拥塞窗口可能会导致这些浏览器的某些用户出现拥塞，但我们认为浏览器和其他应用程序
need to respect HTTP 1.1 regulation and stop increasing the number of simultaneous TCP connections. We believe a modest increase of the initial window will help to stop this trend and provide the best interim solution to improve overall user performance and reduce the server, client, and network load.
需要遵守HTTP 1.1法规，停止增加同时TCP连接的数量。我们相信，适度增加初始窗口将有助于阻止这种趋势，并提供最佳的临时解决方案，以提高总体用户性能，减少服务器、客户端和网络负载。
Note that persistent connections and pipelining are designed to address some of the above issues with HTTP [RFC2616]. Their presence does not diminish the need for a larger initial window, e.g., data from the Chrome browser shows that 35% of HTTP requests are made on new TCP connections. Our test data also shows significant latency reduction with the large initial window even in conjunction with these two HTTP features [Duk10].
请注意，持久连接和管道设计用于解决HTTP[RFC2616]的上述一些问题。它们的存在并不会减少对更大初始窗口的需求，例如，来自Chrome浏览器的数据显示，35%的HTTP请求是在新的TCP连接上发出的。我们的测试数据还显示，即使结合这两个HTTP特性，大初始窗口也能显著减少延迟[Duk10]。
Also note that packet pacing has been suggested as a possible mechanism to avoid large bursts and their associated harm [VH97]. Pacing is not required in this proposal due to a strong preference for a simple solution. We suspect for packet bursts of a moderate size, packet pacing will not be necessary. This seems to be confirmed by our test results.
还要注意的是，数据包起搏被认为是一种可能的机制，以避免大爆发及其相关伤害[VH97]。由于对简单解决方案的强烈偏好，本提案中不需要调整。我们怀疑对于中等大小的数据包突发，不需要数据包起搏。我们的测试结果似乎证实了这一点。
More discussion of the increase in initial window, including the choice of 10 segments, can be found in [Duk10] and [CD10].
关于初始窗口增加的更多讨论，包括10个段的选择，请参见[Duk10]和[CD10]。
An increase of the initial window from 3 segments to 10 segments reduces the total transfer time for data sets greater than 4 KB by up to 4 round trips.
将初始窗口从3个段增加到10个段，可将大于4KB的数据集的总传输时间最多减少4次往返。
The table below compares the number of round trips between IW=3 and IW=10 for different transfer sizes, assuming infinite bandwidth, no packet loss, and the standard delayed ACKs with large delayed-ACK timer.
下表比较了不同传输大小的IW=3和IW=10之间的往返次数，假设带宽无限，无数据包丢失，以及标准延迟ACK具有大延迟ACK定时器。
---------------------------------------
| total segments | IW=3 | IW=10 |
---------------------------------------
| 3 | 1 | 1 |
| 6 | 2 | 1 |
| 10 | 3 | 1 |
| 12 | 3 | 2 |
| 21 | 4 | 2 |
| 25 | 5 | 2 |
| 33 | 5 | 3 |
| 46 | 6 | 3 |
| 51 | 6 | 4 |
| 78 | 7 | 4 |
| 79 | 8 | 4 |
| 120 | 8 | 5 |
| 127 | 9 | 5 |
---------------------------------------
---------------------------------------
| total segments | IW=3 | IW=10 |
---------------------------------------
| 3 | 1 | 1 |
| 6 | 2 | 1 |
| 10 | 3 | 1 |
| 12 | 3 | 2 |
| 21 | 4 | 2 |
| 25 | 5 | 2 |
| 33 | 5 | 3 |
| 46 | 6 | 3 |
| 51 | 6 | 4 |
| 78 | 7 | 4 |
| 79 | 8 | 4 |
| 120 | 8 | 5 |
| 127 | 9 | 5 |
---------------------------------------
For example, with the larger initial window, a transfer of 32 segments of data will require only 2 rather than 5 round trips to complete.
例如，对于较大的初始窗口，32段数据的传输只需要2次往返即可完成，而不是5次往返。
RFC 3390 stated that the main motivation for increasing the initial window to 4 KB was to speed up connections that only transmit a small amount of data, e.g., email and web. The majority of transfers back then were less than 4 KB and could be completed in a single RTT [All00].
RFC 3390指出，将初始窗口增加到4KB的主要动机是加速仅传输少量数据的连接，例如电子邮件和web。当时大多数传输小于4KB，可以在单个RTT中完成[All00]。
Since RFC 3390 was published, web objects have gotten significantly larger [Chu09] [RJ10]. Today only a small percentage of web objects (e.g., 10% of Google's search responses) can fit in the 4 KB initial window. The average HTTP response size of gmail.com, a highly scripted web site, is 8 KB (Figure 1 in [Duk10]). The average web page, including all static and dynamic scripted web objects on the page, has seen even greater growth in size [RJ10]. HTTP pipelining [RFC2616] and new web transport protocols such as SPDY [SPDY] allow multiple web objects to be sent in a single transaction, potentially benefiting from an even larger initial window in order to transfer an entire web page in a small number of round trips.
自从RFC3390发布以来，web对象已经显著增大[Chu09][RJ10]。如今，只有一小部分web对象（例如，10%的Google搜索响应）可以放入4KB的初始窗口。gmail.com是一个高度脚本化的网站，其HTTP响应的平均大小为8KB（参见[Duk10]中的图1]）。普通网页，包括页面上所有静态和动态脚本化的web对象，其大小甚至有了更大的增长[RJ10]。HTTP管道[RFC2616]和新的web传输协议（如SPDY[SPDY]）允许在单个事务中发送多个web对象，这可能得益于更大的初始窗口，以便在少量的往返过程中传输整个web页面。
A greater-than-3-segment initial window increases the chance to recover packet loss through Fast Retransmit rather than the lengthy initial RTO [RFC5681]. This is because the fast retransmit algorithm requires three duplicate ACKs as an indication that a segment has
大于3段的初始窗口增加了通过快速重传而不是冗长的初始RTO恢复数据包丢失的机会[RFC5681]。这是因为快速重传算法需要三个重复的ack来表示一个段已被删除
been lost rather than reordered. While newer loss recovery techniques such as Limited Transmit [RFC3042] and Early Retransmit [RFC5827] have been proposed to help speeding up loss recovery from a smaller window, both algorithms can still benefit from the larger initial window because of a better chance to receive more ACKs.
已经丢失而不是重新排序。虽然已经提出了较新的丢失恢复技术，如有限传输[RFC3042]和早期重传[RFC5827]，以帮助从较小的窗口加速丢失恢复，但这两种算法仍然可以受益于较大的初始窗口，因为接收更多ack的机会更大。
6. Disadvantages of Larger Initial Windows for the Individual Connection
6. 单个连接的初始窗口较大的缺点
The larger bursts from an increase in the initial window may cause buffer overrun and packet drop in routers with small buffers, or routers experiencing congestion. This could result in unnecessary retransmit timeouts. 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.
由于初始窗口的增加而产生的较大的突发可能会导致缓冲区溢出和数据包丢失（在具有小缓冲区的路由器中），或者遇到拥塞的路由器中。这可能会导致不必要的重新传输超时。对于能够在无需重新传输超时的情况下恢复的大窗口连接，这可能会导致不必要的提前过渡，从窗口增加算法的慢速启动过渡到拥塞避免阶段。
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] [RFC3150]).
在具有足够缓冲的未拥塞网络中，或在拥塞路由器使用主动队列管理（例如随机早期检测[FJ93][RFC2309][RFC3150]）的中度拥塞网络中，不太可能发生过早的段丢弃。
Insufficient buffering is more likely to exist in the access routers connecting slower links. A recent study of access router buffer size [DGHS07] reveals the majority of access routers provision enough buffer for 130 ms or longer, sufficient to cover a burst of more than 10 packets at 1 Mbps speed, but possibly not sufficient for browsers opening simultaneous connections.
连接较慢链路的接入路由器更可能存在缓冲不足。最近一项关于访问路由器缓冲区大小的研究[DGHS07]表明，大多数访问路由器提供了130毫秒或更长时间的缓冲区，足以以1 Mbps的速度覆盖10个以上的数据包，但可能不足以让浏览器同时打开连接。
A testbed study [CW10] on the effect of the larger initial window with five simultaneously opened connections revealed that, even with limited buffer size on slow links, IW=10 still reduced the total latency of web transactions, although at the cost of higher packet drop rates as compared to IW=3.
一项关于五个同时打开的连接的较大初始窗口影响的试验台研究[CW10]表明，即使在慢速链路上缓冲区大小有限的情况下，IW=10仍然降低了web事务的总延迟，尽管与IW=3相比，其代价是丢包率更高。
Some TCP connections will receive better performance with the larger 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连接最终被网络拥塞或接收器的播发窗口限制在一个小的拥塞窗口内，则这将是正确的。
An increase in the initial window may increase congestion in a network. However, since the increase is one time only (at the beginning of a connection), and the rest of TCP's congestion backoff mechanism remains in place, it's unlikely the increase by itself will render a network in a persistent state of congestion, or even congestion collapse. This seems to have been confirmed by the large-scale web experiments described later.
初始窗口的增加可能会增加网络中的拥塞。但是，由于增加的次数只有一次（在连接开始时），而TCP的其余拥塞回退机制仍然存在，因此增加的次数本身不太可能使网络处于持续的拥塞状态，甚至拥塞崩溃。这似乎已经被后面描述的大规模网络实验所证实。
It should be noted that the above may not hold if applications open a large number of simultaneous connections.
应该注意的是，如果应用程序同时打开大量连接，则上述情况可能不成立。
Until this proposal is widely deployed, a fairness issue may exist between flows adopting a larger initial window vs. flows that are compliant with RFC 3390. Although no severe unfairness has been detected on all the known tests so far, further study on this topic may be warranted.
在广泛部署此方案之前，采用较大初始窗口的流与符合RFC 3390的流之间可能存在公平性问题。虽然迄今为止，所有已知的测试都没有发现严重的不公平现象，但有必要对这一主题进行进一步的研究。
Some of the discussions from RFC 3390 are still valid for IW=10.
RFC 3390的一些讨论对于IW=10仍然有效。
Moreover, it is worth noting that although TCP NewReno increases the chance of duplicate segments when trying to recover multiple packet losses from a large window, the wide support of the TCP Selective Acknowledgment (SACK) option [RFC2018] in all major OSes today should keep the volume of duplicate segments in check.
此外，值得注意的是，尽管TCP NewReno在试图从一个大窗口恢复多个数据包丢失时增加了重复数据段的机会，但目前所有主要操作系统中对TCP选择性确认（SACK）选项[RFC2018]的广泛支持应能控制重复数据段的数量。
Recent measurements [Get11] provide evidence of extremely large queues (in the order of one second or more) at access networks of the Internet. While a significant part of the buffer bloat is contributed by large downloads/uploads such as video files, emails with large attachments, backups and download of movies to disk, some of the problem is also caused by web browsing of image-heavy sites [Get11]. This queuing delay is generally considered harmful for responsiveness of latency-sensitive traffic such as DNS queries, Address Resolution Protocol (ARP), DHCP, Voice over IP (VoIP), and gaming. IW=10 can exacerbate this problem when doing short downloads, such as web browsing [Get11-1]. The mitigations proposed for the broader problem of buffer bloating are also applicable in this case, such as the use of Explicit Congestion Notification (ECN), Active Queue Management (AQM) schemes [CoDel], and traffic classification (QoS).
最近的测量[Get11]提供了在互联网接入网络上出现超大队列（以1秒或更长的顺序）的证据。虽然大量下载/上传（如视频文件、带有大型附件的电子邮件、备份以及将电影下载到磁盘）导致了缓冲区膨胀，但一些问题也是由大量浏览图像的网站引起的[Get11]。这种排队延迟通常被认为对对延迟敏感的流量（如DNS查询、地址解析协议（ARP）、DHCP、IP语音（VoIP）和游戏）的响应有害。IW=10在进行短时间下载时会加剧此问题，例如web浏览[Get11-1]。针对更广泛的缓冲区膨胀问题提出的缓解措施也适用于这种情况，例如使用显式拥塞通知（ECN）、主动队列管理（AQM）方案[CoDel]和流量分类（QoS）。
Much of the negative impact from an increase in the initial window is likely to be felt by users behind slow links with limited buffers. The negative impact can be mitigated by hosts directly connected to a low-speed link advertising an initial receive window smaller than 10 segments. This can be achieved either through manual configuration by the users or through the host stack auto-detecting the low-bandwidth links.
初始窗口增加的许多负面影响可能会被缓冲区有限的慢速链接后面的用户感受到。负面影响可以通过直接连接到低速链路的主机来减轻，该链路宣传小于10段的初始接收窗口。这可以通过用户手动配置或通过主机堆栈自动检测低带宽链路来实现。
Additional suggestions to improve the end-to-end performance of slow links can be found in RFC 3150 [RFC3150].
RFC 3150[RFC3150]中提供了改进慢链路端到端性能的其他建议。
A large initial window increases the chance of spurious RTO on a low-bandwidth path, because the packet transmission time will dominate the round-trip time. To minimize spurious retransmissions, implementations MUST follow RFC 6298 [RFC6298] to restart the retransmission timer with the current value of RTO for each ACK received that acknowledges new data.
较大的初始窗口会增加低带宽路径上出现虚假RTO的机会，因为数据包传输时间将主导往返时间。为了最大限度地减少伪重传，实现必须遵循RFC 6298[RFC6298]的规定，以确认新数据的每个接收到的ACK的当前RTO值重新启动重传计时器。
For a more detailed discussion, see RFC 3390, Section 6.
有关更详细的讨论，请参阅RFC 3390，第6节。
In this section, we summarize our findings from large-scale Internet experiments with an initial window of 10 segments conducted via Google's front-end infrastructure serving a diverse set of applications. We present results from two data centers, each chosen because of the specific characteristics of subnets served: AvgDC has connection bandwidths closer to the worldwide average reported in [AKAM10], with a median connection speed of about 1.7 Mbps; SlowDC has a larger proportion of traffic from slow-bandwidth subnets with nearly 20% of traffic from connections below 100 Kbps; and a third was below 256 Kbps.
在本节中，我们总结了大规模互联网实验的结果，最初的实验窗口为10个部分，通过谷歌的前端基础设施为不同的应用程序提供服务。我们展示了两个数据中心的结果，每个数据中心的选择都是因为所服务子网的特定特征：AvgDC的连接带宽接近[AKAM10]中报告的全球平均带宽，中值连接速度约为1.7 Mbps；SlowDC拥有更大比例的来自低带宽子网的流量，其中近20%的流量来自低于100Kbps的连接；三分之一的速率低于256kbps。
Guided by measurements data, we answer two key questions: what is the latency benefit when TCP connections start with a higher initial window, and on the flip side, what is the cost?
在测量数据的指导下，我们回答了两个关键问题：当TCP连接从较高的初始窗口开始时，延迟的好处是什么？另一方面，成本是什么？
The average web search latency improvement over all responses in AvgDC is 11.7% (68 ms) and 8.7% (72 ms) in SlowDC. We further analyzed the data based on traffic characteristics and subnet properties such as bandwidth (BW), round-trip time (RTT), and bandwidth-delay product (BDP). The average response latency improved
在AvgDC中，所有响应的平均web搜索延迟改善率分别为11.7%（68毫秒）和8.7%（72毫秒）。我们进一步分析了基于流量特性和子网特性的数据，如带宽（BW）、往返时间（RTT）和带宽延迟积（BDP）。平均响应延迟得到改善
across the board for a variety of subnets with the largest benefits of over 20% from high RTT and high BDP networks, wherein most responses can fit within the pipe. Correspondingly, responses from low RTT paths experienced the smallest improvements -- about 5%.
适用于各种子网，从高RTT和高BDP网络中获得超过20%的最大收益，其中大多数响应可以在管道中进行。相应地，来自低RTT路径的响应经历了最小的改善——大约5%。
Contrary to what we expected, responses from low-bandwidth subnets experienced the best latency improvements (between 10-20%) in the 0-56 Kbps and 56-256 Kbps buckets. We speculate low-BW networks observe improved latency for two plausible reasons: 1) fewer slow-start rounds: unlike many large-BW networks, low-BW subnets with dial-up modems have inherently large RTTs; and 2) faster loss recovery: an initial window larger than 3 segments increases the chances of a lost packet to be recovered through Fast Retransmit as opposed to a lengthy RTO.
与我们预期的相反，来自低带宽子网的响应在0-56 Kbps和56-256 Kbps存储桶中经历了最佳延迟改善（10-20%）。我们推测，低BW网络的延迟有所改善，原因有两个：1）慢启动次数减少：与许多大型BW网络不同，带有拨号调制解调器的低BW子网具有固有的大型RTT；2）更快的丢失恢复：大于3段的初始窗口增加了通过快速重传恢复丢失数据包的机会，而不是冗长的RTO。
Responses of different sizes benefited to varying degrees; those larger than 3 segments naturally demonstrated larger improvements, because they finished in fewer rounds in slow start as compared to the baseline. In our experiments, response sizes less than or equal to 3 segments also demonstrated small latency benefits.
不同规模的反应不同程度地受益；那些大于3节的自然表现出更大的改善，因为与基线相比，他们在慢启动中完成的回合更少。在我们的实验中，小于或等于3段的响应大小也显示出较小的延迟优势。
To find out how individual subnets performed, we analyzed average latency at a /24 subnet level (an approximation to a user base that is offered similar set of services by a common ISP). We find that, even at the subnet granularity, latency improved at all quantiles ranging from 5-11%.
为了了解单个子网的性能，我们分析了a/24子网级别的平均延迟（近似于普通ISP提供类似服务的用户群）。我们发现，即使在子网粒度上，延迟在5-11%范围内的所有分位数上都有所改善。
To quantify the cost of raising the initial window, we analyzed the data specifically for subnets with low bandwidth and BDP, retransmission rates for different kinds of applications, as well as latency for applications operating with multiple concurrent TCP connections. From our measurements, we found no evidence of negative latency impacts that correlate to BW or BDP alone, but in fact both kinds of subnets demonstrated latency improvements across averages and quantiles.
为了量化提高初始窗口的成本，我们专门分析了低带宽和BDP子网的数据、不同类型应用程序的重传率以及使用多个并发TCP连接运行的应用程序的延迟。从我们的测量中，我们没有发现与BW或BDP单独相关的负面延迟影响的证据，但事实上，这两种子网在平均值和分位数上都表现出延迟改善。
As expected, the retransmission rate increased modestly when operating with larger initial congestion window. The overall increase in AvgDC is 0.3% (from 1.98% to 2.29%) and in SlowDC is 0.7% (from 3.54% to 4.21%). In our investigation, with the exception of one application, the larger window resulted in a retransmission increase of less than 0.5% for services in the AvgDC. The exception is the Maps application that operates with multiple concurrent TCP connections, which increased its retransmission rate by 0.9% in AvgDC and 1.85% in SlowDC (from 3.94% to 5.79%).
正如预期的那样，在初始拥塞窗口较大的情况下，重传率略有增加。AvgDC的总体增长率为0.3%（从1.98%增加到2.29%），而慢增长率为0.7%（从3.54%增加到4.21%）。在我们的调查中，除了一个应用程序外，较大的窗口导致AvgDC中服务的重传增加不到0.5%。例外情况是使用多个并发TCP连接运行的Maps应用程序，它在AvgDC中的重传率增加了0.9%，在SlowDC中增加了1.85%（从3.94%增加到5.79%）。
In our experiments, the percentage of traffic experiencing retransmissions did not increase significantly, e.g., 90% of web search and maps experienced zero retransmission in SlowDC (percentages are higher for AvgDC); a break up of retransmissions by percentiles indicate that most increases come from the portion of traffic already experiencing retransmissions in the baseline with initial window of 3 segments.
在我们的实验中，经历重新传输的流量的百分比没有显著增加，例如，90%的web搜索和地图在低速时经历了零重新传输（AvgDC的百分比更高）；按百分位数划分的重传表明，大部分增加来自于基线中已经经历重传的流量部分，初始窗口为3段。
One of the worst-case scenarios where latency can be adversely impacted due to bottleneck buffer overflow is represented by traffic patterns from applications using multiple concurrent TCP connections, all operating with a large initial window. Our investigation shows that such a traffic pattern has not been a problem in AvgDC where all these applications, specifically maps and image thumbnails, demonstrated improved latencies varying from 2-20%. In the case of SlowDC, while these applications continued showing a latency improvement in the mean, their latencies in higher quantiles (96 and above for maps) indicated instances where latency with larger window is worse than the baseline, e.g., the 99% latency for maps has increased by 2.3% (80 ms) when compared to the baseline. There is no evidence from our measurements that such a cost on latency is a result of subnet bandwidth alone. Although we have no way of knowing from our data, we conjecture that the amount of buffering at bottleneck links plays a key role in the performance of these applications.
由于瓶颈缓冲区溢出，延迟可能受到不利影响的最坏情况之一是使用多个并发TCP连接的应用程序的流量模式，所有这些连接都在一个较大的初始窗口中运行。我们的调查表明，在AvgDC中，这样的流量模式不是问题，所有这些应用程序，特别是地图和图像缩略图，都显示了2-20%不等的延迟改善。在慢波DC的情况下，虽然这些应用程序继续显示平均延迟改善，但其较高分位数的延迟（对于MAP为96及以上）表明，窗口较大的延迟比基线更差，例如，与基线相比，MAP的99%延迟增加了2.3%（80 ms）。从我们的测量中没有证据表明这种延迟成本仅仅是子网带宽的结果。虽然我们无法从数据中得知，但我们推测瓶颈链路的缓冲量对这些应用程序的性能起着关键作用。
Further details on our experiments and analysis can be found in [Duk10] and [DCCM10].
有关我们的实验和分析的更多详细信息，请参见[Duk10]和[DCCM10]。
Besides the large-scale Internet experiments described above, a number of other studies have been conducted on the effects of IW10 in various environments. These tests were summarized below, with more discussion in Appendix A.
除了上述大规模互联网实验外，还对IW10在各种环境中的作用进行了许多其他研究。这些测试总结如下，更多讨论见附录A。
A complete list of tests conducted, with their results and related studies, can be found at the [IW10] link.
在[IW10]链接上可以找到所进行测试的完整列表及其结果和相关研究。
1. [Sch08] described an earlier evaluation of various Fast Startup approaches, including the "Initial-Start" of 10 MSS.
1. [Sch08]描述了早期对各种快速启动方法的评估，包括10 MSS的“初始启动”。
2. [DCCM10] presented the result from Google's large-scale IW10 experiments, with a focus on areas with highly multiplexed links or limited broadband deployment such as Africa and South America.
2. [DCCM10]展示了谷歌大规模IW10实验的结果，重点关注高度多路复用链路或有限宽带部署的地区，如非洲和南美。
3. [CW10] contained a testbed study on IW10 performance over slow links. It also studied how short flows with a larger initial window might affect the throughput performance of other coexisting, long-lived, bulk data transfers.
3. [CW10]包含一项关于IW10在慢速链路上性能的试验台研究。它还研究了具有较大初始窗口的短流如何影响其他共存、长寿命的批量数据传输的吞吐量性能。
4. [Sch11] compared IW10 against a number of other fast startup schemes, and concluded that IW10 works rather well and is also quite fair.
4. [Sch11]将IW10与许多其他快速启动方案进行了比较，得出结论：IW10运行良好，也相当公平。
5. [JNDK10] and later [JNDK10-1] studied the effect of IW10 over cellular networks.
5. [JNDK10]和后来的[JNDK10-1]研究了IW10对蜂窝网络的影响。
6. [AERG11] studied the effect of larger sizes of initial congestion windows, among other things, on end users' page load time from Yahoo!'s Content Delivery Network.
6. [AERG11]研究了初始拥塞窗口的较大尺寸对最终用户从Yahoo！加载页面时间的影响中国的内容交付网络。
Further experiments are required before a larger initial window shall be enabled by default in the Internet. The existing measurement results indicate that this does not cause significant harm to other traffic. However, widespread use in the Internet could reveal issues not known yet, e.g., regarding fairness or impact on latency-sensitive traffic such as VoIP.
在互联网上默认启用更大的初始窗口之前，需要进行进一步的实验。现有的测量结果表明，这不会对其他交通造成重大损害。然而，互联网的广泛使用可能会暴露出一些尚不清楚的问题，例如，关于公平性或对延迟敏感流量（如VoIP）的影响。
Therefore, special care is needed when using this experimental TCP extension, in particular on large-scale systems originating a significant amount of Internet traffic or on large numbers of individual consumer-level systems that have similar aggregate impact. Anyone (stack vendors, network administrators, etc.) turning on a larger initial window SHOULD ensure that the performance is monitored before and after that change. Key metrics to monitor are the rate of packet losses, ECN marking, and segment retransmissions during the initial burst. The sender SHOULD cache such information about connection setups using an initial window larger than allowed by RFC 3390, and new connections SHOULD fall back to the initial window allowed by RFC 3390 if there is evidence of performance issues. Further experiments are needed on the design of such a cache and corresponding heuristics.
因此，在使用这种实验性TCP扩展时需要特别小心，特别是在产生大量互联网流量的大型系统上，或在具有类似总体影响的大量单个消费者级系统上。任何打开较大初始窗口的人（堆栈供应商、网络管理员等）都应确保在更改前后监控性能。要监控的关键指标是数据包丢失率、ECN标记和初始突发期间的段重传。发送方应使用大于RFC 3390允许的初始窗口来缓存有关连接设置的此类信息，如果存在性能问题的证据，则新连接应返回到RFC 3390允许的初始窗口。这种缓存的设计和相应的启发式算法还需要进一步的实验。
Other relevant metrics that may indicate a need to reduce the IW include an increased overall percentage of packet loss or segment retransmissions as well as application-level metrics such as reduced data transfer completion times or impaired media quality.
可能指示需要减少IW的其他相关度量包括分组丢失或段重传的总百分比的增加以及诸如数据传输完成时间减少或媒体质量受损等应用级度量。
It is important also to take into account hosts that do not implement a larger initial window. Furthermore, any deployment of IW10 should be aware that there are potential side effects to real-time traffic
还必须考虑到没有实现更大初始窗口的主机。此外，IW10的任何部署都应该意识到对实时流量有潜在的副作用
(such as VoIP). If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window MUST NOT be turned on by default on systems without such monitoring capabilities.
（如VoIP）。如果用户观察到任何明显的性能恶化，出于安全原因，他们应该退回到RFC 3390允许的初始窗口。在没有此类监控功能的系统上，默认情况下不得打开增加的初始窗口。
The IETF TCPM working group is very much interested in further reports from experiments with this specification and encourages the publication of such measurement data. By now, there are no adequate studies available that either prove or do not prove the impact of IW10 to real-time traffic. Further experimentation in this direction is encouraged.
IETF TCPM工作组对本规范实验的进一步报告非常感兴趣，并鼓励公布此类测量数据。到目前为止，还没有足够的研究证明或不证明IW10对实时流量的影响。鼓励在这方面进行进一步试验。
If no significant harm is reported, a follow-up document may revisit the question on whether a larger initial window can be safely used by default in all Internet hosts. Resolution of these experiments and tighter specifications of the suggestions here might be grounds for a future Standards Track document on the same topic.
如果未报告重大损害，后续文件可能会重新讨论是否可以在默认情况下在所有Internet主机中安全使用较大的初始窗口的问题。这些实验的解决方案和更严格的建议规范可能是未来关于同一主题的标准跟踪文件的基础。
It is recognized that if IW10 is causing harm to other traffic, that this may not be readily apparent to the software on the hosts using IW10. In some cases, a local system or network administrator may be able to detect this and to selectively disable IW10. In the general case, however, since the harm may occur on a remote network to other cross-traffic, there may be no good way at all for this to be detected or corrected. Current experience and analysis does not indicate whether this is a real issue, beyond a hypothetical one. As use of IW10 becomes more prevalent, monitoring and analysis of flows throughout the network will be needed to assess the impact across the spectrum of scenarios found on the real Internet.
可以认识到，如果IW10正在对其他流量造成损害，则这对于使用IW10的主机上的软件来说可能并不明显。在某些情况下，本地系统或网络管理员可能能够检测到这一点，并有选择地禁用IW10。但是，在一般情况下，由于损害可能发生在远程网络上，因此可能根本没有检测或纠正这种情况的好方法。目前的经验和分析没有表明这是否是一个真实的问题，而不是一个假设的问题。随着IW10的使用越来越普遍，需要对整个网络的流量进行监测和分析，以评估在真实互联网上发现的各种场景的影响。
Two other proposals [All10] [Tou12] have been published to raise TCP's initial window size over a large timescale. Both aim at reducing the uncertain impact of a larger initial window at an Internet-wide scale. Moreover, [Tou12] seeks an algorithm to automate the adjustment of IW safely over a long period.
另外两项建议[All10][Tou12]已经发布，以在较大的时间范围内提高TCP的初始窗口大小。两者都旨在减少互联网范围内较大初始窗口的不确定影响。此外，[Tou12]寻求一种算法，在较长时间内自动安全地调整IW。
Although a modest, static increase of IW to 10 may address the near-term need for better web performance, much work is needed from the TCP research community to find a long-term solution to the TCP flow startup problem.
虽然将IW适度、静态地增加到10可能会满足提高web性能的短期需求，但TCP研究社区仍需开展大量工作，以找到TCP流启动问题的长期解决方案。
This document discusses the initial congestion window permitted for TCP connections. Although changing this value may cause more packet loss, it is highly unlikely to lead to a persistent state of network congestion or even a congestion collapse. Hence, it does not raise any known new security issues with TCP.
本文档讨论TCP连接允许的初始拥塞窗口。虽然更改此值可能会导致更多的数据包丢失，但不太可能导致网络拥塞的持续状态，甚至拥塞崩溃。因此，它不会对TCP提出任何已知的新安全问题。
This document suggests a simple change to TCP that will reduce the application latency over short-lived TCP connections or links with long RTTs (saving several RTTs during the initial slow-start phase) with little or no negative impact over other flows. Extensive tests have been conducted through both testbeds and large data centers with most results showing improved latency with only a small increase in the packet retransmission rate. Based on these results, we believe a modest increase of IW to 10 is the best solution for the near-term deployment, while scaling IW over the long run remains a challenge for the TCP research community.
本文档建议对TCP进行简单的更改，以减少短寿命TCP连接或长RTT链路上的应用程序延迟（在初始慢启动阶段节省几个RTT），而对其他流的负面影响很小或没有负面影响。通过试验台和大型数据中心进行了广泛的测试，大多数结果显示延迟有所改善，而数据包重传率仅略有增加。基于这些结果，我们认为将IW适度增加到10是近期部署的最佳解决方案，而从长远来看扩展IW仍然是TCP研究界面临的挑战。
Many people at Google have helped to make the set of large-scale tests possible. We would especially like to acknowledge Amit Agarwal, Tom Herbert, Arvind Jain, and Tiziana Refice for their major contributions.
谷歌的许多人帮助实现了大规模测试。我们要特别感谢阿米特·阿加瓦尔、汤姆·赫伯特、阿文德·贾因和蒂齐亚娜·雷菲斯的重要贡献。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment 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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and P. Hurtig, "Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)", RFC 5827, May 2010.
[RFC5827]Allman，M.，Avrachenkov，K.，Ayesta，U.，Blanton，J.，和P.Hurtig，“TCP和流控制传输协议（SCTP）的早期重传”，RFC 5827，2010年5月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[AKAM10] Akamai Technologies, Inc., "The State of the Internet, 3rd Quarter 2009", January 2010, <http://www.akamai.com/html/ about/press/releases/2010/press_011310_1.html>.
[AKAM10]Akamai Technologies，Inc.“互联网状况，2009年第三季度”，2010年1月<http://www.akamai.com/html/ 关于/press/releases/2010/press\u 011310\u 1.html>。
[AERG11] Al-Fares, M., Elmeleegy, K., Reed, B., and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads", Internet Measurement Conference, November 2011.
[AERG11]Al Fares，M.，Elmelegy，K.，Reed，B.，和I.Gashinsky，“超频雅虎CDN以加快网页加载”，互联网测量会议，2011年11月。
[All00] Allman, M., "A Web Server's View of the Transport Layer", ACM Computer Communication Review, 30(5), October 2000.
[All00]Allman，M.，“网络服务器的传输层视图”，ACM计算机通信评论，30（5），2000年10月。
[All10] Allman, M., "Initial Congestion Window Specification", Work in Progress, November 2010.
[All10]Allman，M.，“初始拥塞窗口规范”，正在进行的工作，2010年11月。
[Bel10] Belshe, M., "A Client-Side Argument For Changing TCP Slow Start", January 2010, <http://sites.google.com/a/chromium.org/dev/spdy/ An_Argument_For_Changing_TCP_Slow_Start.pdf>.
[Bel10]Belshe，M.，“改变TCP慢启动的客户端论证”，2010年1月<http://sites.google.com/a/chromium.org/dev/spdy/ 用于更改TCP慢启动的参数。
[CD10] Chu, J. and N. Dukkipati, "Increasing TCP's Initial Window", presented to the IRTF ICCRG and IETF TCPM working group meetings, IETF 77, March 2010, <http://www.ietf.org/ proceedings/77/slides/tcpm-4.pdf>.
[CD10]Chu，J.和N.Dukkipati，“增加TCP的初始窗口”，提交给IRTF ICCRG和IETF TCPM工作组会议，IETF 77，2010年3月<http://www.ietf.org/ 会议记录/77/slides/tcpm-4.pdf>。
[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century", presented to TCPM working group meeting, IETF 75, July 2009. <http://www.ietf.org/proceedings/75/slides/tcpm-1>.
[Chu09]Chu，J.，“为21世纪调整TCP参数”，提交给TCPM工作组会议，IETF 75，2009年7月<http://www.ietf.org/proceedings/75/slides/tcpm-1>.
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM QUEUE, May 6, 2012.
[CoDel]Nichols，K.和V.Jacobson，“控制队列延迟”，ACM队列，2012年5月6日。
[CW10] Chu, J. and Wang, Y., "A Testbed Study on IW10 vs IW3", presented to the TCPM working group meeting, IETF 79, November 2010, <http://www.ietf.org/proceedings/79/slides/tcpm-0>.
[CW10]Chu，J.和Wang，Y.，“IW10与IW3的试验台研究”，提交给TCPM工作组会议，IETF 79，2010年11月<http://www.ietf.org/proceedings/79/slides/tcpm-0>.
[DCCM10] Dukkipati, D., Cheng, Y., Chu, J., and M. Mathis, "Increasing TCP initial window", presented to the IRTF ICCRG meeting, IETF 78, July 2010, <http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf>.
[DCCM10]Dukkipati，D.，Cheng，Y.，Chu，J.，和M.Mathis，“增加TCP初始窗口”，提交给IRTF ICCRG会议，IETF 78，2010年7月<http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf>.
[DGHS07] Dischinger, M., Gummadi, K., Haeberlen, A., and S. Saroiu, "Characterizing Residential Broadband Networks", Internet Measurement Conference, October 24-26, 2007.
[DGHS07]Dischinger，M.，Gummadi，K.，Haeberlen，A.，和S.Saroiu，“住宅宽带网络的特征”，互联网测量会议，2007年10月24-26日。
[Duk10] Dukkipati, N., Refice, T., Cheng, Y., Chu, J., Sutin, N., Agarwal, A., Herbert, T., and J. Arvind, "An Argument for Increasing TCP's Initial Congestion Window", ACM SIGCOMM Computer Communications Review, vol. 40 (2010), pp. 27-33. July 2010.
[Duk10]Dukkipati，N.，Refice，T.，Cheng，Y.，Chu，J.，Sutin，N.，Agarwal，A.，Herbert，T.，和J.Arvind，“增加TCP初始拥塞窗口的论点”，ACM SIGCOMM计算机通信评论，第40卷（2010），第27-33页。2010年7月。
[FF99] Floyd, S., and K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]Floyd，S.和K.Fall，“促进互联网中端到端拥塞控制的使用”，IEEE/ACM网络交易，1999年8月。
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93]Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测网关”，IEEE/ACM网络交易，第1卷第4期，1993年8月，第页。397-413.
[Get11] Gettys, J., "Bufferbloat: Dark buffers in the Internet", presented to the TSV Area meeting, IETF 80, March 2011, <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
[Get11]Gettys，J.，“Bufferbloat:互联网中的暗缓冲区”，提交给TSV区域会议，IETF 80，2011年3月<http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
[Get11-1] Gettys, J., "IW10 Considered Harmful", Work in Progress, August 2011.
[Get11-1]Gettys，J.，“IW10被认为有害”，正在进行的工作，2011年8月。
[IOR2009] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J. Jahanian, F., and M. Karir, "Atlas Internet Observatory 2009 Annual Report", 47th NANOG Conference, October 2009.
[IOR2009]拉博维茨，C.，埃克尔·约翰逊，S.，麦克弗森，D.，奥伯里德，J.贾哈尼安，F.，和M.卡里尔，“阿特拉斯互联网天文台2009年度报告”，第47届NANOG会议，2009年10月。
[IW10] "TCP IW10 links", January 2012, <http://code.google.com/speed/protocols/tcpm-IW10.html>.
[IW10]“TCP IW10链接”，2012年1月<http://code.google.com/speed/protocols/tcpm-IW10.html>.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[Jac88]Jacobson，V.，“拥塞避免和控制”，《计算机通信评论》，第18卷，第4期，第314-329页，1988年8月。
[JNDK10] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "A Simulation Study on Increasing TCP's IW", presented to the IRTF ICCRG meeting, IETF 78, July 2010, <http://www.ietf.org/proceedings/78/slides/iccrg-7.pdf>.
[JNDK10]贾维宁，伊利诺伊州，尼莱宁。A.，Ding，A.，和M.Kojo，“关于增加TCP的IW的模拟研究”，提交给IRTF ICCRG会议，IETF 78，2010年7月<http://www.ietf.org/proceedings/78/slides/iccrg-7.pdf>.
[JNDK10-1] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "Effect of IW and Initial RTO changes", presented to the TCPM working group meeting, IETF 79, November 2010, <http://www.ietf.org/proceedings/79/slides/tcpm-1.pdf>.
[JNDK10-1]伊利诺伊州贾维宁，尼莱宁。A.，Ding，A.和M.Kojo，“信息战和初始RTO变化的影响”，提交给TCPM工作组会议，IETF 79，2010年11月<http://www.ietf.org/proceedings/79/slides/tcpm-1.pdf>.
[LAJW07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion Control Without a Startup Phase", Protocols for Fast, Long Distance Networks (PFLDnet) Workshop, February 2007, <http://www.icir.org/mallman/papers/ jumpstart-pfldnet07.pdf>.
[LAJW07]Liu，D.，Allman，M.，Jin，S.，和L.Wang，“无启动阶段的拥塞控制”，快速远程网络协议研讨会，2007年2月<http://www.icir.org/mallman/papers/ jumpstart-pfldnet07.pdf>。
[PK98] Padmanabhan V.N. and R. Katz, "TCP Fast Start: A technique for speeding up web transfers", in Proceedings of IEEE Globecom '98 Internet Mini-Conference, 1998.
[PK98]Padmanabhan V.N.和R.Katz，“TCP快速启动：一种加速网络传输的技术”，《IEEE Globecom’98互联网小型会议记录》，1998年。
[PRAKS02] Partridge, C., Rockwell, D., Allman, M., Krishnan, R., and J. Sterbenz, "A Swifter Start for TCP", Technical Report No. 8339, BBN Technologies, March 2002.
[PRAKS02]帕特里奇，C.，罗克韦尔，D.，奥尔曼，M.，克里希南，R.，和J.斯特本茨，“TCP更快的开始”，技术报告8339号，BBN技术，2002年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月。
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC2414141998年9月。
[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月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]Dawkins，S.，黑山，G.，Kojo，M.，和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782]Floyd，S.，Allman，M.，Jain，A.，和P.Sarolahti，“TCP和IP的快速启动”，RFC 4782，2007年1月。
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. Briscoe, "Open Research Issues in Internet Congestion Control", RFC 6077, February 2011.
[RFC6077]Papadimitriou，D.，Ed.，Welzl，M.，Scharf，M.，和B.Briscoe，“互联网拥塞控制的开放研究问题”，RFC 6077，2011年2月。
[RJ10] Ramachandran, S. and A. Jain, "Aggregate Statistics of Size Related Metrics of Web Pages metrics", May 2010, <http://code.google.com/speed/articles/web-metrics.html>.
[RJ10]Ramachandran，S.和A.Jain，“网页度量的大小相关度量的聚合统计”，2010年5月<http://code.google.com/speed/articles/web-metrics.html>.
[Sch08] Scharf, M., "Quick-Start, Jump-Start, and Other Fast Startup Approaches", presented to the IRTF ICCRG meeting, IETF 73, November 2008, <http://www.ietf.org/proceedings/73/slides/iccrg-2.pdf>.
[Sch08]Scharf，M.“快速启动、跳跃启动和其他快速启动方法”，提交给IRTF ICCRG会议，IETF 73，2008年11月<http://www.ietf.org/proceedings/73/slides/iccrg-2.pdf>.
[Sch11] Scharf, M., "Performance and Fairness Evaluation of IW10 and Other Fast Startup Schemes", presented to the IRTF ICCRG meeting, IETF 80, March 2011, <http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf>.
[Sch11]Scharf，M.“IW10和其他快速启动方案的性能和公平性评估”，提交给IRTF ICCRG会议，IETF 80，2011年3月<http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf>.
[Sch11-1] Scharf, M., "Comparison of end-to-end and network-supported fast startup congestion control schemes", Computer Networks, Feb. 2011, <http://dx.doi.org/10.1016/j.comnet.2011.02.002>.
[Sch11-1]Scharf，M.“端到端和网络支持的快速启动拥塞控制方案的比较”，计算机网络，2011年2月<http://dx.doi.org/10.1016/j.comnet.2011.02.002>.
[SPDY] "SPDY: An experimental protocol for a faster web", <http://dev.chromium.org/spdy>.
[SPDY]“SPDY：一个更快网络的实验协议”<http://dev.chromium.org/spdy>.
[Ste08] Sounders S., "Roundup on Parallel Connections", High Performance Web Sites blog, March 2008, <http://www.stevesouders.com/blog/2008/03/20/ roundup-on-parallel-connections>.
[Ste08]Sounders S.，“并行连接综述”，高性能网站博客，2008年3月<http://www.stevesouders.com/blog/2008/03/20/ 并联连接综述>。
[Tou12] Touch, J., "Automating the Initial Window in TCP", Work in Progress, July 2012.
[Tou12]Touch，J.，“自动化TCP中的初始窗口”，正在进行的工作，2012年7月。
[VH97] Visweswaraiah, V. and J. Heidemann, "Improving Restart of Idle TCP Connections", Technical Report 97-661, University of Southern California, November 1997.
[VH97 ] VISWESARWAIAH，V和J. Heidemann，“改善重新启动闲置TCP连接”，技术报告97661，南加州大学，1997年11月。
Concerns have been raised since the initial draft of this document was posted, based on a set of large-scale experiments. To better understand the impact of a larger initial window and in order to confirm or dismiss these concerns, additional tests have been conducted using either large-scale clusters, simulations, or real testbeds. The following attempts to compile the list of concerns and summarize findings from relevant tests.
自从根据一系列大规模实验发布本文件初稿以来，人们就提出了一些担忧。为了更好地理解较大初始窗口的影响，并确认或消除这些问题，使用大规模集群、模拟或真实试验台进行了额外的测试。以下尝试汇编关注点列表并总结相关测试的结果。
o How complete are various tests in covering many different traffic patterns?
o 覆盖多种不同交通模式的各种测试完成程度如何？
The large-scale Internet experiments conducted at Google's front-end infrastructure covered a large portfolio of services beyond web search. It included Gmail, Google Maps, Photos, News, Sites, Images, etc., and covered a wide variety of traffic sizes and patterns. One notable exception is YouTube, because we don't think the large initial window will have much material impact, either positive or negative, on bulk data services.
在谷歌前端基础设施上进行的大规模互联网实验涵盖了网络搜索以外的大量服务组合。它包括Gmail、谷歌地图、照片、新闻、网站、图片等，涵盖了各种各样的流量大小和模式。一个值得注意的例外是YouTube，因为我们不认为庞大的初始窗口会对批量数据服务产生太大的实质性影响，无论是正面的还是负面的。
[CW10] contains some results from a testbed study on how short flows with a larger initial window might affect the throughput performance of other coexisting, long-lived, bulk data transfers.
[CW10]包含了一项试验台研究的一些结果，该研究涉及具有较大初始窗口的短流如何影响其他共存、长寿命的批量数据传输的吞吐量性能。
o Larger bursts from the increase in the initial window cause significantly more packet drops.
o 初始窗口中增加的较大突发会导致更多的数据包丢失。
All the tests conducted on this subject ([Duk10] [Sch11] [Sch11-1] [CW10]) so far have shown only a modest increase of packet drops. The only exception is from the testbed study [CW10] under extremely high load and/or simultaneous opens. But under those conditions, both IW=3 and IW=10 suffered very high packet loss rates.
到目前为止，针对这一主题进行的所有测试（[Duk10][Sch11][Sch11-1][CW10]）都显示，数据包丢失量仅略有增加。唯一的例外是在极高负载和/或同时打开的情况下进行的试验台研究[CW10]。但是在这些条件下，IW=3和IW=10都遭受了非常高的丢包率。
o A large initial window may severely impact TCP performance over highly multiplexed links still common in developing regions.
o 较大的初始窗口可能会严重影响TCP在高度多路复用链路上的性能，这种情况在发展中国家仍然很常见。
Our large-scale experiments described in Section 10 above also covered Africa and South America. Measurement data from those regions [DCCM10] revealed improved latency, even for those services that employ multiple simultaneous connections, at the cost of a small increase in the retransmission rate. It seems that the round-trip savings from a larger initial window more than make up the time spent on recovering more lost packets.
我们在上文第10节中描述的大规模实验也涵盖了非洲和南美洲。来自这些区域[DCCM10]的测量数据显示，延迟有所改善，即使对于采用多个同时连接的服务，延迟也有所改善，但重新传输速率略有增加。从一个更大的初始窗口中节省的往返时间似乎超过了恢复更多丢失数据包所花费的时间。
Similar phenomena have also been observed from the testbed study [CW10].
从试验台研究[CW10]中也观察到类似现象。
o Why 10 segments?
o 为什么是10段？
Questions have been raised on how the number 10 was picked. We have tried different sizes in our large-scale experiments, and found that 10 segments seem to give most of the benefits for the services we tested while not causing significant increase in the retransmission rates. Going forward, 10 segments may turn out to be too small when the average of web object sizes continues to grow. But a scheme to "right size" the initial window automatically over long timescales has yet to be developed.
人们对10号是如何挑选的提出了疑问。在我们的大规模实验中，我们尝试了不同大小的数据段，发现10个数据段似乎为我们测试的服务提供了大部分好处，同时不会导致重传率的显著增加。展望未来，当web对象的平均大小继续增长时，10个片段可能会变得太小。但是，在长时间内自动“调整”初始窗口大小的方案尚未开发。
o More thorough analysis of the impact on slow links is needed.
o 需要对慢速链接的影响进行更彻底的分析。
Although [Duk10] showed the large initial window reduced the average latency even for the dialup link class of only 56 Kbps in bandwidth, more studies were needed in order to understand the effect of IW10 on slow links at the microscopic level. [CW10] was conducted for this purpose.
尽管[Duk10]表明，即使对于带宽仅为56 Kbps的拨号链路类别，较大的初始窗口也会降低平均延迟，但还需要进行更多的研究，以便从微观层面了解IW10对慢速链路的影响。[CW10]是为此目的而进行的。
Testbeds in [CW10] emulated a 300 ms RTT, bottleneck link bandwidth as low as 64 Kbps, and route queue size as low as 40 packets. A large combination of test parameters were used. Almost all tests showed varying degrees of latency improvement from IW=10, with only a modest increase in the packet drop rate until a very high load was injected. The testbed result was consistent with both the large-scale data center experiments [CD10] [DCCM10] and a separate study using the Network Simulation Cradle (NSC) framework [Sch11] [Sch11-1].
[CW10]中的试验台模拟了300 ms RTT，瓶颈链路带宽低至64 Kbps，路由队列大小低至40个数据包。使用了大量试验参数组合。几乎所有的测试都显示，从IW=10到IW=10，延迟都有不同程度的改善，在注入非常高的负载之前，数据包丢弃率只略有增加。试验台结果与大规模数据中心实验[CD10][DCCM10]和使用网络模拟支架（NSC）框架[Sch11][Sch11]的单独研究一致。
o How will the larger initial window affect flows with initial windows of 4 KB or less?
o 较大的初始窗口将如何影响初始窗口小于等于4KB的流？
Flows with the larger initial window will likely grab more bandwidth from a bottleneck link when competing against flows with smaller initial windows, at least initially. How long will this "unfairness" last? Will there be any "capture effect" where flows with larger initial window possess a disproportional share of bandwidth beyond just a few round trips?
当与初始窗口较小的流竞争时，初始窗口较大的流可能会从瓶颈链路中获取更多带宽，至少在初始阶段是这样。这种“不公平”会持续多久？如果初始窗口较大的流在仅几次往返之外拥有不成比例的带宽份额，是否会出现“捕获效应”？
If there is any "unfairness" issue from flows with different initial windows, it did not show up in the large-scale experiments, as the average latency for the bucket of all responses less than 4 KB did not seem to be affected by the presence of many other larger responses employing large initial window. As a matter of fact, they seemed to benefit from the large initial window too, as shown in Figure 7 of [Duk10].
如果不同初始窗口的流存在任何“不公平”问题，则在大规模实验中不会出现，因为小于4KB的所有响应的平均延迟似乎不会受到使用大初始窗口的许多其他较大响应的影响。事实上，他们似乎也受益于较大的初始窗口，如[Duk10]的图7所示。
The same phenomenon seems to exist in the testbed experiments [CW10]. Flows with IW=3 only suffered slightly when competing against flows with IW=10 in light to medium loads. Under high load, both flows' latency improved when mixed together. Also long-lived, background bulk-data flows seemed to enjoy higher throughput when running against many foreground short flows of IW=10 than against short flows of IW=3. One plausible explanation was that IW=10 enabled short flows to complete sooner, leaving more room for the long-lived, background flows.
在试验台试验中似乎也存在同样的现象[CW10]。当IW=3的流量与IW=10的流量在轻至中等负荷下竞争时，仅受到轻微影响。在高负载下，混合在一起时，两个流的延迟都得到了改善。同样，长寿命的后台批量数据流在运行于许多IW=10的前台短流时，似乎比运行于IW=3的短流时具有更高的吞吐量。一个合理的解释是IW=10使短流能够更快地完成，为长寿命的背景流留下更多的空间。
A study using an NSC simulator has also concluded that IW=10 works rather well and is quite fair against IW=3 [Sch11] [Sch11-1].
使用NSC模拟器进行的一项研究也得出结论，IW=10的效果相当好，与IW=3相当公平[Sch11][Sch11-1]。
o How will a larger initial window perform over cellular networks?
o 较大的初始窗口将如何在蜂窝网络上运行？
Some simulation studies [JNDK10] [JNDK10-1] have been conducted to study the effect of a larger initial window on wireless links from 2G to 4G networks (EGDE/HSPA/LTE). The overall result seems mixed in both raw performance and the fairness index.
已经进行了一些模拟研究[JNDK10][JNDK10-1]，以研究较大初始窗口对从2G到4G网络（EGDE/HSPA/LTE）的无线链路的影响。总体结果在原始性能和公平性指数方面似乎是混合的。
Authors' Addresses
作者地址
Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Jerry Chu Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: hkchu@google.com
EMail: hkchu@google.com
Nandita Dukkipati Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Nandita Dukkipati Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: nanditad@google.com
EMail: nanditad@google.com
Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
美国加利福尼亚州山景公园道1600圆形剧场，邮编94043
EMail: ycheng@google.com
EMail: ycheng@google.com
Matt Mathis Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Matt Mathis Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: mattmathis@google.com
EMail: mattmathis@google.com