DCTCP协议

摘要：云数据中心托管不同的应用程序，将需要小的可预测延迟的工作负载与需要大的持续吞吐量的工作负载混合在一起。在这种环境下，当今最先进的TCP协议达不到要求。

一、背景

为了给用户提供高质量的云服务，许多大型互联网企业,如微软、谷歌、亚马逊和阿里巴巴等，在全球修建了许多数据中心。在数据中心内部，数以万计的服务器通过高带宽(10-100Gbps)低时延(0-100us)的数据中心网络(DataCenterNetwork，DCN)相连。数据中心内运行着很多对延迟敏感的实时应用，比如电商零售、搜索、社交网络等。这些实时应用的用户请求需要尽快得到响应，而较高的响应延迟将严重影响用户体验，降低公司的运营收入。

数据中心网络流量以其突发性著称，当流量瞬间爆发时，极易在流量接收端产生拥塞(端点拥塞)。不恰当的路由也会导致网络内部流量不均衡，从而产生内部拥塞(链路拥塞)。网络拥塞般可以通过负载均衡机制来解决。一旦发生拥塞，流量的网络延迟和吞吐量都会受到影响，从而造成较长的应用响应时延和更差的用户体验。传统数据中心的内部网络是有损网络(lossynetwork)，网络发生严重拥塞时交换机可以直接丢弃数据包。由于数据中心交换机的缓冲区较小，加之数据中心流量的突发性特点，拥塞丢包在数据中心十分常见。丢包的后果会造成较高的重传时延，从而影响实时应用的性能。学术界与工业界都十分关注传统有损数据中心网络的拥塞问题，采取了一系列拥塞控制机制，以降低网络中的排队和拥塞丢包问题。即便如此,这些机制也很难完全避免拥塞丢包。著名的DCTCP协议在网络拥塞并不严重时可以有效控制交换机队列长度，但是当出现大量并发连接时，DCTCP仍难以避免交换机缓冲区的溢出。

数据中心设计的一贯主题是使用低成本的商用组件构建高可用性、高性能的计算和存储基础架构。数据中心网络也出现了相应的趋势。特别是，低成本交换机常见于机架顶部，以1Gbps的速度提供多达48个端口，价格低于2000美元，大致相当于一台数据中心服务器的价格。最近的一些研究建议设想使用构建在这些商用交换机上的新型架构来创建经济、易于管理的数据中心。

软实时应用程序，支持推动了大量数据中心建设的网络搜索、零售、广告和推荐系统。这些应用程序产生长短流的不同组合，并要求数据中心网络具备三个条件:
短流的低延迟、
高突发容忍度、
长流的高利用率。

DCTCP的作者们在一个6000台服务器规模的DC中调查了一个月，采样了超过150TB的压缩数据，总结流量模式如下：

1. 99.91%的流量是TCP协议贡献的。
2. DC中long-lived flow(large traffic)与short-lived flow (small traffic) 并存：从flow数量上看， small flow占绝大多数比例，但从流量的字节数上看，绝大多数又由large flow贡献。
3. Flow的并发程度越高，flow的尺寸越小。例如，在考虑所有flow的情况下，并发flow的中数为36；但如果只考虑大于1MB的flow，中数只有1，而且75%的情况下为2。

我们对一个6000台服务器的生产集群进行了测量，并揭示了导致应用程序高延迟的缺陷，其根源在于TCP对数据中心交换机中可用的有限缓冲空间的需求。

二、要解决的问题

影响性能的现象有哪些，大约总结为以下三类：

1. Incast。指的是这样一种现象：1个client向N个server同时发送请求，client必须等待N个server的应答全部到达时才能进行下一步动作。N个服务器中的多个同时向client发送应答，多个同时到达的”应答”导致交换机缓存溢出，从而丢包。这样只有等server发生TCP重传超时才能让client继续。这个现象同时损害高吞吐量和低延迟。目前对于Incast的已有研究表明，降低TCP RTO的粒度是比较有效的方案，但这并没有解决所有问题。

2. Queue buildup。由于TCP发送流量的“贪婪性”，可以导致网络流量的大幅振荡，因而表现在交换机队列长度的大幅振荡。在队列长度增高时，会有导致两个副作用：small flow丢包产生incast、small flow在队列中延迟较长时间（在1Gb网络中是1ms vs 12ms的区别）。

3. Buffer pressure。因为许多交换机上的缓存是在端口间共享的。因此，某端口上short flow很容易因为缺少缓存受到其他端口上的large flow的影响。

三、DCTCP工作原理

DCTCP的一个设计约束就是必须充分现有的硬件资源，这意味着不能定制硬件，只修改软件，它的工作原理是这样的：

1. 交换机。在交换机发现队列长度超过某个阀值时，使用ECN中的CE标记通过的TCP segment。但与标准的ECN（RFC3168）的不同，这里交换机的判断依据不是平均队列长度，而是当前队列长度（instantaneous queue size）。这个设计的动机在于快速响应交换机的队列长度变化，因为现代交换机许多都是shallow buffer的，如果不及时动作，可能在发送方进行有效拥塞控制之前交换机就已经发生缓冲溢出了。

2. 接收方。接收到CE标记后的行为，也与RFC3168中所要求的有所不同：RFC要求接收者在接收到CWR之前都在回复的报文中设置ECE标志。但DCTCP只在对有CE标志的报文的ACK中设置ECE。如原作者们所说，一个最简单的实现方案是立刻确认每个收到的报文。但这样就与延迟确认的基本机制冲突，会带来一些副作用，为此，DCTCP作者引入了一个简单的状态机解决这个问题：延迟确认仍然保留，但在出现CE标志，或者CE标志消失时立即发送确认，这两种情况下不再延迟。这么做的动机在于可以确切告知发送方有多少TCP流量（一个序号范围）几乎触发了“拥塞”，这个序号范围的大小标志了拥塞的程度。

3. 发送方。接收到的ECE的发送方，当然也与RFC3168做的不同。RFC要求：TCP减半拥塞窗口，但DCTCP则是按照“拥塞程度”缩小拥塞窗口。这么做的原因在于，我们在上面的分析已经看到，大多数流量由少数的large flow构成，并且它们的并发度很小。如果过度减小拥塞窗口，就意味着交换机的buffer可能很快就进入了下溢的状态。
   

DCTCP算法有三个主要组件:

交换机处的简单标记：DCTCP采用了一种非常简单的主动队列管理方案。只有一个参数，即标记阈值K。如果到达的数据包到达时队列占用率大于K，则使用CE码点标记该数据包。否则不作标记。该方案确保了队列超调可以快速通知源。大多数现代交换机采用的红色标记方案可用于DCTCP。我们只需将低阈值和高阈值都设置为K，并根据瞬时值而不是平均队列长度进行标记。

接收器的回复：DCTCP接收器和TCP接收器之间的唯一区别是CE码点中的信息被传回发送方的方式。rfc3168声明接收机在一系列ACK分组中设置ECN Echo标志，直到它从发送方（通过CWR标志）接收到拥塞通知已被接收的确认为止。然而，DCTCP接收器试图准确地将标记包的确切序列传回发送者。最简单的方法是确认每个包，当且仅当包具有标记的CE码点时设置ECN Echo标志。
但是，由于各种原因，使用延迟ack非常重要，包括减少数据发送方的负载。为了使用延迟ACK（每m个连续接收的包有一个累积ACK），DCTCP接收器使用图10所示的普通两状态机来确定是否设置ECNEcho位。这些状态对应于最后接收的分组是否用CE码点标记。由于发送方知道每个ACK覆盖多少个包，因此它可以准确地重建接收方看到的标记运行。

发送方的控制器：发送方保持对标记的分组部分的估计，称为α，其对于每个数据窗口(大约一个RTT)更新一次，如下所示:

α ← (1 − g) × α + g × F

其中F是在上一个数据窗口中标记的数据包的比例，0<g<1是在α的估计中给予新样本相对于过去的权重。假设发送方在队列长度大于K时接收每个包的标记，而在队列长度小于K时不接收任何标记，上等式表示α估计队列大小大于K的概率。本质上，α接近0表示低拥塞水平，α接近1表示高拥塞水平。

DCTCP发送器和TCP发送器之间的唯一区别在于，它们在接收设置了ECN Echo标志的ACK时如何作出反应。TCP的其他特性，如慢启动、拥塞避免的附加增加或从数据包丢失中恢复，都保持不变。虽然TCP总是根据标记的ACK将其窗口大小缩减2倍，但DCTCP使用α：

cwnd ← cwnd × (1 − α/2)

因此，当α接近0(低拥塞)时，窗口仅略微减小。换句话说，一旦队列超过K，DCTCP发送方就开始逐渐减少他们的窗口。这就是DCTCP如何保持低队列长度，同时仍然确保高吞吐量。当拥塞较高(α = 1)时，DCTCP将窗口减半，就像TCP一样。

这样，整个DCTCP有两个参数需要调整：

1. g，用于评估拥塞概率，它的上限是1.386 / (2(C*RTT+K))^0.5

2. K，交换机判断是否处于拥塞状态的阀值，它的下限是 (C x RTT)/7

注意：
1.DCTCP不适用于WAN环境的拥塞控制方案。
2.DCTCP没有考虑RCP的解决方案。