最近读了一篇关于数据中心网络的文章，是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：? ? ?
?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的问题。
对于β值的计算：
? g是一个EWMA增量
经过调整，下一个数据包发送时间 的计算方式更新如下，取代了原本的（2）式：
所以，新的On-Ramp的方法主要改动如下：，引入了
，更新OWD值的计算方法，也更新了下一个数据包何时发送的时间的计算方法。
新旧On-Ramp性能对比如下：?
OWD的准确度对于整个On-Ramp方法的性能非常重要
部署?
?包括四个部分：
????????① On-Ramp controller：在sender端，用于计算OWD值并决定是否要暂停sender发送数据
? ? ? ? ② NIC drive：两端都有，可以在物理和虚拟环境中都存在
? ? ? ?③? QDisc：在sender端，将包排队到每个流的队列中，并在每个流的基础上施加暂停
? ? ? ? ④ On-Ramp acker：在receiver端，是UDP数据，用于回应给sender，避免用TCP类型的数据来回应，因为TCP协议是可靠传输，可能会导致延迟等。
除此之外，还有几个问题需要解决：
?1.Timestamp collection：用于计算OWD值
?2.The effect of generic send offload (GSO)：GSO对上层协议栈的开销有影响，同样对On-Ramp的性能也有影响，GSO值减小可以使得OR性能提高，但GSO值减小,上层的开销，CPU的开销会增加，因此这里存在一个权衡
?3.Behavior after a pause ends：当暂停结束时，rate pacer将按照CC确定的速率继续向网络释放数据包，因此传输不会出现bursty的情况。
评估?
关于实验的测试评估，
选用了三种不同的环境：public cloud、CloudLab cluster(bare-metal cloud)和ns-3 simulations ；
用到的CC算法有： DCQCN、TIMELY,、DCTCP和HPCC；
使用的流量负载有两种：incast type traffic 和 background traffic（包括不同大小的流量）
????????其中，background traffic来自 WebSearch、FB_Hadoop、GoogleSearchRPC
关于测试的结果在文中有详细的介绍。
总结：
整体来说，这篇文章的思想比较简单，就是判断是否发生拥塞，发生了就从数据来源处进行处理，暂停发送端发送数据，等待一段时间后再发送。
主要是利用OWD（单程时延）来判断网络是否发生拥塞，发生了拥塞后则暂停发送端的数据发送，直到下一个可以发送数据的时间后再发送数据包，文中对”OWD值“和 ”下一个数据包的发送时间“进行了比较仔细的计算。
?优：
? ? ? ? 1、该方法使得即使是在虚拟机环境下也能正常的进行拥塞控制
? ? ? ? 2、如果部署起来比较简单，因为它只需要更改终端设备即可，无需更改交换机等
不足：
? ? ? ? 1、对于HPCC和DCTCP这类本身就是依靠时延避免拥塞的算法而言，On-Ramp对它并没有明显的性能提升。
????????2、然后是公平性问题。On-ramp的应对方式其实相当消极，只要owd低于阈值就会暂停。那么如果网络中其它的流全都是类似于CUBIC这种会把缓冲区全部填满的激进算法呢？On-ramp算法在这种竞争中无疑会出于绝对的劣势，从而使用了On-ramp的流链路占有率非常低
第2点 不足是在参考了其他博主笔记后加上来的，由于我也是刚入门，还想不到那么多的问题。
? ? ? ?参考链接：https://blog.csdn.net/weixin_41820355/article/details/116272188