SIGCOMM2022 Starvation in End-to-End Congestion Control

传统基于丢包的拥塞控制算法，例如TCP里的Reno、Cubic算法。他们都是基于丢包的，但此类拥塞控制算法对丢包过于敏感，且对于延时不可控，无法实现低延时的传输。为了克服这些弱点，出现了许多其它类型的拥塞控制算法，利于基于延时的拥塞控制算法，例如BBR、PCC、Copa等。基于延时的拥塞控制算法主要为了在不使延时增大的情况下，实现高利用率，例如BBR、PCC、Copa等。在一个有固定瓶颈速率的路径上运行时，这些拥塞控制算法在平衡的状态下收敛到一个较小延时的情况下，及既保证路径利用率高，也保证延时较小。

饥饿现象

尽管被设计为实现合理的公平性，但目前去掉延迟约束的拥塞控制算法不是总能避免饥饿，这是一种极端形式的不公平。当这种拥塞控制算法在路径上运行时，由于现实世界的因素（如ACK聚合和终端主机调度）导致的非拥挤性网络延迟变化超过了拥塞控制算法在平衡状态下收敛的延迟范围的两倍，就可能发生饥饿。

主要原因

许多拥塞控制算法共享一个共同的属性。在具有恒定瓶颈率和传播延迟的理想网络路径上，它们会收敛到一个小的延迟范围并在该范围内振荡。平衡时经历的平均排队延迟范围要么是恒定的（无论瓶颈率是多少），要么是瓶颈率的递减函数（例如，拥塞控制算法保持一定数量的排队数据包）。

但是这种收敛特性会导致一种结果。因为大多数拥塞控制算法试图在许多数量级的速率中工作，它们必须将大的速率范围映射到小的延迟范围中。因此，即使估计排队延迟的微小变化也会引起巨大的变化。

这表明，除非延迟完全可测量，否则带宽可能无法公平共享。

RTT的分类

1.拥塞延迟，这是等待在瓶颈链接上发送的数据包产生的排队延迟的总和，以及瓶颈链接上的传输时间。

2.最小数据包传播RTT（或延迟），表示，定义为单个数据包穿越路径的非瓶颈部分和发送方收到ACK所需的时间（这包括路径的光速延迟和每个非瓶颈链路的数据包传输延迟）。

3.非拥堵性延迟，我们将其定义为由于网络元素（也许也在瓶颈处）引起的抖动，这些网络元素可能会暂时保留数据包或ACK，但本身并不是持久的速率瓶颈。

非拥塞延迟的来源包括 ACK 聚合、延迟的 ACK、终端主机或网络内调度开销、令牌桶过滤器、硬件卸载时序变化以及 MAC 和物理层的延迟。在实践中，非拥塞延迟的范围可以从操作系统线程调度 引起的几毫秒到链路层（例如 Wi-Fi）ACK 聚合引起的几十毫秒。这些因素中的每一个都会以不可预测的方式使 RTT 抖动。

延迟边界的拥塞控制算法试图控制瓶颈链路处的排队延迟。

工作模式

迄今为止开发的大多数（如果不是全部）延迟限制 CCA 具有共同的属性，称之为延迟收敛。这些拥塞控制算法试图收敛到一个固定的发送速率和排队延迟，只在那个点附近产生很小的振荡。这种设计模式有两个好处。首先，稳定的发送速率为应用程序提供了稳定的性能。其次，许多方案，无论是隐式还是显式，都将发送速率映射到相应的排队延迟，这使得对其行为的推理变得更容易。

论文中证明了对于延迟收敛算法，饥饿是不可避免的。

论文中为 CCA 设计提供了三个结论，应该在延迟收敛的 CCA 中明确地建模（或更好地估计）非拥塞延迟。

1.为了有效地利用链路，CCA 必须维护一个大于路径上非拥塞延迟的队列

2.稳定状态下排队延迟的变化也必须大于延迟抖动的二分之一

3.如果对发送速率有一个预先的上限，则可能能够避免饥饿，同时也减少队列延迟变化。