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
        
1. Introduction
1. 介绍

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的安全特性。

2. Conventions
2. 习俗

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]所述进行解释。

3. Design Principles of CUBIC
3. 立方体的设计原则

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的立方体流总是收敛到相同的吞吐量,与统计复用无关,从而实现算法内公平性。我们还发现,在统计复用充分的环境下,立方流的收敛速度是合理的。

4. CUBIC Congestion Control
4. 立方体拥塞控制

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表示慢启动阈值。

4.1. Window Increase Function
4.1. 窗口增加功能

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在每个区域采取的确切行动。

4.2. TCP-Friendly Region
4.2. TCP友好区

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)
        
4.3. Concave Region
4.3. 凹区

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计算。

4.4. Convex Region
4.4. 凸区

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计算。

4.5. Multiplicative Decrease
4.5. 乘性递减

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下一版本的一项。

4.6. Fast Convergence
4.6. 快速收敛

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,则表示由于可用带宽的变化,该