参考资料:
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的流链路占有率非常低。