Sigcomm‘2020 Annulus: A Dual Congestion Control Loop for Datacenter and WAN Traffic Aggregates论文阅读笔记

Introduction

Annulus这篇文章是麻省理工发表于2020年sigcomm上面的文章，主要解决了WAN flows和datacenter flows混合而导致的尾部延时上升的问题。

Background

在现在的数据中心中，有一些主机会同时发送数据中心的流量以及WAN流量。
数据中心的流量会使用数据中心的拥塞控制，而WAN的流量会使用WAN的拥塞控制。

这两种网络环境的区别是非常大的。数据中心端RTTs更小，缓冲区也更浅。同时引入了一些新的挑战类似于incast问题。在数据中心中运营商几乎可以控制所有的网络元素，这提供了一些更加灵活的拥塞控制部署方案：包括DCQCN，TIMELY，HPCC等等。 而在WAN中，RTT更长，带宽更大，缓冲区也更大。现有的一些控制算法包括BBR，PCC，Copa等。

这篇文章关注的点在于：当在瓶颈中，两种不同的流量使用它们各自的拥塞控制算法会有什么不良的反应吗？
这两张图是从谷歌收集到的数据。上图展示了WAN的吞吐量，而下面的图展示了在数据中心中95%的尾部延时以及99%的尾部延时。突出点区域表面当WAN的需求明显增加时，数据中心的尾部延时增加了一倍以上。

论文还检查了ToR交换机上的丢包率。ToR交换机是网络超载的第一个点，可以看到，随着WAN吞吐量的增加，ToR交换机上的丢包率也在增加。

这说明，WAN的需求会严重影响到数据中心流量的丢包率以及延迟。下面的内容会详细介绍为什么这样，以及如何补救。

WAN的RTT通常在数十毫秒的数量级，另一方面，数据中心的RTTS通常为微秒级。当拥塞发生时，数据中心流量会很快地检测到它并且解决它。
换句话说，WAN会花费数千个数据中心中的RTTs来检测拥塞，这会导致拥塞控制的全部负担都会来到数据中心流量。

这里用仿真举了一个例子。当飞行包的数量增加，队列开始堆积时，数据中心的拥塞控制马上开始发挥作用排光队列。而当WAN的拥塞控制开始发挥作用时，拥塞问题早就被解决了。

而同时，广域网的流也会受到影响。因为WAN拥塞控制多是基于BDP来进行设计的，而数据中心的buffer非常浅，这会带来一些问题。

这里论文提出了自己的解决方案：annulus。

Annulus

Annulus应该解决两个问题：
1，如何解决瓶颈上WAN和datacenter共享的问题。
2，共享以外其他的瓶颈如何解决。

要回答第一个问题，必须看到这个问题的起因：这个问题之所以存在是因为WAN的反应过于缓慢。所以，论文的主要想法是减少WAN的反馈延时。
通过使用bottleneck直接生成拥塞信号反馈回发送端可以达成这个目标。

对于第二个问题，Annulus使用双控制回路方案的第一个回路控制方案来解决。第一个回路控制方案是依靠现有的拥塞控制，也就是WAN的拥塞控制用于WAN的流，数据中心的拥塞控制用于数据中心的流。

Annulus添加了第二控制回路，论文中称为近源控制回路（Near-source control loop），它对底部的拥塞做出反应，这里是WAN与数据中心共享瓶颈的地方。当拥塞发生时，会有显式的拥塞通知信号QCN反馈回发送方，准确地告知是哪个流引起了拥塞，然后降低那条流的发送速率。

Near-Source Control Loop

这里对近源控制回路进行详细介绍。

ideal

这里的模型认为在数据中心中存在有不属于数据中心的流。如果这个模型是普遍模型的话那么接收端驱动就失去意义了，由于广域网的流的终点并不是数据中心的交换机，接收端驱动的拥塞情况会比基于速率与基于窗口的拥塞控制情况要差得多。