On-Ramp算法参考资料

参考资料：

NSDI 2021 Breaking the Transience-Equilibrium Nexus: A New Approach to Datacenter Packet Transport笔记
https://blog.csdn.net/weixin_44260459/article/details/120687536?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.fixedcolumn&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.fixedcolumn

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

https://blog.csdn.net/weixin_41820355/article/details/116272188

Breaking the Transience-Equilibrium Nexus A New Approach to Datacente

https://www.bilibili.com/video/BV1Zy4y1s76Z?p=10

NSDI 2021】Breaking the Transience-Equilibrium Nexus【双语字幕】

https://www.bilibili.com/video/BV1764y1q7TN

OnRamp NSDI’21

https://zhuanlan.zhihu.com/p/378519343

NDSI21: On-Ramp论文解读

https://zhuanlan.zhihu.com/p/373194288

===================================================

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

​ 一类是 依赖于网络中日益丰富的拥塞信号（ECN、队列大小，链路利用率等）

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

2 近几年提出的算法越来越依赖于网络内部的支持，这些内部的支持包括有更加复杂的拥塞信号的传递。比如：ECN标记，到后来可能有例如链路利用率，链路带宽，队列大小等复杂信息。

3 On-Ramp是为了解决什么问题？

尽可能地实现数据中心的高吞吐量和低延迟的目标，并有效地处理突发流量，incast问题。

少用网络内部支持。

4 应用环境换了？

但是现在某些环境下并不能得到这些复杂的网络信号，比如公共云环境中，云用户可以访问网络的边缘，但是他们不能访问网络基础设施，那么他们就无法接收到拥塞控制信号或是调度机制，从而无法有效的进行拥塞控制。

一方面这些复杂的机制导致了协议部署难度加大（可能需要修改交换机），另一方面在一些特定环境下，网络是不能导出复杂的网络信号，也不能进行复杂的包调度，比如说公共云客户所处的环境。

5 原来的方法为啥不好？

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V77neV77-1641267015993)(C:\Users\dongzhi\Desktop\1数据中心网络\picture\On-Ramp\TIMELY和DCQCN两个拥塞控制协议举例.png)]

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

6 On-Ramp算法思路：

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

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

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

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

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

On-Ramp的算法细节：

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

优点：

1、该方法使得即使是在虚拟机环境下也能正常的进行拥塞控制

2、如果部署起来比较简单，因为它只需要更改终端设备即可，无需更改交换机等

不足：

1、对于HPCC和DCTCP这类本身就是依靠时延避免拥塞的算法而言，On-Ramp对它并没有明显的性能提升。对于对于自己不能控制排队延迟的拥塞控制算法(例如TCP CUBIC)， on - ramp添加了这个功能。对于一个自身能够控制排队延迟的拥塞控制算法(例如DCTCP)， on - ramp的工作方式就像一种保护措施，用于降低尾部延时。

2、然后是公平性问题。On-ramp的应对方式其实相当消极，只要owd低于阈值就会暂停。那么如果网络中其它的流全都是类似于CUBIC这种会把缓冲区全部填满的激进算法呢？On-ramp算法在这种竞争中无疑会出于绝对的劣势，从而使用了On-ramp的流链路占有率非常低。