TCP 拥塞控制详解 | 3. 设计空间(下）-阿里云开发者社区

3.3 比较分析

评估任何拥塞控制机制的第一步是单独衡量其性能，包括:

流能够达到平均吞吐量(goodput)。
流的平均端到端延迟体验。
机制应该避免跨一系列运维场景的持久化队列。
机制应该在一系列运维场景中都是稳定的。
流获得公平的可用容量份额的程度。

第二步是比较两种或更多机制。考虑到互联网的分布式特性，没有办法确保统一采用一种机制。比较吞吐量等量化指标很容易，问题是如何评估可能共存的、相互竞争网络资源的多种机制。

问题不在于某个给定机制是否能够公平对待所有流，而在于机制 A 是否能公平对待机制 B 管理的流。如果机制 A 能够提供比 B 更好的吞吐量，但也许是通过更积极的方式来做到这一点，因此，A 会从 B 窃取带宽，那么 A 的改进就不是公平的，效果可能会大打折扣。很明显，互联网的高度分散的拥塞控制方法是有效的，大量的流以合作的方式响应拥塞，为更激进的流打开了大门，牺牲了那些实施了不那么激进的算法的流的性能。

延伸阅读:

R. Ware, et al. Beyond Jain’s Fairness Index: Setting the Bar for the Deployment of Congestion Control Algorithms. ACM SIGCOMM HotNets. November 2019.

在过去 30 年里，这样的争论已经发生了很多次，这为部署新算法设置了很高的门槛。即使新算法的全球部署会产生净积极效果，增量部署(这是唯一的实际选择)仍然可能会对使用现有算法的流产生负面影响，导致大家不愿部署新方法。但正如 Ranysha Ware 及其同事所指出的那样，这种分析存在三个问题:

理想驱动的目标(Ideal-Driven Goalposting): 基于公平的门槛决定了新机制 B 应该与当前部署的机制 A 平等共享瓶颈链接。这个目标在实践中太理想化了，特别是当 A 有时对自己的流也无法完全公平的时候。
以吞吐量为中心(Throughput-Centricity): 基于公平的门槛关注新机制 B 如何通过关注 A 已实现的吞吐量来影响使用机制 A 的竞争流。然而，这忽略了其他重要的性能指标，如延迟、流完成时间或丢包率。
平衡假设(Assumption of Balance): 机制间的相互作用通常具有某些偏见，但公平指标不能告诉我们结果是偏向于现状还是反对现状。就可部署性而言，新机制 B 比老机制 A 占用更大的带宽份额还是留给 A 更大的带宽份额是有区别的: 前者可能会引起老机制 A 用户的抱怨，而后者却不会。Jain 公平指数对两种情况的打分基本一样。

相对于简单计算 Jain 公平指数，Ware 主张使用基于丢包的阈值，以吞吐量的减少或延迟或抖动的增加来衡量。直观的说，如果使用新机制 B 的流对使用现有机制 A 的流造成的伤害在一个范围内，这个范围来源于 A 管理的某个流对其他流造成的伤害，我们可以认为 B 与 A 一起部署不会造成更多伤害。Ware 继续提出了可接受伤害的具体测量方法，结果证明这比乍看起来要复杂得多。即使使用单一拥塞控制算法，一个流对另一个流造成的伤害也取决于 RTT、启动时间和持续时间等因素。因此，对伤害的衡量需要考虑到在现有机制下，不同的流动对彼此的影响，并力求在新算法中没有变得更糟。

3.4 实验方法

评估拥塞控制机制的方法是测量真实系统的性能，正如我们在第一章中指出的，Linux 中实现的版本是各个机制的实际规范。我们现在介绍一种执行这些度量的广泛应用的具体方法，该方法使用了 Netesto(网络测试工具包, Network Test Toolkit) ，这是 GitHub 上的一个软件工具集。此外还有基于模拟的方法，NS-3 是最流行的开源工具。

延伸阅读:

Netesto

NS-3 Network Simulator

请注意，虽然本节介绍的实验测量了真正的拥塞控制算法(当然，我们还没有详细描述)，目的是概述如何评估算法，而不是得出任何关于具体机制的结论。

3.4.1 实验设置

我们在 Linux 主机上运行真正的 TCP 发送者/接收者，并使用netem和tbf qdisc等内核包来研究一系列行为，然后使用tcpdump收集性能数据。连接终端主机的网络是由一组真实的交换机和仿真组件构成的，可以支持如广域延迟和低带宽链路等场景。

实验沿着两个正交维度进行。一个是网络拓扑结构，包括链路带宽、RTT、缓冲区大小等。另一个维度是我们在网络上运行的流量负载，包括流的数量和持续时间，以及每个流的特征(例如，stream vs RPC)。

针对网络拓扑结构，我们评估了三种特定配置下的算法:

具有 20μs RTT 和 10 Gbps 链路带宽的局域网。这个场景表示同一数据中心机架中的服务器。
具有 10ms RTT 和 10 Gbps 链路带宽的广域网，通过配置一个 20000 个包的发送队列从而在接收端引入延迟。瓶颈是一个具有浅缓冲区(1-2 MB)的真实交换机。当观察两到三个流时，这是一个很好的可视化算法动态的场景。
具有 40ms RTT 和 10/100 Mbps 瓶颈带宽的广域网，通过引入中间路由器将链路带宽降低到 10 或 100 Mbps。这个场景反映了终端用户在现代网络上可能体验到的连接。

图 13 展示了前两个场景的拓扑结构，其中发送方和接收方通过单个交换机连接。在第二个场景中，使用接收器中的netem实现延迟，只影响被发送回的 ACK。

图 13. 10Gbps 测试拓扑，引入可选的 10ms 延迟。

图 14 显示了第三种场景的拓扑结构，其中路由器由基于服务器的转发器实现，该转发器使用tbf qdisc限制出口链路带宽。

图 14. 10-100 Mbps 测试拓扑，引入可选的 10ms 或 40ms 延迟。

对于流量负载，我们通过以下测试来评估算法的动态性和公平性:

2-flow 测试: 第一条流持续 60 秒，第二条流持续 20 秒并比第一条晚 22 秒开始。
3-flow 测试: 第一条流 60 秒，第二条流 40 秒并比第一条流晚 12 秒开始，第三条流 20 秒并比第一条流晚 26 秒开始。

这些测试使下列工作成为可能:

检查现有流对新流的适应速度有多快。
检查流终止并释放的带宽被新流使用的速度有多快。
度量使用相同(或不同)拥塞算法的流之间的公平性。
度量拥堵程度。
识别性能发生突然变化的情况，显示可能的不稳定性。

其他测试包括组合流，外加 10 KB 和 1 MB 的 RPC。这些测试允许我们查看较小的 RPC 流是否会受到影响，如果是的话，会受到多少影响。这些测试使下列工作成为可能:

研究在不断增加的负荷下的行为。
测量 1 MB 和 10 KB 流的性能(吞吐量和延迟)，以及在它们之间分配可用带宽的公平程度。
识别重传或延迟发生突然变化时的情况，这是不稳定的信号。

3.4.2 结果示例

下面展示了一些示例结果，我们选取这些结果来说明评估过程。从一个简单的 2-flow 实验开始，其中两个流都由相同的拥塞控制算法管理。图 15 显示了生成的 goodput 图。正如人们所希望的那样，一旦第二个流(红色部分)在 20 秒后开始，两个流的就会收敛到几乎使用相等的可用带宽。这种收敛不会立即发生(两个图在第二个流开始大约 10 秒后交叉)，其他算法试图纠正这种行为(例如，通过使用来自路由器的显式反馈)。有利的一面是，一旦第二个流结束，第一个流会很快使用释放的带宽。

图 15. 运行在相同拥塞控制算法下的两个流实现的 goodput(端到端交付的每秒字节数)。

也可以更仔细观察这两个流，例如跟踪每个流的拥塞窗口。相应的图表如图 16 所示。毫不奇怪，随着时间的推移，不同的算法会有不同的"模式"来应对拥塞窗口，我们将在下一章中看到更多细节。

图 16. 在相同的拥塞控制算法下竞争带宽的两个流的拥塞窗口(以字节度量)。

我们可以改变其中一个流程使用的算法来重复这些实验，从而可视化这两种算法是如何相互作用的。如果两者都是公平算法，我们将期望看到类似于图 15 的结果。如果没有，可能会看到类似于图 17 的结果，其中第二个流(算法 B)积极的从第一个流(算法 A)夺走带宽。

图 17. 运行在不同拥塞控制算法下的两个流的 goodput(端到端交付的每秒字节数)，其中一个流接收的带宽明显少于另一个。

可以在三个并发流中重复实验，但我们接下来要评估各种算法如何处理不同的工作负载。特别的，我们对大小公平(size fairness) 问题感兴趣，也就是说，当给定算法必须与正在进行的流竞争时，如何处理连续的 10 KB 或 1 MB RPC 调用。图 18 (1 MB 的 RPC)和图 19 (10 KB 的 RPC)显示了一些示例结果。图中显示了五种不同算法(用不同颜色表示)的性能，测试了 1、2、4、8 和 16 个并发流。

图 18. 当与不同数量的 TCP 流竞争时，通过 5 种不同算法的 1 MB RPC 调用的平均 goodput(以 Gbps 为单位)。

图 19. 当与不同数量的 TCP 流竞争时，通过 5 种不同算法的 10 KB RPC 调用的平均 goodput(以 Gbps 为单位)。

1 MB 的结果并不令人惊讶，在五种算法中没有显著的异常值，并且随着 rpc 与越来越多的流竞争，平均 goodput 越来越低。虽然图 18 没有显示，但当所有流都基于 stream 时，第四个算法(绿色)的性能最好，避免了在 RPC 调用之间共享可用带宽时会发生的大量重传。

10 KB 的结果有一个显著的异常值，第三个算法(黄色)的性能明显更好，差不多有 4 倍的优势。如果我们绘制延迟而不是带宽(这是和小消息 RPC 调用更相关的指标)，则会发现第三种算法实现了最低的延迟，其 P99 和 P999 基本相同。

最后，可以在包含广域 RTT 的网络拓扑上重复上述所有实验。当然，流之间的公平性和流大小的公平性仍然值得关注，但排队延迟也可能成为问题。例如，图 20 显示了当网络拓扑包含 10 Mbps 瓶颈链路和 40ms RTT 时，四种不同算法的 P99 延迟。关于这个结果的重要结论是，当瓶颈路由器上可用的缓冲的带宽时延积小于一个单位时，第二种算法(红色)的性能很差，这引起了对另一个可能影响结果的变量的注意。