3.4 实验方法论
Last updated
Last updated
我们评估拥塞控制机制的方法是在真实系统上测量它们的性能，正如我们在第一章中指出的，各种拥塞控制机制事实上的规范是在Linux中的实现版本。我们现在将描述一种具体的测量方法，它展示了一种当今被广泛应用的一种方法论。我们的方法使用 Netesto（Network Test Toolkit），这是在GitHub上开源的一套软件工具。另一种方法是仿真，其中NS-3是最流行的开源工具。
更多阅读：
请注意，虽然本节描述的实验测量了真实的拥塞控制算法（当然，我们还没有详细描述这些算法），但本节的目的是概述如何评估算法，而不是对特定算法做出任何结论。
我们的方法会使用真实运行在Linux主机上的TCP发送端/接收端，并通过使用例如netem和 tbf qdisc的内核工具来模拟一些列的行为。性能数据通过tcpdump来收集。连接终端主机的网络由真实交换机和仿真组件组合构成，这里的网络支持例如广域延迟和低带宽链路。
实验可以通过两个正交维度进行描述。一个是网络的拓扑结构。这包括链路带宽、往返时延（RTTs）、缓冲区大小等。另一个维度是我们在网络上运行的流量负载。这包括数据流的数量和持续时间，以及每个流的特点（例如，是流媒体还是RPC）。
对于网络拓扑，我们将在以下三种配置上评估算法：
LAN，带有20us的RTT和10Gbps的链路带宽。这个场景代表了同一个数据中心机柜中的服务器之间的网络。
WAN，带有10ms的RTT和10Gbps的链路带宽，以及接收端配置的深度为20000个packet的队列。瓶颈在一个有着浅buffer（1-2MB）真实的交换机。这是一个很好的用来观察，当有2-3个数据流时，算法的动态特征的场景。
WAN，带有40ms的RTT，以及一个将链路带宽减少至10或者100Mbps的中间路由器。这反应了一个终端用户在当今互联网上可能经历的场景。
图 13 展示了前两种情景的网络拓扑，发送端和接收端通过单个交换机连接。通过在接收端中使用 netem 实现了第二种情景的延迟，这仅影响了返回的 ACKs。
图 14 展示了第三种场景的网络拓扑，在这种场景中，路由器由一个基于服务器的转发端实现，该转发端使用 tbf qdisc 来限制出站链路的带宽。
对于流量负载，我们通过以下测试评估算法的稳定性和公平性：
两个数据流测试：第一个数据流持续60秒；第二个数据流持续20秒，并在第一个流之后22秒开始。
三个数据流测试：第一个数据流持续60秒；第二个数据流持续40秒，并在第一个流之后12秒开始；第三个数据流持续20秒，并在第一个流之后26秒开始。
这些测试能够做到以下：
检查现存的数据流多快能适应新的数据流的加入
检查数据流终结之后多快会释放带宽
测试数据流在使用相同或者不同的拥塞算法时的公平性
测量拥塞的等级
确定在何种情况下性能会突然变化，这表明了拥塞控制算法的不稳定性
附加测试包括结合流媒体、10-KB 和 1-MB 的 RPC。这些测试使我们能够看到小型 RPC 流是否有公平的分到网络资源，如果没有，那究竟有多不公平。这些测试可以：
研究负载增加时的行为
测试1-MB和10-KB数据流的性能（吞吐量和延时），同时也测量它们之间的带宽分配有多公平
确定何种情况下重传或者延时会突然变化，这表明了拥塞控制算法的不稳定性
加下来将会展示一些选定的测试结果，旨在说明评估的过程。
我们从一个简单的两个数据流 测试开始，这两个数据流都采用相同的拥塞控制算法。图15显示了得出的goodput 示意图。正如人们所希望的那样，一旦第二个流（用红色表示）在20秒后开始，两个流的 goodput 就会趋于相同，并平等的共享可用带宽。但是这种收敛并不是立即发生的（两个图在第二个流开始后大约十秒钟交叉），这也是其他方法试图纠正的地方（例如，通过使用路由器的显式反馈）。好的一面是，一旦第二个流结束，第一个流很快使用了被释放的带宽。
我们也可以更仔细地观察这两个数据流，例如，通过跟踪每个数据流的拥塞窗口。相应的图表显示在图16中。不出所料，不同的算法的拥塞窗口随着时间会有不通的“模式”，我们将在下一章中看到。
我们可以通过对其中一个数据流使用不同的算法，来重复这里的实验。这样可以让我们看到两个不同的算法之间是如何相互作用的。如果它们都是公平的，你可以预期看到的结果类似于图15。如果不是，你可能会看到一个类似于图17的结果，在该图中，第二个数据流（算法B）会激进地从第一个数据流（算法A）那里抢夺带宽。
上面的实验可以继续按照3个并发数据流来进行，但我们接下来将评估不同算法处理不同工作负载的情况。我们特别感兴趣的问题是 尺寸公平性（size fairness），即，当有正在进行的持续的数据流时，给定的算法如何处理连续的10 KB或1 MB的RPC调用。一些示例结果展示在图18（1-MB RPCs）和图19（10-KB RPCs）。这些图展示了五种不同算法（用不同颜色表示）在1、2、4、8和16个并发数据流中的性能。
1-MB结果并不令人惊讶，因为五种算法中没有显著的异常点，并且当RPC与越来越多的数据流竞争时，平均goodput会下降。虽然图18没有显示，但在所有流都是长时间数据流的情况下，第四种算法（绿色）表现最佳，因为与它在于RPC竞争时有大量重传。
在10-KB结果中，第三种算法（黄色）的表现的明显更好，性能比其他算法好4倍。如果你绘制延迟而不是带宽图——对于小的RPC调用来说，这是一个更重要的指标——结果显示第三种算法不仅实现了最低的延迟，并且在一致性上也做得很好，其第99个和99.9个百分位数相同。
最后，所有前面的实验都可以在一个包含了广域网RTT的网络拓扑上进行。当然，数据流之间的公平性和尺寸公平性将继续是关注点，但队列延迟成为问题的可能性也增加了。例如，图20展示了当网络拓扑包含一个10-Mbps的瓶颈链接和40ms RTT时，四种不同算法的99%延迟情况。关于这一结果的一个重要观察是，当瓶颈路由器处的缓存可用量小于一个带宽延迟积时，第二种算法（红色）表现不佳，这提醒我们还有其他变量可能影响你的结果。
当我们在结束实验方法的讨论时，如果我们只能一句话总结，那就是：在查看了这么多算法，这么多网络拓扑，这么多不同的网络流量场景之后，我们知道，没有一个算法在所有条件下比其他所有的算法都要好。如之前的例子所示，其中一个解释是，有太多因素需要考虑了。这也解释了为什么拥塞控制持续成为网络研究人员和网络实践者关注的话题。
