3.3 对比分析

测量任何拥塞控制机制的第一步是单独评估其性能，这包括了：

• 数据流能达到的平均吞吐量（goodput）

• 数据流经历的平均端到端延时（RTT）

• 在一系列操作场景下避免持续队列堆积的机制

• 在一系列操作场景下保持传输稳定的机制

• 数据流可以多公平的获得网络容量的程度（Jain的公平性指数）

第二步不可避免的要比较两种或者多种机制。这是因为互联网的去中心化性质，无法确保整个互联网只采用一种机制，因此必然要比较两个或多个机制。量化单个机制的指标（如吞吐量）的比较容易，难得是如何评估可能共存并同时竞争网络资源的多个拥塞控制机制。

这里的问题不在于特定机制是否对其所有流量公平对待，而在于机制A是否对由机制B管理的流量公平。如果机制A能够获得相对于B的更高的吞吐量，但这种提升是通过更加激进的方式来窃取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: 如果一个公平性阈值，通过关注机制A所能达到的吞吐，来判断当存在竞争的数据流时，新机制B是否影响A，那么这个阈值又这忽略了其他重要的性能指标，诸如延迟、流完成时间和丢包率。

• Assumption of Balance: 机制间的相互作用可能是正面也可能是负面的，但是Jain 的公平性指标无法区分这两种情况。从可部署性的角度来看，新机制B占用的带宽比现有机制A更多，还是会留给A更多的带宽，这两种情况是有区别的：前者可能会引起现有的A用户的抱怨，而后者则不会。但是Jain 的公平指数对这两种情况会得出相同的评分。

相较于简单的计算Jain 的公平指数，Ware提倡基于伤害 设立一个阈值，伤害通过吞吐量减少、延迟增加或抖动增加来衡量。直观上，如果使用新机制B的流对使用现有机制A的流造成的伤害量，少于在一个由A管理的数据流对其他A管理的流造成的伤害量，我们可以认为B与A并行部署而不会造成伤害。Ware接着提出了可接受伤害的具体度量标准，这比最初看起来要复杂得多。即使是单一的拥塞控制算法，一个流对另一个流造成的伤害量也依赖于多种因素，如其RTT、开始时间和持续时间。因此，伤害的度量需要考虑到不同流在现有机制下彼此影响的范围，并力求新算法不会带来更糟的结果。