SIGCOMM 2022 Elasticity Detection:A Building Block for Internet Congestion Control

弹性

该文章介绍了一种新的指标“弹性”，它描述了交叉流量与流竞争的性质。弹性描述交叉流量是否对可用带宽的变化做出反应。如果一个流，它的发送速率会随着可用带宽的变化而变化，那么就说它是弹性的。并且如果交叉流量包含任何弹性流，则整体是弹性的，否则它是非弹性的。

随后该文章针对如何检测这种弹性流量进行介绍，因为这样的流对于拥塞控制有着非常重要的意义

NimbusCC

NimbusCC是一种拥塞控制器，使用Nimbus在TCP竞争模式和延迟控制模式之间切换。由于目前存在在的拥塞控制协议例如BBR，GCC等本质上都是TCP竞争协议，只要在链路中有他们吃得下的带宽就会照单全收，竭尽全力为自己服务的应用争取资源，当发生拥塞以后，才会执行回退，降低自身的发送速率，但这往往只是亡羊补牢之举。NimbusCC相当于在竞争的基础上加入了文明模式，检测到是弹性流就会根据带宽的变化动态调整发送速率。但是延迟控制协议在部署问题存在一个主要障碍：当在共享瓶颈上与更积极地竞争带宽的流（例如Cubic、NewReno、BBR等）竞争时，它们的吞吐量会受到影响。例如，在没有数据包丢失或ECN的情况下，Cubic流会稳步提高其速率，导致排队延迟上升；为了应对这些不断增加的延迟，竞争的延迟控制流将降低其速率。然后，Cubic流抓住这个释放的带宽。延迟控制流的通放率直线下降，但延迟不会减少。

NimbusCC估计流速的方法

S(t)表示发送端发送速率，z(t)表示交叉流量，R(t)表示接受端的接收速率
进入瓶颈队列的总流量为S(t) +z(t)，接收者看到R(t)。只要瓶颈链路繁忙（即其队列不是空的），并且路由器以相同的方式处理所有流量，R(t)与H的比率必须等于S(t)和总传入流量S(t) +z(t)的比率，因此就可以推算一个z(t)的估计

弹性流量的检测方法

从上图可以看到，以Cubic流为例（因为TCP竞争协议的流通常包含弹性的和非弹性的两个阶段，可以清晰的比较），它的弹性和非弹性阶段的队列时延变化几乎是没有差异的，因此只是使用简单的RTT测量是没有办法判断这个流是否包含弹性成分

因此要检测弹性流量就必须从弹性流量的特点着手，弹性流量的特点是会根据带宽的变化而变化，那么考虑发送一个瞬时大流量（脉冲）短时间内挤占链路，那么如果是弹性流量就必然会引发速率较大的变化（如图3），这样就可以根据速率是否有显著变化来区分一个流是否含有弹性成分。

弹性检测实现

基于上述的讨论，实现弹性检测就面临着第三个挑战

1. 发送速率中的脉冲必须引起 z 的可测量变化，但不会阻塞瓶颈链路（如何控制脉冲的发送以及频率）。
2. 由于交叉流量和 z 中的噪声存在自然变化，因此很难在 z 的预测变化和测量的 z 之间进行稳健的比较。
3. 由于发送方不知道交叉流量的 RTT，因此不知道何时在交叉流量速率中寻找预测响应。
   文章介绍了一种方法：首先，发送方使用已知频率为5的正弦脉冲来调制其数据包传输，这些脉冲在链接处诱导包间时间的显著变化，而不会引起拥堵，因为在脉冲的一部分中创建的队列在后续部分被排出，脉冲的周期很短。通过使用短脉冲，我们确保在脉冲中发送的数据总爆发只是典型瓶颈队列大小的一小部分，使用快速傅立叶变换将时域信息转换到频域，观察流量是否对5Hz频段的干扰产生强烈反应
   
   可以看到，只有弹性流量会对5Hz产生强烈的反应，因为在%Hz频段遭到干扰

但是这种方法目前我还存在一些问题，比如为什么一定要使用5Hz的频率调制数据包发送，文章中没有给出5Hz的使用理由，还是说使用其他频率也是可以的？