Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2180138
  • 博文数量: 230
  • 博客积分: 9346
  • 博客等级: 中将
  • 技术积分: 3418
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-26 01:58
文章分类

全部博文(230)

文章存档

2015年(30)

2014年(7)

2013年(12)

2012年(2)

2011年(3)

2010年(42)

2009年(9)

2008年(15)

2007年(74)

2006年(36)

分类: 云计算

2015-04-09 12:18:38

原文地址:Data Center TCP(DCTCP) 作者:raise_sail

这几天研究了一下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标志。

阅读(12471) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

rainjn2017-07-23 21:05:36

总结的很好,但是引用呢? 想找到原文深入阅读以下