Internet Engineering Task Force (IETF) I. Rhee
Request for Comments: 8312 NCSU
Category: Informational L. Xu
ISSN: 2070-1721 UNL
S. Ha
Colorado
A. Zimmermann
Internet Engineering Task Force (IETF) I. Rhee
Request for Comments: 8312 NCSU
Category: Informational L. Xu
ISSN: 2070-1721 UNL
S. Ha
Colorado
A. Zimmermann
L. Eggert R. Scheffenegger NetApp February 2018
L.Eggert R.Scheffenegger NetApp 2018年2月
CUBIC for Fast Long-Distance Networks
快速长距离网络的立方体
Abstract
摘要
CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.
CUBIC是当前TCP标准的扩展。它与当前TCP标准的不同之处在于发送方的拥塞控制算法。特别是，它使用立方函数代替当前TCP标准的线性窗口增加函数，以提高快速和远程网络下的可伸缩性和稳定性。CUBIC及其前身算法已被Linux默认采用，并已使用多年。本文档提供了CUBIC的规范，以支持第三方实现，并通过对CUBIC性能的实验征求社区反馈。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8312.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8312.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Design Principles of CUBIC ......................................4
4. CUBIC Congestion Control ........................................6
4.1. Window Increase Function ...................................6
4.2. TCP-Friendly Region ........................................7
4.3. Concave Region .............................................8
4.4. Convex Region ..............................................8
4.5. Multiplicative Decrease ....................................8
4.6. Fast Convergence ...........................................9
4.7. Timeout ...................................................10
4.8. Slow Start ................................................10
5. Discussion .....................................................10
5.1. Fairness to Standard TCP ..................................11
5.2. Using Spare Capacity ......................................13
5.3. Difficult Environments ....................................13
5.4. Investigating a Range of Environments .....................13
5.5. Protection against Congestion Collapse ....................14
5.6. Fairness within the Alternative Congestion Control
Algorithm .................................................14
5.7. Performance with Misbehaving Nodes and Outside Attackers ..14
5.8. Behavior for Application-Limited Flows ....................14
5.9. Responses to Sudden or Transient Events ...................14
5.10. Incremental Deployment ...................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Design Principles of CUBIC ......................................4
4. CUBIC Congestion Control ........................................6
4.1. Window Increase Function ...................................6
4.2. TCP-Friendly Region ........................................7
4.3. Concave Region .............................................8
4.4. Convex Region ..............................................8
4.5. Multiplicative Decrease ....................................8
4.6. Fast Convergence ...........................................9
4.7. Timeout ...................................................10
4.8. Slow Start ................................................10
5. Discussion .....................................................10
5.1. Fairness to Standard TCP ..................................11
5.2. Using Spare Capacity ......................................13
5.3. Difficult Environments ....................................13
5.4. Investigating a Range of Environments .....................13
5.5. Protection against Congestion Collapse ....................14
5.6. Fairness within the Alternative Congestion Control
Algorithm .................................................14
5.7. Performance with Misbehaving Nodes and Outside Attackers ..14
5.8. Behavior for Application-Limited Flows ....................14
5.9. Responses to Sudden or Transient Events ...................14
5.10. Incremental Deployment ...................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18
The low utilization problem of TCP in fast long-distance networks is well documented in [K03] and [RFC3649]. This problem arises from a slow increase of the congestion window following a congestion event in a network with a large bandwidth-delay product (BDP). [HKLRX06] indicates that this problem is frequently observed even in the range of congestion window sizes over several hundreds of packets. This problem is equally applicable to all Reno-style TCP standards and their variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582] [RFC6675], SCTP [RFC4960], and TFRC [RFC5348], which use the same linear increase function for window growth, which we refer to collectively as "Standard TCP" below.
[K03]和[RFC3649]中详细记录了TCP在快速远程网络中的低利用率问题。这个问题源于在具有大带宽延迟积（BDP）的网络中发生拥塞事件后拥塞窗口的缓慢增加。[HKLRX06]表明，即使在数百个数据包的拥塞窗口大小范围内，也经常出现此问题。这个问题同样适用于所有雷诺风格的TCP标准及其变体，包括TCP-Reno[RFC5681]、TCP-NewReno[RFC6582][RFC6675]、SCTP[RFC4960]和TFRC[RFC5348]，它们使用相同的线性增加函数进行窗口增长，我们在下面统称为“标准TCP”。
CUBIC, originally proposed in [HRX08], is a modification to the congestion control algorithm of Standard TCP to remedy this problem. This document describes the most recent specification of CUBIC. Specifically, CUBIC uses a cubic function instead of a linear window increase function of Standard TCP to improve scalability and stability under fast and long-distance networks.
CUBIC最初是在[HRX08]中提出的，它是对标准TCP拥塞控制算法的一种修改，以解决这个问题。本文档描述了CUBIC的最新规范。具体来说，CUBIC使用一个CUBIC函数代替标准TCP的线性窗口增加函数，以提高快速和远程网络下的可伸缩性和稳定性。
Binary Increase Congestion Control (BIC-TCP) [XHR04], a predecessor of CUBIC, was selected as the default TCP congestion control algorithm by Linux in the year 2005 and has been used for several years by the Internet community at large. CUBIC uses a similar window increase function as BIC-TCP and is designed to be less aggressive and fairer to Standard TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC-TCP such as stability, window scalability, and RTT fairness. CUBIC has already replaced BIC-TCP as the default TCP congestion control algorithm in Linux and has been deployed globally by Linux. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for testing and deployment in the global Internet.
CUBIC的前身Binary Increase拥塞控制（BIC-TCP）[XHR04]在2005年被Linux选为默认的TCP拥塞控制算法，并被整个互联网社区使用了几年。CUBIC使用与BIC-TCP类似的窗口增加功能，在带宽使用方面比BIC-TCP的攻击性更小，更公平，同时保持BIC-TCP的优势，如稳定性、窗口可伸缩性和RTT公平性。CUBIC已经取代BIC-TCP作为Linux中默认的TCP拥塞控制算法，并已由Linux在全球部署。通过在各种互联网场景中的广泛测试，我们相信CUBIC在全球互联网上进行测试和部署是安全的。
In the following sections, we first briefly explain the design principles of CUBIC, then provide the exact specification of CUBIC, and finally discuss the safety features of CUBIC following the guidelines specified in [RFC5033].
在以下章节中，我们首先简要说明CUBIC的设计原则，然后提供CUBIC的确切规格，最后根据[RFC5033]中规定的指南讨论CUBIC的安全特性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
CUBIC is designed according to the following design principles:
立方体根据以下设计原则进行设计：
Principle 1: For better network utilization and stability, CUBIC uses both the concave and convex profiles of a cubic function to increase the congestion window size, instead of using just a convex function.
原则1：为了更好的网络利用率和稳定性，CUBIC同时使用一个立方函数的凹凸轮廓来增加拥塞窗口的大小，而不是仅仅使用一个凸函数。
Principle 2: To be TCP-friendly, CUBIC is designed to behave like Standard TCP in networks with short RTTs and small bandwidth where Standard TCP performs well.
原则2：为了对TCP友好，CUBIC被设计成在RTT短、带宽小且标准TCP性能良好的网络中像标准TCP一样工作。
Principle 3: For RTT-fairness, CUBIC is designed to achieve linear bandwidth sharing among flows with different RTTs.
原则3：对于RTT公平性，CUBIC设计用于在具有不同RTT的流之间实现线性带宽共享。
Principle 4: CUBIC appropriately sets its multiplicative window decrease factor in order to balance between the scalability and convergence speed.
原则4:CUBIC适当设置其乘法窗口减少因子，以平衡可伸缩性和收敛速度。
Principle 1: For better network utilization and stability, CUBIC [HRX08] uses a cubic window increase function in terms of the elapsed time from the last congestion event. While most alternative congestion control algorithms to Standard TCP increase the congestion window using convex functions, CUBIC uses both the concave and convex profiles of a cubic function for window growth. After a window reduction in response to a congestion event is detected by duplicate ACKs or Explicit Congestion Notification-Echo (ECN-Echo) ACKs [RFC3168], CUBIC registers the congestion window size where it got the congestion event as W_max and performs a multiplicative decrease of congestion window. After it enters into congestion avoidance, it starts to increase the congestion window using the concave profile of the cubic function. The cubic function is set to have its plateau at W_max so that the concave window increase continues until the window size becomes W_max. After that, the cubic function turns into a convex profile and the convex window increase begins. This style of window adjustment (concave and then convex) improves the algorithm stability while maintaining high network utilization [CEHRX07]. This is because the window size remains almost constant, forming a plateau around W_max where network utilization is deemed highest. Under steady state, most window size samples of CUBIC are close to W_max, thus promoting high network utilization and stability. Note that those congestion control algorithms using only convex functions to increase the congestion window size have the maximum increments around W_max, and thus introduce a large number of packet bursts around the saturation point of the network, likely causing frequent global loss synchronizations.
原则1：为了提高网络利用率和稳定性，CUBIC[HRX08]根据上次拥塞事件所经过的时间使用CUBIC窗口增加功能。虽然标准TCP的大多数替代拥塞控制算法都使用凸函数来增加拥塞窗口，但CUBIC同时使用了立方函数的凹凸轮廓来进行窗口增长。在重复ACK或显式拥塞通知回波（ECN回波）ACK[RFC3168]检测到响应拥塞事件的窗口缩小后，CUBIC将获取拥塞事件的拥塞窗口大小注册为W_max，并执行拥塞窗口的乘法减小。进入拥塞避免后，它开始使用立方函数的凹形轮廓增加拥塞窗口。将三次函数设置为其平台位于W_max，以便凹窗口继续增大，直到窗口大小变为W_max。之后，三次函数变为凸轮廓，凸窗口开始增大。这种窗口调整方式（先凹后凸）提高了算法的稳定性，同时保持了较高的网络利用率[CEHRX07]。这是因为窗口大小几乎保持不变，在网络利用率最高的W_max周围形成一个平台。在稳定状态下，CUBIC的大多数窗口大小样本接近W_max，从而提高了网络利用率和稳定性。注意，那些仅使用凸函数来增加拥塞窗口大小的拥塞控制算法在W_max附近具有最大增量，因此在网络饱和点附近引入大量分组突发，可能导致频繁的全局丢失同步。
Principle 2: CUBIC promotes per-flow fairness to Standard TCP. Note that Standard TCP performs well under short RTT and small bandwidth (or small BDP) networks. There is only a scalability problem in networks with long RTTs and large bandwidth (or large BDP). An alternative congestion control algorithm to Standard TCP designed to be friendly to Standard TCP on a per-flow basis must operate to increase its congestion window less aggressively in small BDP networks than in large BDP networks. The aggressiveness of CUBIC mainly depends on the maximum window size before a window reduction, which is smaller in small BDP networks than in large BDP networks. Thus, CUBIC increases its congestion window less aggressively in small BDP networks than in large BDP networks. Furthermore, in cases when the cubic function of CUBIC increases its congestion window less aggressively than Standard TCP, CUBIC simply follows the window size of Standard TCP to ensure that CUBIC achieves at least the same throughput as Standard TCP in small BDP networks. We call this region where CUBIC behaves like Standard TCP, the "TCP-friendly region".
原则2:CUBIC将每个流的公平性提升到标准TCP。请注意，标准TCP在短RTT和小带宽（或小BDP）网络下表现良好。在具有长RTT和大带宽（或大BDP）的网络中，只有可伸缩性问题。标准TCP的另一种拥塞控制算法设计为在每流基础上对标准TCP友好，必须在小型BDP网络中比在大型BDP网络中更有效地增加其拥塞窗口。立方体的攻击性主要取决于窗口缩减前的最大窗口大小，小BDP网络中的最大窗口大小小于大BDP网络中的最大窗口大小。因此，CUBIC在小型BDP网络中增加拥塞窗口的力度小于在大型BDP网络中增加拥塞窗口的力度。此外，当cubic的cubic函数增加拥塞窗口的力度小于标准TCP时，cubic只需遵循标准TCP的窗口大小，以确保cubic在小型BDP网络中至少达到与标准TCP相同的吞吐量。我们将立方行为类似于标准TCP的区域称为“TCP友好区域”。
Principle 3: Two CUBIC flows with different RTTs have their throughput ratio linearly proportional to the inverse of their RTT ratio, where the throughput of a flow is approximately the size of its congestion window divided by its RTT. Specifically, CUBIC maintains a window increase rate independent of RTTs outside of the TCP-friendly region, and thus flows with different RTTs have similar congestion window sizes under steady state when they operate outside the TCP-friendly region. This notion of a linear throughput ratio is similar to that of Standard TCP under high statistical multiplexing environments where packet losses are independent of individual flow rates. However, under low statistical multiplexing environments, the throughput ratio of Standard TCP flows with different RTTs is quadratically proportional to the inverse of their RTT ratio [XHR04]. CUBIC always ensures the linear throughput ratio independent of the levels of statistical multiplexing. This is an improvement over Standard TCP. While there is no consensus on particular throughput ratios of different RTT flows, we believe that under wired Internet, use of a linear throughput ratio seems more reasonable than equal throughputs (i.e., the same throughput for flows with different RTTs) or a higher-order throughput ratio (e.g., a quadratical throughput ratio of Standard TCP under low statistical multiplexing environments).
原则3：具有不同RTT的两个立方体流的吞吐量比率与其RTT比率的倒数成线性比例，其中流的吞吐量大约等于其拥塞窗口大小除以其RTT。具体地说，CUBIC在TCP友好区域外保持独立于RTT的窗口增加率，因此具有不同RTT的流在稳定状态下在TCP友好区域外运行时具有相似的拥塞窗口大小。这种线性吞吐量比的概念类似于高统计复用环境下的标准TCP，在这种环境中，数据包丢失与单个流量无关。然而，在低统计复用环境下，具有不同RTT的标准TCP流的吞吐量比率与其RTT比率的倒数成二次比例[XHR04]。CUBIC始终确保线性吞吐量比与统计复用级别无关。这是对标准TCP的改进。虽然对于不同RTT流的特定吞吐量比率没有共识，但我们认为，在有线互联网下，使用线性吞吐量比率似乎比同等吞吐量（即，不同RTT流的相同吞吐量）或更高阶吞吐量比率更合理（例如，低统计复用环境下标准TCP的二次吞吐量比）。
Principle 4: To balance between the scalability and convergence speed, CUBIC sets the multiplicative window decrease factor to 0.7 while Standard TCP uses 0.5. While this improves the scalability of CUBIC, a side effect of this decision is slower convergence, especially under low statistical multiplexing environments. This design choice is following the observation that the author of
原则4：为了平衡可伸缩性和收敛速度，CUBIC将乘法窗口减少因子设置为0.7，而标准TCP使用0.5。虽然这提高了CUBIC的可伸缩性，但此决定的一个副作用是收敛速度较慢，特别是在低统计复用环境下。这一设计选择遵循了作者的观察
HighSpeed TCP (HSTCP) [RFC3649] has made along with other researchers (e.g., [GV02]): the current Internet becomes more asynchronous with less frequent loss synchronizations with high statistical multiplexing. Under this environment, even strict Multiplicative-Increase Multiplicative-Decrease (MIMD) can converge. CUBIC flows with the same RTT always converge to the same throughput independent of statistical multiplexing, thus achieving intra-algorithm fairness. We also find that under the environments with sufficient statistical multiplexing, the convergence speed of CUBIC flows is reasonable.
高速TCP（HSTCP）[RFC3649]与其他研究人员一起（例如[GV02]）：当前的互联网变得更加异步，丢失同步的频率更低，具有高统计复用。在这种环境下，即使是严格的乘法递增乘法递减（MIMD）也可以收敛。具有相同RTT的立方体流总是收敛到相同的吞吐量，与统计复用无关，从而实现算法内公平性。我们还发现，在统计复用充分的环境下，立方流的收敛速度是合理的。
The unit of all window sizes in this document is segments of the maximum segment size (MSS), and the unit of all times is seconds. Let cwnd denote the congestion window size of a flow, and ssthresh denote the slow-start threshold.
本文档中所有窗口大小的单位为最大段大小（MSS）的段，所有时间的单位为秒。让cwnd表示流的拥塞窗口大小，ssthresh表示慢启动阈值。
CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by increasing the congestion window only at the reception of an ACK. It does not make any change to the fast recovery and retransmit of TCP, such as TCP-NewReno [RFC6582] [RFC6675]. During congestion avoidance after a congestion event where a packet loss is detected by duplicate ACKs or a network congestion is detected by ACKs with ECN-Echo flags [RFC3168], CUBIC changes the window increase function of Standard TCP. Suppose that W_max is the window size just before the window is reduced in the last congestion event.
CUBIC通过仅在接收到ACK时增加拥塞窗口来维持标准TCP的确认（ACK）时钟。它不会对TCP的快速恢复和重传进行任何更改，例如TCP NewReno[RFC6582][RFC6675]。在拥塞避免期间，如果重复ACK检测到数据包丢失或ACK使用ECN回波标志[RFC3168]检测到网络拥塞，CUBIC会更改标准TCP的窗口增加功能。假设W_max是在上一次拥塞事件中窗口减小之前的窗口大小。
CUBIC uses the following window increase function:
CUBIC使用以下窗口增加功能：
W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)
W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)
where C is a constant fixed to determine the aggressiveness of window increase in high BDP networks, t is the elapsed time from the beginning of the current congestion avoidance, and K is the time period that the above function takes to increase the current window size to W_max if there are no further congestion events and is calculated using the following equation:
其中C是一个常数，用于确定高BDP网络中窗口增加的攻击性，t是从当前拥塞避免开始经过的时间，K是如果没有进一步的拥塞事件，则上述函数将当前窗口大小增加到W_max所需的时间段，并使用以下公式计算：
K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)
K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)
where beta_cubic is the CUBIC multiplication decrease factor, that is, when a congestion event is detected, CUBIC reduces its cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how we set beta_cubic in Section 4.5 and how we set C in Section 5.
其中beta_cubic是立方乘法减少因子，即，当检测到拥塞事件时，cubic将其cwnd减少到W_cubic（0）=W_max*beta_cubic。我们将在第4.5节中讨论如何设置beta_立方，以及如何在第5节中设置C。
Upon receiving an ACK during congestion avoidance, CUBIC computes the window increase rate during the next RTT period using Eq. 1. It sets W_cubic(t+RTT) as the candidate target value of the congestion window, where RTT is the weighted average RTT calculated by Standard TCP.
当在拥塞避免期间接收到ACK时，CUBIC使用等式1计算下一RTT期间的窗口增加率。它将W_cubic（t+RTT）设置为拥塞窗口的候选目标值，其中RTT是标准TCP计算的加权平均RTT。
Depending on the value of the current congestion window size cwnd, CUBIC runs in three different modes.
根据当前拥塞窗口大小cwnd的值，CUBIC以三种不同的模式运行。
1. The TCP-friendly region, which ensures that CUBIC achieves at least the same throughput as Standard TCP.
1. TCP友好区域，确保CUBIC至少达到与标准TCP相同的吞吐量。
2. The concave region, if CUBIC is not in the TCP-friendly region and cwnd is less than W_max.
2. 凹面区域，如果立方体不在TCP友好区域，且cwnd小于W_max。
3. The convex region, if CUBIC is not in the TCP-friendly region and cwnd is greater than W_max.
3. 凸区域，如果立方体不在TCP友好区域，且cwnd大于W_max。
Below, we describe the exact actions taken by CUBIC in each region.
下面，我们描述CUBIC在每个区域采取的确切行动。
Standard TCP performs well in certain types of networks, for example, under short RTT and small bandwidth (or small BDP) networks. In these networks, we use the TCP-friendly region to ensure that CUBIC achieves at least the same throughput as Standard TCP.
标准TCP在某些类型的网络中表现良好，例如，在短RTT和小带宽（或小BDP）网络下。在这些网络中，我们使用TCP友好区域来确保CUBIC至少达到与标准TCP相同的吞吐量。
The TCP-friendly region is designed according to the analysis described in [FHP00]. The analysis studies the performance of an Additive Increase and Multiplicative Decrease (AIMD) algorithm with an additive factor of alpha_aimd (segments per RTT) and a multiplicative factor of beta_aimd, denoted by AIMD(alpha_aimd, beta_aimd). Specifically, the average congestion window size of AIMD(alpha_aimd, beta_aimd) can be calculated using Eq. 3. The analysis shows that AIMD(alpha_aimd, beta_aimd) with alpha_aimd=3*(1-beta_aimd)/(1+beta_aimd) achieves the same average window size as Standard TCP that uses AIMD(1, 0.5).
TCP友好区是根据[FHP00]中描述的分析设计的。分析研究了加法增加和乘法减少（AIMD）算法的性能，该算法的加法因子为alpha_AIMD（每RTT的分段数），乘法因子为beta_AIMD，表示为AIMD（alpha_AIMD，beta_AIMD）。具体而言，AIMD的平均拥塞窗口大小（alpha_AIMD，beta_AIMD）可以使用公式3计算。分析表明，当alpha_AIMD=3*（1-beta_AIMD）/（1+beta_AIMD）时，AIMD（alpha_AIMD，beta_AIMD）的平均窗口大小与使用AIMD的标准TCP（1，0.5）相同。
AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)
AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)
Based on the above analysis, CUBIC uses Eq. 4 to estimate the window size W_est of AIMD(alpha_aimd, beta_aimd) with alpha_aimd=3*(1-beta_cubic)/(1+beta_cubic) and beta_aimd=beta_cubic, which achieves the same average window size as Standard TCP. When receiving an ACK in congestion avoidance (cwnd could be greater than
基于上述分析，CUBIC使用公式4估计窗口大小W_est of AIMD（alpha_AIMD，beta_AIMD），alpha_AIMD=3*（1-β_CUBIC）/（1+β_CUBIC）和beta_AIMD=beta_CUBIC，从而实现与标准TCP相同的平均窗口大小。在拥塞避免（cwnd）中接收ACK时，可能大于
or less than W_max), CUBIC checks whether W_cubic(t) is less than W_est(t). If so, CUBIC is in the TCP-friendly region and cwnd SHOULD be set to W_est(t) at each reception of an ACK.
或小于W_max），立方检查W_立方（t）是否小于W_est（t）。如果是这样，CUBIC在TCP友好区域中，并且cwnd应该在每次接收ACK时设置为W_est（t）。
W_est(t) = W_max*beta_cubic +
[3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4)
W_est(t) = W_max*beta_cubic +
[3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4)
When receiving an ACK in congestion avoidance, if CUBIC is not in the TCP-friendly region and cwnd is less than W_max, then CUBIC is in the concave region. In this region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1.
在拥塞避免中接收ACK时，如果CUBIC不在TCP友好区域，且cwnd小于W_max，则CUBIC在凹区域。在该区域中，对于每个接收到的ACK，cwnd必须增加（W_cubic（t+RTT）-cwnd）/cwnd，其中W_cubic（t+RTT）使用等式1计算。
When receiving an ACK in congestion avoidance, if CUBIC is not in the TCP-friendly region and cwnd is larger than or equal to W_max, then CUBIC is in the convex region. The convex region indicates that the network conditions might have been perturbed since the last congestion event, possibly implying more available bandwidth after some flow departures. Since the Internet is highly asynchronous, some amount of perturbation is always possible without causing a major change in available bandwidth. In this region, CUBIC is being very careful by very slowly increasing its window size. The convex profile ensures that the window increases very slowly at the beginning and gradually increases its increase rate. We also call this region the "maximum probing phase" since CUBIC is searching for a new W_max. In this region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1.
在拥塞避免中接收ACK时，如果CUBIC不在TCP友好区域中，且cwnd大于或等于W_max，则CUBIC在凸区域中。凸面区域表明，自上次拥塞事件以来，网络条件可能受到干扰，这可能意味着在一些流量偏离后，可用带宽会增加。由于互联网是高度异步的，在不引起可用带宽重大变化的情况下，一定程度的扰动始终是可能的。在这个区域，CUBIC非常小心，非常缓慢地增加其窗口大小。凸面轮廓确保窗口在开始时增长非常缓慢，并逐渐增加其增长率。我们还将该区域称为“最大探测阶段”，因为CUBIC正在搜索新的W_max。在该区域中，对于每个接收到的ACK，cwnd必须增加（W_CUBIC（t+RTT）-cwnd）/cwnd，其中W_CUBIC（t+RTT）使用等式1计算。
When a packet loss is detected by duplicate ACKs or a network congestion is detected by ECN-Echo ACKs, CUBIC updates its W_max, cwnd, and ssthresh as follows. Parameter beta_cubic SHOULD be set to 0.7.
当重复ACK检测到数据包丢失或ECN Echo ACK检测到网络拥塞时，CUBIC将按如下方式更新其W_max、cwnd和ssthresh。参数beta_cubic应设置为0.7。
W_max = cwnd; // save window size before reduction
ssthresh = cwnd * beta_cubic; // new slow-start threshold
ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS
cwnd = cwnd * beta_cubic; // window reduction
W_max = cwnd; // save window size before reduction
ssthresh = cwnd * beta_cubic; // new slow-start threshold
ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS
cwnd = cwnd * beta_cubic; // window reduction
A side effect of setting beta_cubic to a value bigger than 0.5 is slower convergence. We believe that while a more adaptive setting of beta_cubic could result in faster convergence, it will make the analysis of CUBIC much harder. This adaptive adjustment of beta_cubic is an item for the next version of CUBIC.
将beta_cubic设置为大于0.5的值的副作用是收敛速度较慢。我们相信，尽管β_立方的更具适应性的设置可能导致更快的收敛，但它将使立方的分析更加困难。beta_cubic的自适应调整是cubic下一版本的一项。
To improve the convergence speed of CUBIC, we add a heuristic in CUBIC. When a new flow joins the network, existing flows in the network need to give up some of their bandwidth to allow the new flow some room for growth if the existing flows have been using all the bandwidth of the network. To speed up this bandwidth release by existing flows, the following mechanism called "fast convergence" SHOULD be implemented.
为了提高CUBIC算法的收敛速度，我们在CUBIC算法中加入了一个启发式算法。当新流加入网络时，如果现有流已经使用了网络的所有带宽，则网络中的现有流需要放弃一些带宽，以允许新流有一些增长空间。为了通过现有流加速带宽释放，应该实现以下称为“快速收敛”的机制。
With fast convergence, when a congestion event occurs, before the window reduction of the congestion window, a flow remembers the last value of W_max before it updates W_max for the current congestion event. Let us call the last value of W_max to be W_last_max.
通过快速收敛，当发生拥塞事件时，在拥塞窗口的窗口缩小之前，流在更新当前拥塞事件的W_max之前会记住W_max的最后一个值。让我们将W_max的最后一个值称为W_last_max。
if (W_max < W_last_max){ // should we make room for others
W_last_max = W_max; // remember the last W_max
W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else {
W_last_max = W_max // remember the last W_max
}
if (W_max < W_last_max){ // should we make room for others
W_last_max = W_max; // remember the last W_max
W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else {
W_last_max = W_max // remember the last W_max
}
At a congestion event, if the current value of W_max is less than W_last_max, this indicates that the saturation point experienced by this flow is getting reduced because of the change in available bandwidth. Then we allow this flow to release more bandwidth by reducing W_max further. This action effectively lengthens the time for this flow to increase its congestion window because the reduced W_max forces the flow to have the plateau earlier. This allows more time for the new flow to catch up to its congestion window size.
在拥塞事件中，如果W_max的当前值小于W_last_max，则表示由于可用带宽的变化，该流经历的饱和点正在减小。然后，我们通过进一步降低W_max来允许该流释放更多带宽。此操作有效地延长了此流增加其拥塞窗口的时间，因为减少的W_max迫使流更早地达到平台。这使得新流量有更多的时间赶上其拥塞窗口大小。
The fast convergence is designed for network environments with multiple CUBIC flows. In network environments with only a single CUBIC flow and without any other traffic, the fast convergence SHOULD be disabled.
快速收敛是针对具有多个立方流的网络环境而设计的。在只有单立方流且没有任何其他流量的网络环境中，应禁用快速收敛。
In case of timeout, CUBIC follows Standard TCP to reduce cwnd [RFC5681], but sets ssthresh using beta_cubic (same as in Section 4.5) that is different from Standard TCP [RFC5681].
在超时情况下，CUBIC遵循标准TCP以减少cwnd[RFC5681]，但使用不同于标准TCP[RFC5681]的beta_CUBIC（与第4.5节中的相同）设置ssthresh。
During the first congestion avoidance after a timeout, CUBIC increases its congestion window size using Eq. 1, where t is the elapsed time since the beginning of the current congestion avoidance, K is set to 0, and W_max is set to the congestion window size at the beginning of the current congestion avoidance.
在超时后的第一次拥塞避免期间，CUBIC使用等式1增加其拥塞窗口大小，其中t是自当前拥塞避免开始以来经过的时间，K设置为0，W_max设置为当前拥塞避免开始时的拥塞窗口大小。
CUBIC MUST employ a slow-start algorithm, when the cwnd is no more than ssthresh. Among the slow-start algorithms, CUBIC MAY choose the standard TCP slow start [RFC5681] in general networks, or the limited slow start [RFC3742] or hybrid slow start [HR08] for fast and long-distance networks.
当cwnd不超过ssthresh时，CUBIC必须采用慢启动算法。在慢启动算法中，CUBIC可以在一般网络中选择标准TCP慢启动[RFC5681]，或在快速和远程网络中选择有限慢启动[RFC3742]或混合慢启动[HR08]。
In the case when CUBIC runs the hybrid slow start [HR08], it may exit the first slow start without incurring any packet loss and thus W_max is undefined. In this special case, CUBIC switches to congestion avoidance and increases its congestion window size using Eq. 1, where t is the elapsed time since the beginning of the current congestion avoidance, K is set to 0, and W_max is set to the congestion window size at the beginning of the current congestion avoidance.
在CUBIC运行混合慢启动[HR08]的情况下，它可能会退出第一次慢启动，而不会导致任何数据包丢失，因此W_max未定义。在这种特殊情况下，CUBIC切换到拥塞避免并使用等式1增加其拥塞窗口大小，其中t是自当前拥塞避免开始以来经过的时间，K设置为0，W_max设置为当前拥塞避免开始时的拥塞窗口大小。
In this section, we further discuss the safety features of CUBIC following the guidelines specified in [RFC5033].
在本节中，我们将根据[RFC5033]中规定的指南进一步讨论CUBIC的安全特性。
With a deterministic loss model where the number of packets between two successive packet losses is always 1/p, CUBIC always operates with the concave window profile, which greatly simplifies the performance analysis of CUBIC. The average window size of CUBIC can be obtained by the following function:
对于两次连续丢包之间的数据包数始终为1/p的确定性丢包模型，CUBIC始终采用凹窗模式，这大大简化了CUBIC的性能分析。立方体的平均窗口大小可通过以下函数获得：
AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 *
(RTT^0.75) / (p^0.75) (Eq. 5)
AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 *
(RTT^0.75) / (p^0.75) (Eq. 5)
With beta_cubic set to 0.7, the above formula is reduced to:
将β_立方设置为0.7时，上述公式简化为：
AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6)
AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6)
We will determine the value of C in the following subsection using Eq. 6.
我们将在下一小节中使用公式6确定C的值。
In environments where Standard TCP is able to make reasonable use of the available bandwidth, CUBIC does not significantly change this state.
在标准TCP能够合理利用可用带宽的环境中，CUBIC不会显著改变这种状态。
Standard TCP performs well in the following two types of networks:
标准TCP在以下两种类型的网络中表现良好：
1. networks with a small bandwidth-delay product (BDP)
1. 具有小带宽延迟积（BDP）的网络
2. networks with a short RTTs, but not necessarily a small BDP
2. 具有短RTT但不一定是小BDP的网络
CUBIC is designed to behave very similarly to Standard TCP in the above two types of networks. The following two tables show the average window sizes of Standard TCP, HSTCP, and CUBIC. The average window sizes of Standard TCP and HSTCP are from [RFC3649]. The average window size of CUBIC is calculated using Eq. 6 and the CUBIC TCP-friendly region for three different values of C.
CUBIC在上述两种网络中的行为与标准TCP非常相似。以下两个表显示了标准TCP、HSTCP和CUBIC的平均窗口大小。标准TCP和HSTCP的平均窗口大小来自[RFC3649]。使用公式6和立方TCP友好区域计算立方的平均窗口大小，三个不同的C值。
+--------+----------+-----------+------------+-----------+----------+
| Loss | Average | Average | CUBIC | CUBIC | CUBIC |
| Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) |
+--------+----------+-----------+------------+-----------+----------+
| 10^-2 | 12 | 12 | 12 | 12 | 12 |
| 10^-3 | 38 | 38 | 38 | 38 | 59 |
| 10^-4 | 120 | 263 | 120 | 187 | 333 |
| 10^-5 | 379 | 1795 | 593 | 1054 | 1874 |
| 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 |
| 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 |
| 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 |
+--------+----------+-----------+------------+-----------+----------+
+--------+----------+-----------+------------+-----------+----------+
| Loss | Average | Average | CUBIC | CUBIC | CUBIC |
| Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) |
+--------+----------+-----------+------------+-----------+----------+
| 10^-2 | 12 | 12 | 12 | 12 | 12 |
| 10^-3 | 38 | 38 | 38 | 38 | 59 |
| 10^-4 | 120 | 263 | 120 | 187 | 333 |
| 10^-5 | 379 | 1795 | 593 | 1054 | 1874 |
| 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 |
| 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 |
| 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 |
+--------+----------+-----------+------------+-----------+----------+
Table 1
表1
Table 1 describes the response function of Standard TCP, HSTCP, and CUBIC in networks with RTT = 0.1 seconds. The average window size is in MSS-sized segments.
表1描述了RTT=0.1秒的网络中标准TCP、HSTCP和CUBIC的响应功能。平均窗口大小以MSS大小的段为单位。
+--------+-----------+-----------+------------+-----------+---------+
| Loss | Average | Average | CUBIC | CUBIC | CUBIC |
| Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) |
+--------+-----------+-----------+------------+-----------+---------+
| 10^-2 | 12 | 12 | 12 | 12 | 12 |
| 10^-3 | 38 | 38 | 38 | 38 | 38 |
| 10^-4 | 120 | 263 | 120 | 120 | 120 |
| 10^-5 | 379 | 1795 | 379 | 379 | 379 |
| 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 |
| 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 |
| 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 |
+--------+-----------+-----------+------------+-----------+---------+
+--------+-----------+-----------+------------+-----------+---------+
| Loss | Average | Average | CUBIC | CUBIC | CUBIC |
| Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) |
+--------+-----------+-----------+------------+-----------+---------+
| 10^-2 | 12 | 12 | 12 | 12 | 12 |
| 10^-3 | 38 | 38 | 38 | 38 | 38 |
| 10^-4 | 120 | 263 | 120 | 120 | 120 |
| 10^-5 | 379 | 1795 | 379 | 379 | 379 |
| 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 |
| 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 |
| 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 |
+--------+-----------+-----------+------------+-----------+---------+
Table 2
表2
Table 2 describes the response function of Standard TCP, HSTCP, and CUBIC in networks with RTT = 0.01 seconds. The average window size is in MSS-sized segments.
表2描述了RTT=0.01秒的网络中标准TCP、HSTCP和CUBIC的响应功能。平均窗口大小以MSS大小的段为单位。
Both tables show that CUBIC with any of these three C values is more friendly to TCP than HSTCP, especially in networks with a short RTT where TCP performs reasonably well. For example, in a network with RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 packets. If the packet size is 1500 bytes, then TCP can achieve an average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 achieves exactly the same rate as Standard TCP, whereas HSTCP is about ten times more aggressive than Standard TCP.
两个表都显示，具有这三个C值中任何一个的CUBIC对TCP都比HSTCP更友好，尤其是在RTT较短的网络中，TCP的性能相当好。例如，在RTT=0.01秒且p=10^-6的网络中，TCP的平均窗口为1200个数据包。如果数据包大小为1500字节，则TCP可以实现1.44 Gbps的平均速率。在这种情况下，C=0.04或C=0.4的CUBIC实现了与标准TCP完全相同的速率，而HSTCP的攻击性大约是标准TCP的十倍。
We can see that C determines the aggressiveness of CUBIC in competing with other congestion control algorithms for bandwidth. CUBIC is more friendly to Standard TCP, if the value of C is lower. However, we do not recommend setting C to a very low value like 0.04, since CUBIC with a low C cannot efficiently use the bandwidth in long RTT and high-bandwidth networks. Based on these observations and our experiments, we find C=0.4 gives a good balance between TCP-friendliness and aggressiveness of window increase. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 is reduced to:
我们可以看到，C决定了CUBIC在带宽方面与其他拥塞控制算法竞争的积极性。如果C值较低，CUBIC对标准TCP更友好。但是，我们不建议将C设置为非常低的值（如0.04），因为C低的CUBIC无法在长RTT和高带宽网络中有效使用带宽。基于这些观察和我们的实验，我们发现C=0.4在TCP友好性和窗口增加的攻击性之间取得了很好的平衡。因此，C应设置为0.4。当C设置为0.4时，等式6减小为：
AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)
AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)
Eq. 7 is then used in the next subsection to show the scalability of CUBIC.
然后在下一小节中使用等式7来显示CUBIC的可伸缩性。
CUBIC uses a more aggressive window increase function than Standard TCP under long RTT and high-bandwidth networks.
CUBIC在长RTT和高带宽网络下使用比标准TCP更具攻击性的窗口增加功能。
The following table shows that to achieve the 10 Gbps rate, Standard TCP requires a packet loss rate of 2.0e-10, while CUBIC requires a packet loss rate of 2.9e-8.
下表显示，要达到10 Gbps速率，标准TCP要求丢包率为2.0e-10，而CUBIC要求丢包率为2.9e-8。
+------------------+-----------+---------+---------+---------+
| Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P |
+------------------+-----------+---------+---------+---------+
| 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 |
| 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 |
| 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 |
| 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 |
| 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 |
+------------------+-----------+---------+---------+---------+
+------------------+-----------+---------+---------+---------+
| Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P |
+------------------+-----------+---------+---------+---------+
| 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 |
| 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 |
| 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 |
| 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 |
| 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 |
+------------------+-----------+---------+---------+---------+
Table 3
表3
Table 3 describes the required packet loss rate for Standard TCP, HSTCP, and CUBIC to achieve a certain throughput. We use 1500-byte packets and an RTT of 0.1 seconds.
表3描述了标准TCP、HSTCP和CUBIC实现一定吞吐量所需的丢包率。我们使用1500字节的数据包和0.1秒的RTT。
Our test results in [HKLRX06] indicate that CUBIC uses the spare bandwidth left unused by existing Standard TCP flows in the same bottleneck link without taking away much bandwidth from the existing flows.
我们在[HKLRX06]中的测试结果表明，CUBIC在同一瓶颈链路中使用现有标准TCP流未使用的备用带宽，而不会从现有流中占用太多带宽。
CUBIC is designed to remedy the poor performance of TCP in fast and long-distance networks.
CUBIC旨在弥补TCP在快速和长距离网络中性能差的缺点。
CUBIC has been extensively studied by using both NS-2 simulation and test-bed experiments covering a wide range of network environments. More information can be found in [HKLRX06].
CUBIC已经通过使用NS-2模拟和试验台实验进行了广泛的研究，涵盖了广泛的网络环境。更多信息请参见[HKLRX06]。
Same as Standard TCP, CUBIC is a loss-based congestion control algorithm. Because CUBIC is designed to be more aggressive (due to a faster window increase function and bigger multiplicative decrease factor) than Standard TCP in fast and long-distance networks, it can fill large drop-tail buffers more quickly than Standard TCP and
与标准TCP相同，CUBIC是一种基于丢失的拥塞控制算法。由于CUBIC的设计在快速和远程网络中比标准TCP更具攻击性（因为它具有更快的窗口增加功能和更大的乘法减少因子），因此它可以比标准TCP和TCP更快地填充大落尾缓冲区
increase the risk of a standing queue [KWAF17]. In this case, proper queue sizing and management [RFC7567] could be used to reduce the packet queuing delay.
增加排队等候的风险[KWAF17]。在这种情况下，可以使用适当的队列大小和管理[RFC7567]来减少数据包队列延迟。
With regard to the potential of causing congestion collapse, CUBIC behaves like Standard TCP since CUBIC modifies only the window adjustment algorithm of TCP. Thus, it does not modify the ACK clocking and Timeout behaviors of Standard TCP.
至于导致拥塞崩溃的可能性，CUBIC的行为与标准TCP类似，因为CUBIC只修改TCP的窗口调整算法。因此，它不会修改标准TCP的ACK时钟和超时行为。
CUBIC ensures convergence of competing CUBIC flows with the same RTT in the same bottleneck links to an equal throughput. When competing flows have different RTTs, their throughput ratio is linearly proportional to the inverse of their RTT ratios. This is true independent of the level of statistical multiplexing in the link.
CUBIC确保在相同瓶颈链路中具有相同RTT的竞争CUBIC流收敛到相同吞吐量。当竞争流具有不同的RTT时，它们的吞吐量比率与其RTT比率的倒数成线性比例。这与链路中的统计复用级别无关。
This is not considered in the current CUBIC.
当前立方体中不考虑这一点。
CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window. In case of long periods when cwnd has not been updated due to the application rate limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; otherwise, W_cubic(t) might be very high after restarting from these periods.
如果流当前由应用程序而不是拥塞窗口限制，CUBIC不会提高其拥塞窗口大小。如果由于应用速率限制，cwnd未更新的时间较长，例如空闲时间，则等式1中的t不得包括这些时间段；否则，从这些时段重新启动后，W_立方（t）可能会非常高。
If there is a sudden congestion, a routing change, or a mobility event, CUBIC behaves the same as Standard TCP.
如果出现突发拥塞、路由更改或移动事件，CUBIC的行为与标准TCP相同。
CUBIC requires only the change of TCP senders, and it does not make any changes to TCP receivers. That is, a CUBIC sender works correctly with the Standard TCP receivers. In addition, CUBIC does not require any changes to the routers and does not require any assistance from the routers.
CUBIC只需要更改TCP发送方，不需要更改TCP接收方。也就是说，立方体发送器可以与标准TCP接收器正常工作。此外，CUBIC不需要对路由器进行任何更改，也不需要路由器的任何帮助。
This proposal makes no changes to the underlying security of TCP. More information about TCP security concerns can be found in [RFC5681].
此建议不改变TCP的底层安全性。有关TCP安全问题的更多信息，请参见[RFC5681]。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.
[RFC3649]Floyd，S.，“用于大拥塞窗口的高速TCP”，RFC 3649，DOI 10.17487/RFC3649，2003年12月<https://www.rfc-editor.org/info/rfc3649>.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 2004, <https://www.rfc-editor.org/info/rfc3742>.
[RFC3742]Floyd，S.，“具有大拥塞窗口的TCP有限慢启动”，RFC 3742，DOI 10.17487/RFC3742，2004年3月<https://www.rfc-editor.org/info/rfc3742>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.
[RFC5033]Floyd，S.和M.Allman，“指定新的拥塞控制算法”，BCP 133，RFC 5033，DOI 10.17487/RFC5033，2007年8月<https://www.rfc-editor.org/info/rfc5033>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，DOI 10.17487/RFC5348，2008年9月<https://www.rfc-editor.org/info/rfc5348>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<https://www.rfc-editor.org/info/rfc5681>.
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, April 2012, <https://www.rfc-editor.org/info/rfc6582>.
[RFC6582]Henderson，T.，Floyd，S.，Gurtov，A.，和Y.Nishida，“TCP快速恢复算法的NewReno修改”，RFC 6582，DOI 10.17487/RFC6582，2012年4月<https://www.rfc-editor.org/info/rfc6582>.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.
[RFC6675]Blanton，E.，Allman，M.，Wang，L.，Jarvinen，I.，Kojo，M.，和Y.Nishida，“基于TCP选择性确认（SACK）的保守损失恢复算法”，RFC 6675，DOI 10.17487/RFC6675，2012年8月<https://www.rfc-editor.org/info/rfc6675>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567]Baker，F.，Ed.和G.Fairhurst，Ed.，“IETF关于主动队列管理的建议”，BCP 197，RFC 7567，DOI 10.17487/RFC7567，2015年7月<https://www.rfc-editor.org/info/rfc7567>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic Ordering for Internet Congestion Control and its Applications", In Proceedings of IEEE INFOCOM, DOI 10.1109/INFCOM.2007.111, May 2007.
[CEHRX07]Cai，H.，Eun，D.，Ha，S.，Rhee，I.，和L.Xu，“互联网拥塞控制及其应用的随机排序”，发表于IEEE INFOCOM会议记录，DOI 10.1109/INFCOM.2007.1112007年5月。
[FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of Equation-Based and AIMD Congestion Control", May 2000.
[FHP00]Floyd，S.，Handley，M.，和J.Padhye，“基于方程和AIMD拥塞控制的比较”，2000年5月。
[GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary Adjustment Algorithms", Technical Report TR2002-29, Department of Computer Sciences, The University of Texas at Austin, August 2002.
[GV02] GrimSkys，S.和H. Vin，“二元调整算法的扩展分析”，2002年8月，得克萨斯大学奥斯汀分校计算机科学系技术报告TR200—29。
[HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step toward Realistic Performance Evaluation of High-Speed TCP Variants", International Workshop on Protocols for Fast Long-Distance Networks.
[HKLRX06]Ha，S.，Kim，Y.，Le，L.，Rhee，I.，和L.Xu，“向高速TCP变体的现实性能评估迈出的一步”，快速远程网络协议国际研讨会。
[HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth and Long-Distance Networks", International Workshop on Protocols for Fast Long-Distance Networks.
[HR08]Ha，S.和I.Rhee，“高带宽和长距离网络的混合慢启动”，快速长距离网络协议国际研讨会。
[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", ACM SIGOPS Operating System Review, DOI 10.1145/1400097.1400105, July 2008.
[HRX08]Ha，S.，Rhee，I.，和L.Xu，“CUBIC：一种新的TCP友好型高速TCP变体”，ACM SIGOPS操作系统评论，DOI 10.1145/1400097.14001052008年7月。
[K03] Kelly, T., "Scalable TCP: Improving Performance in HighSpeed Wide Area Networks", ACM SIGCOMM Computer Communication Review, DOI 10.1145/956981.956989, April 2003.
[K03]Kelly，T.“可扩展TCP：提高高速广域网的性能”，《ACM SIGCOMM计算机通信评论》，DOI 10.1145/956981.956989，2003年4月。
[KWAF17] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-05, December 2017.
[KWAF17]Khademi，N.，Welzl，M.，Armitage，G.，和G.Fairhurst，“使用ECN（ABE）的TCP替代回退”，正在进行的工作，草案-ietf-tcpm-alternativebackoff-ECN-052017年12月。
[XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase Congestion Control for Fast, Long Distance Networks", In Proceedings of IEEE INFOCOM, DOI 10.1109/INFCOM.2004.1354672, March 2004.
[XHR04]Xu，L.，Harfoush，K.，和I.Rhee，“快速长距离网络的二进制增量拥塞控制”，发表于IEEE信息网会议录，DOI 10.1109/INFCOM.2004.1354672，2004年3月。
Acknowledgements
致谢
Alexander Zimmermann and Lars Eggert have received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document reflects only the authors' views and the European Commission is not responsible for any use that may be made of the information it contains.
亚历山大·齐默尔曼（Alexander Zimmermann）和拉尔斯·艾格特（Lars Eggert）已根据第644866号赠款协议（SSICLOPS）获得欧盟地平线2020研究与创新计划2014-2018的资助。本文件仅反映了作者的观点，欧盟委员会不对其所含信息的任何使用负责。
The work of Lisong Xu was partially supported by the National Science Foundation (NSF) under Grant No. 1526253. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the NSF.
李松旭的工作部分得到了国家科学基金会（NSF）1526253号资助。本材料中表达的任何意见、发现和结论或建议均为作者的意见、发现和结论或建议，不一定反映NSF的观点。
Authors' Addresses
作者地址
Injong Rhee North Carolina State University Department of Computer Science Raleigh, NC 27695-7534 United States of America Email: rhee@ncsu.edu
北卡罗来纳州罗利北卡罗来纳州立大学计算机科学系，北卡罗来纳州，邮编27695-7534美利坚合众国电子邮件：rhee@ncsu.edu
Lisong Xu University of Nebraska-Lincoln Department of Computer Science and Engineering Lincoln, NE 68588-0115 United States of America
林松旭内布拉斯加大学林肯分校计算机科学与工程系，美利坚合众国
Email: xu@unl.edu
Email: xu@unl.edu
Sangtae Ha University of Colorado at Boulder Department of Computer Science Boulder, CO 80309-0430 United States of America Email: sangtae.ha@colorado.edu
桑塔哈科罗拉多大学波尔得分校计算机科学博尔德分校，合作80309 - 0430美利坚合众国电子邮件：桑塔。ha@colorado.edu
Alexander Zimmermann Phone: +49 175 5766838 Email: alexander.zimmermann@rwth-aachen.de
Alexander Zimmermann电话：+49 175 5766838电子邮件：Alexander。zimmermann@rwth-亚琛
Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany Phone: +49 151 12055791 Email: lars@netapp.com
Lars Eggert NetApp Sonnenalee 1 Kirchheim 85551德国电话：+49 151 12055791电子邮件：lars@netapp.com
Richard Scheffenegger NetApp Am Europlatz 2 Vienna 1120 Austria Email: rs.ietf@gmx.at
Richard Scheffenegger NetApp Am Europlatz 2维也纳1120奥地利电子邮件：rs。ietf@gmx.at