Data Center TCP(DCTCP)

这几天研究了一下DCTCP，写些东西记录吧。主要是DCTCP论文摘要和一点对它的理解。

 一、背景

 数据中心网络的一个发展趋势是使用相对廉价的非定制交换机（$2000，与DC中一台服务器价格相妨），而且据统计，DC中的99.91%的流量均是TCP流量 。在这样的硬件和软件技术背景下，出现了几个需要解决的问题，DCTCP就是众多解决方案之一。

 二、鱼与熊掌

Map/Reduce设计模式是恐怕目前最流行分布式计算模式了（注意不是之一哦）。这种模式对网络性能提出了几点要求：

1.低延迟。
2.对突发（burst）流量的良好容忍性。
3.长时间连接的高吞吐量。

 以搜索业务为例，前两项决定了用户体验；最后一项的需要主要来自于最底层的worker node需要定期更新一些最新时效的数据，所以满足“高吞吐量”的要求也对搜索结果的质量有不可忽略的影响。我们无法确定三个因素孰重孰轻。但有一点严酷的现实是，同时优化延迟和吞吐量谈何容易，退一步讲，借助于“并发”，吞吐量的优化的往往可能到不错的效果，但优化延迟则往往没有直观的解决方案。

 与福尔摩斯破案类似，解决问题的第一个步骤是“现场调查”。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。

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

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可能很快就进入了下溢的状态。

 下面是一些细节了：

 发送方按以下公式调节拥塞窗口（cwnd）：

 cwnd = cwnd * (1 – a/2)

 a可以看作是交换机队列超过最大临界长度K的概率。当它为趋近于1时，行为与RFC3168相同：减半拥塞窗口，但是但概率很小时，拥塞窗口不会受太大影响。它按以下方法计算：

 a = (1 –g) * a + g * F

 其中，g是一个可以调整的参数（0 < g < 1），F是接收到的上一个RTT（上个窗口）中ECE标记的数据比例。

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

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

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

注意以上估算公式在计算除了假定一些理想条件外，还假定了 处于一个很小的水平，据作者观察，这是绝大多数情况下的情况。以上公式中的C是链路的带宽，单位是每秒packets数（PPS），RTT的单位是秒。

在使用DCTCP时，估算交换机中的最长队列长度是K+N，其中N是large flow的并发数量。

考虑到实际环境中的TCP实现中，发送数据包的burst情况（因为Large Segment Offload的缘故，即Linux中的TSO），K往往不能使用下限，在以下试验中，1Gb网络中K=20，在10Gb网络中，K=65。

另外，DCTCP也不是适用于WAN环境的拥塞控制方案。

 四、性能

 作者做了三种测试：第一是针对各种单一性能指标的、第二是一些microbetchmark、最后是一些产品环境中的benchmark。作者使用的TCP变体是NewReno(w/SACK)。交换机使用RED方案（不丢包，而是标记）。在吞吐量/队列长度测试中，DCTCP在不损失吞吐量的前提下，交换机队列长度比传统的TCP小10倍，并且波动较小，这意味着对突发流量的容忍性更好！在收敛时间上，DCTCP是传统TCP的2~3倍。在Incast的实验上，三种情况下，DCTCP均优于传统的TCP。具体的结果数据可以在论文中找到，这里不再重复了。

五、实现。

　在实现上，DCTCP是非常简单的。没有太多可以说的，但有一个地方也违反了RFC3168：重传的报文和纯ACK(Pure ACK)也会打上ECT标志。