当前位置：首页 > ICNP > 正文

【ICNP 2021】FLASHPASS：阿里巴巴在浅buffer WAN上提出的主动拥塞控制方法

ICNP
2022-10-18
1836
更新：2023-01-04 21:47:17

## 摘要

近年来，大型企业（如谷歌、阿里巴巴等）一直在构建和部署基于浅buffer交换芯片的广域路由器。然而，对于传统的被动式传输协议/reactive transport（如TCP Cubic），浅buffer很容易被大型BDP广域流量淹没，导致高数据包丢失和吞吐量降低。为了解决这个问题，我们要问：我们是否可以设计一种传输协议，以同时实现浅buffer广域网的高吞吐量和低丢包？

我们通过采用主动拥塞控制（PCC）来肯定地回答这个问题。然而，现有PCC在WAN上工作存在两个问题。首先，广域业务具有不同的RTT，导致我们称之为不完美调度问题（例如，数据崩溃/data crash in time）。其次，信用触发数据发送时有一个RTT延迟，这可能会降低网络性能。因此，我们提出了一种新的PCC设计——FLASHPASS。为了解决第一个问题，FLASHPASS采用发送方驱动的仿真过程，并进行发送时间校准，以避免数据包崩溃。为了解决第二个问题，FLASHPASS允许在开始阶段进行早期数据传输，并在结束阶段采用了带有选择性丢包机制的过度配置，以实现高效的信用分配。我们对生产工作负载的评估表明，FLASHPASS将TCP Cubic和ExpressPass的总体流量完成时间分别减少32%和11.4%，将小流量的第99个尾部完成时间分别减少49.5%和38%。

## 1 导言

随着地理分布web应用程序和服务的普及，广域网（WAN）正成为一个越来越重要的云基础设施。例如，谷歌披露其数据中心间广域通信量呈指数级增长，近5年来每9个月就翻一番。这使得广域网设施的发展速度比其其他基础设施组件快得多。

为了经济高效、灵活地扩展广域网，谷歌和阿里巴巴等大型企业一直在基于浅buffer商用交换芯片（第2.1节）构建和部署其定制的广域路由器。然而，传统观点认为，在最坏（同步）情况下，需要一个带宽延迟乘积（BDP）的缓冲区大小来实现完整链路利用率。因此，廉价的浅buffer WAN设备对底层传输协议提出了严格的要求。

我们使用最新发展的TCP风格的被动式拥塞控制（RCC）算法重新研究了缓冲区大小问题，发现浅buffer很容易被广域流量所淹没（第2.2节）。具体而言，在浅buffer WAN上运行传统的被动式传输协议可能导致高数据包丢失或吞吐量降低，或者两者兼而有之。为了缓解这些问题，目前的做法寻求全局流量工程、终端主机速率限制，或具有差异化服务的流量调度的帮助。

相反，我们会问这样一个问题：我们能否设计一种传输，在浅buffer广域网下同时实现低丢包率和高吞吐量？受新兴的主动拥塞控制（PCC）设计（图1）的启发，我们通过主动将PCC理念扩展到浅buffer广域网，肯定地回答了这个问题。

然而，尽管PCC已被证明在数据中心网络（DCN）中运行良好，但我们发现它在WAN上运行存在一些实用性问题（第2.3节）。首先，集中式PCC和交换机辅助PCC协议对网络设施提出了很高的要求（例如，削减有效负载/cutting payload），因此要么无法扩展，要么不切实际。此外，一些接收端驱动的协议（如Homa）是基于机架顶部（ToR）交换机和接收端之间存在单一瓶颈的假设，这不适用于广域网。

虽然类似ExpressPass的信用仿真PCC (credit-emulated PCC)似乎有效，但我们发现它可能会在广域网上遇到效率问题。首先，与同质DCN不同，广域业务具有多种RTT。由于不同的RTT时间，反向路径上调度良好的信用仍然可能触发数据转发路径上的数据包挤压。其次，对于PCC中的起始阶段（更快地开始数据发送）和结束阶段（及时停止信用生成），信用有一个RTT延迟来触发数据发送。考虑到广域网上更高的RTT，这样的开销是禁止使用的。

因此，我们提出了一种新的PCC解决方案——FLASHPASS来应对这些挑战（第3节）。首先，为了解决不完善的信用调度问题，FLASHPASS利用发送端驱动仿真过程和发送时间校准。与接收方驱动的协议不同，发送方驱动的FLASHPASS可以准确地排布/rehearse未来在仿真网络上以相同方向发送的数据。通过在仿真和信用包上添加时间戳信息，FLASHPASS可以在时间空间中严格地调度数据发送。其次，为了减轻一次RTT延迟对信用触发数据发送的影响，FLASHPASS利用Aeolus在启动阶段实现早期数据传输，并进一步结合了一种信用超过供应机制以及一种选择性丢包规程，以在流结束阶段实现有效的信用或带宽分配。

我们在阿里巴巴的生产广域网上测量了实际工作负载，并使用NS2仿真对FLASHPASS进行了实验，以证明其优越的性能（第4节）。在静态工作负载实验中，FLASHPASS在浅buffer WAN下的各种设置下实现了接近全吞吐量（9.14Gbps）的零数据包丢失。与TCP-Cubic相比，吞吐量提高了55.9%。与ExpressPass相比，FLASHPASS以零丢包率实现了类似的吞吐量（ExpressPass的丢包率高达0.12%）。在真实的动态负载实验中，FLASHPASS（具有Aeolus增强）将TCP Cubic和ExpressPass（也具有Aeolus增强）的总体流完成时间分别减少了32%和11.4%；小流量99次尾流完成时间的减少分别可达49.5%和38%。

我们还介绍了实际部署分析（第5节）。具体而言，应跨WAN配置多个队列和ECN标记/丢包（例如，与传统TCP流量共存），并且需要高效的传输实现。然而，构建一个功能齐全的原型超出了本文的范围。我们希望本文中进行的设计、分析和广泛的仿真将为下一步的原型设计和部署铺平道路。

## 2 背景和动机

### 2.1 浅buffer网络

过去十年见证了网络应用和服务（如网络搜索、云计算、社交网络等）的指数级增长。这促使大型互联网公司（如谷歌、微软、脸书和阿里巴巴等）在全球范围内以无法预见的速度和规模建设现代数据中心（DC）。随着通信需求的不断增长，使用商用交换机构建的传统网络基础设施无法满足规模、管理和成本要求。

为了解决这个问题，受当时新兴的商业交换芯片行业的启发，大型企业开始在WAN和DCN上构建和部署自己的定制网络硬件。然而，虽然尖端商业芯片以经济高效的方式提供了最高的带宽密度，但其附带的浅buffer（表1）可以在很大程度上降低网络性能。例如，Google报告了其在浅buffer WAN和DCN上的高数据包丢包率的经历。

WAN通信的buffer压力特别高。关于缓冲区大小问题的传统观点指出，在最坏的情况下（即同步流），需要一个带宽延迟积（BDP）缓冲来实现全链路利用率。然而，根据表1，商用交换芯片提供的浅buffer每Gbps每端口小于20KB。这甚至低于WAN BDP的0.1%（假设200ms RTT，每Gbps 25MB）。因此，在浅缓冲广域网上同时提供低丢包率和高吞吐量是极具挑战性的。

### 2.2 被动式拥塞控制（RCC）不符合要求

我们重新讨论了缓冲区大小问题，并查看最先进的被动式拥塞控制（RCC）协议是否能在浅buffer WAN中运行良好。理论分析总结在表II中：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">TCP NewReno是一种开创性的基于丢包的拥塞控制算法。它遵循加法递增和乘法递减（AIMD）控制规则。传统的缓冲区大小调整理论表明，完整链路利用率需要一个BDP缓冲区。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">TCP Cubic是基于丢包的拥塞控制，在Linux系统中默认启用。它根据时间的三次函数增加窗口大小，默认情况下，在丢包时乘性减少$$\beta=0.2$$的比例。由此产生的缓冲要求是BDP/4。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">TCP Vegas对延迟和丢包信号做出被动式。它采用基于延迟信号的加性增加和加性减少（AIAD）控制规则来控制飞行中过量数据包的上下限，并对丢包信号进行乘法减少。缓冲区要求为5×flow#数据包。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Copa基于延迟信号。它通过AIAD控制规则将发送速率调整为$$1/(\delta d_q)$$，其中$$d_q$$是测量的排队延迟。默认$$\delta=0.5$$时，缓冲区要求为5×flow#数据包。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">BBR是基于模型的拥塞控制。它试图根据准确的带宽和RTT估计将传输移动到理论最佳点。默认情况下，BBR将数据包限制为cwnd_gain×BDP。然而，准确的带宽估计是很难实现的，在实践中常常导致高缓冲。
</span>

在分析的基础上，我们发现被动式拥塞控制协议都需要不可忽略的缓冲来实现高吞吐量和低丢包率。更糟糕的是，随着网络的发展和流量需求的增长，缓冲区需求无法扩展（与网络容量或流量成比例）。

请注意，这个问题对于RCC协议来说至关重要，因为它们只能在队列形成后检测拥塞，并且在采取被动式之前需要一个RTT延迟。我们运行NS3仿真来说明浅buffer下被动式协议的性能下降。我们使用40ms RTT（因此BDP=50MB）从不同的发送方到共享相同10Gbps瓶颈链路的单个接收方生成200个并行流，持续5秒。我们实验了0.2、0.5、1、2、5、10、20、50、100和200MB的缓冲区大小。在10Gbps网络中，商用交换芯片的浅buffer应不超过每个端口0.2MB（根据表I）。我们启用选择性确认（SACK）以实现高效的丢包检测和重传。

实验结果如图2所示。我们发现，当缓冲区减小到较浅的大小（即10Gbps下的200KB）时，总吞吐量会下降18%-37%。某些协议的丢包率也显著增加（例如，Copa为8.4%，BBR为5.1%）。我们观察到在慢启动结束时（时间为~0.5秒）丢包很严重。这是因为在慢启动阶段，每个RTT的窗口大小都是原来的两倍，最终导致大约一半窗口大小的数据包丢失。因此，我们得出结论，使用RCC协议，浅buffer很容易被大的BDP广域流量淹没，导致高数据包丢失和吞吐量降低。

### 2.3 主动式拥塞控制（PCC）是问题的解决方案

受新兴的主动式拥塞控制（PCC）设计（图1）的启发，我们现在探索将PCC协议用于浅buffer WAN的可能性。与使用“尝试和退避/try and backoff”方法的RCC不同，PCC以“请求和分配”方式运行。关键的概念思想是在活动流之间明确分配瓶颈链路的带宽，并主动预防拥塞。因此，可以实现超低的缓冲区占用率和（接近）零分组丢失。此外，PCC在大约一个RTT内达到峰值速率，避免了RCC慢启动的长收敛时间和高丢包率。

然而，由于大多数现有的PCC协议都是为DCN设计的，它们中的许多协议实际上无法在广域网上工作。集中式PCC和交换机辅助PCC协议对网络设施提出了很高的要求（例如，削减有效负载），因此无法扩展或不切实际。一些接收端驱动的协议，如Homa在接收端采用简单的信用调度，假设机架顶部（ToR）交换机和接收端之间存在单一瓶颈链路。然而，这种假设在广域网中并不成立。

还有其他接收端驱动的协议，如ExpressPass，它在单独的队列上利用复杂的信用仿真过程进行信用分配。与简单的调度不同，基于仿真的方法适用于拥挤的网络（在广域网中更实用）。图3显示了接收端驱动的信用仿真PCC协议的概览。具体来说，它们在反向速率限制的路径上生成信用包，以仿真数据发送。通过网络的每个最小大小的信用分组（例如84B）触发发送方发送MTU大小的数据分组（例如1538B）。因此，信用队列的利率限制为84/（84+1538）约等于链路容量的5%，其余95%用于传输数据包。这使得他们能够在广域网上工作，而不必假设网络核心不拥挤。

因此，我们选择ExpressPass作为WAN的基准PCC设计。在第2.2节中使用开源NS2仿真代码进行相同的静态工作负载实验后，我们验证了其优于RCC协议的性能。结果表明，当在WAN上使用相同的RTT运行静态工作负载时，ExpressPass可以实现9.5Gbps吞吐量和零数据包丢失（参见图10中的更多结果）。

然而，我们发现现有的PCC协议存在一些效率问题，这些问题在具有不同RTT的广域网上尤其严重，尤其是在动态工作负载下。

**问题1**：与同质DCN不同，广域业务有很多不同的RTT（不像第2.2节中的情况那么简单）。由于流的不同往返时间，反向路径上调度良好的信用仍然可能触发数据分组崩溃或数据转发路径上的带宽利用不足。

我们用图4所示的一个案例来说明这个问题。从主机H1和主机H2到主机H3有两个流，在连接到H3的同一个瓶颈链路上竞争。RTT分别为40ms和20ms。两者的流量需求大小均为20ms×线速率。表四显示了接收端驱动的PCC协议的运行过程。来自H1的流1从0ms开始，即信用请求发送时间。在半个RTT之后，即在时间20ms，信用请求到达接收方H3并触发信用生成。信用生成持续20毫秒，并在40毫秒停止，这取决于传输需求规模。来自H2的流量2在30毫秒开始，并在40-60毫秒内触发来自H3的信用生成。因此，流1和流2的信用生成良好地交织。然后，所有信用成功通过网络。它们触发实际数据发送，数据到达时间约为信用发送时间后1 RTT。理想情况下（隐式地假设DCN中不同流的RTT相同），我们期望数据包通过网络而不会彼此挤压。然而，在这种情况下，在WAN上为流1和流2提供不同的RTT，我们发现两个流的数据到达时间相同，即60-80ms。这会导致严重的拥塞，导致浅buffer WAN中的大量排队和数据包丢失。

理论上，最大排$$队Q_{max}$$可计算为：

**公式1**：$$Q_{max} = \Delta RTT \times linereate$$

$$\Delta RTT$$是流之间的最大RTT差异。

我们使用10Gbps链路在图4场景下运行仿真。我们在到主机H3的瓶颈链路中设置了非常大的缓冲区大小。我们将初始信用率设置为最大，并在达到流量需求后立即终止信用生成。结果表明，最大排队量达到8532个1.5KB-MTU大小的数据包或12.5MB，这与我们的理论分析（即方程1）完全相符。这将导致浅缓冲WAN上的严重数据包丢失。

而在另一个仿真中，我们将流2的RTT更改为40ms（与流程1的RTT相同），并将启动时间更改为0ms、10ms、20ms或30ms；重复同样的实验。我们发现最大排队长度急剧下降，不超过6个数据包。这就解释了为什么ExpressPass在RTT差异较大的广域网上不能很好地工作，即使它可以用于DCN等同构网络。

问题2：信用有一个RTT延迟来触发数据发送。这会影响PCC中流的开始阶段（以更快地开始数据发送）和结束阶段（以及时停止信用生成）。考虑到广域网上长RTT，这样的开销是令人望而却步的。虽然我们发现最近的工作（如Aeolus）已经解决了启动阶段的问题，并且可以在WAN上进行类似的扩展，但完成阶段的问题仍然没有解决。

对于流完成阶段，延迟的数据发送可能导致网络利用率低，默认的积极信用生成，或者可能通过提前终止信用生成增加流完成时间。如前所述，为了处理核心拥塞的广域网，现有的PCC协议应该利用接收端驱动的信用仿真。然后，接收方无法确定成功授予每个流的信用的确切数量。这是有问题的，因为这意味着接收者也无法确定停止信用生成的确切时间。接收者有两种选择。一方面，如果它一直发送信用直到得到最后的数据包，那么大约会有一个RTT信用丢包，导致网络利用率不足。另一方面，如果在飞行信用足以满足流量需求时立即停止信用生成，则当仿真过程中某些信用被丢弃时，流量可能需要请求更多信用，从而导致更高的网络延迟。

图5显示了我们在平均流量RTT为60ms、瓶颈链路为1Gbps的网络上运行实际工作负载的实验结果（设置与第4.3节2）相同）。我们生成合成工作负载。流量大小从10MB到80MB不等（基于第4.1节中的广域网测量）。平均网络负载设置为全网络容量的0.8。我们发现，ExpressPass的信用损失高达成功接收信用总额的23.5%。请注意，ExpressPass文章显示，在具有许多小流量的工作负载中，信用丢包甚至更高，高达60%。

## 3 FLASHPASS设计

### 3.1 设计概述

在这项工作中，我们的目标是设计一种实用高效的传输协议，以同时实现浅buffer广域网的高吞吐量和低丢包率（第2.1节）。我们对被动式性传输协议的研究表明其固有的不足，需要不可忽略的缓冲（第2.2节）区才行。然后，我们转向新兴的主动传输协议。在揭示接收端驱动的PCC协议的潜力的同时，我们还发现了两个关键的技术挑战（第2.3节）：

1）即使网络流量具有不同的RTT，如何在不触发数据崩溃的情况下有效地调度信用？

2）如何在不浪费信用的情况下充分产生信用，即使授予的数量不可预测？

第一个挑战是接收端驱动协议的基础。这是因为接收端驱动的协议使用反向路径上的信用发送来仿真正向路径数据发送。接收方和瓶颈链路之间的网络延迟不同于发送方和瓶颈之间的网络延迟。因此，通过反向路径的交错信用不能保证在瓶颈处良好地交错传入数据。为了解决这个问题，我们建议采用发送方驱动的仿真机制。这确保了仿真遵循与实际数据发送相同的方向。此外，对数据发送应严格执行定时/timing。这确保了触发数据包输出的仿真/信用包延迟保持不变，而不是依赖于不同的RTT。

为了解决第二个挑战，我们应该继续生成信用，即使预期的传入信用足以满足流量需求（我们称之为过度供应）。这是为了确保流能够有足够的信用来快速完成，即使成功通过仿真网络并授予发送方的信用量未知。但是，我们也应该确保这些过度提供的信用不浪费带宽，即，它们应该只占用普通流量的剩余带宽。为此，我们采用了一种选择性丢包机制，以“尽力而为”的方式授予超额供应的信用。

因此，我们提出了一种新的PCC解决方案—FLASHPASS，以同时为浅buffer WAN提供高吞吐量和低丢包率。FLASHPASS是第一个发送方驱动的PCC协议。它利用发送方驱动的仿真过程以及发送时间校准，有效地分配带宽信用，并及时消除数据包挤压（第3.2节）。它能够在流开始阶段实现早期数据传输，并结合了信用超额供应和选择性丢包机制，以有效利用流结束阶段的网络带宽（第3.3节）。

### 3.2 发送方驱动的仿真机制

FLASHPASS利用发送方驱动的仿真机制（图6）来分配网络带宽，而不会造成数据包崩溃。仿真过程需要将网络分为两部分：运行在仿真队列上的仿真网络和数据通信队列上的真实数据通信网络。仿真包被设置为最小大小，即84B以太网帧，包括前导码和包间间隙。通过网络的每个仿真数据包触发来自接收端和发送端的信用返回，然后是最大大小以太网帧（例如1538B）的发送端数据传输。因此，在以太网中，仿真网络的速率限制为84/（84+1538）约为链路容量的5%，其余95%用于数据通信。与现有的PCC在信用到达时立即发送数据包不同，FLASHPASS在其仿真数据包和信用数据包中对时间戳（T）进行编码，并允许在$$T+T_{wait}$$的准确时间发送数据，以消除瓶颈链路上的数据挤压。这种发送时间校准机制有效地避免了数据包在时间上的挤压，如下所示。

图6显示了发送方驱动的仿真机制的运行过程。S1：在时间T，新的流到达并立即以仿真网络的全速率生成仿真数据包。仿真数据包将在仿真网络上竞争，如果形成队列，则会被丢弃。仿真网络配置了几个数据包的低缓冲区。S2：大约在时间T+0.5rtt时，仿真数据包通过网络并触发来自接收方的信用反馈。大约半个RTT后，发送方收到并记录信用数据包。S3：在时间$$T+T_{wait}$$，发送方相应地将数据分组注入数据通信网络。请注意，$$T_{wait}$$应大于网络的最大RTT。这样，仿真网络就完全仿真了未来数据通信网络的带宽竞争。如果网络被过度利用，只有仿真数据包在仿真网络上被丢弃，数据通信网络保持零缓冲。

为了进一步说明发送方驱动的仿真机制的有效性，我们将FLASHPASS（表IV）的结果与接收方驱动的PCC（表III）的结果进行了比较——在图4的情况下，两者都是运行过程。在FLASHPASS中，$$T_{wait}$$设置为网络的最大RTT，即40ms。我们发现流2将其数据发送时间调整为70-90ms，从而导致接收端的数据到达时间为~80-100ms。与接收端驱动的解决方案一样，这有效地避免了流1在60-80ms时间内的数据挤压。我们还应该注意到，接收端驱动的解决方案通常不能通过简单地添加一个恒定的等待时间$$T_{wait}$$来解决数据挤压问题，即使它在这种情况下似乎有效（ToR-to-receiver链路的瓶颈）。这是因为在实践中，瓶颈链路可能位于网络的任何一个节点中，到达瓶颈的时间或距离对于发送方和接收方都是不同的和未知的。因此，如果不忠实地模仿发送方驱动的方法发送的数据，就很难避免数据崩溃。

**仿真反馈控制**：FLASHPASS使用仿真反馈控制来调节仿真数据包的发送速率。这是为了确保高带宽利用率和公平性，类似于ExpressPass。例如，在停车场场景中，天真地以linerate发送仿真数据包将导致链路利用率不足。为了解决这个问题，需要对仿真过程进行反馈控制。

与数据转发不同，仿真反馈控制在其仿真数据包丢失方面具有较低的成本，因此在探测更多带宽时具有攻击性。根据这一特点，FLASHPASS采用了一种简单而有效的基于丢包的反馈控制，如算法1所示。仿真数据包丢包率控制在最小目标丢失率（min_target_loss）和最大目标丢失率（max_target_loss ）之间（默认分别为1%和10%）。速率调整遵循乘法递增和乘法递减（MIMD）控制规则。通过记录当前丢包率和目标丢包率范围，可以精确计算增减调整。这样，FLASHPASS仿真过程可以实现快速收敛到完全链路利用率。请注意，FLASHPASS仿真过程允许快速启动新的流，同时仍然通过选择性丢包机制保证低信用浪费。我们还表明，这里的反馈控制算法有助于计算飞行中的预期信用（见等式2和第3.3节中的更多细节）。

**发送方驱动还是接收方驱动？**发送方驱动的方法既有优点也有缺点。一方面，发送方驱动的方法可以仿真在瓶颈链路上具有精确交错到达时间的数据转发，从而实际上可以实现接近零的缓冲。这是我们针对浅buffer WAN场景中最理想的功能，并解释了为什么我们在设计中选择发送方驱动的方法。此外，它不需要像接收端驱动的协议那样确保路径对称性，其中数据包必须完全遵循信用仿真的反向路径。

另一方面，发送方驱动的方法在仿真和数据发送之间引入了半个RTT延迟。如果不仔细考虑，这种较长的延迟可能会产生负面影响。在FLASHPASS中，我们在开始阶段和结束阶段都很好地处理了这个问题。此外，它还增加了单向多个控制包。为了减少这种开销，FLASHPASS采用延迟信用发送。具体地说，如果时间戳信息指示数据发送的等待时间较长，它将等待相同流的更多信用，并在单个数据包中反馈这些信用。延迟反馈信用包应包括所有相应仿真包的时间戳。

### 3.3 具有选择性丢包机制的过度资源调配

为了处理流量启动阶段的信用延迟问题，FLASHPASS采用了与Aeolus类似的想法。具体而言，新流量在收到任何信用之前（即预信用阶段/pre-credit phase），在第一次RTT中以linerate开始。第一个RTT数据包被标记为“未调度/unscheduled”。如果在网络中遇到（非第一RTT）调度分组，则在预信用阶段中的未调度数据分组可以被选择性地丢弃（类似于下面描述的选择性丢包机制）。在第一个RTT分组丢失的情况下，尾部丢包检测与信用调度重传一起使用。

为了处理流完成阶段的信用浪费问题（Aeolus未解决），FLASHPASS采用了一种具有选择性丢包规则的信用超额供应机制（本文的主要贡献）。具体来说，FLASHPASS不断生成仿真数据包并触发信用数据包，即使预期的传入信用足以满足流量需求（我们称之为过度提供）。而在数据包仿真过程中，如果过度配置的仿真数据包与网络中的普通仿真数据包冲突，则会有选择地丢弃这些数据包。这确保过度供应的信用只占用普通业务未使用的剩余带宽。

然而，确定将仿真数据包从普通数据包切换到过度配置数据包的正确时间也是一个挑战。为此，我们需要保持对传入信用的估计。如果估计无法覆盖剩余的流量需求，则将仿真数据包设置为普通数据包。否则，将过度配置仿真数据包。

图7展示了FLASHPASS的详细信用过度供应和选择性丢包机制。

**终端主机上的数据包标记**。终端主机对传入的信用数据包（$$C_{expected}$$）进行逐流估计。具体而言，发送端主机记录飞行中的仿真数据包（$$E_{out}$$）。随着仿真反馈控制回路的调整，实际仿真丢包率预计在大多数情况下低于最大目标丢包率。因此，可根据方程式（2）计算预期信用：

**公式2**：$$C_{expected} >= E_{out}\times(1-max\_target\_loss)$$

当预期的信用量C_{expected}超过流的剩余流量需求时，发送方终端主机开始将仿真数据包标记为过度配置，即具有高丢弃优先级标签。否则，仿真数据包被标记为普通数据包，即具有低丢弃优先级标签。

网络结构上的选择性丢包。网络交换机根据仿真包中的丢弃优先级标签，在网络带宽不足时，有选择地先丢弃高优先级的包，再丢弃低优先级的包。商用交换芯片不能推出（push out）已经存储在交换缓冲区中的数据包。因此，我们只能在入口队列中有选择地丢弃数据包。为此，我们采用了RED/ECN功能，这一功能得到了商用交换机的广泛支持。具体地说，当交换机队列长度超过ECN标记阈值时，交换机将标记到达的支持ECN的分组，并丢弃不支持ECN的分组。因此，FLASHPASS可以重新利用此功能来实现选择性丢包。发送方可以简单地将普通仿真数据包设置ECN标记位，将过度配置的仿真数据包设置为无标记位，以便能够在网络结构上以高优先级选择性地丢弃过度配置的数据包。

## 4 评估

在本节中，我们在第4.1节中介绍了详细的FLASHPASS评估设置，并进行了大量实验以回答以下问题：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">FLASHPASS能否在静态工作负载下实现高吞吐量和低丢包率？在静态工作负载实验（第4.2.1节））中，FLASHPASS在浅buffer WAN下的各种设置下实现接近全吞吐量（9.14Gbps）的零数据包丢失。与TCP-Cubic相比，吞吐量提高了55.9%。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">FLASHPASS能否在实际动态工作负载下减少流量完成时间（FCT）？在真实的动态负载实验（第4.2.2节））中，与Cubic和Aeolus增强ExpressPass相比，具有Aeolus增强功能的FLASHPASS的总流量完成时间分别减少了28.5%-32%和3.4%-11.4%。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">FLASHPASS的不同参数和组件如何影响其网络性能？我们在第4.3节1）中展示了FLASHPASS参数设置的影响，并在第4.3节2）中验证了选择性丢包机制的过度供应的有效性。
</span>

### 4.1 评估设置

比较方案：我们主要比较FLASHPASS与TCP Cubic和ExpressPass的性能。TCP Cubic是一种基于丢包的被动式拥塞控制（RCC）协议，默认情况下在Linux中启用。如今，它为大多数真实的广域传输服务。ExpressPass是一种开创性的主动拥塞控制（PCC）协议。据我们所知，它是目前唯一一个可以在广域网上实际工作的PCC。我们在ExpressPass中使用默认参数设置。我们已经评估了FLASHPASS和ExpressPass（带和不带Aeolus）。Aeolus是PCC解决方案的组成部分，可提高其在预信用阶段（即首次RTT）的性能。

**实验配置**：我们基于ExpressPass的开源代码构建并运行NS2仿真。在静态负载实验（第4.2.1节））中，我们主要使用哑铃网络拓扑，如图9所示。在动态工作负载实验（第4.2.2节））中，我们主要使用区域广域网，如图13所示。默认情况下，根据表I，交换机数据包缓冲区设置为每端口20KB/Gbps。FLASHPASS和ExpressPass的仿真/信用网络队列缓冲区均设置为8个数据包。对于Aeolus和FLASHPASS的过度供应机制，选择性丢包阈值设置为2个数据包。重传超时设置为200ms。数据包MTU设置为1.5KB。

**实际工作负载**：我们测量了阿里巴巴区域广域网的流量大小。数据通过两个数据中心之间的链接收集。在这些链路上运行的流量主要来自数据存储服务。流量大小分布如图8所示，并汇总在表V中。

与数据中心工作负载相比，广域工作负载具有更大的平均流大小(~65MB）。根据我们的分类，有84.2%以上的流量是大型流量，流量超过10MB。WAN上的最大流量可以达到GB（图中未显示），这同样比DCN上的流量大得多。在我们的实际工作负载实验中，工作负载是根据从生产WAN测量的流量模式生成的。流量通过泊松过程到达。源和目的地从不同的DC中均匀随机选择。

**性能指标**：在静态工作负载实验（第4.2.1节））中，我们主要测量吞吐量或网络利用率、丢包率和缓冲区占用率。在动态负载实验（第4.2.2节））中，我们使用流完成时间（FCT）作为主要性能指标，它可以直接反映网络应用程序的数据传输速度。

### 4.2 评价结果

**1）静态工作负载实验**：在这一部分中，我们评估了FLASHPASS在静态工作负载实验下的性能。我们主要使用哑铃网络拓扑，如图9所示。所有链路的容量均为10Gbps。有N个发送方同时将数据传输到同一个接收方。从发送方到瓶颈交换机的网络延迟设置为0到20ms之间的均匀随机值。我们还测试了相同延迟为10ms（即40ms RTT）的情况。发送方为20或200。流在最初的0.2秒内随机启动，并运行5秒。

图10显示了实验结果。具体而言，图10a显示了20个不同RTT长流量下的结果。TCP Cubic、ExpressPass和FLASHPASS的吞吐量分别为6.4Gbps、9.2Gbps和9.1Gbps。TCP Cubic、ExpressPass和FLASHPASS的丢包率分别为1.7%、0.12%和0。一般来说，与Cubic和ExpressPass相比，FLASHPASS实现了最佳性能。它能够在整个实验过程中保持接近全吞吐量且零数据包丢失。

作为一种被动式协议，TCP Cubic在整个实验过程中实现了最低的吞吐量和最差的丢包率。与FLASHPASS相比，在最坏的情况下，吞吐量可以降低35.9%（图10c）。这是因为RCC的“尝试和退避”特性导致固有的高数据包丢失，以及在速率“退避”后周期性的利用不足。此外，Cubic在初始阶段使用慢启动来提高其发送速率，这可能导致慢启动结束时的高丢包率（在初始阶段的时间段内观察到显著丢包）在我们的实验中为~0.5秒）。

虽然ExpressPass实现了与FLASHPASS相似的吞吐量，但在不同RTT的场景中，它具有可观察到的数据包丢失（即图10a和10b）。虽然在这种情况下，数据包丢失只会略微降低大数据传输的吞吐量，但它对小流量有更大的负面影响，我们将在动态负载实验中看到这一点。FLASHPASS通过发送方驱动的仿真过程可以有效地解决不完美的调度问题。请注意，由于仿真数据包开销，FLASHPASS的吞吐量稍低。在静态实验中，只有单向流量，这隐藏了ExpressPass的反向路径信用开销。

当比较20个流（图10a）和200个流（图10b）的情况时，对于并发流较小的Cubic和ExpressPass，吞吐量更好，而分组丢失率更差。这是因为更多的流可以产生更好的统计多路复用，从而总体上获得更稳定的吞吐量性能。当比较不同RTT（图10a）和相同RTT（图10c）的情况时，我们发现ExpressPass的丢包确实是由WAN上的不同RTT造成的。相同的RTT也会导致Cubic的吞吐量降低，因为它增加了同步“锯齿”的概率（即拥塞窗口或发送速率的较大变化）。

**2）动态工作负载实验**：在这一部分中，我们在真实的动态工作负载实验下评估FLASHPASS的性能。我们主要使用广域网（WAN）拓扑，如图13所示。广域区内有三个数据中心（DC），分别通过20毫秒、30毫秒和40毫秒单向延迟的WAN链路相互连接。所有广域链路的容量均为10Gbps。

每个DC中有20台主机直接连接到广域边界路由器，每个主机都有1Gbps链路。直流链路延迟设置为10微秒，与广域网的延迟相比可以忽略不计。工作负载是根据从生产WAN测量的流量模式生成的（图8）。流量通过泊松过程到达。源和目的地从不同的DC中均匀随机选择。因此，WAN链路和DC链路平均应具有相同的负载。我们将负载从整个网络容量的0.4更改为0.8。

图11和图12显示了实验结果。通常，与Cubic和ExpressPass相比，FLASHPASS在小流量（<10MB）和大流量（>10MB）的流量完成时间（FCT）方面表现最好。具体而言，对于最佳版本（即，通过Aeolus增强），与Cubic和ExpressPass相比，FlashPass分别将整体FCT降低28.5%-32%和3.4%-11.4%。

对于小流量，像Cubic这样的被动式拥塞控制增加了慢启动的时间延迟，其固有的高数据包丢失率也引入了高重传超时开销，导致比主动传输的完成时间大得多。而对于ExpressPass，它使用更积极的信用控制算法探测更多的带宽，同时仍然保持较低的数据包丢失率和较低的超时。FLASHPASS改进了仿真过程，实现了零丢包，从而在很大程度上减少了小流量完成时间。当Aeolus通过linerate启动（即ExpressPass和FlashPass）进行增强时，会再保存一个RTT以供信用包开始数据发送，从而产生更低的小流量FCT。当平均网络负载较低时，这一点尤为重要。例如，与ExpressPass相比，FlashPass平均降低小流量FCT 5.1%-16.4%，在第99个尾部降低24.3%-38.0%。

对于大流量，由于缓冲区浅和数据包丢包率高，Cubic的吞吐量较低，因此对于大流量可以获得相对较高的FCT。虽然由于时间调度不完善，ExpressPass数据发送也会有一些丢包，但负面影响非常有限，因为当发生丢包或超时时，ExpressPass不会重置其发送速率。然而，由于最后的RTT信用调度，它确实浪费了一些带宽。当网络负载较高时（例如，当平均负载=0.8时），这种信用丢包会带来严重的负面影响。FLASHPASS使用过度供应和选择性丢包机制处理最后一个RTT信用调度问题。因此，在比较FlashPass和ExpressPass时，可有效避免信用浪费，从而使大流量完成时间减少约10.2%。

### 4.3 深挖

**1）FLASHPASS的参数如何影响其网络性能**：在这一部分中，我们评估了在各种参数设置下的FLASHPASS性能。首先，FLASHPASS将新流的初始信用率设置为仿真网络的最大值。这是由信用包的低丢包率惩罚以及借助FLASHPASS的选择性丢包机制可忽略的信用丢包实现的。linerate信用启动有助于减少短流量完成时间，尤其是在网络大部分空闲时。其次，FLASHPASS仿真反馈控制回路使用最小目标损失和最大目标损失两个参数来控制目标信用丢包率。我们重复第4.2节2）中的相同实验，图14显示了结果。一般来说，较高的目标丢包率会导致在流量动态下更快的收敛，从而提高网络带宽利用效率，而较低的目标丢包率则具有较小的仿真数据包开销。根据结果，我们建议默认参数设置为最小目标损失=1%，最大目标损失=10%。

**2）FLASHPASS选择性丢包机制的过度配置在避免带宽或信用浪费方面的效果如何**：在这一部分中，我们比较了FLASHPASS在使用和不使用选择性丢包机制的过度配置时的性能。我们再次使用广域网拓扑，如图13所示。我们生成合成工作负载。流量大小从10MB到80MB不等。平均网络负载设置为全网络容量的0.8。图15显示了实验结果。我们发现，FLASHPASS选择性丢包机制的过度供应有助于在最后一次RTT中节省3.4%-27%的总流量。与没有过度供应和选择性丢包机制的FLASHPASS相比，这将导致流完成时间减少19%。

## 5 实际部署分析

对于企业WAN上的实际部署，与纯端到端传输相比，FLASHPASS有更多的要求。首先，应在网络交换机上保留一个单独的仿真队列，并对其速率进行限制，以便进行仿真过程。其次，为了启用选择性丢包（第3.3节），应在仿真队列上配置单阈值ECN标记/丢弃。这些要求可以通过商用交换机来实现，但需要在整个网络中进行配置。第三，我们还注意到，PCC解决方案不能与传统的TCP协议共存。一个简单的解决方法是使用多个队列分离不同的流量，但可能会带来一些开销。

最后，需要有效地实现主动拥塞控制逻辑。最近的一项工作介绍了一个Linux内核实现（基于Homa），它实现了比TCP低的延迟。具体来说，各种各样的问题，如批处理、负载平衡和实时处理，都在工作中得到了很好的解决。在用户空间DPDK或拥塞控制平面（CCP）上实现PCC协议还有其他一些努力。

虽然这些工作已经验证了构建高效PCC网络堆栈的可行性，但我们下一步的工作是制作一个功能齐全的FLASHPASS原型，这超出了本文的范围。我们希望本文中进行的设计、分析和广泛的仿真将为下一步的原型设计和部署铺平道路。

## 结论

在本文中，我们揭示了在广域网（WAN）上采用浅buffer商用交换芯片的趋势。然后，我们研究了它对网络性能的影响，发现了TCP类型的被动式拥塞控制（RCC）的不足。为了解决这个问题，我们转向新兴的主动拥塞控制（PCC），并提出FLASHPASS。FLASHPASS是在WAN上使用PCC的第一次尝试。它也是第一个发送方驱动的信用调度PCC协议。它利用发送方驱动的仿真过程和选择性丢包机制的过度配置，实际有效地用于浅buffer WAN。进行了大量实验，验证了FLASHPASS在实际工作负载下的优越性。

参考文献：G. Zeng, J. Qiu, Y. Yuan, H. Liu and K. Chen, "FlashPass: Proactive Congestion Control for Shallow-buffered WAN".ICNP 2021.

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。</span>

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>