Elasticity Detection:A Building Block for Internet Congestion Control读后感

        这周我读的论文是Elasticity Detection:A Building Block for Internet Congestion Control。这篇论文提出了一个新的度量“弹性”，用来表征与流(flow)竞争的交叉流量 (cross-traffic) 的性质。弹性捕获交叉流量是否对可用带宽的变化作出反应，弹性检测可以通过启用延迟控制拥塞控制协议来减少Internet中的延迟，而不会损害流吞吐量，这篇论文还证明了在没有路由器的支持下，在发送端健壮地检测交叉流量的弹性是可能的。

       实现高吞吐和低延迟是拥塞控制的一个关键目标，一个重要的提议类别是延迟控制拥塞控制协议，延迟控制协议方案（如Vegas，FAST，LEDBAT，Sprout， Copa）随着延迟的增加降低其速率，但是在Internet上部署延迟控制协议有一个主要的障碍：当与共享瓶颈处竞争带宽更激烈的流(例如Cubic、NewReno、BBR等)竞争时，它们的吞吐量会受到影响，例如，一个Cubic流稳定地增加其速率导致排队延迟的上升，而为了响应这些延迟，一个竞争的延迟控制流将降低它的速率，然后Cubic流就能获得释放出来的带宽，而对延迟控制流而言，非但延迟没有减少，吞吐量还在直线下降。

        因此，这篇论文就在探寻是否可能在不降低吞吐量的情况下实现延迟控制协议的好处的答案时提出了Nimbus，它只使用端到端时延和速率测量来检测瓶颈链路上的竞争流量是否具有弹性。弹性流是指它在感知到共享瓶颈处有更多带宽可用时增加其速率，而在其他情况下降低其速率。交叉流量作为一个整体，如果它包含任意弹性流，那么它就是弹性的，否则时非弹性的。当Nimbus认为交叉通信是非弹性的时，发送方可以使用延迟控制协议来减少发送方和交叉通信的延迟，而不必担心吞吐量损失。否则，它可以切换到一个tcp竞争协议，如Cubic(或任何被认为占主导地位的协议)，以在不试图减少延迟的情况下很好地进行竞争。

        这篇论文还设计出了一种鲁棒弹性检测器。光轮发送器通过用正弦脉冲调制其速率来测量弹性，从而在瓶颈处以特定频率(例如5hz)产生流量的小波动。同时，它通过测量自身的发送和接收速率来估计交叉流量的速率，并通过快速傅里叶变换(FFT)计算交叉流量的频率响应，以确定其速率是否在同一频率振荡。如果是，发送方认为交叉流量包含弹性流;如果不是，它就是无弹性的。

       论文用NimbusCC演示了使用弹性检测进行拥塞控制的好处，NimbusCC是一个拥塞控制器，它使用Nimbus在tcp竞争模式和延迟控制模式之间切换。论文使用Vegas、Copa(默认的“延迟”模式)和BasicDelay(一种使用交叉流量速率估计器的新方法)作为延迟控制协议的例子，以及Cubic和NewReno作为tcp竞争协议的例子来报告结果。实验结果表明，Nimbus对各种交叉交通条件具有鲁棒性，即使交叉交通是不同大小的非弹性流和弹性流的高度动态混合。针对由可变数量的TCP流组成的弹性流量，NimbusCC实现了理想值的10%以内的吞吐量，而Copa则低54%。对于泊松分布非弹性交叉流量，NimbusCC也比Cubic低60毫秒的平均延迟。

        Nimbus检测流是否具有弹性的思想是：Nimbus首先要估计发送端的交叉流量的总速率，之后通过监测交叉流量在一段时间内如何响应瓶颈链路上诱导的交叉流量变化来检测弹性。关键的观察结果是，弹性流以可预测的方式对瓶颈处的速率波动作出反应，相比之下，非弹性流的发送速率不依赖于接收速率。具体操作就是通过在瓶颈链路上以脉冲形式发送数据包来诱导交叉流量的包间间隔的变化，发送这样的脉冲(例如，在正弦信号上调制)可以以可控的方式改变离开瓶颈链路的交叉流量的包间间隔。如果交叉通信包含弹性流，那么由于这些流的ACK时钟的诱导变化，它们的速率将对脉冲作出反应。

       而用这一思想指导实践时面临着挑战：发送速率中的脉冲必须引起交叉流量总速率的可测变化但不能使链路阻塞；因为交叉交通中有自然的变化，而且在交叉流量总速率z中有噪声，所以在z的预测变化和测量z之间进行稳健的比较并不容易。而论文解决这些挑战的方法是光轮，但是可能由于个人缺乏相关知识，对于为何发送方使用已知频率fp的正弦脉冲（振幅等于瓶颈连接率的一部分）调制其包传输就能使交叉流量产生可测变化且不会拥塞，以及频域检测周期性的过程和目的都不理解。而且，对于后文中针对一个瓶颈被多个NimbusCC流共享时的解决方法也无法理解。