[rfc9438] TCP 拥塞控制算法-用于快速和长距离网络的 CUBIC

CUBIC用于快速和长距离网络

摘要

CUBIC 是一种标准的 TCP 拥塞控制算法，它使用三次函数（cubic function）而不是线性拥塞窗口增加函数来提高快速和长距离网络的可扩展性和稳定性。

CUBIC 已被 Linux、Windows 和 Apple 堆栈采用为默认的 TCP 拥塞控制算法。

本文档更新了 CUBIC 的规范，以包括基于这些实现和最近的学术工作的算法改进。

基于对CUBIC的广泛部署经验，该文档还将规范转移到标准跟踪，并废弃RFC 8312。该文档还更新了RFC 5681，以允许 CUBIC 偶尔出现更激进的发送行为。

本备忘录的状态

这是一份互联网标准跟踪文档。

本文档是 Internet 工程任务组 （IETF） 的产品。它代表了IETF社区的共识。

它已获得公众审核，并已获得互联网工程指导小组 （IESG） 的批准发布。有关 Internet 标准的更多信息，请参阅 RFC 7841 的第 2 节。

有关本文档的当前状态、任何勘误表以及如何提供有关本文档的反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9438。

版权声明

版权所有 （c） 2023 IETF Trust 和被确定为文档作者的人员。保留所有权利。

本文档受 BCP 78 和 IETF Trust 的 IETF 文档相关法律规定 （https://trustee.ietf.org/license-info） 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。

从本文档中提取的代码组件必须包含经修订的 BSD 许可证文本，如信托法律条款第 4.e 节所述，并且不提供任何保证，如经修订的 BSD 许可证中所述。

1. 引言

在Linux、Windows和Apple协议栈中，CUBIC都是默认的TCP拥塞控制算法，并在全球范围内得到部署和使用。数十年来，在各种不同的互联网场景下的广泛部署经验令人信服地证明，CUBIC在全球互联网上部署是安全的，并且比经典的 Reno 拥塞控制具有更大的优势[RFC5681]。因此，它被认为是目前应用最广泛的TCP拥塞控制标准。CUBIC也可以用于其他传输协议，如 QUIC [RFC9000]和流控制传输协议(SCTP) [RFC9260]作为默认拥塞控制器。

CUBIC的设计源于经典 Reno TCP 在快速和长距离网络上利用率低的问题[K03][RFC3649]。此问题是由于在具有大带宽延迟积 （bandwidth-delay product，BDP） 的网络中发生拥塞事件后拥塞窗口 （cwnd） 缓慢增加而引起的。[HLRX07] 表示，即使在数百个数据包的拥塞窗口大小范围内，也经常观察到此问题。这个问题同样适用于所有 Reno 风格的标准及其变体，包括TCP- reno [RFC5681]， TCP- newreno [RFC6582] [RFC6675]， SCTP [RFC9260]， TCP Friendly Rate Control (TFRC) [RFC5348]， QUIC congestion Control [RFC9002]，它们都使用相同的线性增长函数来实现窗口增长。所有Reno风格的标准及其变体在本文档中统称为“Reno”。

CUBIC最初在[HRX08]中提出，是对经典 Reno 的拥塞控制算法的修改，以解决这个问题。具体来说，CUBIC使用三次函数代替 Reno 的线性窗口增加函数，以提高快速和长距离网络下的可扩展性和稳定性。

本文档更新了 CUBIC 的规范，以包括基于 Linux、Windows 和 Apple 实现以及最近的学术工作的算法改进。基于对CUBIC的广泛部署经验，该文档还将规范转移到标准跟踪，并废弃[RFC8312]。这要求对[RFC5681]的第3节进行更新，以限制Reno TCP实现的侵略性。由于CUBIC偶尔比[RFC5681]中定义的算法更加激进，因此该文档更新了[RFC5681]第3节的第一段，将其替换为对[RFC5033]第3节准则（1）的规范引用，该准则允许CUBIC按照本文档的定义进行行为。

具体来说，在拥塞避免阶段，CUBIC 可能会比 Reno 更积极地增加拥塞窗口。根据 [RFC5681]，在避免拥塞期间，发送方每次往返时间 （RTT） 增加 cwnd 不得超过发送方最大段（SMSS）大小字节，而 CUBIC 可能会更激进地增加 cwnd。此外，CUBIC 建议将 HyStart++ 算法 [ RFC9406] 用于慢启动，该算法允许在慢启动期间将传入确认的 cwnd 增加超过 SMSS 字节，而此行为不允许作为 [RFC5681] 规定的标准行为的一部分。

二进制增加拥塞控制 （BIC-TCP， Binary Increase Congestion Control）[XHR04] 是 CUBIC 的前身，在 2005 年被 Linux 选为默认的 TCP 拥塞控制算法，并被整个互联网社区使用了好几年。

CUBIC 使用类似于 BIC-TCP 的窗口增加函数，旨在比 BIC-TCP 在带宽使用方面相对 Reno 不那么激进且更公平，同时保持 BIC-TCP 的优势，例如稳定性、窗口可扩展性和 RTT 公平性。

[RFC5033] 记录了 IETF 指定新拥塞控制算法的当前最佳实践，特别是那些与 [RFC2914] 中概述的一般拥塞控制原则不同的算法。它描述了IETF希望进行哪种类型的评估，以了解新的拥塞控制算法的适用性，以及使规范能够被批准在全球互联网上广泛部署的过程。

在某些领域，CUBIC与之前在Standards Track RFC中发布的拥塞控制算法不同;本文档中说明了这些更改。但是，这些更改是否超出了 [RFC2914] 中概述的一般拥塞控制原则并不明显，因此 [RFC5033] 中记录的过程可能不适用。

此外，CUBIC在互联网上的广泛部署是由大多数流行的操作系统直接采用推动的，并且没有遵循[RFC5033]中记录的做法。但是，由于在很长一段时间内产生的互联网规模部署经验，IETF 决定 CUBIC 可以作为标准跟踪规范发布。IETF 的这一决定不会改变 [ RFC2914] 中提供的一般指导。

以下部分：

1. 简要说明CUBIC的设计原则，

2. 提供 CUBIC 的确切规格，并且

3. 按照 [RFC5033] 中指定的指南讨论 CUBIC 的安全功能。

2. 约定

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”（“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL”）应按照 BCP 14 [ RFC2119][ RFC8174] 中的描述进行解释，当且仅当它们出现在所有大写字母中时，如下所示。

3. CUBIC设计原则

CUBIC的设计原则如下：

原则 1： 为了提高网络利用率和稳定性，CUBIC使用了三次函（cubic function）的凹凸曲线来增加拥塞窗口的大小，而不仅仅使用凸函数。

原则 2： 为了对Reno友好，CUBIC被设计成在往返时延（RTT）短、带宽小的网络中表现类似于Reno，因为Reno在这种情况下表现良好。

原则 3： 为了实现RTT公平性，CUBIC被设计成在具有不同往返时延（RTT）的流之间实现线性带宽共享。

原则 4： 为了在可扩展性和收敛速度之间实现平衡，CUBIC适当地设置其乘法窗口减小因子。

3.1 原则1 CUBIC增加函数

为了更好的网络利用率和稳定性，CUBIC [HRX08]根据上一次拥塞事件经过的时间使用了一个立方窗口增加函数（cubic window increase function）。虽然大多数提供 Reno 替代方案的拥塞控制算法都使用凸函数来增加拥塞窗口，但 CUBIC 同时使用三次函数的凹面和凸面来增加窗口。

在检测到由于重复确认(ACK)引起的拥塞事件、ECN-Echo (ECE) ACK [RFC3168]、RACK-TLP for TCP [RFC8985]或QUIC丢包检测[RFC9002]后，CUBIC会对拥塞窗口进行窗口缩小来响应。CUBIC会记录收到拥塞事件时的拥塞窗口大小，并对拥塞窗口进行乘法缩小。当CUBIC进入拥塞避免阶段时，它开始使用凹曲线的立方函数(cubic function)配置来增加拥塞窗口。将三次函数设置为在记忆的拥塞窗口大小处保持稳定，以便凹窗口增加一直持续到那时。之后，三次函数变成凸轮廓，凸窗开始增加。

这种窗口调整方式（先凹后凸）提高了算法的稳定性，同时保持了较高的网络利用率 [ CEHRX09]。这是因为窗口大小几乎保持不变，在上一个拥塞事件的记忆拥塞窗口大小周围形成一个平台，其中网络利用率被认为是最高的。在稳态下，CUBIC的大多数窗口大小样本都接近记忆的拥塞窗口大小，从而促进了较高的网络利用率和稳定性。

请注意，仅使用凸函数来增加拥塞窗口大小的拥塞控制算法，其最大增量集中在上次拥塞事件的记忆拥塞窗口大小周围，因此会在网络饱和点附近引入许多数据包突发，可能导致频繁的全局丢包同步。

3.2 原则2 Reno友好（for Reno-Friendliness）

CUBIC 提升了 Reno 每条流的公平性。请注意，Reno 在具有较小 BDP 的路径上表现良好，并且仅在尝试在具有较大 BDP 的路径上提高带宽利用率时才遇到问题。

一个设计成对Reno友好的拥塞控制算法，在小BDP（带宽延迟乘积）的网络中应该比在大BDP的网络中更谨慎地增加其拥塞窗口大小。

CUBIC的激进程度主要取决于窗口缩小前的最大窗口大小，在小BDP（带宽延迟乘积）的网络中比在大BDP的网络中要小。因此，在小BDP的网络中，CUBIC比在大BDP的网络中更谨慎地增加其拥塞窗口大小。

此外，在CUBIC的立方函数比Reno更谨慎地增加拥塞窗口的情况下，CUBIC会简单地跟随Reno的窗口大小，以确保CUBIC在小BDP（带宽延迟乘积）网络中至少达到与Reno相同的吞吐量。
CUBIC表现得像Reno的区域被称为“Reno友好区域（Reno-friendly region）”。

3.3 原则3 RTT公平性

具有不同 RTT（往返时间） 的两个 CUBIC 流的吞吐量比率与其 RTT 比率的倒数成线性比例，其中流量的吞吐量大约是其拥塞窗口的大小除以其 RTT。

具体而言，在Reno友好区域（Reno-friendly region）之外，CUBIC保持窗口增加速率与RTT无关，因此当它们在Reno友好区域之外运行时，具有不同RTT的流在稳定状态下具有类似的拥塞窗口大小。

这种线性吞吐量比的概念类似于在异步丢包模型下的Reno，其中具有不同RTT的流具有相同的丢包率，但在不同的时间经历丢包事件。然而，在同步丢包模型下，具有不同RTT的流在相同时间经历丢包事件，但具有不同的丢包率，Reno流的吞吐量比与其RTT比的倒数成二次比例关系 [XHR04]。

CUBIC始终确保一个与丢包环境无关的线性吞吐量比。这比Reno更优秀。虽然对于不同RTT流的最佳吞吐量比率还没有得到共识，但是在有线互联网路径上，使用线性吞吐量比似乎比平等吞吐量（即具有不同RTT的流获得相同的吞吐量）或更高阶的吞吐量比（例如，在同步丢包环境中的Reno的二次吞吐量比）更为合理。

3.4 原则4 CUBIC减少因子

为了在可扩展性和收敛速度之间取得平衡，CUBIC 将乘法窗口递减系数设置为 0.7，而 Reno 使用 0.5。

虽然这提高了CUBIC的可扩展性，但这个决策的一个副作用是更慢的收敛，特别是在低统计复用情况下。这个设计选择是基于以下观察所做出的：当前的互联网在高统计复用情况下变得更加异步，丢包同步更少，类似于HighSpeed TCP（HSTCP）[RFC3649]和其他方法（例如[GV02]）的情况。

在这种环境下，即使采用严格的乘法递增乘法递减（MIMD）算法，CUBIC仍然能够收敛。具有相同往返时延（RTT）的CUBIC流无论统计复用的情况如何，总是会独立地收敛到相同的吞吐量，从而实现了算法内部的公平性。在具有足够统计复用的环境中，CUBIC的收敛速度是合理的。

4. CUBIC拥塞控制

本节讨论如何在 CUBIC 拥塞控制器的不同阶段更新拥塞窗口。

4.1. 定义

本文档中所有窗口大小的单位是SMSS的段大小，所有时间的单位是秒。实现可以使用字节来表示窗口大小，这将需要在必要的地方考虑到SMSS，并将segments_acked（图4）替换为已确认字节的数量。

4.1.1. 感兴趣的常量

• ${\beta }_{cubic}$ ：第 4.6 节中所述的 CUBIC 乘法递减因子。

• ${\alpha }_{cubic}$：CUBIC加法增量因子，如第4.3节中所述，在Reno友好区域（Reno-friendly region）中使用。

• C: 决定CUBIC在高BDP网络中与其他拥塞控制算法竞争程度的常量。请参阅第5节，了解有关如何设置该常量的更多说明。C的单位为:
  

4.1.2. 感兴趣的变量

本节定义了实现 CUBIC 所需的变量：

• RTT：平滑的往返时间（以秒为单位），计算方式如 [ RFC6298] 中所述。

• cwnd：当前拥塞窗口（以segment为单位）

• ssthresh：当前慢启动阈值（以segment为单位）。

• ${cwnd}_{prior}$: 最近设置 ssthresh 时 cwnd 的大小（以segment为单位），无论是在退出第一个慢启动时还是在 cwnd 在最后一个拥塞事件中减少之前。

• $W_{max}$: 禁用快速收敛时，在上一次拥塞事件中，cwnd 在 cwnd 减少之前段中 cwnd 的大小（与拥塞事件的 ${cwnd}_{prior}$ 相同）。但是，如果启用快速收敛，则可能会根据当前饱和点进一步降低$W_{max}$

• K：将当前拥塞避免阶段开始时的拥塞窗口大小增加到$W_{max}$所需的时间段（以秒为单位）。

• $t_{current}$ ：系统的当前时间，以秒为单位。

• $t_{epoch}$ ：当前拥塞避免阶段开始的时间（以秒为单位）。

• ${cwnd}_{epoch}$ ：当前拥塞避免阶段开始时的 cwnd，即在时间$t_{epoch}$处。

• $W_{cubic（t）}$：基于三次递增函数的时间 t 处以秒为单位的拥塞窗口（以segment为单位），如第 4.2 节所述。

• target: 下一个往返时间（RTT）后的拥塞窗口目标值，即 $W_{cubic}$（t+RTT），如第4.2节所述。

• $W_{est}$ ：对 Reno 友好区域中段的拥塞窗口的估计值，即对 Reno 拥塞窗口的估计值。

• segments_acked: 当收到“新的ACK”时，即累积确认先前未确认的已发送的数据时，所确认的SMSS大小的片段个数。当新 ACK 确认非 SMSS 大小的数据量时，此数字将是一个十进制值。具体而言，当新 ACK 确认小于 SMSS 的段时，它可以小于 1。

4.2. 窗口增加函数

CUBIC 通过仅在接收新 ACK 时增加拥塞窗口来维护 Reno 的 ACK 时钟。它不会对 TCP 快速恢复和快速重传算法 [ RFC6582][ RFC6675] 进行任何更改。

在避免拥塞期间，在检测到第 3.1 节所述的拥塞事件后，CUBIC 使用不同于 Reno 的窗口增加函数。

CUBIC 使用以下窗口增加函数：

图1

其中 t 是从当前拥塞避免阶段开始经过的时间（以秒为单位），即

其中 t epoch 是当前拥塞避免阶段开始的时间。K 是上述函数在没有进一步的拥塞事件的情况下将当前拥塞避免阶段开始时的拥塞窗口大小增加到 $W_{max}$ 所花费的时间段。K 使用以下公式计算：

图2

其中 ${CWND}_{epoch}$ 是当前拥塞避免阶段开始时的拥塞窗口。

在拥塞避免阶段收到新的ACK时，CUBIC会使用图1计算下一个RTT后的目标拥塞窗口大小，其中RTT是平滑的往返时延。下面的下界和上界保证CUBIC的拥塞窗口增长率不下降，并且小于慢启动的增长率[SXEZ19]。

在图1中，经过的时间t不应包括由于应用程序受限行为（见第5.8节）导致cwnd未更新的时间段。

根据当前拥塞窗口大小 cwnd 的值，CUBIC 在三个不同的区域运行：

1. Reno友好型(Reno-friendly)区域，确保 CUBIC 至少实现与Reno相同的吞吐量。
2. 凹区域，如果 CUBIC 不在 Reno 友好区域且 cwnd 小于 $W_{max}$ 。
3. 凸区域，如果 CUBIC 不在 Reno 友好区域且 cwnd 大于 $W_{max}$ 。

总而言之，CUBIC 在接收新的 ACK 以避免拥塞时同时计算 $W_{cubic}$（t） 和 $W_{est}$ （参见第 4.3 节），并选择两个值中较大的一个。

下一节将介绍CUBIC在每个地区采取的确切行动。

4.3. Reno友好区域

Reno 在某些类型的网络中表现良好，例如，在短 RTT 和小带宽（或小 BDP）下。在这些网络中，CUBIC保持在里诺友好区域，以达到至少与 Reno 相同的吞吐量。

Reno友好区域是根据[FHP00]中讨论的分析设计的，该分析研究了一种带有α（每个RTT的分段数）加法因子和β乘法因子的AIMD算法，称为AIMD(α, β)。p是数据包丢失率。具体来说，可以使用图3计算AIMD(α, β)的平均拥塞窗口大小。

图3

根据同样的分析，要实现与使用AIMD（1, 0.5）的Reno相似的平均窗口大小，α必须等于

因此，CUBIC 使用图 4 来估计 Reno 友好区域的窗口大小 $W_{est}$ ，其中

在许多情况下，它实现了与Reno几乎相同的平均窗口大小。用于计算 ${\alpha }_{cubic}$ 的模型并不绝对准确，但是在[AIMD-friendliness]中讨论的分析和模拟，以及对公共互联网上CUBIC进行了十多年的实践经验表明，这种方法在CUBIC和Reno流之间产生了可接受的速率公平水平。同时，还没有报告这种模型的显著缺点。然而，对这种方法的持续详细分析将是有益的。在拥塞避免阶段收到新的ACK时（其中cwnd可能大于或小于$Wmax$），CUBIC会检查$Wcubic$(t)是否小于$W_{est}$。如果是这样，说明CUBIC处于Reno友好区域，建议在每次收到新的ACK时将cwnd设置为$W_{est}$。

$W_{est}$在拥塞避免阶段开始时设置为等于 ${cwnd}_{epoch}$ 。之后，在每个新的 ACK 上，$W_{est}$都会使用图 4 进行更新。请注意，此方程使用 segments_acked，cwnd 以段为单位进行测量。以字节为单位测量 cwnd 的实现应使用已确认的字节数和 SMSS 相应地调整公式。另请注意，此等式适用于启用或禁用延迟 ACK [RFC5681] 的连接，因为根据新 ACK 实际确认的段，segments_acked会有所不同

图4

一旦$W_{est}$增长到达最近设置ssthresh时的cwnd，即$W_{est}$ >= ${cwnd}_{prior}$，发送方应将${\alpha }_{cubic}$设置为1，以确保其可以实现与使用AIMD（1，0.5）的Reno相同的拥塞窗口增量率。

接下来的两节假设 CUBIC 不在 Reno 友好区域中，并使用第 4.2 节中描述的窗口增加函数。尽管凹面和凸面区域的 cwnd 以相同的方式递增，但为了分析和理解这两个区域之间的差异，将分别讨论它们。

4.4. 凹区

在避免拥塞时接收新的 ACK 时，如果 CUBIC 不在 Reno 友好区域且 cwnd 小于 $W_{max}$，则 CUBIC 位于凹区域。在此区域中，cwnd 必须按以下递增

对于每个收到的新 ACK，其中目标按第 4.2 节所述计算。

4.5. 凸区域

当接收到新的 ACK 以避免拥塞时，如果 CUBIC 不在 Reno 友好区域，并且 cwnd 大于或等于 $W_{max}$ ，则 CUBIC 位于凸区域。

凸区域表示自上次拥塞事件以来，网络条件可能已更改，可能意味着某些数据流离开后有更多可用带宽。由于互联网高度异步，一定程度的干扰总是可能的，而不会导致可用带宽发生重大变化。

除非 cwnd 被 AIMD 窗口增加覆盖，否则 CUBIC 在该区域运行时将谨慎行事。凸面的目的是在开始时非常缓慢地增加窗口，当 cwnd 在 $W_{max}$ 附近时，然后逐渐增加其增加速率。该区域也称为“最大探测阶段”，因为CUBIC正在寻找新的$W_{max}$。在此区域中，cwnd 必须按如下方式递增

对于每个收到的新 ACK，其中目标按第 4.2 节所述计算。

4.6 乘法减小

当检测到拥塞事件时，根据第3.1节中描述的机制，CUBIC会立即更新$W_{max}$，并减小cwnd和ssthresh，具体如下所述。在丢包情况下，发送方必须立即在进入丢包恢复状态时减小cwnd和ssthresh，类似于[RFC5681]（和[RFC6675]）。注意，在丢包恢复过程中可以使用其他机制，例如比例速率减小[RFC6937]，以更渐进的方式减小发送速率。参数${\beta }_{cubic}$应设为0.7，这与[RFC5681]（和[RFC6675]）中在快速恢复阶段使用的乘法减小因子不同。

在图5中，flight_size是网络中未确认的数据量，根据[RFC5681]的定义。请注意，对于有速率限制的应用程序，其在空闲期间或无法以cwnd允许的最大速率发送数据的时段，可能会导致从一个RTT到另一个RTT发送的数据量出现明显的变化，从而导致在拥塞事件发生时，flight_size明显小于cwnd。因此，拥塞响应会将cwnd减小到比实际需要的更低的值。为了避免这种次优的性能，可以使用[RFC7661]中描述的机制。[RFC7661]描述了如何在速率限制的间隔期管理和使用cwnd和ssthresh，在检测到拥塞后如何更新cwnd和ssthresh。[RFC7661]中定义的机制即使在cwnd大于接收窗口时也可以安全使用，因为它们基于网络在一个RTT中确认的数据量来验证cwnd，这隐含地考虑了允许的接收窗口。

一些CUBIC的实现目前在计算新的ssthresh时使用cwnd而不是flight_size。在实现使用cwnd时，如果在途字节（bytes in flight）的数据量小于cwnd，则必须采取其他措施防止cwnd增大。这也有效防止cwnd增长超过接收窗口。这些措施对于防止在检测到拥塞时CUBIC发送方使用任意高的cwnd值来计算新的ssthresh和cwnd值非常重要。这可能不如[RFC7661]中描述的机制稳健。

QUIC发送端在检测到拥塞事件后，使用cwnd值计算cwnd和ssthresh的新值，这需要应用类似的机制[RFC9002]。

图5

将${\beta }_{cubic}$设置为大于0.5的副作用是，在某些情况下，数据包丢失可能会发生超过一个往返时间（RTT），但在其他情况下它可以有效工作 - 例如，当HyStart++ [RFC9406]与CUBIC一起使用时，或者当发送速率受应用程序限制时。尽管更自适应的${β}_{cubic}设置可以帮助将数据包丢失限制为单个回合，但需要进行详细分析和大规模评估来验证这样的算法。

请注意，CUBIC 必须继续减少 cwnd 以响应 ECN-Echo ACK 检测到的拥塞事件，直到它达到 1 SMSS 的值。如果 ECN-Echo ACK 指示的拥塞事件持续存在，则 cwnd 为 1 SMSS 的发送方必须进一步降低其发送速率。这可以通过使用具有指数退避的重传计时器来实现，如 [RFC3168] 中所述。

4.7. 快速收敛

为了提高收敛速度，CUBIC使用启发式方法。当新流加入网络时，现有流需要放弃部分带宽，以便在现有流已使用所有网络带宽的情况下为新流留出一些增长空间。为了加快现有流的带宽释放速度，应实现以下快速收敛机制。

通过快速收敛，当发生拥塞事件时，$W_{max}$ 将按如下方式更新，在第 4.6 节中描述的窗口减少之前。

在拥塞事件发生时，如果当前的拥塞窗口大小小于 $W_{max}$，则说明该流量所经历的饱和点正在减小，因为可用带宽发生了变化。通过进一步减小$W_{max}$，该流量可以释放更多带宽。这个动作有效地延长了该流量增加拥塞窗口的时间，因为减小的$W_{max}$迫使流量更早地进入平稳状态。这样可以为新的流量提供更多时间来追赶其拥塞窗口大小。

快速收敛专为具有多个 CUBIC 流的网络环境而设计。在只有单个 CUBIC 流且没有任何其他流量的网络环境中，应禁用快速收敛。

4.8. 超时

在超时的情况下，CUBIC按照Reno的方式减小拥塞窗口cwnd[RFC5681]，但在设置慢启动门限ssthresh时，使用与Reno TCP[RFC5681]不同的${\beta }_{cubic}$方法（与第4.6节相同）。

在超时后的第一个拥塞避免阶段，CUBIC 使用图 1 增加其拥塞窗口大小，其中 t 是自当前拥塞避免阶段开始以来经过的时间，K 设置为 0，$W_{max}$ 设置为当前拥塞避免阶段开始时的拥塞窗口大小。此外，对于 Reno 友好区域，应将$W_{est}$设置为当前拥塞避免阶段开始时的拥塞窗口大小。

4.9. 虚假拥塞事件

在CUBIC通过重复ACK或超时检测到丢包而减少其拥塞窗口的情况下，丢失的ACK有可能在拥塞窗口减少和相应的分组重传之后到达。例如，包的重新排序可能会触发这种行为。高度的数据包重排序会导致多个拥塞窗口减少事件，其中虚假的丢包会被错误地解释为拥塞信号，从而显著降低CUBIC的性能。

对于 TCP，有两种类型的虚假事件：虚假超时和虚假快速重传。在 QUIC 的情况下，没有虚假超时，因为只有在收到 ACK 后才会检测到丢失。

4.9.1. 虚假超时

实现可以根据前向 RTO 恢复 [RFC5682] 中描述的机制检测虚假超时。实验替代方案包括 Eifel 检测算法 [RFC3522]。当检测到虚假超时时，TCP 实现可以遵循 [RFC4015] 中描述的响应算法来恢复拥塞控制状态并调整重传计时器以避免进一步的虚假超时。

4.9.2. 虚假快速重传

收到ACK后，TCP实现可以通过TCP时间戳或D-SACK [RFC2883]来检测虚假的快速重传。正如上面所述，实验性替代方案包括使用TCP时间戳的Eifel检测算法[RFC3522]和使用DSACK信息的DSACK检测[RFC3708]。如果QUIC数据包被标记为丢失，原始数据已经通过新的QUIC数据包进行了重传，而QUIC数据包在被确认后，QUIC实现可以轻松确定虚假的快速重传。

本部分指定通过确认检测到虚假快速重传时的简单响应算法。实现需要仔细评估在可能经历可用容量突然变化（例如，由于可变无线电容量、路由更改或移动事件）的不同环境中使用此算法的影响。

当通过确认（ACK）检测到数据包丢失时，CUBIC 实现可以在减少拥塞窗口之前保存以下变量的当前值。

一旦先前声明的丢包被确认为虚假，如果当前拥塞窗口cwnd低于${cwnd}_{prior}$，CUBIC可以通过以下方式恢复上述变量的原始值。恢复原始值可确保CUBIC的性能与没有虚假损失时的性能相似。

在极少数情况下，当检测发生在虚假的快速重传事件很久之后，并且当前cwnd已经高于${cwnd}_{prior}$时，CUBIC应继续使用这些变量的当前值和最新值。

4.10. 慢启动

当cwnd不超过ssthresh时，CUBIC必须采用慢启动算法。通常情况下，CUBIC应该使用HyStart++慢启动算法[RFC9406]，或者在HyStart++不适用的罕见情况下，可以使用Reno TCP慢启动算法[RFC5681]。实验性的替代算法包括混合慢启动[HR11]，这是HyStart++的前身，一些CUBIC实现已将其作为默认算法使用了十年，以及有限慢启动[RFC3742]。无论使用哪种启动算法，都可能需要努力确保慢启动的结束和拥塞避免的第一次乘法减少能够很好地协同工作。

当CUBIC使用HyStart++ [RFC9406]时，它可能在不遭受任何数据包丢失的情况下退出第一个慢启动阶段，因此$W_{max}$未定义。在这种特殊情况下，CUBIC设置cwnd = ${cwnd}_{prior}$，并切换到拥塞避免。然后，它使用图1增加其拥塞窗口大小，其中t是自当前拥塞避免阶段开始以来的经过的时间，K设为0，$W_{max}$设为当前拥塞避免阶段开始时的拥塞窗口大小。

5. 讨论

本节进一步讨论了CUBIC的安全特性，遵循[RFC5033]中指定的准则。

采用确定性丢包模型，两个连续丢包之间的数据包数量始终为1/p，CUBIC始终采用凹形窗口轮廓，这极大地简化了对CUBIC性能的分析。CUBIC的平均窗口大小（见附录B）可以通过以下函数计算得到：

图6

当 ${\beta }_{cubic}$ 设置为 0.7 时，上述公式简化为

下面的小节将使用图7确定C的值。

5.1. 对 Reno 的公平性

在 Reno 能够合理利用可用带宽的环境中，CUBIC 不会显著改变此状态。

Reno 在以下两种类型的网络中表现良好：

1. 具有小带宽延迟积 （BDP） 的网络
2. 具有短 RTT 但不一定是小 BDP 的网络

CUBIC被设计成在上述两种网络中的行为非常类似于Reno。下面的两个表格展示了Reno TCP、HSTCP和CUBIC TCP的平均窗口大小。Reno TCP和HSTCP的平均窗口大小来自[RFC3649]。CUBIC的平均窗口大小使用图7和CUBIC Reno-friendly区域在三个不同的C值下计算。

表 1：RTT = 0.1 秒的 Reno TCP、HSTCP 和 CUBIC

表 1 描述了 RTT = 0.1 秒网络中 Reno TCP、HSTCP 和 CUBIC 的响应函数。平均窗口大小以 SMSS 大小的段为单位。

表 2：RTT = 0.01 秒的 Reno TCP、HSTCP 和 CUBIC

表 2 描述了 RTT = 0.01 秒网络中 Reno TCP、HSTCP 和 CUBIC 的响应函数。平均窗口大小以 SMSS 大小的段为单位。

两个表格都显示，使用任何一个C值的CUBIC相比HSTCP对Reno TCP更友好，尤其是在RTT较短的网络中，Reno TCP表现得比较出色。例如，在RTT=0.01秒和p=${10}^{-6}$的网络中，Reno TCP的平均窗口为1200个数据包。如果数据包大小为1500字节，则Reno TCP可以实现平均速率为1.44 Gbps。在这种情况下，C=0.04或C=0.4的CUBIC实现的速率与Reno TCP完全相同，而HSTCP比Reno TCP更激进约十倍。

C决定了CUBIC在与其他拥塞控制算法争夺带宽时的攻击性程度。如果C的值较低，CUBIC对Reno TCP更为友好。然而，不建议将C设置为非常低的值，如0.04，因为低C的CUBIC在快速和长距离网络中无法高效利用带宽。基于这些观察和广泛的部署经验，C=0.4似乎在Reno友好性和窗口增加的攻击性之间提供了良好的平衡。因此，C应该设置为0.4。将C设置为0.4后，图7 简化为。

图8

然后在下一小节中使用图8来展示CUBIC的可扩展性。

5.2. 使用空闲容量

CUBIC在快速和远程网络中使用比Reno更激进的窗口增加函数。

表 3 显示，要达到 10 Gbps 的速率，Reno TCP 需要 2.0e-10 的丢包率，而 CUBIC TCP 需要 2.9e-8 的丢包率。

表 3：Reno TCP、HSTCP 和 CUBIC 实现特定吞吐量所需的丢包率

表 3 描述了 Reno TCP、HSTCP 和 CUBIC 在 1500 字节数据包和 0.1 秒的 RTT 下实现一定吞吐量所需的丢包率。

[HLRX07]中提供的测试结果表明，在具有一定程度的后台流量的典型情况下，CUBIC使用同一瓶颈链路中现有Reno TCP流未使用的空闲带宽，而不会从现有流中占用太多带宽。

5.3. 困难的环境

CUBIC旨在弥补Reno在快速和长距离网络中的不良性能。

5.4. 调查一系列环境

CUBIC已通过仿真、测试台仿真、互联网实验和互联网测量进行了广泛的研究，涵盖了广泛的网络环境[HLRX07][H16][CEHRX09][HR11][BSCLU13][LBEWK16]。他们已经令人信服地证明，与传统的Reno拥塞控制相比，CUBIC具有实质性的优势[RFC5681]。

与Reno一样，CUBIC是一种基于丢包的拥塞控制算法。由于在快速和长距离网络中，CUBIC被设计得比Reno更为激进（由于其更快的窗口增量函数和更大的乘性减少因子），它可以比Reno更快地填充大型drop-tail缓冲区，并增加了出现standing queue的风险[RFC8511]。在这种情况下，可以使用适当的队列大小和管理[RFC7567]来在一定程度上减轻风险并减少数据包排队延迟。此外，在大BDP网络中经历拥塞事件后，由于其立方窗口增量函数，CUBIC可以快速恢复到最高链路利用率点。这意味着链路利用率对于低于整个锯齿的振幅的主动队列管理（AQM：active queue management）目标不太敏感。

与 Reno 类似，CUBIC 作为一种基于丢失的拥塞控制算法，在数据包丢失不能很好地指示带宽利用率的网络（例如无线或移动网络）中的性能会受到影响 [LIU16]。

5.5. 防止拥塞崩溃

就可能导致拥塞崩溃的潜在影响而言，CUBIC的行为与Reno相似，因为CUBIC只修改了Reno的窗口调整算法。它并没有修改Reno的ACK定时和超时行为。

CUBIC 还满足 [RFC5033] 中所述的“完全退避”要求。在响应 ECN-Echo ACK 检测到的拥塞事件将发送速率降低到每个 RTT 一个数据包后，CUBIC 会在拥塞持续存在时以指数方式增加每个数据包重传的传输计时器。

5.6. 替代拥塞控制算法中的公平性

CUBIC确保在相同瓶颈链路上具有相同RTT的竞争CUBIC流收敛到相等的吞吐量。当竞争流具有不同的RTT值时，它们的吞吐量比例与它们的RTT比例的倒数成线性关系。这是事实，并且与链路上的统计多路复用级别无关。收敛时间取决于网络环境（例如，带宽，RTT）和统计多路复用级别，如第 3.4 节所述。

5.7. 行为异常节点和外部攻击者的性能

CUBIC不会引入新的实体或信号，因此它对行为不端的节点或攻击者的脆弱性与Reno相同。

5.8. 应用程序受限流的行为

如果当前发送的流量小于拥塞窗口允许的流量，则该流量受到应用程序限制。如果流量受到发送端应用程序或接收端应用程序(通过接收端发布的窗口)的限制，从而发送的数据比发送端拥塞窗口允许的数据少，就会发生这种情况。

CUBIC不会在流受应用限制时增加其拥塞窗口。根据第4.2节的要求，图1中的t不应包括应用限制期，例如空闲期；否则，在从这些期间重新启动后，$W_{cubic}$(t)可能会非常高。

5.9. 对突发或瞬态事件的响应

如果容量突然增加，例如，由于可变的无线电容量、路由更改或移动事件，CUBIC旨在比Reno更快地利用新的可用容量。

另一方面，如果容量突然减少，CUBIC 的减少速度比 Reno 慢。无论 CUBIC 是否处于 Reno 友好模式，也无论是否启用了快速收敛，这都是如此。

5.10. 增量部署

CUBIC 只需要更改发送方的拥塞控制，不需要对接收方进行任何更改。也就是说，CUBIC发送端可以与Reno接收端正常工作。另外，CUBIC不需要对路由器进行任何改动，也不需要从路由器获取任何帮助。

6. 安全注意事项

CUBIC 不会对传输协议的底层安全性进行任何更改，并继承 [RFC5681] 中描述的一般安全问题。具体而言，更改发送方的窗口计算可能允许攻击者通过删除或注入 ACK（如 [RFC5681] 中所述）强制 CUBIC 实现减少其带宽，或者在确实存在拥塞时使其确信不存在拥塞，并使用 CUBIC 实现作为针对其他主机的攻击媒介。这些攻击对于CUBIC来说并不新鲜，而且是任何传输协议(如TCP)固有的一部分。

7. IANA 考量

本文档不需要执行任何 IANA 操作。

8. 参考资料

8.1. 规范性引用

[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.
[RFC2883]
Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, “An Extension to the Selective Acknowledgement (SACK) Option for TCP”, RFC 2883, DOI 10.17487/RFC2883, July 2000, https://www.rfc-editor.org/info/rfc2883.
[RFC2914]
Floyd, S., “Congestion Control Principles”, BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, https://www.rfc-editor.org/info/rfc2914.
[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.
[RFC4015]
Ludwig, R. and A. Gurtov, “The Eifel Response Algorithm for TCP”, RFC 4015, DOI 10.17487/RFC4015, February 2005, https://www.rfc-editor.org/info/rfc4015.
[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.
[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.
[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.
[RFC5682]
Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, “Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP”, RFC 5682, DOI 10.17487/RFC5682, September 2009, https://www.rfc-editor.org/info/rfc5682.
[RFC6298]
Paxson, V., Allman, M., Chu, J., and M. Sargent, “Computing TCP’s Retransmission Timer”, RFC 6298, DOI 10.17487/RFC6298, June 2011, https://www.rfc-editor.org/info/rfc6298.
[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.
[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.
[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.
[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.
[RFC8985]
Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, “The RACK-TLP Loss Detection Algorithm for TCP”, RFC 8985, DOI 10.17487/RFC8985, February 2021, https://www.rfc-editor.org/info/rfc8985.
[RFC9002]
Iyengar, J., Ed. and I. Swett, Ed., “QUIC Loss Detection and Congestion Control”, RFC 9002, DOI 10.17487/RFC9002, May 2021, https://www.rfc-editor.org/info/rfc9002.
[RFC9406]
Balasubramanian, P., Huang, Y., and M. Olson, “HyStart++: Modified Slow Start for TCP”, RFC 9406, DOI 10.17487/RFC9406, May 2023, https://www.rfc-editor.org/info/rfc9406.

8.2. 信息参考

[AIMD-friendliness]
Briscoe, B. and O. Albisser, “Friendliness between AIMD Algorithms”, DOI 10.48550/arXiv.2305.10581, May 2023, https://arxiv.org/abs/2305.10581.
[BSCLU13]
Belhareth, S., Sassatelli, L., Collange, D., Lopez-Pacheco, D., and G. Urvoy-Keller, “Understanding TCP cubic performance in the cloud: A mean-field approach”, 2013 IEEE 2nd International Conference on Cloud Networking (CloudNet), DOI 10.1109/cloudnet.2013.6710576, November 2013, https://doi.org/10.1109/cloudnet.2013.6710576.
[CEHRX09]
Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, “Stochastic convex ordering for multiplicative decrease internet congestion control”, Computer Networks, vol. 53, no. 3, pp. 365-381, DOI 10.1016/j.comnet.2008.10.012, February 2009, https://doi.org/10.1016/j.comnet.2008.10.012.
[FHP00]
Floyd, S., Handley, M., and J. Padhye, “A Comparison of Equation-Based and AIMD Congestion Control”, May 2000, https://www.icir.org/tfrc/aimd.pdf.
[GV02]
Gorinsky, S. 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, https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=1828bdcef118b02d3996b8e00b8aaa92b50abb0f.
[H16]
Ha, S., “Deployment, Testbed, and Simulation Results for CUBIC”, Wayback Machine archive, 3 November 2016, https://web.archive.org/web/20161118125842/http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing.
[HLRX07]
Ha, S., Le, L., Rhee, I., and L. Xu, “Impact of background traffic on performance of high-speed TCP variant protocols”, Computer Networks, vol. 51, no. 7, pp. 1748-1762, DOI 10.1016/j.comnet.2006.11.005, May 2007, https://doi.org/10.1016/j.comnet.2006.11.005.
[HR11]
Ha, S. and I. Rhee, “Taming the elephants: New TCP slow start”, Computer Networks, vol. 55, no. 9, pp. 2092-2110, DOI 10.1016/j.comnet.2011.01.014, June 2011, https://doi.org/10.1016/j.comnet.2011.01.014.
[HRX08]
Ha, S., Rhee, I., and L. Xu, “CUBIC: a new TCP-friendly high-speed TCP variant”, ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 64-74, DOI 10.1145/1400097.1400105, July 2008, https://doi.org/10.1145/1400097.1400105.
[K03]
Kelly, T., “Scalable TCP: improving performance in highspeed wide area networks”, ACM SIGCOMM Computer Communication Review, vol. 33, no. 2, pp. 83-91, DOI 10.1145/956981.956989, April 2003, https://doi.org/10.1145/956981.956989.
[LBEWK16]
Lukaseder, T., Bradatsch, L., Erb, B., Van Der Heijden, R., and F. Kargl, “A Comparison of TCP Congestion Control Algorithms in 10G Networks”, 2016 IEEE 41st Conference on Local Computer Networks (LCN), DOI 10.1109/lcn.2016.121, November 2016, https://doi.org/10.1109/lcn.2016.121.
[LIU16]
Liu, K. and J. Lee, “On Improving TCP Performance over Mobile Data Networks”, IEEE Transactions on Mobile Computing, vol. 15, no. 10, pp. 2522-2536, DOI 10.1109/tmc.2015.2500227, October 2016, https://doi.org/10.1109/tmc.2015.2500227.
[RFC3522]
Ludwig, R. and M. Meyer, “The Eifel Detection Algorithm for TCP”, RFC 3522, DOI 10.17487/RFC3522, April 2003, https://www.rfc-editor.org/info/rfc3522.
[RFC3649]
Floyd, S., “HighSpeed TCP for Large Congestion Windows”, RFC 3649, DOI 10.17487/RFC3649, December 2003, https://www.rfc-editor.org/info/rfc3649.
[RFC3708]
Blanton, E. and M. Allman, “Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions”, RFC 3708, DOI 10.17487/RFC3708, February 2004, https://www.rfc-editor.org/info/rfc3708.
[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.
[RFC6937]
Mathis, M., Dukkipati, N., and Y. Cheng, “Proportional Rate Reduction for TCP”, RFC 6937, DOI 10.17487/RFC6937, May 2013, https://www.rfc-editor.org/info/rfc6937.
[RFC7661]
Fairhurst, G., Sathiaseelan, A., and R. Secchi, “Updating TCP to Support Rate-Limited Traffic”, RFC 7661, DOI 10.17487/RFC7661, October 2015, https://www.rfc-editor.org/info/rfc7661.
[RFC8312]
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, “CUBIC for Fast Long-Distance Networks”, RFC 8312, DOI 10.17487/RFC8312, February 2018, https://www.rfc-editor.org/info/rfc8312.
[RFC8511]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, “TCP Alternative Backoff with ECN (ABE)”, RFC 8511, DOI 10.17487/RFC8511, December 2018, https://www.rfc-editor.org/info/rfc8511.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.
[RFC9260]
Stewart, R., Tüxen, M., and K. Nielsen, “Stream Control Transmission Protocol”, RFC 9260, DOI 10.17487/RFC9260, June 2022, https://www.rfc-editor.org/info/rfc9260.
[SXEZ19]
Sun, W., Xu, L., Elbaum, S., and D. Zhao, “Model-Agnostic and Efficient Exploration of Numerical Congestion Control State Space of Real-World TCP Implementations”, IEEE/ACM Transactions on Networking, vol. 29, no. 5, pp. 1990-2004, DOI 10.1109/tnet.2021.3078161, October 2021, https://doi.org/10.1109/tnet.2021.3078161.
[XHR04]
Xu, L., Harfoush, K., and I. Rhee, “Binary increase congestion control (BIC) for fast long-distance networks”, IEEE INFOCOM 2004, DOI 10.1109/infcom.2004.1354672, March 2004, https://doi.org/10.1109/infcom.2004.1354672.

附录 A. CUBIC自原始论文以来的演变

CUBIC自其算法和实现的初始版本[HRX08]以来经历了一些变化。本附录重点介绍了原论文与[RFC8312]的区别。

• 原始论文[HRX08]包含使用Linux的可插式拥塞控制框架实现CUBIC的伪代码，其中不包括特定于系统的优化。简化的伪代码可能是学习CUBIC的一个很好的起点。

• [HRX08]还包括实验结果，显示了其性能和公平性。

• ${\beta }_{cubic}$常数的定义在[RFC8312]中发生了变化。例如，在原始论文中，${\beta }_{cubic}$被称为窗口减小常数，而[RFC8312]将其改为"CUBIC乘法减小因子"。随着这个改变，[RFC8312]中列出的拥塞事件后的当前拥塞窗口大小为${\beta }_{cubic}$ * $W_{max}，而在原始论文中是(1-${β}{cubic}$) * ${W}{max}。

• 它的伪代码使用$W_{last\_max}$，而[RFC8312]使用$W_{max}$ 。

• 它的AIMD友好窗口是$W_{tcp}$，而[RFC8312]使用的是$W_{est}$。

附录 B. 平均 CUBIC 窗口大小的证明

该附录中包含了对图6中的平均CUBIC窗口大小${AV{G}_W}_{cubic}$的证明。

我们在确定性丢包模型下发现了${AV{G}_W}_{cubic}$，其中连续两次丢包之间的数据包数量为1/p。在该模型下，CUBIC始终以凹形窗口轮廓运行，连续两次丢包之间的时间间隔为K。

平均窗口大小${AV{G}_W}_{cubic}$定义如下，其中分子1/p是连续两个数据包丢失之间的总数据包数，分母K/RTT是连续两个数据包丢失之间的总往返时间数。

图9

以下，我们找到了K作为CUBIC参数${\beta }_{cubic}$和C以及网络参数p和RTT的函数。 根据图2中对K的定义，我们有

图10

使用图1 中的窗口增加函数，也可以按如下方式获得两个连续数据包丢失之间的数据包总数。。具体而言，第一个往返时间（RTT）（即n=1，或者等价地，t=0）的窗口大小为${C(-K)}^3$+$W_{max}$，最后一个RTT（即n=K/RTT，或者等价地，t=K-RTT）的窗口大小为${C(-RTT)}^3$+$W_{max}$。

图11

在求解图10 和图11 中 K 和 ${W}_{max}的方程后，我们有

图12

平均CUBIC窗口大小${AVG_W}_{cubic}可以通过在图9中代入图12中的K来获得。