最近读了一篇关于数据中心网络的文章，是NSDI 2021年的论文，在这里进行简单的总结，相当于是我的阅读笔记啦~

在此之前已经提出过了很多关于数据中心网络的算法，整体的思想主要是降低时延、提高吞吐量、避免拥塞的发生、避免bursty traffic ，尤其是incast traffic，经典的一些算法包括DCTCP、TIMELY、DCQCN、BBR等。

数据中心网络解决方案

现在数据中心网络的解决主要包含两类方式：

一类是依赖于网络中日益丰富的拥塞信号（ECN、queue size、link utilization等）

一类是关注数据包调度机制，通过对数据包进行调度避免拥塞的发生

近几年提出的算法越来越依赖于网络内部，比如依赖于网络拥塞的信号（rely heavily on rich congestion signals from network）或者是返回的网络的链路带宽、队列大小等复杂的信息，但是现在某些环境下并不能得到这些复杂的网络信号，比如公共云环境中，云用户可以访问网络的边缘，但是他们不能访问网络基础设施，那么他们就无法接收到拥塞控制信号或是调度机制，从而无法有效的进行拥塞控制。而本文提出的On-Ramp可以有效的解决这个问题，因为它是在网络边缘进行处理的。无需基础设施的支持就可以实现。

这篇文章提出的思想与以往的算法有所不同，以往的算法如下图所示的公式来更新发送窗口和发送的速率，但这在瞬时（transient）和均（equilibrium）状态下的权衡考虑有所欠缺，导致 Transience-Equilibrium Tension，即：在均衡状态下表现良好的参数在瞬时过载状态下的表现并不理想，反之亦然。

拥塞控制算法分别选 TIMELY 和 DCQCN，黄色代表equilibrium，红色箭头代表transient：

CC算法为TIMELY：

扫描二维码关注公众号，回复： 13233765 查看本文章

CC算法为DCQCN：

可以看到，当设定的β值符合equilibrium时（link fully utilized）transient 的性能不理想，反之，当transient理想时（排队延迟很快就下降，应对严重的暂态拥塞）equilibrium的性能又下降了。

也就是说，在没有OR的情况下，要权衡equilibrium和transient两种状态。

而如果使用了OR算法，对瞬时和均衡的性能都有明显提升，此时可以不用考虑这两者的权衡了：

CC算法为TIMELY：

CC算法为DCQCN：

所以本文将这两种网络状态解耦合，分开进行处理，提出On-Ramp，对均衡和瞬时的流量分别处理：

在均衡（equilibrium）状态下：使用现有的拥塞控制算法。（On-Ramp可以和任何数据中心拥塞控制算法结合，只需要修改终端主机而不需要修改交换机）

而在瞬时过载（transient overload）状态下：使用本文的新算法On-Ramp，On-Ramp在瞬时过载期间拦截并保存网络边缘的任何协议的数据包。

On-Ramp的核心思想：

当发送方的拥塞控制协议决定发送一个包时，如果最近确认的包的发送方到接收方的单向延迟（OWD）超过一个阈值T，则发送方会暂停发送数据包。

On-Ramp实现的关键：

On-Ramp的关键是精准的测量OWD(单程延迟)，利用OWD来检测瞬时过载的情况；本文采用的是Huygens，使得On-Ramp更容易部署。

On-Ramp的设计：

On-Ramp是一种简单的端到端流控制算法，作为拥塞控制算法和网络之间的垫片；部署在sender和receiver之间的CC算法下。

On-Ramp旨在：当 OWD的值超过阀值T时，通过暂停发送端的流使得路径队列延迟尽可能快的降低。当OWD没有超过T时，On-Ramp不起作用。

对于没有自己不控制排队延迟的拥塞算法（如 TCP、CUBIC等），On-Ramp添加这个功能

对于自己控制排队延迟的拥塞控制算法（如 DCTCP），On-Ramp起到了类似保障的作用

初始版本的On-Ramp

Receiver Side：收到Packert后，返回一个OR-ACK给sender，包含了收到数据包的时间。

Sneder Side：发送端包含两个数据结构，（i）属于当前流的未发送的数据包（ii），代表下一个数据包何时会被传送（被传送的时间）。其中的初始值为0，更新方法如下：

是现在的时间；当> 时，sender会被暂停。

但是这种计算方法存在不足，如果返回的OR-ACK在传送过程中发生丢包，那么上式就无法正确计算，的值不能正确更新。

在正确收到OR-ACK后，若OWD的值O大于阀值T，则应该暂停O-T这么长的时间后再重新发送数据包。但是O-T是理想情况下的暂停时间，即返回的ACK在链路上没有任何的延迟，实际情况应该更复杂。并且这还需要另外的一个RTT来检测O-T时间后的链路状态。

新的On-Ramp的设计：

在新设计中，还考虑了另一种情况：sender在发送数据的时候可能有暂停一会才发送的情况，但是receiver收到packet时并不知道这个情况，依然把这一段时间看作是OWD值。然后返回给sender，假设暂停的时间是P，返回的OWD值是O，那么实际的单程延迟（OWD值）不是O，而是 O-P。

文章还引入了和来分别代表black packet和green packet之间暂停的时间（即上面考虑的O-P的情况）和sender暂停对OWD值的影响，当β接近1时，说明OWD值的减少与sender暂停时间的减少大致相同（此时链路状态应该是比较畅通的）；β接近0时，说明On-Ramp必须暂停较长的时间才能降低OWD值（也就是black packet和green packet两者发送之间暂停的时间很长），也即此时发送端偏多，可能已经发生了incast的问题。