NSDI‘2021 A New Approach to Datacenter Packet Transport论文阅读笔记

这篇文章发表于NSDI’2021，也是NSDI2021年唯一一篇有关于数据中心拥塞控制的文章（我看到的）。特别提一下这篇文章的三作默罕默德，曾经发表过论文DCTCP，行业大牛不解释。

背景介绍

十多年来，数据中心协议设计一直是一个活跃的研究领域。它的主要目标是实现高吞吐量和低延迟，并有效地处理突发流量，incast问题。

从最早的数据中心拥塞控制协议DCTCP到现在目前最新Homa和HPCC，在这几个目标上已经有了非常大的进步。但是同时也要注意到，这些最新算法越来越多地需要网络内部的支持，这些内部的支持包括有更加复杂的拥塞信号的传递。例如早期的拥塞信号只有一些简单的ECN标记，到后来可能有例如链路利用率，链路带宽，队列大小等复杂信息。一方面这些复杂的机制导致了协议部署难度加大（可能需要修改交换机），另一方面在一些特定环境下，网络是不能导出复杂的网络信号，也不能进行复杂的包调度，比如说公共云客户所处的环境。

所以，这篇文章的目的就是想要设计一种少量需求网络内部支持的简单机制On-Ramp，尽可能地实现数据中心的高吞吐量和低延迟的目标，同时也能够有效地处理突发流量。

问题分析

在方案构思上，论文首先将网络中的状态分为了两种，瞬时状态 与一般状态。论文认为应该更多地把设计的注意力集中在瞬时状态，因为大多数的拥塞控制机制在一般状态下能够保证良好的性能。而在使用有限的拥塞信号的前提下，瞬时状态下的问题是不太好解决的，因为发送方必须非常快速地对流量的上升进行反应，以防止丢包。而过于快速地反应又会和流稳定收敛形成冲突。

换句话说，这篇文章想要做的事情是将整个网络中的状态解耦合为两种状态，一般状态就使用现有的拥塞控制协议，瞬时状态再采用设计的On-Ramp方案，从而回避之前提到的那些复杂拥塞信号的问题。

那么，为什么要进行这种解耦合处理呢？这里以TIMELY和DCQCN两个拥塞控制协议举例。这两张图展示的都是十二条流存在于网络中，向一个接受端进行发送，其中两条流从第零秒开始发包，剩下十条流第两百毫秒开始发包。

可以发现，激进地选择减窗参数虽然可以使得incast问题能够被很快地解决，但是同时也会导致带宽利用率过低；而选择平缓的减窗参数虽然会使得利用率维持在100%，但是面对incast问题时反应相当缓慢。
这两个例子说明了一个问题：在没有使用丰富的拥塞信号的情况下，两种状态是要进行权衡的。

方案设计

On-Ramp的设计思路是如果最近一个被接收到的数据包的单边延时(OWD)大于阈值T，那么发送方会暂停该条流的发送。通过这种方式将瞬时状态从普通状态下解耦合出来，因为如果单边延时的大小不会超过T，On-Ramp不会生效。它会对瞬时状态并发流的生成来进行阻止。

它可以与任何现有已经存在的拥塞控制协议相结合，只需要修改终端主机而不需要修改交换机。对于对于自己不能控制排队延迟的拥塞控制算法(例如TCP CUBIC)， on - ramp添加了这个功能。对于一个自身能够控制排队延迟的拥塞控制算法(例如DCTCP)， on - ramp的工作方式就像一种保护措施，用于降低尾部延时。

为了讲清楚On-Ramp的算法细节，论文中首先介绍了一个Strawman(稻草人)版本。当测得 $OWD>T$，发送方将这条流暂停直到时间 $t_{Now}+OWD-T$，如果$OWD<T$,发送方正常发包。具体有公式如下所示：

这么做的目的是希望将队列延时降低到T。但是要注意的是RTT除了两个往返延时以外还包括有接受端收到包以后的ACK周转时间，反馈延时。没有考虑这一段反馈延时的后归就是它高估了OWD降到t所需的额外暂停时间，也就是说总体暂停时间会偏长，从而导致链路利用率偏低。

纠正问题的一种方法是，从ack中获得的OWD值O减去发送方在飞行中暂停的总时间。这种方法假设，如果发送方暂停了一段时间P，那么OWD的当前值不再是O，而是$O-P$。然而，这忽略了其他发送方对OWD的贡献。也就是说，应该减去的值不是P，而是最多为P，这里不应该这么简单地进行处理，会导致暂停时间偏短，最后延时会在阈值T之上，这也是论文中不愿意看到的。

在这里论文新定义了两个参数，$P_{BG}$与${\beta }_m$。$P_{BG}$为BLACK流和GREEN流中间暂停的总时长。${\beta }_m$代表发送方暂停对OWD造成的影响。$O_B{O}_G$是单边延时。${\beta }_m$接近于1表明OWD的减少与发送者暂停时间的减少大致相同；${\beta }_m$接近0时，表明On- ramp必须暂停较长时间才能降低OWD，也就是说此时发送端偏多，可能已经发生了incast问题。

取${\beta }_m$滑动平均降低偶然误差，得到有最终的Or-Ramp发包公式，解决之前暂停时间偏长或者是偏短的问题。

这里看到一组实验，分别是基于CUBIC的strawman版本的与最终版的比对，第二个流在第6秒打开。很明显，strawman On-Ramp导致显著的队列不足，并导致利用率不足，最终的On-Ramp修复了这个问题。

问题分析与总结

简单来说，这篇文章就是想要在不使用复杂拥塞信号的前提下解决incast问题，On-ramp给出的解决方案非常简单，就是通过暂停，只要我停住并且不停过头，那么incast问题就不会存在了。

首先是这篇文章对于能够自我调节延时的协议帮助非常有限，比如说DCTCP或者是HPCC，它们本身就不需要On-ramp的帮助就已经解决了这些问题。
然后是公平性问题。On-ramp的应对方式其实相当消极，只要owd低于阈值就会暂停。那么如果网络中其它的流全都是类似于CUBIC这种会把缓冲区全部填满的激进算法呢？On-ramp算法在这种竞争中无疑会出于绝对的劣势，从而使用了On-ramp的流链路占有率非常低。
另外，On-ramp其实也破坏了算法本身的调节功能。很多算法的公平性都来自于AIMD，On-ramp使得AIMD中的乘法下降完全不能正常工作，那么这些流的公平性从何而来？

这篇文章想法还是非常简单的，能发这种顶刊还是赢一手写作优秀，赢一手实验到位（扬长避短，公平性实验在论文中完全没有体现），还赢一手三作默罕默德大佬hh。