基于网络弹性流检测机制的拥塞控制

 在别人的文章里，永远不会找到自己的答案。
 2016年谷歌发表了BBR拥塞控制算法，之后就是一个研究拥塞控制的小高潮，这些文章大多会在2018年出现。下面看罗列的文章[1-4]，都是MIT的研究人员提出的。[1]根据网络中流的分类(弹性流，非弹性流)情况，采用分别不同拥塞控制机制(loss based or delay based)。弹性流(elastic traffic)就是发送速率随网络状况变化的流，反之，就是非弹性流(inelastic traffic)。TCP流属于弹性流，而一些恒定码率的数据流属于典型的非弹性流。基于丢包的拥塞控制机制，属于buffer-filling algorithms，导致了网络中较大的时延。而基于时延的拥塞控制同基于丢包的拥塞控制机制进行瓶颈带宽竞争的时候，处于劣势。但是如果网络中cross trffics(就是在同一条网络链路中，刨除自身的流量)属于非弹性流，流S如果采用基于丢包的拥塞控制算法，则会导致self inflicted delay，就是流S给自己制造了时延。[1]就是提出一种网络弹性流的检测机制，非常经典，将傅里叶变换用在网络中。
 在瓶颈链路满载的情况下(队列在增加却未丢包)，假设网络瓶颈链路容量为$\mu$，发送端的发送速率为$S(t)$，cross traffics 的发送速率为$z(t)$，接收端的接收速率为$R(t)$,cross traffics 的接收速率为$\mu-R(t)$。

 文中认为，输入的速率比等于输出的速率比(意会一下)。
$\frac{S(t)}{z(t)}=\frac{R(t)}{\mu-R(t)}\Rightarrow z(t)=\mu\frac{S(t)}{R(t)}-S(t)\tag{1}$
 通过式(1)可以估计网络中的cross traffic 速率$z(t)$。
 由Jacobson确定的AIMD的TCP拥塞控制机制，有个特点，在拥塞避免阶段，它的发送速率是ack-clocking的，遵循 the principle of packets conservation，在确认有一个数据包离开网络后，才向网络中注入一个新的数据包。ack的返回间隔可以影响TCP的数据发送速率。[1]而文中提出的弹性流检测机制，就是基于这个事实。发送方可以采用一个正弦函数式发送速率$S(t)$，类似于BBR的带宽探测机制，在一定的时间增大发送速率，增加网络中的排队数据包，再以一定的时间间隔减少发送速率，排空之前造成的排队，保持平均发送速率不变。在发送端注入数据包阶段，这样可以在瓶颈链路上增大cross traffic 数据包之间的间隔，使得cross traffic收到ack的间隔变大，使得cross traffic的发送速率减少。假设之前的ack之间的间隔为d，ack间隔增大后为$d+\delta$,那么这两种情况下，cross traffics的发送速率分别为$\frac{1}{d},\frac{1}{d+\delta}$ pkt/s。就是说探测出来弹性流的发送速率$z(t)$随$S(t)$周期性变化。但是非弹性流却没有这种速率变化规律。看看，原文中的图例。

 文中选取的$S(t)$的频率为5Hz,为了对瓶颈链路能够造成明显的排队，$S(t)$的在速率增加阶段振幅为$\frac{\mu}{4}$。
 最后，对测量得到的$z(t)$进行傅里叶变化，若是频谱集中在5Hz附近，证明网络中存在弹性流，可以看下图例。此时$S(t)$应该采用基于丢包的拥塞控制算法。

[1]Elasticity Detection: A Building Block for Delay-Sensitive Congestion Control
[2]Restructuring Endpoint Congestion Control(sigcomm 2018 submission)
[3]PCC Vivace: Online-Learning Congestion Control(2018-NSDI)
[4]Copa: Practical Delay-Based Congestion Control for the Internet(2018-NSDI)