Network Working Group S. Floyd
Request for Comments: 3649 ICSI
Category: Experimental December 2003
Network Working Group S. Floyd
Request for Comments: 3649 ICSI
Category: Experimental December 2003
HighSpeed TCP for Large Congestion Windows
适用于大拥塞窗口的高速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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.
本文件中的建议是实验性的。虽然它们可能部署在当前的互联网上，但它们并不代表这是高速拥塞控制的最佳方法的共识。特别是，我们注意到，可能会有替代性的实验性建议，并且不清楚本文件中的建议将如何与此类替代性建议相互作用。
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.
本文档提出了高速TCP，这是对TCP拥塞控制机制的一种修改，用于具有大拥塞窗口的TCP连接。当前标准TCP的拥塞控制机制限制了TCP在现实环境中可以实现的拥塞窗口。例如，对于具有1500字节数据包和100 ms往返时间的标准TCP连接，实现10 Gbps的稳态吞吐量需要平均83333个段的拥塞窗口，以及每5000000000个数据包最多一次拥塞事件的丢包率（或者相当于，每12/3小时最多发生一次拥塞事件）。这被广泛认为是一个不现实的限制。为了解决TCP的这一限制，本文提出了高速TCP，并征求更广泛社区的实验和反馈。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem Description.. . . . . . . . . . . . . . . . . . . . 3
3. Design Guidelines.. . . . . . . . . . . . . . . . . . . . . . . 4
4. Non-Goals.. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Modifying the TCP Response Function.. . . . . . . . . . . . . . 6
6. Fairness Implications of the HighSpeed Response
Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Translating the HighSpeed Response Function into
Congestion Control Parameters . . . . . . . . . . . . . . . . . 12
8. An alternate, linear response functions.. . . . . . . . . . . . 13
9. Tradeoffs for Choosing Congestion Control Parameters. . . . . . 16
9.1. The Number of Round-Trip Times between Loss Events . . . . 17
9.2. The Number of Packet Drops per Loss Event, with Drop-Tail. 17
10. Related Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Slow-Start. . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Limiting burstiness on short time scales. . . . . . . . . 19
10.3. Other limitations on window size. . . . . . . . . . . . . 19
10.4. Implementation issues.. . . . . . . . . . . . . . . . . . 19
11. Deployment issues. . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Deployment issues of HighSpeed TCP. . . . . . . . . . . . 20
11.2. Deployment issues of Scalable TCP . . . . . . . . . . . . 22
12. Related Work in HighSpeed TCP. . . . . . . . . . . . . . . . . 23
13. Relationship to other Work.. . . . . . . . . . . . . . . . . . 25
14. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . . 26
17. Informative References . . . . . . . . . . . . . . . . . . . . 26
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 28
A. TCP's Loss Event Rate in Steady-State. . . . . . . . . . . . . 29
B. A table for a(w) and b(w). . . . . . . . . . . . . . . . . . . 30
C. Exploring the time to converge to fairness . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem Description.. . . . . . . . . . . . . . . . . . . . 3
3. Design Guidelines.. . . . . . . . . . . . . . . . . . . . . . . 4
4. Non-Goals.. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Modifying the TCP Response Function.. . . . . . . . . . . . . . 6
6. Fairness Implications of the HighSpeed Response
Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Translating the HighSpeed Response Function into
Congestion Control Parameters . . . . . . . . . . . . . . . . . 12
8. An alternate, linear response functions.. . . . . . . . . . . . 13
9. Tradeoffs for Choosing Congestion Control Parameters. . . . . . 16
9.1. The Number of Round-Trip Times between Loss Events . . . . 17
9.2. The Number of Packet Drops per Loss Event, with Drop-Tail. 17
10. Related Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Slow-Start. . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Limiting burstiness on short time scales. . . . . . . . . 19
10.3. Other limitations on window size. . . . . . . . . . . . . 19
10.4. Implementation issues.. . . . . . . . . . . . . . . . . . 19
11. Deployment issues. . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Deployment issues of HighSpeed TCP. . . . . . . . . . . . 20
11.2. Deployment issues of Scalable TCP . . . . . . . . . . . . 22
12. Related Work in HighSpeed TCP. . . . . . . . . . . . . . . . . 23
13. Relationship to other Work.. . . . . . . . . . . . . . . . . . 25
14. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . . 26
17. Informative References . . . . . . . . . . . . . . . . . . . . 26
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 28
A. TCP's Loss Event Rate in Steady-State. . . . . . . . . . . . . 29
B. A table for a(w) and b(w). . . . . . . . . . . . . . . . . . . 30
C. Exploring the time to converge to fairness . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. In a steady-state environment, with a packet loss rate p, the current Standard TCP's average congestion window is roughly 1.2/sqrt(p) segments. This places a serious constraint on the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500- byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of
本文档提出了高速TCP，这是对TCP拥塞控制机制的一种修改，用于具有大拥塞窗口的TCP连接。在稳态环境中，在丢包率为p的情况下，当前标准TCP的平均拥塞窗口约为1.2/sqrt（p）段。这严重限制了TCP在现实环境中可以实现的拥塞窗口。例如，对于具有1500字节数据包和100毫秒往返时间的标准TCP连接，要实现10 Gbps的稳态吞吐量，需要平均拥塞窗口为
83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). The average packet drop rate of at most 2*10^(-10) needed for full link utilization in this environment corresponds to a bit error rate of at most 2*10^(-14), and this is an unrealistic requirement for current networks.
83333段，每5000000000个数据包最多发生一次拥塞事件的数据包丢弃率（或等效地，每12/3小时最多发生一次拥塞事件）。在此环境中，全链路利用率所需的平均丢包率最多为2*10^（-10），对应的误比特率最多为2*10^（-14），这对于当前网络来说是不现实的要求。
To address this fundamental limitation of TCP and of the TCP response function (the function mapping the steady-state packet drop rate to TCP's average sending rate in packets per round-trip time), this document describes a modified TCP response function for regimes with higher congestion windows. This document also solicits experimentation and feedback on HighSpeed TCP from the wider community.
为了解决TCP和TCP响应函数（将稳态数据包丢弃率映射到TCP的平均发送速率（以每往返时间的数据包为单位）的这一基本限制，本文档描述了一种改进的TCP响应函数，用于具有较高拥塞窗口的状态。本文档还从更广泛的社区征求关于高速TCP的实验和反馈。
Because HighSpeed TCP's modified response function would only take effect with higher congestion windows, HighSpeed TCP does not modify TCP behavior in environments with heavy congestion, and therefore does not introduce any new dangers of congestion collapse. However, if relative fairness between HighSpeed TCP connections is to be preserved, then in our view any modification to the TCP response function should be addressed in the IETF, rather than made as ad hoc decisions by individual implementors or TCP senders. Modifications to the TCP response function would also have implications for transport protocols that use TFRC and other forms of equation-based congestion control, as these congestion control mechanisms directly use the TCP response function [RFC3448].
由于HighSpeed TCP修改后的响应函数只会在较高的拥塞窗口下生效，因此HighSpeed TCP不会在拥塞严重的环境中修改TCP行为，因此不会引入任何新的拥塞崩溃危险。然而，如果要保持高速TCP连接之间的相对公平性，那么在我们看来，对TCP响应功能的任何修改都应该在IETF中解决，而不是由单个实施者或TCP发送者作为临时决定。对TCP响应函数的修改也会对使用TFRC和其他形式的基于等式的拥塞控制的传输协议产生影响，因为这些拥塞控制机制直接使用TCP响应函数[RFC3448]。
This proposal for HighSpeed TCP focuses specifically on a proposed change to the TCP response function, and its implications for TCP. This document does not address what we view as a separate fundamental issue, of the mechanisms required to enable best-effort connections to *start* with large initial windows. In our view, while HighSpeed TCP proposes a somewhat fundamental change to the TCP response function, at the same time it is a relatively simple change to implement in a single TCP sender, and presents no dangers in terms of congestion collapse. In contrast, in our view, the problem of enabling connections to *start* with large initial windows is inherently more risky and structurally more difficult, requiring some form of explicit feedback from all of the routers along the path. This is another reason why we would propose addressing the problem of starting with large initial windows separately, and on a separate timetable, from the problem of modifying the TCP response function.
这项关于高速TCP的提案特别关注TCP响应功能的拟议变更及其对TCP的影响。本文档并没有解决我们认为是一个独立的基本问题，即使用大型初始窗口实现尽最大努力连接到*启动*所需的机制。在我们看来，虽然高速TCP对TCP响应函数提出了某种根本性的改变，但在单个TCP发送方中实现这一改变相对简单，并且不会带来拥塞崩溃的危险。相比之下，在我们看来，启用连接以大初始窗口“启动”的问题本质上更危险，结构上更困难，需要路径上所有路由器的某种形式的明确反馈。这也是为什么我们建议从修改TCP响应函数的问题出发，分别在单独的时间表上解决大初始窗口问题的另一个原因。
This section describes the number of round-trip times between congestion events required for a Standard TCP flow to achieve an average throughput of B bps, given packets of D bytes and a round-trip time of R seconds. A congestion event refers to a window of data with one or more dropped or ECN-marked packets (where ECN stands for Explicit Congestion Notification).
本节描述了在给定数据包为D字节且往返时间为R秒的情况下，标准TCP流实现B bps平均吞吐量所需的拥塞事件之间的往返次数。拥塞事件是指包含一个或多个丢弃的或带有ECN标记的数据包的数据窗口（其中ECN表示显式拥塞通知）。
From Appendix A, achieving an average TCP throughput of B bps requires a loss event at most every BR/(12D) round-trip times. This is illustrated in Table 1, for R = 0.1 seconds and D = 1500 bytes. The table also gives the average congestion window W of BR/(8D), and the steady-state packet drop rate P of 1.5/W^2.
根据附录A，实现平均TCP吞吐量B bps需要最多每BR/（12D）往返时间发生一次丢失事件。如表1所示，R=0.1秒，D=1500字节。该表还给出了平均拥塞窗口W为BR/（8D），稳态丢包率P为1.5/W^2。
TCP Throughput (Mbps) RTTs Between Losses W P
--------------------- ------------------- ---- -----
1 5.5 8.3 0.02
10 55.5 83.3 0.0002
100 555.5 833.3 0.000002
1000 5555.5 8333.3 0.00000002
10000 55555.5 83333.3 0.0000000002
TCP Throughput (Mbps) RTTs Between Losses W P
--------------------- ------------------- ---- -----
1 5.5 8.3 0.02
10 55.5 83.3 0.0002
100 555.5 833.3 0.000002
1000 5555.5 8333.3 0.00000002
10000 55555.5 83333.3 0.0000000002
Table 1: RTTs Between Congestion Events for Standard TCP, for 1500-Byte Packets and a Round-Trip Time of 0.1 Seconds.
表1:1500字节数据包的标准TCP拥塞事件与0.1秒往返时间之间的RTT。
This document proposes HighSpeed TCP, a minimal modification to TCP's increase and decrease parameters, for TCP connections with larger congestion windows, to allow TCP to achieve high throughput with more realistic requirements for the steady-state packet drop rate. Equivalently, HighSpeed TCP has more realistic requirements for the number of round-trip times between loss events.
本文档针对拥塞窗口较大的TCP连接，提出了高速TCP，这是对TCP的增加和减少参数的最小修改，以允许TCP实现高吞吐量，同时对稳态丢包率有更实际的要求。同样，高速TCP对丢失事件之间的往返次数有更现实的要求。
Our proposal for HighSpeed TCP is motivated by the following requirements:
我们对高速TCP的提议基于以下要求：
* Achieve high per-connection throughput without requiring unrealistically low packet loss rates.
* 实现高的每连接吞吐量，而不需要不切实际的低数据包丢失率。
* Reach high throughput reasonably quickly when in slow-start.
* 在慢速启动时合理快速地达到高吞吐量。
* Reach high throughput without overly long delays when recovering from multiple retransmit timeouts, or when ramping-up from a period with small congestion windows.
* 在从多次重传超时中恢复时，或在从拥塞窗口较小的时段加速时，无需过长的延迟即可达到高吞吐量。
* No additional feedback or support required from routers:
* 无需路由器提供额外反馈或支持：
For example, the goal is for acceptable performance in both ECN-capable and non-ECN-capable environments, and with Drop-Tail as well as with Active Queue Management such as RED in the routers.
例如，目标是在支持ECN和不支持ECN的环境中，以及在路由器中使用Drop Tail和活动队列管理（如RED）时获得可接受的性能。
* No additional feedback required from TCP receivers.
* 不需要TCP接收器的额外反馈。
* TCP-compatible performance in environments with moderate or high congestion (e.g., packet drop rates of 1% or higher):
* 在中等或高拥塞（例如，数据包丢失率为1%或更高）环境中的TCP兼容性能：
Equivalently, the requirement is that there be no additional load on the network (in terms of increased packet drop rates) in environments with moderate or high congestion.
等效地，要求在中度或高度拥塞的环境中，网络上不存在额外的负载（以增加的丢包率为例）。
* Performance at least as good as Standard TCP in environments with moderate or high congestion.
* 在中等或高拥塞环境中，性能至少与标准TCP相同。
* Acceptable transient performance, in terms of increases in the congestion window in one round-trip time, responses to severe congestion, and convergence times to fairness.
* 可接受的瞬态性能，就一次往返时间内拥塞窗口的增加、对严重拥塞的响应以及对公平性的收敛时间而言。
Currently, users wishing to achieve throughputs of 1 Gbps or more typically open up multiple TCP connections in parallel, or use MulTCP [CO98,GRK99], which behaves roughly like the aggregate of N virtual TCP connections. While this approach suffices for the occasional user on well-provisioned links, it leaves the parameter N to be determined by the user, and results in more aggressive performance and higher steady-state packet drop rates if used in environments with periods of moderate or high congestion. We believe that a new approach is needed that offers more flexibility, more effectively scales to a wide range of available bandwidths, and competes more fairly with Standard TCP in congested environments.
目前，希望达到1 Gbps或更高吞吐量的用户通常会并行打开多个TCP连接，或使用MulTCP[CO98，GRK99]，其行为大致类似于N个虚拟TCP连接的聚合。虽然这种方法仅适用于配置良好的链路上的偶尔用户，但它将参数N留给用户来确定，并且如果在具有中度或高度拥塞的环境中使用，则会导致更具攻击性的性能和更高的稳态数据包丢弃率。我们认为需要一种新的方法，提供更大的灵活性，更有效地扩展到更广泛的可用带宽，并在拥挤的环境中与标准TCP更公平地竞争。
The following are explicitly *not* goals of our work:
以下是我们工作的明确目标：
* Non-goal: TCP-compatible performance in environments with very low packet drop rates.
* 非目标：在数据包丢失率非常低的环境中具有TCP兼容的性能。
We note that our proposal does not require, or deliver, TCP-compatible performance in environments with very low packet drop rates, e.g., with packet loss rates of 10^-5 or 10^-6. As we discuss later in this document, we assume that Standard TCP is unable to make effective use of the available bandwidth in environments with loss
我们注意到，我们的提案不要求或提供在丢包率非常低的环境中（例如，丢包率为10^-5或10^-6）的TCP兼容性能。正如我们在本文档后面讨论的，我们假设标准TCP无法在有损耗的环境中有效利用可用带宽
rates of 10^-6 in any case, so that it is acceptable and appropriate for HighSpeed TCP to perform more aggressively than Standard TCP in such an environment.
在任何情况下，速率均为10^-6，因此在这种环境下，高速TCP比标准TCP执行得更积极是可以接受和适当的。
* Non-goal: Ramping-up more quickly than allowed by slow-start.
* 非目标：加速比慢速启动允许的速度更快。
It is our belief that ramping-up more quickly than allowed by slow-start would necessitate more explicit feedback from routers along the path. The proposal for HighSpeed TCP is focused on changes to TCP that could be effectively deployed in the current Internet environment.
我们相信，比慢速启动所允许的速度更快的爬坡将需要路由器在路径上提供更明确的反馈。关于高速TCP的提案集中于对TCP的更改，这些更改可以有效地部署在当前的Internet环境中。
* Non-goal: Avoiding oscillations in environments with only one-way, long-lived flows all with the same round-trip times.
* 非目标：避免在只有单向、长寿命流且往返时间相同的环境中发生振荡。
While we agree that attention to oscillatory behavior is useful, avoiding oscillations in aggregate throughput has not been our primary consideration, particularly for simplified environments limited to one-way, long-lived flows all with the same, large round-trip times. Our assessment is that some oscillatory behavior in these extreme environments is an acceptable price to pay for the other benefits of HighSpeed TCP.
虽然我们同意对振荡行为的关注是有益的，但避免总吞吐量的振荡并不是我们的主要考虑因素，特别是对于仅限于单向、长寿命流且往返时间相同的简化环境。我们的评估是，在这些极端环境中的一些振荡行为是为高速TCP的其他好处付出的可接受的代价。
The TCP response function, w = 1.2/sqrt(p), gives TCP's average congestion window w in MSS-sized segments, as a function of the steady-state packet drop rate p [FF98]. This TCP response function is a direct consequence of TCP's Additive Increase Multiplicative Decrease (AIMD) mechanisms of increasing the congestion window by roughly one segment per round-trip time in the absence of congestion, and halving the congestion window in response to a round-trip time with a congestion event. This response function for Standard TCP is reflected in the table below. In this proposal we restrict our attention to TCP performance in environments with packet loss rates of at most 10^-2, and so we can ignore the more complex response functions that are required to model TCP performance in more congested environments with retransmit timeouts. From Appendix A, an average congestion window of W corresponds to an average of 2/3 W round-trip times between loss events for Standard TCP (with the congestion window varying from 2/3 W to 4/3 W).
TCP响应函数w=1.2/sqrt（p），给出了TCP的平均拥塞窗口w，以MSS大小的段为单位，作为稳态丢包率p的函数[FF98]。此TCP响应函数是TCP的加法-递增-乘法-递减（AIMD）机制的直接结果，该机制在没有拥塞的情况下，将拥塞窗口每往返时间大约增加一段，并将拥塞窗口减半以响应有拥塞事件的往返时间。标准TCP的此响应函数反映在下表中。在该方案中，我们将注意力限制在丢包率最多为10^-2的环境中的TCP性能上，因此我们可以忽略在具有重传超时的更拥挤的环境中建模TCP性能所需的更复杂的响应函数。根据附录A，平均拥塞窗口W对应于标准TCP丢失事件之间平均2/3 W往返时间（拥塞窗口从2/3 W到4/3 W不等）。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 120 80
10^-5 379 252
10^-6 1200 800
10^-7 3795 2530
10^-8 12000 8000
10^-9 37948 25298
10^-10 120000 80000
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 120 80
10^-5 379 252
10^-6 1200 800
10^-7 3795 2530
10^-8 12000 8000
10^-9 37948 25298
10^-10 120000 80000
Table 2: TCP Response Function for Standard TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表2：标准TCP的TCP响应函数。MSS大小的段中的平均拥塞窗口W作为丢包率P的函数给出。
To specify a modified response function for HighSpeed TCP, we use three parameters, Low_Window, High_Window, and High_P. To ensure TCP compatibility, the HighSpeed response function uses the same response function as Standard TCP when the current congestion window is at most Low_Window, and uses the HighSpeed response function when the current congestion window is greater than Low_Window. In this document we set Low_Window to 38 MSS-sized segments, corresponding to a packet drop rate of 10^-3 for TCP.
为了为高速TCP指定修改后的响应函数，我们使用了三个参数：Low_Window、High_Window和High_P。为了确保TCP兼容性，当当前拥塞窗口最多为Low_Window时，高速响应函数使用与标准TCP相同的响应函数，当当前拥塞窗口大于Low_窗口时，使用高速响应功能。在本文中，我们将Low_Window设置为38个MSS大小的段，对应于TCP的10^-3丢包率。
To specify the upper end of the HighSpeed response function, we specify the packet drop rate needed in the HighSpeed response function to achieve an average congestion window of 83000 segments. This is roughly the window needed to sustain 10 Gbps throughput, for a TCP connection with the default packet size and round-trip time used earlier in this document. For High_Window set to 83000, we specify High_P of 10^-7; that is, with HighSpeed TCP a packet drop rate of 10^-7 allows the HighSpeed TCP connection to achieve an average congestion window of 83000 segments. We believe that this loss rate sets an achievable target for high-speed environments, while still allowing acceptable fairness for the HighSpeed response function when competing with Standard TCP in environments with packet drop rates of 10^-4 or 10^5.
为了指定高速响应函数的上端，我们指定高速响应函数中需要的丢包率，以实现83000段的平均拥塞窗口。对于本文档前面使用的默认数据包大小和往返时间的TCP连接，这大概是维持10 Gbps吞吐量所需的窗口。对于设置为83000的High_窗口，我们指定High_P为10^-7；也就是说，对于高速TCP，10^-7的丢包率允许高速TCP连接实现83000段的平均拥塞窗口。我们认为，这种丢失率为高速环境设定了一个可实现的目标，同时在丢包率为10^-4或10^-5的环境中与标准TCP竞争时，仍然允许高速响应功能具有可接受的公平性。
For simplicity, for the HighSpeed response function we maintain the property that the response function gives a straight line on a log-log scale (as does the response function for Standard TCP, for low to moderate congestion). This results in the following response function, for values of the average congestion window W greater than Low_Window:
为简单起见，对于高速响应函数，我们保持响应函数在对数刻度上给出一条直线的特性（对于标准TCP，对于低到中度拥塞，响应函数也是如此）。对于平均拥塞窗口W大于低_窗口的值，这将产生以下响应函数：
W = (p/Low_P)^S Low_Window,
W = (p/Low_P)^S Low_Window,
for Low_P the packet drop rate corresponding to Low_Window, and for S as following constant [FRS02]:
对于Low_P，对应于Low_窗口的数据包丢弃率，对于S，如下常数[FRS02]：
S = (log High_Window - log Low_Window)/(log High_P - log Low_P).
S = (log High_Window - log Low_Window)/(log High_P - log Low_P).
(In this paper, "log x" refers to the log base 10.) For example, for Low_Window set to 38, we have Low_P of 10^-3 (for compatibility with Standard TCP). Thus, for High_Window set to 83000 and High_P set to 10^-7, we get the following response function:
（在本文中，“logx”指的是日志基数10。）例如，对于设置为38的Low_窗口，我们有10^-3的Low_P（与标准TCP兼容）。因此，对于设置为83000的High_Window和设置为10^-7的High_P，我们得到以下响应函数：
W = 0.12/p^0.835. (1)
W = 0.12/p^0.835. (1)
This HighSpeed response function is illustrated in Table 3 below. For HighSpeed TCP, the number of round-trip times between losses, 1/(pW), equals 12.7 W^0.2, for W > 38 segments.
该高速响应功能如表3所示。对于高速TCP，当W>38段时，损耗之间的往返次数1/（pW）等于12.7 W^0.2。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 263 38
10^-5 1795 57
10^-6 12279 83
10^-7 83981 123
10^-8 574356 180
10^-9 3928088 264
10^-10 26864653 388
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 25
10^-4 263 38
10^-5 1795 57
10^-6 12279 83
10^-7 83981 123
10^-8 574356 180
10^-9 3928088 264
10^-10 26864653 388
Table 3: TCP Response Function for HighSpeed TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表3：高速TCP的TCP响应函数。MSS大小的段中的平均拥塞窗口W作为丢包率P的函数给出。
We believe that the problem of backward compatibility with Standard TCP requires a response function that is quite close to that of Standard TCP for loss rates of 10^-1, 10^-2, or 10^-3. We believe, however, that such stringent TCP-compatibility is not required for smaller loss rates, and that an appropriate response function is one that gives a plausible packet drop rate for a connection throughput of 10 Gbps. This also gives a slowly increasing number of round-trip times between loss events as a function of a decreasing packet drop rate.
我们认为，对于10^-1、10^-2或10^-3的丢失率，与标准TCP的向后兼容性问题需要一个与标准TCP非常接近的响应函数。然而，我们认为，对于较小的丢失率，不需要如此严格的TCP兼容性，并且适当的响应函数可以为10 Gbps的连接吞吐量提供合理的丢包率。这也使得丢失事件之间的往返次数随着丢包率的降低而缓慢增加。
Another way to look at the HighSpeed response function is to consider that HighSpeed TCP is roughly emulating the congestion control response of N parallel TCP connections, where N is initially one, and where N increases as a function of the HighSpeed TCP's congestion window. Thus for the HighSpeed response function in Equation (1) above, the response function can be viewed as equivalent to that of
查看高速响应函数的另一种方法是考虑高速TCP大致模拟N个并行TCP连接的拥塞控制响应，其中N最初是一个，并且其中N作为高速TCP拥塞窗口的函数而增加。因此，对于上述等式（1）中的高速响应函数，可以将响应函数视为等效于
N(W) parallel TCP connections, where N(W) varies as a function of the congestion window W. Recall that for a single standard TCP connection, the average congestion window equals 1.2/sqrt(p). For N parallel TCP connections, the aggregate congestion window for the N connections equals N*1.2/sqrt(p). From the HighSpeed response function in Equation (1) and the relationship above, we can derive the following:
N（W）个并行TCP连接，其中N（W）随着拥塞窗口W的变化而变化。回想一下，对于单个标准TCP连接，平均拥塞窗口等于1.2/sqrt（p）。对于N个并行TCP连接，N个连接的聚合拥塞窗口等于N*1.2/sqrt（p）。根据方程式（1）中的高速响应函数和上述关系，我们可以得出以下结果：
N(W) = 0.23*W^(0.4)
N(W) = 0.23*W^(0.4)
for N(W) the number of parallel TCP connections emulated by the HighSpeed TCP response function, and for N(W) >= 1. This is shown in Table 4 below.
对于N（W），高速TCP响应函数模拟的并行TCP连接数，对于N（W）>=1。如下表4所示。
Congestion Window W Number N(W) of Parallel TCPs
------------------- -------------------------
1 1
10 1
100 1.4
1,000 3.6
10,000 9.2
100,000 23.0
Congestion Window W Number N(W) of Parallel TCPs
------------------- -------------------------
1 1
10 1
100 1.4
1,000 3.6
10,000 9.2
100,000 23.0
Table 4: Number N(W) of parallel TCP connections roughly emulated by the HighSpeed TCP response function.
表4：高速TCP响应函数大致模拟的并行TCP连接数N（W）。
In this document, we do not attempt to seriously evaluate the HighSpeed response function for congestion windows greater than 100,000 packets. We believe that we will learn more about the requirements for sustaining the throughput of best-effort connections in that range as we gain more experience with HighSpeed TCP with congestion windows of thousands and tens of thousands of packets. There also might be limitations to the per-connection throughput that can be realistically achieved for best-effort traffic, in terms of congestion window of hundreds of thousands of packets or more, in the absence of additional support or feedback from the routers along the path.
在本文档中，我们不会认真评估大于100000个数据包的拥塞窗口的高速响应函数。我们相信，随着我们在拥塞窗口为数千和数万个数据包的高速TCP方面获得更多经验，我们将进一步了解在该范围内维持尽力而为连接吞吐量的要求。在没有来自路径沿线路由器的额外支持或反馈的情况下，对于尽力而为的通信量而言，每连接吞吐量也可能存在限制，具体表现为几十万个或更多个分组的拥塞窗口。
The Standard and Highspeed Response Functions can be used directly to infer the relative fairness between flows using the two response functions. For example, given a packet drop rate P, assume that Standard TCP has an average congestion window of W_Standard, and HighSpeed TCP has a higher average congestion window of W_HighSpeed.
标准和高速响应函数可直接用于推断使用这两个响应函数的流之间的相对公平性。例如，给定丢包率P，假设标准TCP的平均拥塞窗口为W_Standard，而高速TCP的平均拥塞窗口为W_HighSpeed。
In this case, a single HighSpeed TCP connection is receiving W_HighSpeed/W_Standard times the throughput of a single Standard TCP connection competing in the same environment.
在这种情况下，单个高速TCP连接正在接收W_HighSpeed/W_Standard乘以在同一环境中竞争的单个标准TCP连接的吞吐量。
This relative fairness is illustrated below in Table 5, for the parameters used for the Highspeed response function in the section above. The second column gives the relative fairness, for the steady-state packet drop rate specified in the first column. To help calibrate, the third column gives the aggregate average congestion window for the two TCP connections, and the fourth column gives the bandwidth that would be needed by the two connections to achieve that aggregate window and packet drop rate, given 100 ms round-trip times and 1500-byte packets.
对于上一节中用于高速响应功能的参数，这种相对公平性如下表5所示。第二列给出了第一列中指定的稳态丢包率的相对公平性。为了帮助校准，第三列给出了两个TCP连接的聚合平均拥塞窗口，第四列给出了两个连接在给定100毫秒往返时间和1500字节数据包的情况下实现聚合窗口和数据包丢弃率所需的带宽。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 2.2 383 45.9 Mbps
10^-5 4.7 2174 260.8 Mbps
10^-6 10.2 13479 1.6 Gbps
10^-7 22.1 87776 10.5 Gbps
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 2.2 383 45.9 Mbps
10^-5 4.7 2174 260.8 Mbps
10^-6 10.2 13479 1.6 Gbps
10^-7 22.1 87776 10.5 Gbps
Table 5: Relative Fairness between the HighSpeed and Standard Response Functions.
表5：高速和标准响应函数之间的相对公平性。
Thus, for packet drop rates of 10^-4, a flow with the HighSpeed response function can expect to receive 2.2 times the throughput of a flow using the Standard response function, given the same round-trip times and packet sizes. With packet drop rates of 10^-6 (or 10^-7), the unfairness is more severe, and we have entered the regime where a Standard TCP connection requires at most one congestion event every 800 (or 2530) round-trip times in order to make use of the available bandwidth. Our judgement would be that there are not a lot of TCP connections effectively operating in this regime today, with congestion windows of thousands of packets, and that therefore the benefits of the HighSpeed response function would outweigh the unfairness that would be experienced by Standard TCP in this regime. However, one purpose of this document is to solicit feedback on this issue. The parameter Low_Window determines directly the point of divergence between the Standard and HighSpeed Response Functions.
因此，对于10^-4的分组丢弃率，在给定相同的往返时间和分组大小的情况下，具有高速响应功能的流可以预期接收到使用标准响应功能的流的吞吐量的2.2倍。由于数据包丢弃率为10^-6（或10^-7），不公平性更为严重，我们已经进入了这样一种状态：标准TCP连接最多需要每800（或2530）次往返时间发生一次拥塞事件，以利用可用带宽。我们的判断是，目前没有很多TCP连接在这种机制下有效运行，拥塞窗口为数千个数据包，因此，高速响应功能的好处将超过标准TCP在这种机制下所经历的不公平。然而，本文件的一个目的是征求对这一问题的反馈意见。参数Low_Window直接确定标准和高速响应函数之间的分歧点。
The third column of Table 5, the Aggregate Window, gives the aggregate congestion window of the two competing TCP connections, with HighSpeed and Standard TCP, given the packet drop rate specified in the first column. From Table 5, a HighSpeed TCP connection would receive ten times the bandwidth of a Standard TCP in an environment with a packet drop rate of 10^-6. This would occur when the two
表5的第三列“聚合窗口”（Aggregate Window）给出了两个竞争TCP连接（高速和标准TCP）的聚合拥塞窗口，给出了第一列中指定的丢包率。从表5可以看出，在丢包率为10^-6的环境中，高速TCP连接将接收到标准TCP的十倍带宽。当两个
flows sharing a single pipe achieved an aggregate window of 13479 packets. Given a round-trip time of 100 ms and a packet size of 1500 bytes, this would occur with an available bandwidth for the two competing flows of 1.6 Gbps.
共享单个管道的流实现了13479个数据包的聚合窗口。如果往返时间为100 ms，数据包大小为1500字节，则这将在两个竞争流的可用带宽为1.6 Gbps时发生。
Next we consider the time that it takes a standard or HighSpeed TCP flow to converge to fairness against a pre-existing HighSpeed TCP flow. The worst case for convergence to fairness occurs when a new flow is starting up, competing against a high-bandwidth existing flow, and the new flow suffers a packet drop and exits slow-start while its window is still small. In the worst case, consider that the new flow has entered the congestion avoidance phase while its window is only one packet. A standard TCP flow in congestion avoidance increases its window by at most one packet per round-trip time, and after N round-trip times has only achieved a window of N packets (when starting with a window of 1 in the first round-trip time). In contrast, a HighSpeed TCP flows increases much faster than a standard TCP flow while in the congestion avoidance phase, and we can expect its convergence to fairness to be much better. This is shown in Table 6 below. The script used to generate this table is given in Appendix C.
接下来，我们考虑的时间，它需要一个标准或高速TCP流收敛到公平的预先存在的高速TCP流。收敛到公平性的最坏情况发生在新流启动时，与高带宽的现有流竞争，并且新流遭受数据包丢失并在其窗口仍然很小时退出慢速启动。在最坏的情况下，考虑新的流已经进入拥塞避免阶段，而它的窗口仅是一个分组。拥塞避免中的标准TCP流每往返时间最多增加一个数据包的窗口，并且在N次往返时间之后，仅实现了N个数据包的窗口（当在第一次往返时间中以1个窗口开始时）。相比之下，在拥塞避免阶段，高速TCP流的增长速度比标准TCP流快得多，我们可以预期其收敛到公平性的速度会更好。如下表6所示。用于生成此表的脚本在附录C中给出。
RTT HS_Window Standard_TCP_Window
--- --------- -------------------
100 131 100
200 475 200
300 1131 300
400 2160 400
500 3601 500
600 5477 600
700 7799 700
800 10567 800
900 13774 900
1000 17409 1000
1100 21455 1100
1200 25893 1200
1300 30701 1300
1400 35856 1400
1500 41336 1500
1600 47115 1600
1700 53170 1700
1800 59477 1800
1900 66013 1900
2000 72754 2000
RTT HS_Window Standard_TCP_Window
--- --------- -------------------
100 131 100
200 475 200
300 1131 300
400 2160 400
500 3601 500
600 5477 600
700 7799 700
800 10567 800
900 13774 900
1000 17409 1000
1100 21455 1100
1200 25893 1200
1300 30701 1300
1400 35856 1400
1500 41336 1500
1600 47115 1600
1700 53170 1700
1800 59477 1800
1900 66013 1900
2000 72754 2000
Table 6: For a HighSpeed and a Standard TCP connection, the congestion window during congestion avoidance phase (starting with a congestion window of 1 packet during RTT 1).
表6：对于高速和标准TCP连接，拥塞避免阶段的拥塞窗口（在RTT1期间从1个数据包的拥塞窗口开始）。
The classic paper on relative fairness is from Chiu and Jain [CJ89]. This paper shows that AIMD (Additive Increase Multiplicative Decrease) converges to fairness in an environment with synchronized congestion events. From [CJ89], it is easy to see that MIMD and AIAD do not converge to fairness in this environment. However, the results of [CJ89] do not apply to an asynchronous environment such as that of the current Internet, where the frequency of congestion feedback can be different for different flows. For example, it has been shown that MIMD converges to fair states in a model with proportional instead of synchronous feedback in terms of packet drops [GV02]. Thus, we are not concerned about abandoning a strict model of AIMD for HighSpeed TCP. However, we note that in an environment with Drop-Tail queue management, there is likely to be some synchronization of packet drops. In this environment, the model of completely synchronous feedback does not hold, but the model of completely asynchronous feedback is not accurate either. Fairness in Drop-Tail environments is discussed in more detail in Sections 9 and 12.
关于相对公平性的经典论文来自Chiu和Jain[CJ89]。本文证明了在具有同步拥塞事件的环境中，AIMD（Additive-Increase-乘法-Decrease）收敛于公平性。从[CJ89]可以很容易地看出，MIMD和AIAD在这种环境中并不收敛于公平性。然而，[CJ89]的结果不适用于异步环境，例如当前互联网的异步环境，在这种环境中，不同流量的拥塞反馈频率可能不同。例如，已经证明，MIMD在一个具有比例反馈而非同步反馈的模型中收敛到公平状态，即分组丢弃[GV02]。因此，我们并不担心放弃用于高速TCP的严格AIMD模型。然而，我们注意到，在具有丢弃尾队列管理的环境中，可能存在一些数据包丢弃的同步。在这种环境下，完全同步反馈的模型不成立，但完全异步反馈的模型也不准确。第9节和第12节将更详细地讨论掉尾环境中的公平性。
7. Translating the HighSpeed Response Function into Congestion Control Parameters
7. 将高速响应函数转化为拥塞控制参数
For equation-based congestion control such as TFRC, the HighSpeed Response Function above could be used directly by the TFRC congestion control mechanism. However, for TCP the HighSpeed response function has to be translated into additive increase and multiplicative decrease parameters. The HighSpeed response function cannot be achieved by TCP with an additive increase of one segment per round-trip time and a multiplicative decrease of halving the current congestion window; HighSpeed TCP will have to modify either the increase or the decrease parameter, or both. We have concluded that HighSpeed TCP is most likely to achieve an acceptable compromise between moderate increases and timely decreases by modifying both the increase and the decrease parameter.
对于基于方程的拥塞控制（如TFRC），TFRC拥塞控制机制可以直接使用上述高速响应函数。然而，对于TCP，高速响应函数必须转换为加性增加和乘性减少参数。高速响应功能不能通过TCP来实现，因为每次往返时间增加一个区段，并且当前拥塞窗口将乘性减少一半；高速TCP必须修改递增或递减参数，或同时修改两者。我们得出结论，通过修改增加和减少参数，高速TCP最有可能在适度增加和及时减少之间达成可接受的折衷。
That is, for HighSpeed TCP let the congestion window increase by a(w) segments per round-trip time in the absence of congestion, and let the congestion window decrease to w(1-b(w)) segments in response to a round-trip time with one or more loss events. Thus, in response to a single acknowledgement HighSpeed TCP increases its congestion window in segments as follows:
也就是说，对于高速TCP，在没有拥塞的情况下，让拥塞窗口每往返时间增加a（w）段，并让拥塞窗口减少到w（1-b（w））段，以响应具有一个或多个丢失事件的往返时间。因此，作为对单个确认的响应，高速TCP将其拥塞窗口分段增加，如下所示：
w <- w + a(w)/w.
w<-w+a（w）/w。
In response to a congestion event, HighSpeed TCP decreases as follows:
作为对拥塞事件的响应，高速TCP降低如下：
w <- (1-b(w))w.
w<-（1-b（w））w。
For Standard TCP, a(w) = 1 and b(w) = 1/2, regardless of the value of w. HighSpeed TCP uses the same values of a(w) and b(w) for w <= Low_Window. This section specifies a(w) and b(w) for HighSpeed TCP for larger values of w.
对于标准TCP，a（w）=1，b（w）=1/2，而与w的值无关。对于w<=低_窗口，高速TCP使用相同的a（w）和b（w）值。本节为高速TCP指定了a（w）和b（w），以获得更大的w值。
For w = High_Window, we have specified a loss rate of High_P. From [FRS02], or from elementary calculations, this requires the following relationship between a(w) and b(w) for w = High_Window:
对于w=高_窗口，我们已从[FRS02]或从基本计算中指定了高_P的损失率，这需要w=高_窗口的a（w）和b（w）之间的以下关系：
a(w) = High_Window^2 * High_P * 2 * b(w)/(2-b(w)). (2)
a(w) = High_Window^2 * High_P * 2 * b(w)/(2-b(w)). (2)
We use the parameter High_Decrease to specify the decrease parameter b(w) for w = High_Window, and use Equation (2) to derive the increase parameter a(w) for w = High_Window. Along with High_P = 10^-7 and High_Window = 83000, for example, we specify High_Decrease = 0.1, specifying that b(83000) = 0.1, giving a decrease of 10% after a congestion event. Equation (2) then gives a(83000) = 72, for an increase of 72 segments, or just under 0.1%, within a round-trip time, for w = 83000.
我们使用参数High_Decrease指定w=High_窗口的减小参数b（w），并使用方程（2）推导w=High_窗口的增大参数a（w）。例如，与High_P=10^-7和High_Window=83000一起，我们指定High_reduce=0.1，指定b（83000）=0.1，在拥塞事件后给出10%的减少。方程（2）给出了（83000）=72，对于w=83000，在往返时间内增加72段，或略低于0.1%。
This moderate decrease strikes us as acceptable, particularly when coupled with the role of TCP's ACK-clocking in limiting the sending rate in response to more severe congestion [BBFS01]. A more severe decrease would require a more aggressive increase in the congestion window for a round-trip time without congestion. In particular, a decrease factor High_Decrease of 0.5, as in Standard TCP, would require an increase of 459 segments per round-trip time when w = 83000.
我们认为这种适度的降低是可以接受的，特别是当TCP的ACK时钟在限制发送速率以响应更严重的拥塞时[BBFS01]。如果减少的幅度更大，则需要在往返时间内更大幅度地增加拥堵窗口，而不会造成拥堵。特别是，当w=83000时，如在标准TCP中，减少系数高_减少0.5，则每往返时间需要增加459段。
Given decrease parameters of b(w) = 1/2 for w = Low_Window, and b(w) = High_Decrease for w = High_Window, we are left to specify the value of b(w) for other values of w > Low_Window. From [FRS02], we let b(w) vary linearly as the log of w, as follows:
对于w=低_窗口，给定减小参数b（w）=1/2，对于w=高_窗口，给定减小参数b（w）=高_，对于w>低_窗口的其他值，我们需要指定b（w）的值。从[FRS02]中，我们让b（w）作为w的对数线性变化，如下所示：
b(w) = (High_Decrease - 0.5) (log(w)-log(W)) / (log(W_1)-log(W)) +
0.5,
b(w) = (High_Decrease - 0.5) (log(w)-log(W)) / (log(W_1)-log(W)) +
0.5,
for W = Low_window and W_1 = High_window. The increase parameter a(w) can then be computed as follows:
对于W=低_窗口和W_1=高_窗口。然后，增加参数a（w）可计算如下：
a(w) = w^2 * p(w) * 2 * b(w)/(2-b(w)),
a（w）=w^2*p（w）*2*b（w）/（2-b（w）），
for p(w) the packet drop rate for congestion window w. From inverting Equation (1), we get p(w) as follows:
对于p（w），拥塞窗口w的丢包率。通过对方程（1）进行反演，我们得到如下p（w）：
p(w) = 0.078/w^1.2.
p（w）=0.078/w^1.2。
We assume that experimental implementations of HighSpeed TCP for further investigation will use a pre-computed look-up table for finding a(w) and b(w). For example, the implementation from Tom Dunigan adjusts the a(w) and b(w) parameters every 0.1 seconds. In the appendix we give such a table for our default values of Low_Window = 38, High_Window = 83,000, High_P = 10^-7, and High_Decrease = 0.1. These are also the default values in the NS simulator; example simulations in NS can be run with the command "./test-all-tcpHighspeed" in the directory tcl/test.
我们假设用于进一步研究的高速TCP的实验实现将使用预先计算的查找表来查找a（w）和b（w）。例如，Tom Dunigan的实现每0.1秒调整一次a（w）和b（w）参数。在附录中，我们给出了低_窗口=38、高_窗口=83000、高_P=10^-7和高_减少=0.1的默认值。这些也是NS模拟器中的默认值；NS中的模拟示例可以使用目录tcl/test中的命令“/test all tcpHighspeed”运行。
In this section we explore an alternate, linear response function for HighSpeed TCP that has been proposed by a number of other people, in particular by Glenn Vinnicombe and Tom Kelly. Similarly, it has been suggested by others that a less "ad-hoc" guideline for a response function for HighSpeed TCP would be to specify a constant value for the number of round-trip times between congestion events.
在本节中，我们将探讨其他一些人，特别是Glenn Vinnicombe和Tom Kelly提出的高速TCP的替代线性响应函数。类似地，其他人建议，对于高速TCP的响应函数，一个不太“特别”的指导原则是为拥塞事件之间的往返次数指定一个常量。
Assume that we keep the value of Low_Window as 38 MSS-sized segments, indicating when the HighSpeed response function diverges from the current TCP response function, but that we modify the High_Window and High_P parameters that specify the upper range of the HighSpeed response function. In particular, consider the response function given by High_Window = 380,000 and High_P = 10^-7, with Low_Window = 38 and Low_P = 10^-3 as before.
假设我们将Low_Window的值保持为38 ms大小的段，指示高速响应函数何时偏离当前TCP响应函数，但我们修改了High_Window和High_P参数，这些参数指定了高速响应函数的上限范围。特别地，考虑由HyiValk窗口＝380000和HyiSp＝10 ^ - 7给出的响应函数，与LoWixWindows＝38和Loopyp＝10 ^ -3一样。
Using the equations in Section 5, this would give the following Linear response function, for w > Low_Window:
使用第5节中的方程式，对于w>Low_窗口，这将给出以下线性响应函数：
W = 0.038/p.
W=0.038/p。
This Linear HighSpeed response function is illustrated in Table 7 below. For HighSpeed TCP, the number of round-trip times between losses, 1/(pW), equals 1/0.38, or equivalently, 26, for W > 38 segments.
该线性高速响应函数如表7所示。对于高速TCP，损耗之间的往返次数1/（pW）等于1/0.38，或等于26，对于W>38段。
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 26
10^-4 380 26
10^-5 3800 26
10^-6 38000 26
10^-7 380000 26
10^-8 3800000 26
10^-9 38000000 26
10^-10 380000000 26
Packet Drop Rate P Congestion Window W RTTs Between Losses
------------------ ------------------- -------------------
10^-2 12 8
10^-3 38 26
10^-4 380 26
10^-5 3800 26
10^-6 38000 26
10^-7 380000 26
10^-8 3800000 26
10^-9 38000000 26
10^-10 380000000 26
Table 7: An Alternate, Linear TCP Response Function for HighSpeed TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P.
表7：高速TCP的备用线性TCP响应函数。MSS大小的段中的平均拥塞窗口W作为丢包率P的函数给出。
Given a constant decrease b(w) of 1/2, this would give an increase a(w) of w/Low_Window, or equivalently, a constant increase of 1/Low_Window packets per acknowledgement, for w > Low_Window. Another possibility is Scalable TCP [K03], which uses a fixed decrease b(w) of 1/8 and a fixed increase per acknowledgement of 0.01. This gives an increase a(w) per window of 0.005 w, for a TCP with delayed acknowledgements, for pure MIMD.
假设b（w）恒定减少1/2，这将增加w/Low_窗口的a（w），或者等效地，对于w>Low_窗口，每个确认恒定增加1/Low_窗口分组。另一种可能性是可伸缩TCP[K03]，它使用1/8的固定减少b（w）和0.01的固定增加。对于具有延迟确认的TCP，对于纯MIMD，每窗口增加0.005 w（w）。
The relative fairness between the alternate Linear response function and the standard TCP response function is illustrated below in Table 8.
替代线性响应函数和标准TCP响应函数之间的相对公平性如下表8所示。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 3.2 500 60.0 Mbps
10^-5 15.1 4179 501.4 Mbps
10^-6 31.6 39200 4.7 Gbps
10^-7 100.1 383795 46.0 Gbps
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 3.2 500 60.0 Mbps
10^-5 15.1 4179 501.4 Mbps
10^-6 31.6 39200 4.7 Gbps
10^-7 100.1 383795 46.0 Gbps
Table 8: Relative Fairness between the Linear HighSpeed and Standard Response Functions.
表8：线性高速和标准响应函数之间的相对公平性。
One attraction of the linear response function is that it is scale-invariant, with a fixed increase in the congestion window per acknowledgement, and a fixed number of round-trip times between loss events. My own assumption would be that having a fixed length for the congestion epoch in round-trip times, regardless of the packet drop rate, would be a poor fit for an imprecise and imperfect world with routers with a range of queue management mechanisms, such as the Drop-Tail queue management that is common today. For example, a
线性响应函数的一个优点是它具有尺度不变性，每个确认的拥塞窗口都有固定的增加，丢失事件之间的往返时间也固定。我自己的假设是，在往返时间中，无论数据包丢弃率如何，拥塞时段的长度都是固定的，这对于一个不精确且不完美的世界来说是不合适的，因为路由器具有一系列队列管理机制，例如今天常见的掉尾队列管理。例如，一个
response function with a fixed length for the congestion epoch in round-trip times might give less clearly-differentiated feedback in an environment with steady-state background losses at fixed intervals for all flows (as might occur with a wireless link with occasional short error bursts, giving losses for all flows every N seconds regardless of their sending rate).
在所有流量在固定时间间隔存在稳态背景损失的环境中，往返时间内拥堵时段的固定长度响应函数可能会给出不太明显的差异反馈（偶尔出现短错误突发的无线链路可能会出现这种情况，每N秒所有流都会丢失，而不管它们的发送速率如何）。
While it is not a goal to have perfect fairness in an environment with synchronized losses, it would be good to have moderately acceptable performance in this regime. This goal might argue against a response function with a constant number of round-trip times between congestion events. However, this is a question that could clearly use additional research and investigation. In addition, flows with different round-trip times would have different time durations for congestion epochs even in the model with a linear response function.
虽然目标不是在损失同步的环境中实现完美的公平性，但在这一制度中有适度可接受的表现是好的。这一目标可能会反对在拥挤事件之间具有恒定往返次数的响应函数。然而，这个问题显然需要更多的研究和调查。此外，即使在具有线性响应函数的模型中，具有不同往返时间的流量在拥堵时段也会有不同的持续时间。
The third column of Table 8, the Aggregate Window, gives the aggregate congestion window of two competing TCP connections, one with Linear HighSpeed TCP and one with Standard TCP, given the packet drop rate specified in the first column. From Table 8, a Linear HighSpeed TCP connection would receive fifteen times the bandwidth of a Standard TCP in an environment with a packet drop rate of 10^-5. This would occur when the two flows sharing a single pipe achieved an aggregate window of 4179 packets. Given a round-trip time of 100 ms and a packet size of 1500 bytes, this would occur with an available bandwidth for the two competing flows of 501 Mbps. Thus, because the Linear HighSpeed TCP is more aggressive than the HighSpeed TCP proposed above, it also is less fair when competing with Standard TCP in a high-bandwidth environment.
表8的第三列“聚合窗口”（Aggregate Window）给出了两个竞争TCP连接的聚合拥塞窗口，一个使用线性高速TCP，另一个使用标准TCP，给定了第一列中指定的丢包率。从表8可以看出，在丢包率为10^-5的环境中，线性高速TCP连接的带宽是标准TCP的15倍。当共享单个管道的两个流达到4179个数据包的聚合窗口时，就会发生这种情况。如果往返时间为100毫秒，数据包大小为1500字节，那么这将在两个竞争流的可用带宽为501 Mbps的情况下发生。因此，由于线性高速TCP比上面提出的高速TCP更具攻击性，因此在高带宽环境中与标准TCP竞争时也不太公平。
A range of metrics can be used for evaluating choices for congestion control parameters for HighSpeed TCP. My assumption in this section is that for a response function of the form w = c/p^d, for constant c and exponent d, the only response functions that would be considered are response functions with 1/2 <= d <= 1. The two ends of this spectrum are represented by current TCP, with d = 1/2, and by the linear response function described in Section 8 above, with d = 1. HighSpeed TCP lies somewhere in the middle of the spectrum, with d = 0.835.
一系列指标可用于评估高速TCP拥塞控制参数的选择。我在本节中的假设是，对于形式为w=c/p^d的响应函数，对于常数c和指数d，唯一需要考虑的响应函数是1/2<=d<=1的响应函数。该频谱的两端用当前TCP表示，d=1/2，用上面第8节中描述的线性响应函数表示，d=1。高速TCP位于频谱的中间，D＝0.835。
Response functions with exponents less than 1/2 can be eliminated from consideration because they would be even worse than standard TCP in accommodating connections with high congestion windows.
指数小于1/2的响应函数可以从考虑中删除，因为它们在适应具有高拥塞窗口的连接方面甚至比标准TCP更差。
Response functions with exponents greater than 1 can be eliminated from consideration because for these response functions, the number of round-trip times between loss events decreases as congestion decreases. For a response function of w = c/p^d, with one loss event or congestion event every 1/p packets, the number of round-trip times between loss events is w^((1/d)-1)/c^(1/d). Thus, for standard TCP the number of round-trip times between loss events is linear in w. In contrast, one attraction of the linear response function, as described in Section 8 above, is that it is scale-invariant, in terms of a fixed increase in the congestion window per acknowledgement, and a fixed number of round-trip times between loss events.
指数大于1的响应函数可以不考虑，因为对于这些响应函数，丢失事件之间的往返次数随着拥塞的减少而减少。对于w=c/p^d的响应函数，每1/p数据包有一个丢失事件或拥塞事件，丢失事件之间的往返次数为w^（（1/d）-1）/c^（1/d）。因此，对于标准TCP，丢失事件之间的往返次数在w中是线性的。相比之下，如上文第8节所述，线性响应函数的一个吸引力在于，就每个确认的拥塞窗口的固定增加和丢失事件之间的固定往返时间而言，它是尺度不变的。
However, for a response function with d > 1, the number of round-trip times between loss events would be proportional to w^((1/d)-1), for a negative exponent ((1/d)-1), setting smaller as w increases. This would seem undesirable.
然而，对于d>1的响应函数，损失事件之间的往返次数将与w^（（1/d）-1）成正比，对于负指数（（1/d）-1），随着w的增加，设置的值越小。这似乎是不可取的。
A TCP connection increases its sending rate by a(w) packets per round-trip time, and in a Drop-Tail environment, this is likely to result in a(w) dropped packets during a single loss event. One attraction of standard TCP is that it has a fixed increase per round-trip time of one packet, minimizing the number of packets that would be dropped in a Drop-Tail environment. For an environment with some form of Active Queue Management, and in particular for an environment that uses ECN, the number of packets dropped in a single congestion event would not be a problem. However, even in these environments, larger increases in the sending rate per round-trip time result in larger stresses on the ability of the queues in the router to absorb the fluctuations.
TCP连接将其发送速率每往返时间增加（w）个数据包，并且在丢弃尾部环境中，这可能会导致在单个丢失事件期间丢弃（w）个数据包。标准TCP的一个吸引人之处在于，它在一个数据包的每次往返时间中有一个固定的增长，从而最大限度地减少了在丢弃尾环境中丢弃的数据包数量。对于具有某种形式的主动队列管理的环境，特别是对于使用ECN的环境，在单个拥塞事件中丢弃的数据包数量不会是问题。然而，即使在这些环境中，每往返时间发送速率的较大增加也会对路由器中队列吸收波动的能力造成较大压力。
HighSpeed TCP plays a middle ground between the metrics of a moderate number of round-trip times between loss events, and a moderate increase in the sending rate per round-trip time. As shown in Appendix B, for a congestion window of 83,000 packets, HighSpeed TCP increases its sending rate by 70 packets per round-trip time, resulting in at most 70 packet drops when the buffer overflows in a Drop-Tail environment. This increased aggressiveness is the price paid by HighSpeed TCP for its increased scalability. A large number of packets dropped per congestion event could result in synchronized drops from multiple flows, with a possible loss of throughput as a result.
高速TCP在损失事件之间适度的往返次数和每次往返时间发送速率的适度增加之间起着中间作用。如附录B所示，对于83000个数据包的拥塞窗口，高速TCP将其发送速率每往返时间增加70个数据包，在丢包尾环境中，当缓冲区溢出时，最多会导致70个数据包丢包。这种增加的攻击性是高速TCP为其增加的可扩展性所付出的代价。每个拥塞事件丢弃的大量数据包可能导致来自多个流的同步丢弃，从而可能导致吞吐量损失。
Scalable TCP has an increase a(w) of 0.005 w packets per round-trip time. For a congestion window of 83,000 packets, this gives an increase of 415 packets per round-trip time, resulting in roughly 415 packet drops per congestion event in a Drop-Tail environment.
可伸缩TCP每往返时间增加0.005 w数据包。对于83000个分组的拥塞窗口，这使得每个往返时间增加415个分组，导致在丢弃尾环境中每个拥塞事件大约415个分组丢弃。
Thus, HighSpeed TCP and its variants place increased demands on queue management in routers, relative to Standard TCP. (This is rather similar to the increased demands on queue management that would result from using N parallel TCP connections instead of a single Standard TCP connection.)
因此，相对于标准TCP，高速TCP及其变体对路由器中的队列管理提出了更高的要求。（这与使用N个并行TCP连接而不是单个标准TCP连接导致的队列管理需求增加非常相似。）
A companion internet-draft on "Limited Slow-Start for TCP with Large Congestion Windows" [F02b] proposes a modification to TCP's slow-start procedure that can significantly improve the performance of TCP connections slow-starting up to large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link.
关于“具有大拥塞窗口的TCP的有限慢启动”的配套互联网草案[F02b]提出了对TCP慢启动程序的修改，该修改可显著提高TCP连接在大拥塞窗口慢启动时的性能。对于能够使用数千个（或上万个）MSS大小段的拥塞窗口的TCP连接（对于MSS，发送方的最大段大小），当前的慢启动过程可能导致在一次往返时间内将拥塞窗口增加数千个段。这种增加很容易导致在一次往返时间内丢弃数千个数据包。这通常会对TCP流本身产生反作用，并且对共享拥塞链路的其余流量也很困难。
[F02b] proposes Limited Slow-Start, limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. We have separated out Limited Slow-Start to a separate draft because it can be used both with Standard or with HighSpeed TCP.
[F02b]提出了有限的慢启动，限制在慢启动期间为一个数据窗口增加拥塞窗口的段数，以提高具有大拥塞窗口的TCP连接的性能。我们将有限的慢速启动分离为单独的草稿，因为它既可以用于标准TCP，也可以用于高速TCP。
Limited Slow-Start is illustrated in the NS simulator, for snapshots after May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib".
对于2002年5月1日之后的快照，NS模拟器在子目录“tcl/lib”中的测试“/test all tcpHighspeed tcp1A”和“/test all tcpHighspeed tcpHighspeed1”中说明了有限的慢启动。
In order for best-effort flows to safely start-up faster than slow-start, e.g., in future high-bandwidth networks, we believe that it would be necessary for the flow to have explicit feedback from the routers along the path. There are a number of proposals for this, ranging from a minimal proposal for an IP option that allows TCP SYN packets to collect information from routers along the path about the allowed initial sending rate [J02], to proposals with more power that require more fine-tuned and continuous feedback from routers. These
为了使尽力而为的流安全地以比慢速启动更快的速度启动，例如，在未来的高带宽网络中，我们认为流必须具有来自路径沿线路由器的明确反馈。对此有许多建议，从允许TCP SYN数据包沿着允许的初始发送速率[J02]的路径从路由器收集信息的IP选项的最低建议，到要求路由器提供更精细和持续反馈的更强大的建议。这些
proposals are all somewhat longer-term proposals than the HighSpeed TCP proposal in this document, requiring longer lead times and more coordination for deployment, and will be discussed in later documents.
与本文件中的高速TCP提案相比，提案都是一些较长期的提案，需要更长的交付周期和更多的部署协调，将在以后的文件中讨论。
Because the congestion window achieved by a HighSpeed TCP connection could be quite large, there is a possibility for the sender to send a large burst of packets in response to a single acknowledgement. This could happen, for example, when there is congestion or reordering on the reverse path, and the sender receives an acknowledgement acknowledging hundreds or thousands of new packets. Such a burst would also result if the application was idle for a short period of time less than a round-trip time, and then suddenly had lots of data available to send. In this case, it would be useful for the HighSpeed TCP connection to have some method for limiting bursts.
由于高速TCP连接实现的拥塞窗口可能相当大，因此发送方有可能发送大量数据包以响应单个确认。例如，当反向路径上出现拥塞或重新排序，并且发送方收到确认数百或数千个新数据包的确认时，可能会发生这种情况。如果应用程序的空闲时间短于往返时间，然后突然有大量数据可供发送，也会导致这种突发。在这种情况下，对于高速TCP连接来说，有一些限制突发的方法是很有用的。
In this document, we do not specify TCP mechanisms for reducing the short-term burstiness. One possible mechanism is to use some form of rate-based pacing, and another possibility is to use maxburst, which limits the number of packets that are sent in response to a single acknowledgement. We would caution, however, against a permanent reduction in the congestion window as a mechanism for limiting short-term bursts. Such a mechanism has been deployed in some TCP stacks, and our view would be that using permanent reductions of the congestion window to reduce transient bursts would be a bad idea [Fl03].
在本文档中，我们没有指定用于减少短期突发性的TCP机制。一种可能的机制是使用某种形式的基于速率的起搏，另一种可能是使用maxburst，它限制响应单个确认发送的数据包数量。不过，我们要提醒大家，不要将永久性减少拥堵窗口作为限制短期突发事件的机制。这种机制已经部署在一些TCP协议栈中，我们的观点是，使用拥塞窗口的永久性减少来减少瞬时突发将是一个坏主意[Fl03]。
The TCP header uses a 16-bit field to report the receive window size to the sender. Unmodified, this allows a window size of at most 2**16 = 65K bytes. With window scaling, the maximum window size is 2**30 = 1073M bytes [RFC 1323]. Given 1500-byte packets, this allows a window of up to 715,000 packets.
TCP标头使用16位字段向发送方报告接收窗口大小。未经修改，这允许窗口大小最多为2**16=65K字节。通过窗口缩放，最大窗口大小为2**30=1073M字节[RFC 1323]。给定1500字节的数据包，这允许最多715000个数据包的窗口。
One implementation issue that has been raised with HighSpeed TCP is that with congestion windows of 4MB or more, the handling of successive SACK packets after a packet is dropped becomes very time-consuming at the TCP sender [S03]. Tom Kelly's Scalable TCP includes a "SACK Fast Path" patch that addresses this problem.
高速TCP提出的一个实现问题是，当拥塞窗口大于等于4MB时，TCP发送方在丢包后处理连续SACK数据包变得非常耗时[S03]。Tom Kelly的可伸缩TCP包括一个解决此问题的“SACK快速路径”补丁。
The issues addressed in the Web100 project, the Net100 project, and related projects about the tuning necessary to achieve high bandwidth data rates with TCP apply to HighSpeed TCP as well [Net100, Web100].
Web100项目、Net100项目以及与使用TCP实现高带宽数据速率所需的调优相关的项目中解决的问题也适用于高速TCP[Net100，Web100]。
We do not claim that the HighSpeed TCP modification to TCP described in this paper is an optimal transport protocol for high-bandwidth environments. Based on our experiences with HighSpeed TCP in the NS simulator [NS], on simulation studies [SA03], and on experimental reports [ABLLS03,D02,CC03,F03], we believe that HighSpeed TCP improves the performance of TCP in high-bandwidth environments, and we are documenting it for the benefit of the IETF community. We encourage the use of HighSpeed TCP, and of its underlying response function, and we further encourage feedback about operational experiences with this or related modifications.
我们并不认为本文中描述的对TCP的高速TCP修改是高带宽环境下的最佳传输协议。根据我们在NS模拟器[NS]中使用高速TCP的经验、模拟研究[SA03]和实验报告[ABLLS03、D02、CC03、F03]，我们认为高速TCP提高了TCP在高带宽环境中的性能，我们正在为IETF社区的利益对其进行记录。我们鼓励使用高速TCP及其底层响应功能，并进一步鼓励反馈有关此修改或相关修改的操作经验。
We note that in environments typical of much of the current Internet, HighSpeed TCP behaves exactly as does Standard TCP today. This is the case any time the congestion window is less than 38 segments.
我们注意到，在当前大多数互联网的典型环境中，高速TCP的行为与当今的标准TCP完全相同。当拥塞窗口小于38段时，情况就是这样。
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 1 0.50
100 Mbps 833 6 0.35
1 Gbps 8333 26 0.22
10 Gbps 83333 70 0.10
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 1 0.50
100 Mbps 833 6 0.35
1 Gbps 8333 26 0.22
10 Gbps 83333 70 0.10
Table 9: Performance of a HighSpeed TCP connection
表9：高速TCP连接的性能
To help calibrate, Table 9 considers a TCP connection with 1500-byte packets, an RTT of 100 ms (including average queueing delay), and no competing traffic, and shows the average congestion window if that TCP connection had a pipe all to itself and fully used the link bandwidth, for a range of bandwidths for the pipe. This assumes that the TCP connection would use Table 12 in determining its increase and decrease parameters. The first column of Table 9 gives the bandwidth, and the second column gives the average congestion window w needed to utilize that bandwidth. The third column shows the increase a(w) in segments per RTT for window w. The fourth column shows the decrease b(w) for that window w (where the TCP sender decreases the congestion window from w to w(1-b(w)) segments after a loss event). When a loss occurs we note that the actual congestion window is likely to be greater than the average congestion window w in column 2, so the decrease parameter used could be slightly smaller than the one given in column 4 of Table 9.
为了帮助校准，表9考虑了具有1500字节数据包、100毫秒RTT（包括平均排队延迟）和无竞争流量的TCP连接，并显示了平均拥塞窗口（如果该TCP连接本身有一个管道，并充分利用了管道带宽范围内的链路带宽）。这假设TCP连接将使用表12确定其增加和减少参数。表9的第一列给出了带宽，第二列给出了利用该带宽所需的平均拥塞窗口w。第三列显示了窗口w每RTT增加的分段数a（w）。第四列显示窗口w的减少量b（w）（其中TCP发送方在丢失事件后将拥塞窗口从w减少到w（1-b（w））段）。当发生损失时，我们注意到实际拥塞窗口可能大于第2列中的平均拥塞窗口w，因此使用的减少参数可能略小于表9第4列中给出的参数。
Table 9 shows that a HighSpeed TCP over a 10 Mbps link behaves exactly the same as a Standard TCP connection, even in the absence of
表9显示了10 Mbps链路上的高速TCP与标准TCP连接的行为完全相同，即使在没有
competing traffic. One can think of the congestion window staying generally in the range of 55 to 110 segments, with the HighSpeed TCP behavior being exactly the same as the behavior of Standard TCP. (If the congestion window is ever 128 segments or more, then the HighSpeed TCP increases by two segments per RTT instead of by one, and uses a decrease parameter of 0.44 instead of 0.50.)
相互竞争的交通。人们可以认为拥塞窗口通常保持在55到110段的范围内，高速TCP行为与标准TCP行为完全相同。（如果拥塞窗口为128段或更多段，则高速TCP每RTT增加两段而不是一段，并使用减少参数0.44而不是0.50。）
Table 9 shows that for a HighSpeed TCP connection over a 100 Mbps link, with no competing traffic, HighSpeed TCP behaves roughly as aggressively as six parallel TCP connections, increasing its congestion window by roughly six segments per round-trip time, and with a decrease parameter of roughly 1/3 (corresponding to decreasing down to 2/3-rds of its old congestion window, rather than to half, in response to a loss event).
表9显示，对于100 Mbps链路上的高速TCP连接，在没有竞争流量的情况下，高速TCP的行为大致与六个并行TCP连接一样具有攻击性，每往返时间将其拥塞窗口增加大约六个段，减少参数约为1/3（对应于减少到原来拥塞窗口的2/3-rds，而不是一半，以响应丢失事件）。
For a Standard TCP connection in this environment, the congestion window could be thought of as generally varying in the range of 550 to 1100 segments, with an average packet drop rate of 2.2 * 10^-6 (corresponding to a bit error rate of 1.8 * 10^-10), or equivalently, roughly 55 seconds between congestion events. While a Standard TCP connection could sustain such a low packet drop rate in a carefully controlled environment with minimal competing traffic, we would contend that in an uncontrolled best-effort environment with even a small amount of competing traffic, the occasional congestion events from smaller competing flows could easily be sufficient to prevent a Standard TCP flow with no lower-speed bottlenecks from fully utilizing the available bandwidth of the underutilized 100 Mbps link.
对于该环境中的标准TCP连接，拥塞窗口可以被认为通常在550到1100段的范围内变化，平均分组丢弃率为2.2×10^-6（对应于1.8×10^-10的误比特率），或者等效地，拥塞事件之间大约55秒。虽然标准TCP连接可以在精心控制的环境中以最小的竞争流量维持如此低的丢包率，但我们认为，在不受控制的尽力而为的环境中，即使竞争流量很小，来自较小竞争流的偶发拥塞事件很容易足以阻止没有低速瓶颈的标准TCP流充分利用未充分利用的100 Mbps链路的可用带宽。
That is, we would contend that in the environment of 100 Mbps links with a significant amount of available bandwidth, Standard TCP would sometimes be unable to fully utilize the link bandwidth, and that HighSpeed TCP would be an improvement in this regard. We would further contend that in this environment, the behavior of HighSpeed TCP is sufficiently close to that of Standard TCP that HighSpeed TCP would be safe to deploy in the current Internet. We note that HighSpeed TCP can only use high congestion windows if allowed by the receiver's advertised window size. As a result, even if HighSpeed TCP was ubiquitously deployed in the Internet, the impact would be limited to those TCP connections with an advertised window from the receiver of 118 MSS or larger.
也就是说，我们认为，在具有大量可用带宽的100 Mbps链路的环境中，标准TCP有时无法充分利用链路带宽，高速TCP将是这方面的改进。我们将进一步主张，在这种环境中，高速TCP的行为与标准TCP的行为非常接近，因此高速TCP可以安全地部署在当前的Internet上。我们注意到，高速TCP只能在接收方公布的窗口大小允许的情况下使用高拥塞窗口。因此，即使在互联网上普遍部署了高速TCP，其影响也仅限于那些从118 ms或更大的接收器发出广告窗口的TCP连接。
We do not believe that the deployment of HighSpeed TCP would serve as a block to the possible deployment of alternate experimental protocols for high-speed congestion control, such as Scalable TCP, XCP [KHR02], or FAST TCP [JWL03]. In particular, we don't expect HighSpeed TCP to interact any more poorly with alternative experimental proposals than would the N parallel TCP connections commonly used today in the absence of HighSpeed TCP.
我们不认为高速TCP的部署会阻碍高速拥塞控制替代实验协议的部署，如可伸缩TCP、XCP[KHR02]或快速TCP[JWL03]。特别是，我们不希望高速TCP与其他实验方案的交互比目前在没有高速TCP的情况下常用的N个并行TCP连接更差。
We believe that Scalable TCP and HighSpeed TCP have sufficiently similar response functions that they could easily coexist in the Internet. However, we have not investigated Scalable TCP sufficiently to be able to claim, in this document, that Scalable TCP is safe for a widespread deployment in the current Internet.
我们相信，可伸缩TCP和高速TCP具有足够相似的响应功能，它们可以很容易地在Internet上共存。然而，我们还没有对可伸缩TCP进行充分的研究，因此在本文档中，我们无法声称可伸缩TCP在当前Internet上广泛部署是安全的。
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 0.4 0.125
100 Mbps 833 4.1 0.125
1 Gbps 8333 41.6 0.125
10 Gbps 83333 416.5 0.125
Bandwidth Avg Cwnd w (pkts) Increase a(w) Decrease b(w)
--------- ----------------- ------------- -------------
1.5 Mbps 12.5 1 0.50
10 Mbps 83 0.4 0.125
100 Mbps 833 4.1 0.125
1 Gbps 8333 41.6 0.125
10 Gbps 83333 416.5 0.125
Table 10: Performance of a Scalable TCP connection.
表10：可扩展TCP连接的性能。
Table 10 shows the performance of a Scalable TCP connection with 1500-byte packets, an RTT of 100 ms (including average queueing delay), and no competing traffic. The TCP connection is assumed to use delayed acknowledgements. The first column of Table 10 gives the bandwidth, the second column gives the average congestion window needed to utilize that bandwidth, and the third and fourth columns give the increase and decrease parameters.
表10显示了具有1500字节数据包、100毫秒RTT（包括平均排队延迟）和无竞争流量的可扩展TCP连接的性能。假定TCP连接使用延迟确认。表10的第一列给出了带宽，第二列给出了利用该带宽所需的平均拥塞窗口，第三列和第四列给出了增加和减少参数。
Note that even in an environment with a 10 Mbps link, Scalable TCP's behavior is considerably different from that of Standard TCP. The increase parameter is smaller than that of Standard TCP, and the decrease is smaller also, 1/8-th instead of 1/2. That is, for 10 Mbps links, Scalable TCP increases less aggressively than Standard TCP or HighSpeed TCP, but decreases less aggressively as well.
请注意，即使在具有10 Mbps链路的环境中，可伸缩TCP的行为也与标准TCP的行为大不相同。增加的参数比标准TCP小，减少的也小，由1/2减少到1/8。也就是说，对于10 Mbps链路，可伸缩TCP的增长不如标准TCP或高速TCP，但其下降也不如标准TCP或高速TCP。
In an environment with a 100 Mbps link, Scalable TCP has an increase parameter of roughly four segments per round-trip time, with the same decrease parameter of 1/8-th. A comparison of Tables 9 and 10 shows that for this scenario of 100 Mbps links, HighSpeed TCP increases more aggressively than Scalable TCP.
在具有100 Mbps链路的环境中，可伸缩TCP的增加参数约为每往返时间四段，减少参数为1/8。表9和表10的比较表明，对于100 Mbps链路的这种情况，高速TCP的增长比可伸缩TCP更为迅猛。
Next we consider the relative fairness between Standard TCP, HighSpeed TCP and Scalable TCP. The relative fairness between HighSpeed TCP and Standard TCP was shown in Table 5 earlier in this document, and the relative fairness between Scalable TCP and Standard TCP was shown in Table 8. Following the approach in Section 6, for a given packet drop rate p, for p < 10^-3, we can estimate the relative fairness between Scalable and HighSpeed TCP as W_Scalable/W_HighSpeed. This relative fairness is shown in Table 11 below. The bandwidth in the last column of Table 11 is the aggregate
接下来，我们考虑标准TCP、高速TCP和可扩展TCP之间的相对公平性。本文档前面的表5显示了高速TCP和标准TCP之间的相对公平性，表8显示了可扩展TCP和标准TCP之间的相对公平性。按照第6节中的方法，对于给定的丢包率p，对于p<10^-3，我们可以将可伸缩和高速TCP之间的相对公平性估计为W_可伸缩/W_高速。这种相对公平性见下表11。表11最后一列中的带宽是总带宽
bandwidth of the two competing flows given 100 ms round-trip times and 1500-byte packets.
给定100毫秒往返时间和1500字节数据包的两个竞争流的带宽。
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 1.4 643 77.1 Mbps
10^-5 2.1 5595 671.4 Mbps
10^-6 3.1 50279 6.0 Gbps
10^-7 4.5 463981 55.7 Gbps
Packet Drop Rate P Fairness Aggregate Window Bandwidth
------------------ -------- ---------------- ---------
10^-2 1.0 24 2.8 Mbps
10^-3 1.0 76 9.1 Mbps
10^-4 1.4 643 77.1 Mbps
10^-5 2.1 5595 671.4 Mbps
10^-6 3.1 50279 6.0 Gbps
10^-7 4.5 463981 55.7 Gbps
Table 11: Relative Fairness between the Scalable and HighSpeed Response Functions.
表11：可扩展和高速响应功能之间的相对公平性。
The second row of Table 11 shows that for a Scalable TCP and a HighSpeed TCP flow competing in an environment with 100 ms RTTs and a 10 Mbps pipe, the two flows would receive essentially the same bandwidth. The next row shows that for a Scalable TCP and a HighSpeed TCP flow competing in an environment with 100 ms RTTs and a 100 Mbps pipe, the Scalable TCP flow would receive roughly 50% more bandwidth than would HighSpeed TCP. Table 11 shows the relative fairness in higher-bandwidth environments as well. This relative fairness seems sufficient that there should be no problems with Scalable TCP and HighSpeed TCP coexisting in the same environment as Experimental variants of TCP.
表11的第二行显示，对于在具有100 ms RTT和10 Mbps管道的环境中竞争的可伸缩TCP和高速TCP流，这两个流将接收基本相同的带宽。下一行显示，对于在具有100 ms RTT和100 Mbps管道的环境中竞争的可伸缩TCP和高速TCP流，可伸缩TCP流将比高速TCP接收大约50%的带宽。表11还显示了更高带宽环境中的相对公平性。这种相对的公平性似乎足够了，可伸缩TCP和高速TCP在与TCP的实验变体相同的环境中共存时应该没有问题。
We note that one question that requires more investigation with Scalable TCP is that of convergence to fairness in environments with Drop-Tail queue management.
我们注意到，需要对可伸缩TCP进行更多研究的一个问题是，在具有落尾队列管理的环境中，如何收敛到公平性。
HighSpeed TCP has been separately investigated in simulations by Sylvia Ratnasamy and by Evandro de Souza [SA03]. The simulations in [SA03] verify the fairness properties of HighSpeed TCP when sharing a link with Standard TCP.
Sylvia Ratnasamy和Evandro de Souza[SA03]分别对高速TCP进行了模拟研究。[SA03]中的仿真验证了高速TCP在与标准TCP共享链路时的公平性。
These simulations explore the relative fairness of HighSpeed TCP flows when competing with Standard TCP. The simulation environment includes background forward and reverse-path TCP traffic limited by the TCP receive window, along with a small amount of forward and reverse-path traffic from the web traffic generator. Most of the simulations so far explore performance on a simple dumbbell topology with a 1 Gbps link with a propagation delay of 50 ms. Simulations have been run with Adaptive RED and with DropTail queue management.
这些模拟探索了高速TCP流在与标准TCP竞争时的相对公平性。模拟环境包括受TCP接收窗口限制的后台正向和反向路径TCP流量，以及来自web流量生成器的少量正向和反向路径流量。到目前为止，大多数模拟都探索了具有1 Gbps链路、传播延迟为50 ms的简单哑铃拓扑上的性能。模拟已使用自适应RED和DropTail队列管理运行。
The simulations in [SA03] explore performance with a varying number of competing flows, with the competing traffic being all standard TCP; all HighSpeed TCP; or a mix of standard and HighSpeed TCP. For the simulations in [SA03] with RED queue management, the relative fairness between standard and HighSpeed TCP is consistent with the relative fairness predicted in Table 5. For the simulations with Drop Tail queues, the relative fairness is more skewed, with the HighSpeed TCP flows receiving an even larger share of the link bandwidth. This is not surprising; with Active Queue Management at the congested link, the fraction of packet drops received by each flow should be roughly proportional to that flow's share of the link bandwidth, while this property no longer holds with Drop Tail queue management. We also note that relative fairness in simulations with Drop Tail queue management can sometimes depend on small details of the simulation scenario, and that Drop Tail simulations need special care to avoid phase effects [F92].
[SA03]中的模拟探索了不同数量的竞争流的性能，竞争流量均为标准TCP；全高速TCP；或者是标准和高速TCP的混合。对于[SA03]中使用红色队列管理的模拟，标准和高速TCP之间的相对公平性与表5中预测的相对公平性一致。对于具有落尾队列的模拟，相对公平性更为扭曲，高速TCP流接收到更大份额的链路带宽。这并不奇怪；在拥塞链路上使用主动队列管理时，每个流接收到的数据包丢弃的分数应大致与该流在链路带宽中的份额成比例，而此属性在丢弃尾队列管理中不再适用。我们还注意到，采用落尾队列管理的模拟中的相对公平性有时可能取决于模拟场景的小细节，并且落尾模拟需要特别注意以避免相位效应[F92]。
[SA03] explores the bandwidth `stolen' by HighSpeed TCP from standard TCP by exploring the fraction of the link bandwidth N standard TCP flows receive when competing against N other standard TCP flows, and comparing this to the fraction of the link bandwidth the N standard TCP flows receive when competing against N HighSpeed TCP flows. For the 1 Gbps simulation scenarios dominated by long-lived traffic, a small number of standard TCP flows are able to achieve high link utilization, and the HighSpeed TCP flows can be viewed as stealing bandwidth from the competing standard TCP flows, as predicted in Section 6 on the Fairness Implications of the HighSpeed Response Function. However, [SA03] shows that when even a small fraction of the link bandwidth is used by more bursty, short TCP connections, the standard TCP flows are unable to achieve high link utilization, and the HighSpeed TCP flows in this case are not `stealing' bandwidth from the standard TCP flows, but instead are using bandwidth that otherwise would not be utilized.
[SA03]通过研究N个标准TCP流与N个其他标准TCP流竞争时收到的链路带宽的分数，并将其与N个标准TCP流与N个高速TCP流竞争时收到的链路带宽分数进行比较，探索高速TCP从标准TCP“窃取”的带宽。对于以长寿命流量为主的1 Gbps模拟场景，少量标准TCP流能够实现高链路利用率，并且高速TCP流可以被视为从竞争标准TCP流中窃取带宽，如第6节“高速响应函数的公平性影响”中预测的。然而，[SA03]表明，即使链路带宽的一小部分被更多的突发性短TCP连接使用，标准TCP流也无法实现高链路利用率，在这种情况下，高速TCP流并不是从标准TCP流“窃取”带宽，相反，他们使用的带宽本来是无法利用的。
The conclusions of [SA03] are that "HighSpeed TCP behaved as forseen by its response function, and appears to be a real and viable option for use on high-speed wide area TCP connections."
[SA03]的结论是“高速TCP通过其响应功能表现为forseen，并且似乎是用于高速广域TCP连接的真实可行的选择。”
Future work that could be explored in more detail includes convergence times after new flows start-up; recovery time after a transient outage; the response to sudden severe congestion, and investigations of the potential for oscillations. We invite contributions from others in this work.
可以更详细地探讨的未来工作包括新流量启动后的收敛时间；短暂停机后的恢复时间；对突发严重拥堵的响应，以及对振荡可能性的调查。我们邀请其他人在这项工作中作出贡献。
Our assumption is that HighSpeed TCP will be used with the TCP SACK option, and also with the increased Initial Window of three or four segments, as allowed by [RFC3390]. For paths that have substantial reordering, TCP performance would be greatly improved by some of the mechanisms still in the research stages for robust performance in the presence of reordered packets.
我们的假设是，高速TCP将与TCP SACK选项一起使用，并且根据[RFC3390]的允许，增加三段或四段的初始窗口。对于具有大量重排序的路径，TCP性能将通过一些仍处于研究阶段的机制得到极大提高，以在存在重排序数据包的情况下获得鲁棒性能。
Our view is that HighSpeed TCP is largely orthogonal to proposals for higher PMTU (Path MTU) values [M02]. Unlike changes to the PMTU, HighSpeed TCP does not require any changes in the network or at the TCP receiver, and works well in the current Internet. Our assumption is that HighSpeed TCP would be useful even with larger values for the PMTU. Unlike the current congestion window, the PMTU gives no information about the bandwidth-delay product available to that particular flow.
我们的观点是，高速TCP在很大程度上与更高PMTU（路径MTU）值的建议正交[M02]。与对PMTU的更改不同，高速TCP不需要对网络或TCP接收器进行任何更改，并且在当前的Internet上运行良好。我们的假设是，即使PMTU的值较大，高速TCP也会很有用。与当前拥塞窗口不同，PMTU不提供有关该特定流可用带宽延迟乘积的信息。
A related approach is that of a virtual MTU, where the actual MTU of the path might be limited [VMSS,S02]. The virtual MTU approach has not been fully investigated, and we do not explore the virtual MTU approach further in this document.
一种相关的方法是虚拟MTU，其中路径的实际MTU可能受到限制[VMS，S02]。虚拟MTU方法尚未得到充分研究，本文档中我们不进一步探讨虚拟MTU方法。
This document has proposed HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. We have explored this proposal in simulations, and others have explored HighSpeed TCP with experiments, and we believe HighSpeed TCP to be safe to deploy on the current Internet. We would welcome additional analysis, simulations, and particularly, experimentation. More information on simulations and experiments is available from the HighSpeed TCP Web Page [HSTCP]. There are several independent implementations of HighSpeed TCP [D02,F03] and of Scalable TCP [K03] for further investigation.
本文档提出了高速TCP，这是对TCP拥塞控制机制的一种修改，用于具有大拥塞窗口的TCP连接。我们已经在模拟中探索了这一建议，其他人也通过实验探索了高速TCP，我们相信高速TCP在当前互联网上部署是安全的。我们欢迎更多的分析、模拟，特别是实验。有关模拟和实验的更多信息，请访问高速TCP网页[HSTCP]。高速TCP[D02，F03]和可扩展TCP[K03]有几种独立的实现方式供进一步研究。
The HighSpeed TCP proposal is from joint work with Sylvia Ratnasamy and Scott Shenker (and was initiated by Scott Shenker). Additional investigations of HighSpeed TCP were joint work with Evandro de Souza and Deb Agarwal. We thank Tom Dunigan for the implementation in the Linux 2.4.16 Web100 kernel, and for resulting experimentation with HighSpeed TCP. We are grateful to the End-to-End Research Group, the members of the Transport Area Working Group, and to members of the IPAM program in Large Scale Communication Networks for feedback. We thank Glenn Vinnicombe for framing the Linear response function in the parameters of HighSpeed TCP. We are also grateful for
高速TCP提案来自与Sylvia Ratnasamy和Scott Shenker的联合工作（由Scott Shenker发起）。与Evandro de Souza和Deb Agarwal联合开展了高速TCP的其他研究。我们感谢Tom Dunigan在Linux 2.4.16 Web100内核中的实现，以及由此产生的高速TCP实验。我们感谢端到端研究小组、交通领域工作组成员以及大规模通信网络IPAM项目成员的反馈。我们感谢Glenn Vinnicombe在高速TCP参数中构建线性响应函数。我们还感谢
contributions and feedback from the following individuals: Les Cottrell, Mitchell Erblich, Jeffrey Hsu, Tom Kelly, Chuck Jackson, Matt Mathis, Jitendra Padhye, Andrew Reiter, Stanislav Shalunov, Alex Solan, Paul Sutter, Brian Tierney, Joe Touch.
以下个人的贡献和反馈：Les Cottrell、Mitchell Erblich、Jeffrey Hsu、Tom Kelly、Chuck Jackson、Matt Mathis、Jitendra Padhye、Andrew Reiter、Stanislav Shalunov、Alex Solan、Paul Sutter、Brian Tierney、Joe Touch。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[ABLLS03] A. Antony, J. Blom, C. de Laat, J. Lee, and W. Sjouw, "Microscopic Examination of TCP Flows over Transatlantic Links", iGrid2002 special issue, Future Generation Computer Systems, volume 19 issue 6 (2003), URL "http://www.science.uva.nl/~delaat/techrep-2003-2- tcp.pdf".
[ABLLS03]A.Antony，J.Blom，C.de Laat，J.Lee和W.Sjouw，“跨大西洋链路TCP流的微观检验”，iGrid2002特刊，未来一代计算机系统，第19卷，第6期（2003），URL“http://www.science.uva.nl/~delaat/techrep-2003-2-tcp.pdf”。
[BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, "Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms", SIGCOMM 2001, August 2001.
[BBFS01]Deepak Bansal、Hari Balakrishnan、Sally Floyd和Scott Shenker，“慢响应拥塞控制算法的动态行为”，SIGCOMM 2001，2001年8月。
[CC03] Fabrizio Coccetti and Les Cottrell, "TCP Stack Measurements on Lightly Loaded Testbeds", 2003. URL "http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/".
[CC03]Fabrizio Coccetti和Les Cottrell，“轻载试验台上的TCP堆栈测量”，2003年。URL“http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/".
[CJ89] D. Chiu and R. Jain, "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks", Computer Networks and ISDN Systems, Vol. 17, pp. 1-14, 1989.
[CJ89]D.Chiu和R.Jain，“计算机网络中避免拥塞的增减算法分析”，计算机网络和ISDN系统，第17卷，第1-14页，1989年。
[CO98] J. Crowcroft and P. Oechslin, "Differentiated End-to-end Services using a Weighted Proportional Fair Share TCP", Computer Communication Review, 28(3):53--69, 1998.
[CO98]J.Crowcroft和P.Oechslin，“使用加权比例公平共享TCP的端到端服务差异化”，计算机通信评论，28（3）：53-691998。
[D02] Tom Dunigan, "Floyd's TCP slow-start and AIMD mods", URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html".
[D02]Tom Dunigan，“Floyd的TCP慢启动和AIMD mods”，URL“http://www.csm.ornl.gov/~dunigan/net100/floyd.html”。
[F03] Gareth Fairey, "High-Speed TCP", 2003. URL "http://www.hep.man.ac.uk/u/garethf/hstcp/".
[F03]Gareth Fairey，“高速TCP”，2003年。URL“http://www.hep.man.ac.uk/u/garethf/hstcp/".
[F92] S. Floyd and V. Jacobson, "On Traffic Phase Effects in Packet-Switched Gateways, Internetworking: Research and Experience", V.3 N.3, September 1992, p.115-156. URL "http://www.icir.org/floyd/papers.html".
[F92]S.Floyd和V.Jacobson，“关于分组交换网关中的流量相位效应，互联网：研究与经验”，第3卷第3期，1992年9月，第115-156页。URL“http://www.icir.org/floyd/papers.html".
[Fl03] Sally Floyd, "Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard", Email to the tsvwg mailing list, May 14, 2003.
[Fl03]Sally Floyd，“回复：[Tsvwg]将NewReno（RFC 2582）纳入拟议标准”，电邮至Tsvwg邮件列表，2003年5月14日。
URLs "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html" and "http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04087.html".
“网址”http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html“和”http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04087.html".
[FF98] Floyd, S., and Fall, K., "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF98]Floyd，S.，和Fall，K.，“促进互联网中端到端拥塞控制的使用”，IEEE/ACM网络交易，1999年8月。
[FRS02] Sally Floyd, Sylvia Ratnasamy, and Scott Shenker, "Modifying TCP's Congestion Control for High Speeds", May 2002. URL "http://www.icir.org/floyd/notes.html".
[FRS02]Sally Floyd、Sylvia Ratnasamy和Scott Shenker，“修改TCP的高速拥塞控制”，2002年5月。URL“http://www.icir.org/floyd/notes.html".
[GRK99] Panos Gevros, Fulvio Risso and Peter Kirstein, "Analysis of a Method for Differential TCP Service". In Proceedings of the IEEE GLOBECOM'99, Symposium on Global Internet , December 1999, Rio de Janeiro, Brazil.
[GRK99]Panos Gevros、Fulvio Risso和Peter Kirstein，“差分TCP服务方法分析”。1999年12月，巴西里约热内卢，IEEE GLOBECOM'99会议记录，全球互联网研讨会。
[GV02] S. Gorinsky and H. Vin, "Extended Analysis of Binary Adjustment Algorithms", Technical Report TR2002-39, Department of Computer Sciences, The University of Texas at Austin, August 2002. URL "http://www.cs.utexas.edu/users/gorinsky/pubs.html".
[GV02] S. Gorinsky和H. Vin，《二进制调整算法的扩展分析》，得克萨斯大学奥斯汀分校计算机科学系技术报告Tr2002—39，2002年8月。URL“http://www.cs.utexas.edu/users/gorinsky/pubs.html".
[HSTCP] HighSpeed TCP Web Page, URL "http://www.icir.org/floyd/hstcp.html".
[HSTCP]高速TCP网页，URL“http://www.icir.org/floyd/hstcp.html".
[J02] Amit Jain and Sally Floyd, "Quick-Start for TCP and IP", Work in Progress, 2002.
[J02]Amit Jain和Sally Floyd，“TCP和IP的快速启动”，正在进行的工作，2002年。
[JWL03] Cheng Jin, David X. Wei and Steven H. Low, "FAST TCP for High-speed Long-distance Networks", Work in Progress, June 2003.
[JWL03]程进，David X.Wei和Steven H.Low，“高速远程网络的快速TCP”，正在进行的工作，2003年6月。
[K03] Tom Kelly, "Scalable TCP: Improving Performance in HighSpeed Wide Area Networks", February 2003. URL "http://www-lce.eng.cam.ac.uk/~ctk21/scalable/".
[K03]Tom Kelly，“可扩展TCP：提高高速广域网的性能”，2003年2月。URL“http://www-lce.eng.cam.ac.uk/~ctk21/scalable/”。
[KHR02] Dina Katabi, Mark Handley, and Charlie Rohrs, "Congestion Control for High Bandwidth-Delay Product Networks", SIGCOMM 2002.
[KHR02]Dina Katabi，Mark Handley和Charlie Rohrs，“高带宽延迟产品网络的拥塞控制”，SIGCOM2002。
[M02] Matt Mathis, "Raising the Internet MTU", Web Page, URL "http://www.psc.edu/~mathis/MTU/".
[M02]Matt Mathis，“提升互联网MTU”，网页，网址“http://www.psc.edu/~mathis/MTU/”。
[Net100] The DOE/MICS Net100 project. URL "http://www.csm.ornl.gov/~dunigan/net100/".
[Net100]DOE/MICS Net100项目。URL“http://www.csm.ornl.gov/~dunigan/net100/”。
[NS] The NS Simulator, "http://www.isi.edu/nsnam/ns/".
[NS]NS模拟器，”http://www.isi.edu/nsnam/ns/".
[RFC 1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC 1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC3390] Allman, M., Floyd, S. and C., Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.和C.，帕特里奇，“增加TCP的初始窗口”，RFC3902002年10月。
[RFC3448] Handley, M., Padhye, J., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Padhye，J.，Floyd，S.和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[SA03] Souza, E. and D.A., Agarwal, "A HighSpeed TCP Study: Characteristics and Deployment Issues", LBNL Technical Report LBNL-53215. URL "http://www.icir.org/floyd/hstcp.html".
[SA03]Souza，E.和D.A.，Agarwal，“高速TCP研究：特征和部署问题”，LBNL技术报告LBNL-53215。URL“http://www.icir.org/floyd/hstcp.html".
[S02] Stanislav Shalunov, "TCP Armonk", Work in Progress, 2002, URL "http://www.internet2.edu/~shalunov/tcpar/".
[S02]Stanislav Shalunov，“TCP Armonk”，在建工程，2002年，网址“http://www.internet2.edu/~shalunov/tcpar/”。
[S03] Alex Solan, private communication, 2003.
[S03]亚历克斯·索兰，《私人通信》，2003年。
[VMSS] "Web100 at ORNL", Web Page, "http://www.csm.ornl.gov/~dunigan/netperf/web100.html".
[VMS]“ORNL的Web100”，网页http://www.csm.ornl.gov/~dunigan/netperf/web100.html”。
[Web100] The Web100 project. URL "http://www.web100.org/".
[Web100]Web100项目。URL“http://www.web100.org/".
This proposal makes no changes to the underlying security of TCP.
此建议不改变TCP的底层安全性。
There are no IANA considerations regarding this document.
关于本文件，没有IANA考虑事项。
A. TCP's Loss Event Rate in Steady-State
A.TCP在稳定状态下的丢失事件率
This section gives the number of round-trip times between congestion events for a TCP flow with D-byte packets, for D=1500, as a function of the connection's average throughput B in bps. To achieve this average throughput B, a TCP connection with round-trip time R in seconds requires an average congestion window w of BR/(8D) segments.
本节给出了具有D字节数据包的TCP流（对于D=1500）拥塞事件之间的往返次数，作为连接平均吞吐量B（bps）的函数。为了达到平均吞吐量B，以秒为单位的往返时间为R的TCP连接需要平均拥塞窗口w的BR/（8D）段。
In steady-state, TCP's average congestion window w is roughly 1.2/sqrt(p) segments. This is equivalent to a lost event at most once every 1/p packets, or at most once every 1/(pw) = w/1.5 round-trip times. Substituting for w, this is a loss event at most every (BR)/12D)round-trip times.
在稳态下，TCP的平均拥塞窗口w约为1.2/sqrt（p）段。这相当于每1/p数据包最多发生一次丢失事件，或每1/（pw）=w/1.5往返时间最多发生一次丢失事件。代替w，最多每（BR）/12D往返一次，这是一个损失事件。
An an example, for R = 0.1 seconds and D = 1500 bytes, this gives B/180000 round-trip times between loss events.
例如，对于R=0.1秒和D=1500字节，这将给出丢失事件之间的B/180000往返时间。
B. A table for a(w) and b(w).
B.A（w）和B（w）的表格。
This section gives a table for the increase and decrease parameters a(w) and b(w) for HighSpeed TCP, for the default values of Low_Window = 38, High_Window = 83000, High_P = 10^-7, and High_Decrease = 0.1.
本节给出了高速TCP的增加和减少参数a（w）和b（w）的表格，默认值为Low_Window=38、High_Window=83000、High_P=10^-7和High_decrease=0.1。
w a(w) b(w)
---- ---- ----
38 1 0.50
118 2 0.44
221 3 0.41
347 4 0.38
495 5 0.37
663 6 0.35
851 7 0.34
1058 8 0.33
1284 9 0.32
1529 10 0.31
1793 11 0.30
2076 12 0.29
2378 13 0.28
2699 14 0.28
3039 15 0.27
3399 16 0.27
3778 17 0.26
4177 18 0.26
4596 19 0.25
5036 20 0.25
5497 21 0.24
5979 22 0.24
6483 23 0.23
7009 24 0.23
7558 25 0.22
8130 26 0.22
8726 27 0.22
9346 28 0.21
9991 29 0.21
10661 30 0.21
11358 31 0.20
12082 32 0.20
12834 33 0.20
13614 34 0.19
14424 35 0.19
15265 36 0.19
16137 37 0.19
17042 38 0.18
17981 39 0.18
18955 40 0.18
w a(w) b(w)
---- ---- ----
38 1 0.50
118 2 0.44
221 3 0.41
347 4 0.38
495 5 0.37
663 6 0.35
851 7 0.34
1058 8 0.33
1284 9 0.32
1529 10 0.31
1793 11 0.30
2076 12 0.29
2378 13 0.28
2699 14 0.28
3039 15 0.27
3399 16 0.27
3778 17 0.26
4177 18 0.26
4596 19 0.25
5036 20 0.25
5497 21 0.24
5979 22 0.24
6483 23 0.23
7009 24 0.23
7558 25 0.22
8130 26 0.22
8726 27 0.22
9346 28 0.21
9991 29 0.21
10661 30 0.21
11358 31 0.20
12082 32 0.20
12834 33 0.20
13614 34 0.19
14424 35 0.19
15265 36 0.19
16137 37 0.19
17042 38 0.18
17981 39 0.18
18955 40 0.18
19965 41 0.17 21013 42 0.17 22101 43 0.17 23230 44 0.17 24402 45 0.16 25618 46 0.16 26881 47 0.16 28193 48 0.16 29557 49 0.15 30975 50 0.15 32450 51 0.15 33986 52 0.15 35586 53 0.14 37253 54 0.14 38992 55 0.14 40808 56 0.14 42707 57 0.13 44694 58 0.13 46776 59 0.13 48961 60 0.13 51258 61 0.13 53677 62 0.12 56230 63 0.12 58932 64 0.12 61799 65 0.12 64851 66 0.11 68113 67 0.11 71617 68 0.11 75401 69 0.10 79517 70 0.10 84035 71 0.10 89053 72 0.10 94717 73 0.09
19965 41 0.17 21013 42 0.17 22101 43 0.17 23230 44 0.17 24402 45 0.16 25618 46 0.16 26881 47 0.16 28193 48 0.16 29557 49 0.15 30975 50 0.15 32450 51 0.15 33986 52 0.15 35586 53 0.14 37253 54 0.14 38992 55 0.14 40808 56 0.14 42707 57 0.13 44694 58 0.13 46776 59 0.13 48961 60 0.13 51258 61 0.13 53677 62 0.12 56230 63 0.12 58932 64 0.12 61799 65 0.12 64851 66 0.11 68113 67 0.11 71617 68 0.11 75401 69 0.10 79517 70 0.10 84035 71 0.10 89053 72 0.10 94717 73 0.09
Table 12: Parameters for HighSpeed TCP.
表12：高速TCP的参数。
This table was computed with the following Perl program:
此表是使用以下Perl程序计算的：
$top = 100000;
$num = 38;
if ($num == 38) {
print " w a(w) b(w)\n";
print " ---- ---- ----\n";
print " 38 1 0.50\n";
$oldb = 0.50;
$olda = 1;
}
while ($num < $top) {
$bw = (0.1 -0.5)*(log($num)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($num**2*2.0*$bw) / ((2.0-$bw)*$num**1.2*12.8);
if ($aw > $olda + 1) {
printf "%6d %5d %3.2f0, $num, $aw, $bw;
$olda = $aw;
}
$num ++;
}
$top = 100000;
$num = 38;
if ($num == 38) {
print " w a(w) b(w)\n";
print " ---- ---- ----\n";
print " 38 1 0.50\n";
$oldb = 0.50;
$olda = 1;
}
while ($num < $top) {
$bw = (0.1 -0.5)*(log($num)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($num**2*2.0*$bw) / ((2.0-$bw)*$num**1.2*12.8);
if ($aw > $olda + 1) {
printf "%6d %5d %3.2f0, $num, $aw, $bw;
$olda = $aw;
}
$num ++;
}
Table 13: Perl Program for computing parameters for HighSpeed TCP.
表13：用于计算高速TCP参数的Perl程序。
C. Exploring the time to converge to fairness.
C.探索实现公平的时间。
This section gives the Perl program used to compute the congestion window growth during congestion avoidance.
本节给出了用于计算拥塞避免期间拥塞窗口增长的Perl程序。
$top = 2001;
$hswin = 1;
$regwin = 1;
$rtt = 1;
$lastrtt = 0;
$rttstep = 100;
if ($hswin == 1) {
print " RTT HS_Window Standard_TCP_Window0;
print " --- --------- -------------------0;
}
while ($rtt < $top) {
$bw = (0.1 -0.5)*(log($hswin)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($hswin**2*2.0*$bw) / ((2.0-$bw)*$hswin**1.2*12.8);
if ($aw < 1) {
$aw = 1;
}
if ($rtt >= $lastrtt + $rttstep) {
printf "%5d %9d %10d0, $rtt, $hswin, $regwin;
$lastrtt = $rtt;
}
$hswin += $aw;
$regwin += 1;
$rtt ++;
}
$top = 2001;
$hswin = 1;
$regwin = 1;
$rtt = 1;
$lastrtt = 0;
$rttstep = 100;
if ($hswin == 1) {
print " RTT HS_Window Standard_TCP_Window0;
print " --- --------- -------------------0;
}
while ($rtt < $top) {
$bw = (0.1 -0.5)*(log($hswin)-log(38))/(log(83000)-log(38))+0.5;
$aw = ($hswin**2*2.0*$bw) / ((2.0-$bw)*$hswin**1.2*12.8);
if ($aw < 1) {
$aw = 1;
}
if ($rtt >= $lastrtt + $rttstep) {
printf "%5d %9d %10d0, $rtt, $hswin, $regwin;
$lastrtt = $rtt;
}
$hswin += $aw;
$regwin += 1;
$rtt ++;
}
Table 14: Perl Program for computing the window in congestion avoidance.
表14：用于计算拥塞避免窗口的Perl程序。
Author's Address
作者地址
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSI互联网研究中心）
Phone: +1 (510) 666-2989
EMail: floyd@acm.org
URL: http://www.icir.org/floyd/
Phone: +1 (510) 666-2989
EMail: floyd@acm.org
URL: http://www.icir.org/floyd/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。