TIMELY

Author: Radhika Mittal (UC Berkeley)
datacenter transport,delay-based congestion control; os-bypass; RDMA

摘要：

数据中心协议要求降低网络延迟，提升带宽。在本文中，作者选择了最简单的测量方式——RTT作为拥塞控制的指标。首先，作者表明新一代NIC，可以做到微妙精度的RTT测量，并且，作者证明了RTT信号与网络队列的强相关性。然后作者提出了TIMELY(Transport Informed by MEasurement of LatencY)，描述了如何通过RTT梯度来控制数据包传输速率，确保在提供高带宽的同时保证较低的延迟。作者在具有OS-bypass功能的NIC上运行的主机端软件中实现这一设计。也在Clos网络拓扑上，使用数百台计算机做实验，证明了其出色性能。TIMELY是第一个用于数据中心的基于延迟的拥塞控制协议，相比早起基于延迟的方案Vegas，TIMELY的RTT信号少一个级别，但是它能达到更好的效果。

关键词：数据中心传输协议，基于延迟的拥塞控制，OS-bypass(操作系统旁路），RDMA

引入：

在数据中心网络中，理想的拥塞信号有以下的属性:

将拥塞程度的信息，迅速通知发件器
具有足够辨识力，在多流的复杂环境中运行
部署起来相对容易

现有的以延迟作为指标的系统有以下问题：

基于延迟的方案，与某些基于丢包的方案竞争带宽时，表现不佳。
由于主机和网络原因，延迟估计可能不准确，难以用微妙精度测量。

作者观察到最新的NIC允许RTT精细度的测量：

最新的NIC可以高精度地标出时间戳
硬件生成ACK支持自动消除主机响应时间
数据中心软件可避免不同传输协议的流竞争

因此，在这样的大环境下，作者提出了基于延迟的拥塞控制TIMELY。TIMELY这一机制在数据中心显示出优异的性能。

数据中心拥塞指标RTT的值：

现有数据中心协议，大多使用交换机上的信息作为拥塞程度的指标，作者认为RTT延迟时间，是一个更优越的拥塞指标，可以不需要交换机信息。

RTT直接反应延迟

作者将RTT与ECN标记做了简单的对比，描述了RTT作为拥塞控制指标的优势：

（一）RTT直接测量了因为队列堆积引起的端到端延迟时间，而ECN无法直接得到这个延迟时间。

（二）ECN标记仅表示包的队列占用超过了一定的阈值。在以下情况下，ECN不能很好的反应拥塞情况——具有不同优先级的多个流共享同一个链路，低优先级流可能经历较大的队列延迟时间，但它的队列占用并不一定很大（不满足ECN标记的条件）

（三）ECN标记描述单一交换机的行为，但拥塞可能发生在多个交换机上，ECN标记并不能很好地分清楚他们。

（四）RTT甚至适用于支持FCoE的无损网络结构。在这种结构下，由于确保零丢包的PFC机制，使得队列占用无法反映拥塞情况。

RTT可以被精确测量

一个最重要的问题是：RTT在数据中心中，是否能够被准确测量？因为数据中心的RTT，相比其他网络延迟，要小1000倍。

新一代NIC从硬件上保证了，可以准确记录包传输和接收时间，且不受软件的影响，这使得精确地追踪端到端网络延迟成为可能。

以下是一组对比实验，证明NIC相比TCP内核能够更精确地测量RTT的值。作者使用10Gbps的链路将两台主机连接到同一网络，并且发送16KB的消息。由于网络中没有拥塞，希望RTT测量值较低且较稳定。

图1比较了使用NIC的时间戳，测量到的RTT的CDF，以及通过OS的TCP协议栈，测量到的RTT的CDF。使用NIC时间戳测得的RTT的CDF（概率累积分布函数）几乎是一条直线，这说明方差很小。而由内核TCP测得的RTT的CDF，方差偏大。

说明NIC上测量的RTT相比自带的TCP测量的要精准许多；

RTT 是一个快速、多位信号：

作者先说明了，网络中的队列延迟的具体计算方式，通过从总的RTT中减掉固定的传播延迟和序列化延迟，可以得到。

【RTT VS ECN】:
ECN作为一个二进制数值（非0即1），因此ECN标记传达的是单个比特的信息，而RTT传达多个比特的信息。（由于每个包都可以携带ECN标记，因此一串ECN标记的序列可以间接表达，多比特的拥塞信息，这是合理的。e.g. DCTCP。）

但ECN这种做法，会破坏标记的独立性，e.g.主机端发生burst时，会使得绝大部分数据包，同时高于或低于标记阈值。

对于RTT而言，测得一个较高的RTT即刻表明网络的拥塞程度。对于网络中burst的情形，测得的延迟是最后那个包的RTT时间，也是整个burst中最大的RTT值。

作者模拟了incast的实验，图2测得的RTT的CDF，以及在交换机上测量的队列占用的CDF，从实验结果看出，这两个概率累积函数非常匹配。

其实，ECN信号与RTT并不强相关。通过类似的实验，作者得到图3所示的散点图和方框图，其显示了ECN标记和RTT之间的弱相关性。

RTT 的限制：

作者发现RTT在有一定的局限性：——RTT测量可以分为两部分，正向路径和反向路径。ACK并不能辨别，其经历的是反向路径拥塞，还是正向路径拥塞。一个简单的解决方法是发送具有更高优先级的ACK，以便ACK不会遭遇排队延迟。该方法适用于在同一个方向上发送数据流。

作者进行了一项实验来验证，给ACK设置优先级的效果：作者启动了两个incast（主要和次要），使得主要的与次要的incast共享相同的拥塞队列，如图4所示。

作者在图5的对比实验中，分析了给ACK设置优先级的情况下延迟的累积分布函数。作者得出的结论是，对ACK划分优先级时，在主要incast下测量的情况，与没有反向拥塞时的情况无法区分。

RTT的另一个缺点是，网络路径改变会造成不同的网络延迟。但这一点在数据中心中并不成问题，因为几乎所有路径的传播延迟都很小。

TIMELY 结构

TIMELY的速率控制框架主要由三部分组成，如图6所示。

1）用于监控网络拥塞的RTT测量引擎
2）将RTT信号转换为目标发送速率的计算引擎
3）在数据段（包）之间插入延迟间隔，从而实现目标速率的控制引擎

RTT的测量

根据图7，作者定义了RTT的测量方式——将多个数据包组成的busrt，作为一个完整的单位，从发送第一个数据包tsend至接收到ACK tcompletion的时间被定义为整个burst的完成时间。

总延迟，通常由以下几部分组成：

1）传输中所有数据包段的序列化延迟，通常高达64 KB。
2）传输数据的RTT时间，以及其ACK在数据中心传播的时间。
3）接收器生成ACK的时间。
4）正反两个方向上的交换机队列延迟时间

这几部分的时间分别可以通过以下方式处理：

第一部分，可以由段的大小和NIC的线速率决定，可以从总时间中减去。
第二部分，传播延迟时间，它又被称作最小RTT，并且对于给定流，数值是固定的，也可以减去。
第三部分，因为采用基于NIC的ACK，所以这个值足够接近零，可以忽略。
第四部分，队列延迟时间，也是导致了RTT变化的原因，这是我们检测拥塞的重点对象。

TIMELY将RTT，如下定义：

此外，还需注意以下指标：
（1）ACK的时间戳，由NIC提供，这一完成时间戳指标 tcompletion。因为由OS提供的时间戳受到诸如调度和中断之类的变化的影响不精确，所以采用了NIC提供的时间戳指标。

（2）tsend是在将一段数据传输到NIC之前，由读取产生的时间。

（3）ACK的生成 采用基于NIC生成ACK，以便我们可以忽略接收器的周转时间。

速率计算引擎

该组件实现了基于RTT的拥塞控制算法，详见§4。速率计算引擎的接口很简单。RTT测量引擎以微秒为单位向速率计算引擎提供RTT，这是仅有的输入，附加的一些时间信息也可能有一定用处。

速率控制引擎

速率控制引擎将消息分成若干段后进行传输，并依次将每个段发送到调度程序。调度程序通过段大小，流速（由速率计算引擎提供）和最后一个包的传输时间，来计算当前段的发送时间，并将该段放入调度程序中的优先级队列中。调度程序会计算在两个这样的段之间，插入多少调步延迟（pacing delay）。

段落总结：TIMELY是基于速率而不是基于窗口的，它可以更好地控制burst的情形。因为，在数据中心，少量包裹burst的情况下，调整发送窗口不能够提供对数据包传输的细粒度控制。但通过指定目标速率，可以很容易控制burst的时间间隔。

TIMELY 拥塞控制:

拥塞控制算法主要在速率计算引擎中实现。本节中，作者描述实验环境和关键性能指标，以及基于梯度的拥塞控制算法.

度量和设置

数据中心网络环境带宽充足，基于经常出现的burst情形，流的完成时间是最重要的考虑因素，以远程过程调用(Remote Procedure Call)为例。

对于较短的RPC，最小完成时间由传播延迟和序列化延迟共同决定。因此，我们尝试最小化队列延迟，来保证较低的RTT。（尾端延迟这一个指标，尤其重要，因为即使一小部分数据包迟到，应用程序的性能也会下降。）这意味，需要满足，低队列延迟和接近零丢包，这两个需求。
对于较长的RPC,由于传输更多数据所需时间更长，所以较长的RPC将具有更长的完成时间，必须保持较高的总吞吐量，以使所有流受益，并保证流之间的公平性。

我们评估的主要指标是尾端(第99百分位处)RTT和聚合吞吐量，因为它们共同决定了完成短期和长期RPC的速度快慢。当吞吐量和数据包RTT之间存在冲突时，我们倾向于以牺牲少量带宽来保持较低的RTT。这是因为带宽充足，RTT的增加将直接影响，短RPC的完成时间。次要指标是公平和损失。最后，为了实现可预测的性能，更倾向于稳定的设计，所以更关注于震荡速率，而不是高平均值。

基于延迟梯度的策略

受到基于延迟的拥塞控制算法，如FAST TCP和Compound和TCP Vegas等开创性工作的启发。
TIMELY使用延迟的梯度作为指标，实现拥塞控制。正延迟梯度表示RTT增加，队列堆积；而负梯度表示队列在减少。

作者假设了以下的情形，N台主机同时以y(t)速率给同一条瓶颈链路发送数据，瓶颈链路的处理速率是C，如果主机的发出速率y(t)≤C，作者假定瓶颈链路处的队列延迟是q(t)。如果y(t)>C，那么队列堆积的速度就是(y(t)-C)。那么队列延迟的梯度就是：

梯度没有量纲。因此，通过RTT信号测量的延迟梯度可以作为瓶颈链路处的速率不匹配的指标。当队列的大小没有变化时，梯度也为零。TIMELY做的就是希望将流入速率y(t)和处理速率C匹配起来。

核心算法

下图显示了拥塞控制算法的核心伪代码。TIMELY对于每个链接，维持了一个单独的速率R(t)，并且使用RTT样本，在每次任务完成后，进行一次更新。它采用梯度追踪，使用平滑的延迟梯度作为误差信号调整速率，以使吞吐量接近可用带宽。此外，使用了阈值，对带宽利用率低或数据包延迟过高，等特殊的情况作出响应。

图8显示了梯度策略以及两个阈值的关系。当RTT处于标准工作范围时，通过梯度跟踪算法来调整发送速率。

计算延迟的梯度

依赖于NIC上的时间戳来计算RTT，并且根据两个连续的RTT样本的差值，来计算延迟梯度。用最小的RTT来做标准化。在实际操作中，最小RTT的值是否精确并不影响最后效果。因此，采用固定值来表示数据中心的传播延迟。最终，把结果输入EWMA过滤器。这个过滤器的作用是可以观察到队列的上升或者下降趋势，同时忽略一些与拥塞无关的队列长度波动。

计算发送速率

然后，TIMELY使用标准化后的梯度来计算连接目标速率R(t)。如果梯度是负值，这说明网络可以应付总的传入速率，速率有提升的空间。TIMELY在这种情况下，对链接速率做出如下改变R=R+△，其中△是带宽的additive增量常数。如果梯度是正值，这表明发送速率过大，因此TIMELY会采用multiplicative乘法递减，并且用梯度来调整目标速率如下：

众所周知的AIMD性质保证了算法能获得各链接之间的公平性。

RTT低阈值-Tlow-

在实际操作中，TIMELY的速率控制策略在<=64KB的段上执行，较大的段会导致burst，产生短暂的队列堆积，并导致RTT突然增加到峰值，核心算法检测到后，较大的正延迟梯度会指示拥塞，极大得减少发送速率。而这种行为没有必要。因此，可通过设置一个Tlow，RTT低阈值，来过滤RTT的突增情况。对于大于这个阈值的RTT样本，才开始使用延迟梯度调整速率的策略。

RTT高阈值-Thigh-

梯度算法的预期是能够在，保持接近瓶颈链路吞吐量的情况下，构建很低的队列。然而理论上存在一种情况，队列占用很大，但是维持不变，在这种情况下，梯度也保持为零。为了避免这种情况，Thigh作为一个端到端网络队列延迟的可容忍的上限，它通过一种与梯度无关的方式来降低速率，这是一种保护操作。如果测出的RTT高于Thigh，则按照如下公式降低速率：

注意到，公式中使用的是瞬时而不是平滑的RTT。这么做，可以减缓对单个过大的RTT的响应速度，因为它优先是要保证低延迟和避免包丢失。

激进增加HAI(Hyperactive increase)为了更快的收敛

因为受到TCP BIC，CUBIC以及QCN启发，作者在TIMELY中，实现了HAI选项，为了更快的收敛。它的功能如下：如果TIMELY计算得梯度在几个连续完成时间内均为负值，则HAI启动，速率可以更快的增加，其中rate增加N△而不是△.

梯度 VS 队列大小

实验具体分析了，基于梯度的策略和基于队列大小的策略不同。如果将Tlow和Thigh的值大小设置为相同的，那么TIMELY的拥塞控制将退化为基于队列大小的策略，类似TCP FAST 算法。Ttarget是唯一的RTT阈值，这一数值加性增加，乘性递减。（additively increased, multiplicately decreased）

图9中比较了基于梯度和基于队列大小，这两种不通过策略下，处理incast流时的带宽和延迟的性能好坏。可以看到，基于队列大小的方法可以维持低延迟，或者高带宽，但很难同时满足两者。（建立一个RTT阈值较高的standing queue，带宽可以达到最大化，然而延迟就会受损；相反的，建立一个RTT阈值较低的standing queue，延迟可以最优，但带宽就不能得到保证，因为队列经常是空的）；而基于延迟梯度的算法可以侦测到队列的变化，从而提前预测了拥塞的情况，因此使得这种策略可以在保持网络高带宽利用率的同时，达到较低的尾端延迟水平。

更进一步来说，如图10中所示，在基于队列大小的策略中，速率的抖动较为严重，因为这种算法要求，根据队列大小，来微调RTT的升降。而基于梯度的算法，在公平保持公平分享带宽的同时，维持了一个较为稳定的速率。

实际应用

实际操作中，作者使用10Gbps的支持OS-bypass功能的NIC。该NIC支持多包分段，反馈基于硬件的ACKs以及时间戳，作者运用TIMELY来支持RDMA。下面作者简要描述了，操作中一些值得注意的细节。

传输界面

TIMELY只关心传输协议的拥塞控制部分，而不关心应用程序更高级别的接口，这允许协议接口端的设计十分简单：只需要提供消息发送和接收。

使用NIC完成进行RTT的测量

使用NIC时间戳是十分具有挑战性的事情。NIC只记录绝对时间戳，换句话说，它只记录传输操作的完成时间，需要用户自己记录操作发送到NIC上的时间点。这需要一个机制把主机端的时钟映射到NIC上的时钟，并实现校准。图11对比根据NIC时间戳以及校准机制共同获得的RTTs，以及单纯应用时间戳算出的RTTs的效果。

从图11中看出，使用NIC端的时间戳以及校准机制，测得的结果十分精确。而使用应用端算出的RTTs具有较大的方差，并且较为复杂。

RDMA速率控制

RDMA的速率控制略有变化。对于RDMA写的操作，发送端的TIMELY直接控制发送间隔。对于RDMA读的操作，接收器处理读的请求，并且对远端主机执行一个数据段的操作。在这种情况下，TIMELY不需要直接控制数据的发送间隔，而是控制Read操作的间隔。

应用限制行为

考虑如下情况，应用没有足够的数据来使得当前流的传输达到目标速率。这种情况发生时，因为网络没有拥塞，不希望速率控制器，不受限制地增加目标速率。为了防止这种情况，规定，只有应用发送速率达到超过80%的情况下，才增加目标速率，还将最高目标速率限制在10 Gbps。

速率更新频率

TIMELY的发送速率，确保了在每个RTT间隔中，最多只有一个完成的事件。然而，对于较小的数据段，在一个RTT的时间间隔内，可能会有很多完成的事件。这种情况下，希望根据最新的信息来更新速率。因此，这时采取的是，对每个完成的事件，更新一次速率。

额外的调度机会

作者尝试用NIC速率限制器，以低于链路速度来传输这一组数据包。基本原理是使用硬件速率限制器，将部分pacing的负荷转移到NIC上。但是因为硬件限制，每间隔几个RTT时间，重新配置发送速率基本不可行。因此作者采用一种混合方法——软件端处理大型的段数据pacing以及硬件端以固定速率(小于链路速率）处理pacing。 NIC做pacing的目的是在两段burst之间插入一些间隙，以此解决多重burst在交换机处重合，导致的延迟突增的问题。

评估

作者在两种不同规模下，评估了TIMELY的效果：

在incast设置下，使用小型测试平台，评估了诸多网络基础特性：带宽，公平性，数据包延迟，以及时间的准确性等microbenchmarks.
在Clos网络拓扑的大规模测试平台中部署TIMELY，所有链路均为10 Gbps。所有实验中的操作系统都是Linux。

作者比较了TIMELY与以下两种不同情况作对比：

第一种，测试了在具有优先流控制（PFC）的结构上，并且使用OS-bypass消息传递。（这经常被用于FCoE中的低损耗和延迟，例如DCB）RDMA的传输通过NIC，并且对丢包比较敏感。PFC确保了无丢包，因此对RDMA尤其重要。将TIMELY添加到RDMA的设置中，来观察它的好处；检查PFC暂停消息计数是否很低，来确保有足够的交换机缓存来使TIMELY工作。
第二种，使用优化的内核堆栈，在不使用PFC的情况下，运行DCTCP。选择DCTCP，是因为它是一个众所周知的现代数据中心的传输协议。

因此，主要做了以下四类的对比实验：

使用DCTCP，没有PFC的结构上的内核DCTCP
使用PFC，进行OS-bypass消息传递
使用类似TCP FAST的拥塞控制算法，进行OS-bypass消息传递
使用TIMELY，进行OS-bypass消息传递

小规模实验

小规模实验中，采用incast的模式，这是数据中心最重要的网络拥塞情况。为了创造这样的incast情形，采用10台机器在单一的机架上，同时给一台服务器发送数据。每个client运行4个链接，一共40个链接。这是测试拥塞控制的理想典型网络环境——虽然数据中心存在数以万计的链接，但因为网络被限制的连接数通常很少。

测量的RTT必须精准：

为了证明RTT样本准确的重要性，作者在测量RTT中添加噪声，并观察其对吞吐量的影响。将均匀分布的随机噪声添加到每个RTT样本中。图12显示了在不同噪声水平下，总吞吐量的变化。发现噪声越高，性能损失就越严重。因此，NIC支持的准确RTT测量是TIMELY的基石。

与PFC做比较：

表1比较了使用OS-bypass的TIMELY，和PFC部署的RDMA，图13显示了对四个单独链接，使用TIMELY后，RTT和吞吐量随时间变化的轴线。观察到4个流公平共享带宽，并且RTT维持在较低的水平。为了量化测试带宽分配的公平程度，计算了Jain fairness指数，TIMELY的指标达到0.953，而PFC的指标达到0.909。TIMELY的设计可以做到更公平共享带宽。

和DCTCP的对比

将DCTCP和TIMELY做对比。注意到，必须比较两个不同的主机软件堆栈，因为DCTCP在没有PFC支持的优化内核中运行，而TIMELY用于OS-bypass消息传递。RTT分布如图14所示。TIMELY的平均端到端延迟比DCTCP低10倍（60μs对600μs）。更重要的是，尾部延迟下降了近13倍（116μs对1490μs）

和TCP FAST-like算法做对比

作者将TIMELY和TCP-FAST拥塞控制算法作比较。此方法使用TCP-FAST方程来调整pacing速率，而不是周期性地更新拥塞窗口。TCP-FAST可通过协议参数a进行调整，该参数控制带宽的公平性以及网络中的缓冲总量。
表1显示三个不同a值下的结果。对于较小的a=10 Mbps，FAST可以实现较低的尾端延迟 49us，尽管吞吐量显着下降。对于较大的a=50 Mbps，TIMELY仍然可以实现较好的的吞吐量和延迟权衡。

变化的Tlow

TIMELY的性能，也受算法参数的影响，如RTT低阈值Tlow。RTT的变化与最大分段大小相关，随着分段变大，incast时的RTT会增加。图15显示了对于大小为16 KB，32 KB和64 KB的段，瓶颈吞吐量和RTT时间如何随着Tlow的变化而变化。

从图中观察到，降低Tlow会降低网络延迟，这是因为较低的阈值，允许更频繁地使用RTT梯度来调整响应队列变化的速率。但是较低的阈值最终会对吞吐量产生负面影响。

使用细粒度的pacer调整使Burst更平滑

速率控制引擎为段与段之间添加pacing延迟，为了更好适应burst的情况，作者选择采用细粒度pacing。除了主机软件pacing之外，NIC硬件也使用pacing来发送数据包（例如HULL），该规则在Linux内核中已有实现。图16显示了不同NIC pacing速率的结果。

注意到，在TIMELY设计中，NIC硬件pacing不是绝对的要求;但更确切地说，可以实现在较低的网络尾端延迟和由于软件pacing引起的较高的CPU开销之间权衡。

变化的Thigh

TIMELY使用一个高阈值，来对更大的RTT来做出更快的反应。这一阈值没有低阈值重要，因为仅对于超大的RTTs起作用。但随着连接变得复杂，RTT突增的可能性变大，这一阈值变得愈发有用。

图17显示了不同数量的链路竞争下，这一阈值对吞吐量的影响。在一对四的结构中，99百分位RTT稳定接近200μs。那么，若将Thigh到100us或者更低，RTT会有下降，且吞吐量也非常优异。

激进增量（HAI）

HAI有助于更快地获取可用带宽。通过多次不同load的incast实验，来证明这一点。incast从10个客户端和每个客户端10个连接开始。在收敛的初始阶段之后，每个客户端同时关闭其10个连接中的9个，从而将剩余连接的公平分享率提高10倍。图18显示了HAI如何在50ms内，将连接吞吐量从初始公平速率200Mbps提升到1.5Gbps，并在100ms内达到2 Gbps的新公平份额。相反，使用固定的加法增量，在140 ms后吞吐量仅仅到1.5 Gbps。发现选择五个连续RTT攻击作为使用HAI的阈值，这一决定，在模型收敛性和稳定性之间取得了良好的平衡。

大规模实验

通过经典Clos拓扑中的几百台机器上的实验，来研究TIMELY大规模试验。来证明TIMELY能在大型的拥塞网络场景中保持可预测和低延迟。

最长路径均匀随机

在此流模式中，客户端从具有网络最长路径的一组服务器中选择服务器。客户端发出64 KB请求。服务器回复相应大小的有效负载。客户端计算了RPC延迟（记录了请求发送到服务器到收到服务器响应的时间）。

图19显示了应用程序在负载增加的情况下，观察到的标准化吞吐量。网络的饱和点（接受负载小于提供的负载的点）对于TIMELY来说更高，因为它能够通过最小化队列，从而也可以每秒暂停帧，来发送更多流量。

【
图20显示了RTT与负载的关系。与PFC相比，TIMELY将RTT的中位数和99百分位数，分别降低了2倍和5倍。这导致RPC中值相应减少约2倍（如图21所示）。如果没有TIMELY，网络队列会增加，以尝试达到提供的负载。有TIMELY，通过将队列从共享网络移到终端主机，来维持低网络队列。因此，随着提供的负载增加超过饱和点，99％的RPC延迟降低效果会减弱。
？？？】

网络不平衡(incast)

为了强调TIMELY缓解拥塞的能力，设计了一个实验，背景负载是最长路径均匀随机流量，使用三个级别的后台负载：低（0.167），中（0.3）和高（0.5）。图22显示了该实验的正常吞吐量和99百分位的RTT。从图19中可知，在网络达到饱和之前，TIMELY和PFC吞吐量对于均匀随机流量是相同的。当添加一个incast，没有TIMELY，吞吐量下降13％至54％，主要原因是由于PFC产生的线路阻塞。用图22中的RTT测量结果也证实了这一观察结果，TIMELY能够保持队列相对较短，并且防止拥塞扩散，且整体吞吐量保持不变。

应用级别的标准

图23显示了数据中心存储的基准测试，RPC延迟（y轴是对数刻度）。有TIMELY的话，该应用程序能够以更高的利用率行动，应用程序数据延迟的下降，这实际上反映了应用程序在查询执行期间能够维持吞吐量的增加。

总结

传统观点认为延迟是数据中心不可靠的拥塞信号。作者设计了TIMELY，发现结果恰恰相反 - 当适当调整延迟后，RTT与网络中的队列建立密切相关。TIMELYd利用现代NIC支持的时间戳和ACK来执行基于精确RTT测量的拥塞控制。TIMELY可以检测并响应数十微秒的队列，以提供低延迟和高吞吐量，即使存在不频繁的RTT信号和NIC offload也是如此。随着数据中心速度向上扩展一个数量级，未来的工作应该集中在RTT如何继续用于拥塞控制，同时重新考虑基于延迟的算法本质。

摘要：

引入：