SIGCOMM22 论文分享 | Elasticity Detection: A Building Block for Internet Congestion Control

  本期分享的论文是由微软研究院和MIT发表在SIGCOMM2022拥塞控制会议上的一篇文章。该文主要引入了一个新的度量：“弹性”，用来表征竞争时的交叉流量的性质。弹性捕获了交叉流量是否对可用带宽的变化作出反应这一属性。文章提出的NimbusCC在没有路由器支持的情况下，能够在发送端健壮地检测交叉流量的弹性，而且可以根据弹性检测来启用延迟控制拥塞控制协议，以达到减少延迟而不会损害吞吐量的目标。下面，我将具体地介绍该文的主要内容以及读后感言。

研究动机

  该文首先揭示了“延迟控制”的拥塞控制机制（例如Copa、Vegas等）与其他流量竞争时的性能问题：（1）当它和其他更具有带宽竞争力的“缓冲填充”的拥塞控制机制（例如Cubic、Reno等）竞争时，瓶颈链路的延迟增加后，“延迟控制”拥塞控制机制很快降低了发送速率，从而导致吞吐量低；（2）当它和固定比特率的流量（CBR）竞争时，不仅减少了延迟并且没有损失吞吐量；而对于“缓冲填充”的拥塞控制机制来说，和同类的机制以及CBR流竞争带宽时属公平竞争，但延迟都比较高。

  结合上述发现，该文得到了一个关键发现也就是它的研究目标：当发送方拥塞控制机制认为交叉流量是非弹性时，发送方可以使用“延迟控制”协议来减少发送方和交叉流量的延迟，而不用担心降低吞吐量。反之，如果是弹性的，它可以切换到TCP竞争的“缓冲填充”拥塞控制机制。这样能够更好地利用“延迟控制”机制，在具有带宽竞争力的同时，“安全”地降低延迟。

关键技术

  为了实现研究目标，该文首先总结并抽象了不同交叉流量进行带宽竞争时的一种属性：弹性。弹性表征了交叉流量在和其他流量竞争时，能够受其他流量带来的瓶颈可用带宽的影响，改变发送速率。比如一些应用限制的流量或者可用带宽超过比特率的视频流是不会对可用带宽变化而作出反应，因此为非弹性流。

  接下来，按照目标需要让发送方知道交叉流量的弹性属性，也就是需要进行弹性检测。这里提出的弹性检测是主动的，是鲁棒的。第一步，他们建立了如下图的交叉流量测速的模型，通过非空非满的瓶颈中，进出流量中发送方和交叉流所占比例守恒这一结论，能够在发送方进入瓶颈的速率S、接收速率R、以及瓶颈估计速率μ已知的情况下，得到交叉流量的速率Z。

  接着，他们并没有直接通过交叉流量速率来衡量弹性，而是通过主动增加发送方速率脉冲，然后根据交叉流会以相同频率响应脉冲的原理，在频域上分析交叉流的FFT，如果FFT在发送脉冲相应频率上具有更高的幅值，就证明更具有弹性。 最后，在发送方根据弹性阈值来切换NimbusCC的模式和应用机制，当交叉流是非弹性时，则应用“延迟控制”机制进行延迟控制模式，以此减少延迟并不损失吞吐量；而当交叉流是弹性时，切换TCP竞争模式，应用类似Cubic之类的机制公平竞争带宽，不考虑延迟问题。总结NimbusCC的整个流程如下图。 【模式切换】

实验验证

  该文做了十分充分的实验验证，包括模拟和真实网络情况下，对于理想情况下的基于弹性检测和模式切换的拥塞控制的性能评估，也有一些不满足假设的情况下性能问题的评估等等。而下图就是对比不同的机制，评估NimbusCC在弹性/非弹性交叉流的背景下的吞吐量和延迟，发现NimbusCC在灰色区域的，竞争模式下比单纯的“延迟控制”机制更具有公平竞争带宽的能力；而在后60s，判断交叉流量是弹性的，切换为延迟控制模式，能够有效减少延迟，并且吞吐量和非弹交叉流公平竞争瓶颈带宽。

个人观点

  作为计算机网络领域顶级会议的文章，我认为它同时具备了发现问题的重要性，解决思路的创新性，以及实现技术的实用性。在拥塞控制研究这么多年的背景下，它发现了“延迟控制”这类机制在应用时的问题和现象。而解决问题的思路又不同于大部分能做到的方法创新，而首先基于“概念”创新，能够抽象并提出新的概念，并且具有一定的数理分析。最后，实际的实现技术时利用现有的一些拥塞控制的实现机制进行切换，简单而实用。所以，希望我们都能够从方法论创新走向思想创新，做更有用的研究吧！