啊…其实最近一直都有在看接收端驱动的论文，应该有那么五六篇吧。最近有时间的话我就把我之前看过的文章都记录一下吧。反正也没人看

这是一篇2015年sigcomm的论文，也是第一个在数据中心使用的基于延迟的拥塞控制协议。所以尽管性能上很难媲美近些年发表的拥塞控制，但是其中的思想非常值得一读。

背景与设计动机

两种设计模式

现阶段数据中心传输有两个需求目标：

• 高带宽（Gbps级别）
• 低延迟（毫秒级别）

那么，如何同时满足数据中心的这两个一定程度上甚至是矛盾的的需求呢？一个普遍的想法是基于拥塞信号来进行后续处理。对于此，主要有两种不同的方法：第一是基于ECN对拥塞信号进行诠释，第二是基于延迟对拥塞信号进行诠释。由此，延生出了两种不同风格的拥塞控制协议：

• 基于ECN的拥塞控制
• 基于延时的拥塞控制

前者主要包括了TCP、DCTCP, D2TCP,L2DCT等协议，后者主要包括了TCP Vegas, FAST TCP, TIMELY等协议。

基于ECN的拥塞控制这里不再多做赘述。论文认为，基于ECN的拥塞控制需要退一步，寻找一种更为简单可以立刻部署的设计。而从RTT测量得出的网络排队延迟是一种出色的拥塞信号，无需任何交换机支持。

RTT作为拥塞信号的价值

RTT之所以有价值，是因为它们直接衡量我们关心的数量： 网络排队导致的端到端延迟。
而从队列占用率得出的信号（例如ECN）无法直接告知该指标，数据包上的ECN标记仅表示与数据包相对应的队列度量值超过阈值。具有不同优先级的多个队列共享同一输出链路，但是ECN标记仅提供有关占用率超过阈值的队列的信息。低优先级的流量可能会经历较大的排队延迟，而不必建立大型队列。在这种情况下，排队延迟反映了网络中的拥塞状态，而低优先级流量的队列占用率却没有反映该问题。此外，ECN标记描述了单个开关的行为。在利用率很高的网络中，拥塞发生在多个交换机上，ECN信号在它们之间无法分辨。

模型设计与现实

TIMELY总体框架

TIMELY为速率控制提供了一个框架，下图显示了它的三个组成部分：

• RTT Measurement Engine：测量RTT，监视网络的拥塞情况；
• Rate Computation Engine：将RTT信号转换为目标发送速率的计算引擎；
• Pacing Engine：在各段（64KB each）之间插入延迟以达到目标速率。

接下来我会进行具体分析。

RTT Measurement Engine

该组件实现了对RTT的测量。
我们根据下图定义RTT。下显示了一条消息的时间轴：由多个数据包组成的段作为单个突发发送，然后由接收器作为一个单元进行确认。

延迟主要由四个组件组成：

• 发送时延
• 传播时延
• 处理时延
• 排队时延

论文将RTT定义为传播时延+排队时延。所以RTT有如下等式，RTT等于总延时减去发送延时和处理延时。具体计算公式如下：

$RTT= t_{completion}-t_{send}-\frac{seg.size}{NIC line rate}$RTT=tcompletion​−tsend​−NIClinerateseg.size​

根据定义，这里$t_{process}=\frac{seg.size}{NIC line rate}$tprocess​=NIClinerateseg.size​ 也就段大小/满带宽下的发送速率。

Rate Computation Engine

该组件实现了该组件实现了我们的基于RTT的拥塞控制算法。
对于计算输出速率的引擎，它必须要满足两个需求：即必须提供低延迟(对于短流)和高吞吐量(对于长流)的网络利用率。 TIMELY的拥塞控制器通过对延迟梯度或排队随时间变化的微分做出反应，从而实现了低延迟，而不是试图保持排队。由于RTT增加而导致的正延迟梯度表示队列增加，而负梯度表示队列减少。 通过使用梯度，我们可以对队列增长做出反应，而无需等待队列的形成一种有助于我们实现低延迟的策略。

这里可以看到具体的伪代码。首先对new_rtt做一次判断，如果它小于阈值Tlow或者大于阈值Thigh，那就直接对发送速率进行增减，具体公式在图中，而不去判断延时梯度。

如果new_rtt落在了中间区域，那么首先就要对延时梯度进行计算。延时梯度等于最新的rtt减去上一个rtt再除以20 µs（微秒），它是一个无量纲的数字。如果梯度小于或等于零，网络可以有更高的速率，发送速率增加一个恒定的值来探测更多的带宽。如果梯度为正，则发送速率超过网络容量，并执行乘法速率递减。计算得到这个发送速率之后，在pacing engine中，使用调度器来处理流。它根据当前段的大小、流率和最后一次传输的时间计算当前段的发送时间，然后将该段放入优先队列中。

优点是基于梯度的拥塞控制可以在队列成型之前就对队列增长做出反应，避免了ECN中可能出现的很多问题。

总结

该论文中基于梯度的拥塞控制算法我认为是非常值得学习的。但是依然也存在一些问题：

• 没有对丢失的报文的处理。（需要依靠PFC来避免丢包）
• 参数太多难以设计
• 虽然硬件上已经避免了内核中可能的影响因素，但是一些不可避免的抖动会在反馈信号中引入延迟和噪声，影响拥塞检测的准确性。