nsdi23 | Bolt：用于超低延迟的 Sub-RTT 拥塞控制

题目：Bolt: Sub-RTT Congestion Control for Ultra-Low Latency 作者：Serhat Arslan∗ Stanford University ， Y uliang Li Google LLC ， Gautam Kumar Google LLC ，Nandita Dukkipati Google LLC. 文章地址：https://www.usenix.org/conference/nsdi23/presentation/arslan 内容整理：胡玥麟 数据中心网络倾向于将线路速率提高到 200Gbps 及以上，以满足 NVMe 和分布式 ML 等应用的性能要求。随着带宽延迟乘积 (BDP) 的增大，几个 BDP 内可以容纳越来越多的传输。这些传输不仅对拥塞性能更加敏感，而且给拥塞控制（CC）带来更多挑战，因为它们几乎没有时间让 CC 做出正确的决策。因此，CC 面临着比以往更大的压力，需要实现最小排队和高链路利用率，不为不完美的控制决策留下空间。论文发现，为了让 CC 做出快速、准确的决策，使用精确的拥塞信号和最小化控制环路延迟至关重要。论文通过设计 Bolt 来解决这些问题，Bolt 试图通过利用可编程数据平面的力量将拥塞控制推向理论极限。Bolt 建立在三个核心理念之上： (i) 子 RTT 控制 (SRC) 对拥塞的反应比 RTT 控制环路延迟更快， (ii) 主动加速 (PRU) 预见未来的流量完成，以立即占用释放的带宽， (iii) 供应匹配 (SM) 明确地将带宽需求与供应相匹配，以最大限度地提高利用率。 论文在测试台和模拟中的实验表明，与 Swift 和 HPCC 相比，Bolt 将 99thp 延迟减少了 80%，并将 99thp 流完成时间提高了 3 倍，同时即使在 400Gbps 下也能保持接近线速的利用率。

简介

数据中心工作负载正在向高度并行、轻量级的应用程序发展，当网络可以提供低尾延迟和高带宽时，这些应用程序将表现良好。因此，应用程序的服务级别目标 (SLO) 变得更加严格，对网络性能的责任也越来越大。为了支持这一趋势，业界倾向于提高线路费率。Gbps 链路已经很丰富，200Gbps 正在得到采用，400Gbps 以太网的行业标准化正在进行中。

随着线路速率的不断提高，CC需要在突发的工作负载下做出更高质量和及时性的决策。

论文根据最近对数据中心中 RPC 大小相对于 100Gbps 和 400Gbps 下 BDP 大小的分析（使用数据中心中的典型基本延迟/RTT 计算）来说明这一点。论文的研究结果如图 1 所示。

适合BDP 的 RPC 比例从 100Gbps 时的 62% 和 80% 增加到 400Gbps 时的 80% 和 89%。

这些 RPC 对排队和未充分利用的性能敏感。最终，即使是一个不正确或缓慢的 CC 决策也可能最终导致数十微秒的尾部排队，或导致利用率不足，从而将流完成时间延长几个 RTT。因此，此类 RPC 的比例不断增加，提高了 CC 的质量和及时性的标准。

与此同时，在更高的带宽下，工作负载变得更加突发，因此更难以控制。下图还显示，只有 40% 负载的 400Gbps 链路大约每个 RTT 都会看到 RPC 到达或完成。因此，当排队和未充分利用在 RTT 时间尺度上快速到达和完成时，控制排队和未充分利用变得更加困难。论文预计这些数字对于即将到来的工作负载（例如分解内存和机器学习）来说更具挑战性。

论文确定了 CC 的两个关键方面，它们对于应对在突发工作负载上实现更高 CC 质量和及时性的挑战非常重要：

图1 读取操作的 RPC 大小分布

首先，有关拥塞位置和严重程度的精细反馈可以避免反应过度/反应不足。精确的 CC 算法将接收瓶颈的准确状态，以便在拥塞期间正确降低瓶颈，并在利用率不足期间正确提高瓶颈。这种拥塞信息直观地涉及遥测，例如当前队列占用率和链路利用率的度量。然后，终端主机将能够计算它们可以注入网络的确切数据包数量，而不会造成拥塞。

其次，控制环路延迟是控制算法灵敏度的决定因素。它被定义为拥塞事件与到达瓶颈的发送方的反应之间的延迟。控制回路延迟越小，控制系统可以做出更准确、更简单的决策。据报道，生产中最先进的 CC 算法在其控制循环延迟允许的范围内运行良好。然而，由于 BDP 的增加，即使是一个 RTT 的延迟对于未来的网络来说也将是无法容忍的。论文推测下一步不可避免的是将控制环路延迟降低到亚 RTT 水平。

幸运的是，可编程开关提供的灵活性和精度允许设计新的机制来减少控制环路延迟并增加控制算法的粒度。这些最先进的交换机可以生成自定义控制信号来报告细粒度遥测，以便流量不需要依赖端到端测量来检测瓶颈链路的拥塞情况。

在这项工作中，论文介绍了 Bolt，论文利用可编程数据平面的力量来设计极其精确的 CC，以实现极高线速下的超低延迟。Bolt 以绝对最小（亚 RTT）延迟收集拥塞反馈，并主动增加流量以迅速占用可用带宽。为了实现这一目标，它将“数据包保护”原则应用到流量上，并在 P4中做出准确的每个数据包决策。每个数据包的 cwnd 变化较小，与细粒度的网络内遥测相结合，有助于限制瞬时拥塞信号中噪声的影响。使用 Bolt，终端主机不会对拥塞的严重性和确切位置或竞争流的数量进行隐式估计，从而使它们免受手动调整的硬编码参数和不准确反应的影响。

Bolt 的主要贡献有：

1. 讨论了具有最小控制环路延迟的最佳 CC 算法的基本限制。
2. 描述共同构成 Bolt 设计的 3 种机制——一种极其精确的 CC 算法，具有尽可能短的控制循环。
3. 论文实验室中 P4 交换机上 Bolt 的实现和评估，与 Swift相比，中值和尾部的 RTT 分别降低了 86% 和 81%。
4. 针对大规模场景的 NS-3实现，与 Swift 和 HPCC相比，Bolt 的 99-p 流程完成时间提高了 3 倍。

实现最小控制环路延迟

众所周知，及时的反馈和对拥塞的反应对于 CC 来说很有价值。通过 Bolt，论文的目标是突破最小化控制环路延迟的限制，控制环路延迟由两个元素组成：

• 反馈延迟是接收发送的数据包的任何反馈的时间。
• 观察周期调整 cwnd 之前收集反馈的时间间隔。大多数 CC 算法发送一个数据包窗口，观察接收器在另一个窗口上反射的反馈，最后调整 cwnd，其总控制环路延迟甚至比 RTT 还要长。

设计

Bolt 旨在通过努力实现下面两张图中所示的理想行为，即使在非常高的线路速率下也能实现超低延迟。该设计旨在将控制环路延迟降低到绝对最小值。

• 首先，通过在交换机生成通知并将其直接反映给发送者，可以最大程度地减少拥塞通知延迟。
• 其次，发送者提前发出信号流完成事件，以隐藏启动延迟并避免利用率不足。
• 第三，cwnd 在每次反馈后更新，以实现快速稳定，其中每个数据包最多更新一次，以适应噪声。这三个想法共同实现了在每个数据包的基础上运行的精确 CC，最大限度地减少了错误的 CC 决策。

图2 流完成后，剩余 Swift 流的 cwnd 和队列占用情况

图3 HPCC 和Swift对于流的到达和完成的反应

先前的工作分别提出了子 RTT反馈、流完成信令和每数据包 cwnd 调整。Bolt 的主要创新是将这些部分编织成和谐且精确的 sub-RTT 拥塞控制，这对于现代高性能数据中心来说是可行的。关键是根据下图中可视化的数据包守恒原则解决拥塞问题，其中网络路径被建模为一次具有一定容量的传输数据包的管道。

图4 数据包守恒原则的管道模型

当总 cwnd 比容量大 1 时，管道中有多余的数据包正在排队。如果总 cwnd 比容量小 1，则瓶颈链路将因每个 RTT 1 个数据包而未充分利用。因此，一旦观察到值得排队或未充分利用的数据包，发送方之一应立即减少或增加 cwnd，而无需长时间观察。

Bolt 最小化反馈延迟和观察周期，同时为每个数据包决策生成精确反馈的基本方法通过 3 个主要机制实现：

1. SRC（子 RTT 控制）将拥塞通知延迟减少到绝对最小值。
2. PRU（主动加速）隐藏可预见的利用率不足事件的任何反馈延迟。
3. SM（供应匹配）从不可避免的利用率不足事件中快速恢复。为了实现这 3 种机制，Bolt 使用了清单 1 中详细介绍的 9 个字节的传输层标头。论文在描述 Bolt 的设计时解释了每个字段的用途，其切换逻辑总结在下述算法中。

图5

SRC - 子 RTT 控制

较小的反馈延迟可提高 CC 的性能。因此，Bolt 通过在交换机的入口管道生成控制数据包并将其直接发送回发送方，最大限度地减少反馈延迟，这是 Intel-Tofino2等可编程交换机中可用的机制。虽然在本质上，这类似于因互联网中的可行性问题而被弃用的 ICMP Source Quench 消息，但 Bolt 的 SRC 机制在高度受控的数据中心环境中利用了精确的遥测技术。

下图描述了传统的基于 ACK 的反馈与基于 SRC 的反馈机制所经过的路径的差异。由于 SRC 数据包是在入口处生成的，因此它们会通过拥塞交换机和发送方之间的最短路径传播，建立可能的绝对最小反馈环路。此外，为了进一步最小化反馈延迟，Bolt 在交换机上优先考虑 ACK 和 SRC 数据包而不是数据包。

图6 基于ACK反馈的路径 vs. 基于SRC反馈的路径

当队列占用率大于或等于 CCT HRESH 时，Bolt 会为每个到达的数据包生成 SRC 数据包，CCT HRESH 通常设置为单个 MTU 以实现最小排队。然而，如果流的路径上有多个拥塞的交换机，则在每个交换机上为相同的数据生成 SRC 将会使网络充斥过量的控制数据包。为了防止泛洪，交换机在生成 SRC 数据包时标记原始数据包的 DEC 标志，以便不会因该数据包而在其他跳上生成更多 SRC 数据包。这意味着 SRC 数据包的数量受到任何给定时间网络中数据包数量的限制。然而，在实践中，论文发现 SRC 数据包的实际负载极低，并在附录 A 中提供了 SRC 数据包的附加负载的近似值。

当存在多个拥塞的跃点，并且流仅从第一个跃点接收 SRC 数据包时，cwnd 递减仍然有助于缓解所有拥塞。因此，即使第一跳的拥塞不像其他跳那么严重，Bolt 也会在第一跳排空队列，并快速开始处理后续跳。

Bolt 在 SRC 数据包上标记两条重要信息——当前队列占用率和链路容量。此外，它还反映了原始数据包的 TX 时间戳。当发送方收到该数据包时，它会运行下述算法中所示的决策逻辑。

图7

首先，

被计算为发送相应数据包和接收其 SRC 数据包之间的时间。这是 Bolt 的拥塞通知延迟，它总是比 RTT 短，并且可以实现子 RTT 控制。

TX 时间戳的反映使得这种计算无需发送方有任何状态。接下来，计算 reaction_factor 作为该流对拥塞的贡献的度量。将此值与报告的队列占用率相乘即可得出此流应排出的排队量。所有旨在仅消耗其负责的流量的流量有机地有助于公平分配。

最后，

/

给出了两次连续cwnd递减之间的最短时间间隔。此间隔可以防止过度反应，因为交换机会不断发送拥塞通知，直到发送者的 cwnd_change 的影响传播到它们。例如，如果目标队列只有一个数据包，则仅当

自上次递减以来已过去时，发送方才会递减其 cwnd。然而，如果队列较大，Bolt 允许更频繁的递减，以使总 cwnd 更改等于一个

中的目标队列大小。由于所需的 cwnd 调整分散在

上，Bolt 对来自任何单个拥塞通知的噪声变得更具弹性。

Bolt 中不会发生丢失和超时等事件，因为它提前开始对拥塞做出反应。然而，由于发生此类事件的可能性，例如由于配置错误或数据包损坏，处理重传超时、选择性确认和丢失恢复与 Swift中的完整性保持相同。

PRU - 主动提升

Bolt 明确跟踪流程完成情况以促进主动提升 (PRU)。当流接近完成时，它会标记传出数据包以通知交换机，交换机提前计划将流释放的带宽分配给链路上竞争的其余流。这有助于剩余的 Bolt 流量主动增加并消除流量完成后的未充分利用期。

当大于一个 BDP 的流发送其最后一个 cwnd 数据时，它们会在数据包上设置 LAST 标志，以标记它们在下一个 RTT 中不会有数据包。请注意，这不需要知道应用程序级别的流量大小。在像 TCP 这样的典型传输中，应用程序在每次 sendAPI 调用时向连接注入已知数量的数据，由 len 参数表示。因此，等待发送的数据量是可以计算的。仅当连接中剩余数据量在 cwnd 大小范围内时才标记 LAST。

接收到 LAST 标志的交换机如果没有拥塞，则会增加相关出口端口的 PRU 令牌值。

该值表示在下一个 RTT 中将释放的带宽量。交换机将这些令牌分发给没有 LAST 标志的数据包，即有数据包要在下一个 RTT 中发送的流，以便发送者可以主动增加。

然而，只有在其他跃点没有遇到瓶颈的流量才应该增加。为了识别此类流量，BOLT使用了贪婪方法。发送数据包时，发送者在数据包上标记 INC 标志。如果交换机具有 PRU 令牌或具有空闲带宽，它会保留数据包上的标志并消耗令牌。否则，交换机会重置 INC 标志，防止路径上的未来交换机消耗该数据包的令牌。然后，如果没有交换机重置路径上的 INC 标志，则可以保证流路径上的所有链路都有足够的带宽来容纳额外的数据包。接收方在 ACK 中反映此标志，以便发送方在接收到 cwnd 后简单地增加 cwnd。

PRU 计算中不考虑短于 1 BDP 的流量。当一个新的流开始时，它的第一个 cwnd 数据包不是网络所期望的，并且会造成额外的负载。因此，一旦它们离开网络，交换机就不应该用其他流中的数据包替换它们。Bolt 通过在流的第一个 cwnd 中的数据包上设置 FIRST 标志来防止这种情况。交换机在增加 PRU 令牌值之前检查数据包上的 FIRST 标志（算法 1 的第 12 行）。

请注意，PRU 不需要通过 SRC 数据包减少反馈延迟，因为它在设计上考虑了下一个 RTT 中的流完成。发送方不应提前开始增加流量，因为这可能会在流量完成之前导致额外的拥塞。因此，传统的基于 RTT 的反馈环路是正确 PRU 核算的正确选择。

SM - Supply matching

链路和设备故障或路由更改等事件可能会导致链路未充分利用，而无需主动发出信号。此外，如果将 PRU 令牌分配给由于已经达到线路速率而无法加速的流，或者受到下游交换机的瓶颈，则可能会浪费 PRU 令牌。对于此类事件，传统的 CC 方法依靠逐渐加性增加来缓慢探测可用带宽，这可能需要数十个 RTT。相反，Bolt 能够通过下述供应匹配 (SM) 显式匹配利用率需求与供应来进行乘法探测。

Bolt 利用可编程交换机中的有状态操作来测量链路的瞬时利用率。

每个交换机都会跟踪每个端口的链路容量供需之间的不匹配情况，其中交换机在单位时间内可以串行化的字节数就是该链路的供给量；同一时间间隔内到达的字节数即为链路的需求。当然，当供应大于需求时，链路利用率不足，否则链路就会拥塞。请注意与 HPCC的相似之处，HPCC 也计算链路利用率，尽管从端到端的角度来看，这限制了它每个 RTT 计算一次。Bolt 将此计算卸载到交换机数据平面，以便它可以捕获精确的瞬时利用率，而不是粗粒度的测量。

当数据包到达时，交换机运行下述算法中的逻辑来计算与出站端口关联的供应令牌值（算法中的 sm_token）。令牌会在每个数据包到达端口时累积供给和需求之间的不匹配（以字节为单位）。令牌的负值表示排队，而正值表示利用率不足。当令牌值超过 1 个 MTU 时，Bolt 会在数据包上保留 INC 标志，并允许发送方将额外的数据包注入网络。然后，供应代币值会减少 MTU，以适应未来的需求。

图8

如果交换机端口长时间没有接收数据包，则供应令牌值可能会变得任意大，如果在空闲期后突发数据包到达，则无法捕获瞬时利用率。考虑到这一点，Bolt 将供应代币值限制为最多 1 个 MTU。

如前所述，在某些情况下可能会浪费令牌，即交换机消耗令牌（PRU 或 SM）来保留 INC 位，但会被下游交换机重置。在这种情况下，SM将在下一个RTT中寻找可用带宽。在最坏的情况下，连续 RTT 会发生这种情况，Bolt 会回落到类似于 Swift的加性增加。即，cwnd 在每个 RTT 时递增一次，以允许流探测更多带宽并实现公平性，即使它们没有收到任何精确的反馈作为故障安全机制。

实现

论文在实验室中通过主机（传输层和网卡）和交换机修改实现了 Bolt。论文使用 Snap作为用户空间传输层，除了现有的 Swift 实现之外，还在 1340 LOC 中添加了 Bolt。另外，交换机端实施由 P4 程序（bolt.p4）组成，位于 1120 LOC。下图显示了论文实验室原型的整体概览。

图9 Bolt 系统概览

交换机原型

论文的实现基于实验室中 Intel Tofino2交换机的可编程数据平面，因为它们可以提供入口管道中出口端口的队列占用并生成 SRC 数据包。这对于 Bolt 最大限度地减少 SRC 数据包引起的反馈延迟至关重要，因为它们在拥塞的跳点上不会受到排队延迟的影响。

当在入口管道中检测到拥塞时，交换机会将此数据包镜像到输入端口，同时沿其路径转发原始数据包。镜像配置是通过查找表来确定的，该查找表与数据包的入口端口相匹配并选择关联的镜像会话。

然后，镜像数据包被修剪以删除有效负载，并交换流标识符（即源/目标地址和端口）。最后，在该数据包上设置SRC标志以完成其到SRC数据包的转换。

整个bolt.p4主要由寄存器数组声明和简单的if-else逻辑组成。

有4个寄存器数组，用于存储队列占用情况、令牌值和最后数据包到达时间。所有寄存器阵列都与交换机上的队列数量一样大，因为状态是按队列维护的。总共只有 3.6% 和 0.6% 的可用 SRAM 和 TCAM 分别用于寄存器阵列、表和计数器。

交换机保留每个出口端口的最后一个数据包到达时间，以计算链路的供电量。在每个数据包到达时，计算当前时间戳与最后一个数据包到达时间之间的差作为到达间隔时间。理想情况下，该值应乘以链路容量来计算供应量。

然而，由于浮点运算在 PISA 管道中不可用，因此论文使用以到达间隔时间为索引的查找表来确定供应量。论文将此查找表的大小设置为 65536，其中每个条目对应不同的到达间隔时间，粒度为纳秒。因此，如果到达间隔时间大于 65 微秒，则供应令牌值将直接设置为其最大值 1 MTU，这会触发设置 INC 标志。论文发现，在相当高的负载下，65 微秒的到达间隔时间对于大于 100Gbps 的链路来说已经足够罕见，因此任何更长的值都可以安全地解释为利用率不足。

论文的原型基于单个硬件管道。因此，论文将Bolt完全实现在入口管道上，以便更容易理解和调试其逻辑。然而，由于 PRU 和 SM 维护每个出口端口的状态，因此它们也可以通过较小的修改在出口管道上实现。

这样，来自多个入口管道的数据包的状态自然会被聚合。

主机原型

论文的传输层使用 NIC 硬件时间戳来计算

。当发送方发送数据时，TX 时间戳会被标记到数据包上。

交换机将此值反射回发送方，因此

是接收到 SRC 数据包时的 NIC 时间（RX 时间戳）与反射的 TX 时间戳之间的差值。

这可以精确测量到瓶颈的网络延迟，而不会产生任何不确定的软件处理延迟。

传输层还将用于同一服务器的 RPC 复用到同一网络连接上。然后，新 RPC 的第一个 cwnd 字节不一定会被检测为连接的第一个窗口。为了缓解这个问题，论文的原型会跟踪连接的空闲周期，并在该周期之后发送新的 RPC 时重置字节发送计数器。因此，当计数器值小于 cwnd 时，在数据包上设置 FIRST 标志。

最后，PRU 的最后一个窗口标记需要确定每个连接的剩余数据的大小。

在论文的原型中，连接会根据应用程序每次发送 API 调用中的数据大小来增加挂起字节计数器。每次连接将数据包传输到网络时，计数器值都会根据数据包的大小递减。因此，当该计数器值小于 cwnd 时，在数据包上设置 LAST 标志。

安全性和身份验证

让 Bolt 用于加密和身份验证的连接是论文实验室的一个关键挑战。论文的原型使用 IPsec ESP的自定义版本在 IP 层上进行加密。然而，交换机需要在不破坏端到端安全性的情况下读取和修改传输标头处的 CC 信息。协议的 crypt_offset 允许仅在超出此偏移量的情况下对数据包进行加密。论文将其设置为传输标头不加密，但仍经过身份验证。

另外，交换机由于缺乏加解密能力，无法生成加密报文。

为了解决这个问题，论文通过添加 IB BTH 和 DETH 标头同时删除加密标头，在交换机上生成 SRC 数据包，作为根据 RoCEv2 标准的不可靠数据报。

RoCEv2 数据包具有针对数据包计算的不变 CRC，并作为尾部附加。幸运的是，Tofino2 提供了一个 CRC extern，能够对小型、恒定大小的数据包进行此计算。因此，NIC 能够根据数据报上的队列对编号 (QPN) 将 SRC 数据包正确转发到上层。

评估

微基准 SRC

Bolt 通过 SRC 减少 cwndis 的唯一方法，其有效性在拥塞期间最好观察。通常，使用传统的基于 RTT 的拥塞控制算法，以线速开始的新流会发出相当于 BDP 的数据包，直到在 RTT 后收到第一个拥塞反馈。如果网络在此流之前已被充分利用，则所有发出的数据包最终都会创建相当于 BDP 的队列，即使对于基于 RTT 的理想方案也是如此。然后，理想的方案将停止发送任何新数据包，以允许快速耗尽队列，这将需要另一个 RTT。

这种行为在下图被描绘为红色，其中新流在 100μs 时加入。

图10 Bolt 对流到达的反应与理想行为的比较

上图中的 HPCC 行为接近理想状态，因为它是一种基于 RTT 的方案，具有高精度拥塞信号。当新流到达时，队列占用率上升至 1 BDP 。然而，队列的耗尽速度低于链路容量，因为流偶尔会继续发送新数据包，而队列尚未完全耗尽。

另一方面，Bolt 比 RTT 更早检测到拥塞。因此，它在队列占用率达到 BDP 之前开始递减 cwnd，并在不到 2 个 RTT 内完全耗尽队列占用率，甚至比基于 RTT 的理想方案还要短。

此外，HPCC 的链路利用率在排空队列后降至 75%，并波动一段时间，这是由于 RTT 较长的观察期造成的。Bolt 按数据包进行的决策避免了这种利用率不足的情况。

PRU

如果没有主动启动或等待队列，则会导致利用率不足，因为传统的拥塞控制算法至少需要一个 RTT 才能对其做出反应。如果完成流的 cwnd 大于队列大小，常设队列可能不足以保持链路繁忙。论文使用 Bolt 重复相同的场景，以测试主动启动的有效性可以基于 Swift 和 HPCC 的流程完成。下图展示了剩余流的cwnd和瓶颈链路处的队列占用情况。当 Bolt 流在 t=200μs 时完成时，剩余的流能够在 1μs 内捕获可用带宽，因为它开始比流完成早一个 RTT 增加 cwnd（通过收集 PRU 令牌）。此外，没有观察到排队或利用率不足的情况。另一方面，HPCC 需要 20μs (> 2×RTT) 才能达到充分利用，因为它需要一个 RTT 来检测利用率不足，并在加速之前需要另一个观察期的 RTT。最后，由于缓慢的加性增加方法不适合下图，Swift 需要超过 370μs 才能达到稳定值。

图11 流完成后剩余流的 cwnd 和队列占用情况

尽管 PRU 和 SM 在快速捕获可用带宽的方式上似乎有重叠，但与 SM 相比，PRU 是一种更快的机制，因为它可以主动检测利用率不足的情况。为了证明这一点，论文创建了一个具有 100Gbps 链路和 5μs 基本 RTT 的星形拓扑，其中 5 个发送器向同一接收器发送 500KB。流程彼此相隔 15μs 开始，在不同时间完成，以便 PRU 和 SM 可以启动。论文在禁用 PRU 或 SM 时重复并测量瓶颈利用率，以观察每种机制如何有效实现高吞吐量。

下表显示了第一个流完成和最后一个流完成之间的链路利用率。当仅禁用 PRU 时，尽管有 SM，利用率仍会下降 6%。另一方面，单独禁用 SM 只会导致 1% 的下降。这表明当利用率不足主要是由于网络中的流完成而导致时，PRU 是比 SM 更强大的机制。它们共同提高了 8% 的利用率。

表1 PRU 和 SM 对瓶颈利用率的有效性

SM

与流程完成不同，诸如链路故障或重新路由之类的事件不会提前提示。然后，PRU 不会发挥作用，使得 Bolt 完全依赖 SM 来实现高利用率。

下图显示了另一流离开瓶颈后剩余流的 cwnd。得益于 SM，cwnd 可以在 23μs (12a) 内快速提升以利用链路。当 SM 被禁用时，Bolt 提升的唯一方法是通过传统的加法增加，即每个 RTT 将 cwnd 增加 1 (12b)。因此，需要超过 33 个 RTT 才能充分利用该链路。

图12 流重新路由后，剩余流的 cwnd 和队列占用情况

结论

由于应用程序的 SLO 严格，提高数据中心的线路速率是不可避免的。然而，较高的线路速率会增加突发性，从而给 CC 带来更大的压力，以最大限度地减少短流的排队延迟以及长流的高链路利用率。根据数据中心的经验，论文发现 CC 的两个关键方面需要突破极限，才能在如此高度动态的环境中正常工作。

Bolt 凭借可编程开关提供的灵活性和精度解决了这些问题。首先，它使用最精细的拥塞信号，即精确的队列占用率，用于每个数据包的决策逻辑。其次，它通过在拥塞交换机处生成反馈并将其直接发送回发送器，将控制环路延迟降至绝对最小值。第三，它通过对可预见的流程完成做出主动决策来隐藏控制循环延迟。从而尽可能快地计算出准确的 cwnd，实现尾部延迟减少80%以上，尾部 FCT 提高3倍。