一种数据中心网络中对TCP友好且能快速收敛的调窗方法
技术领域
本发明涉及数据中心网络(DCN,Data Center Network)中一种对TCP友好且能快速收敛的调窗方法。
背景技术
过去十年,网络链路的带宽已经从1Gbps逐渐增长到今天的10Gbps、乃至40Gbps。数据流的传输过程变得更快,往往在很短的时间内就完成。在这一大趋势下,如何让数据流在传输过程中尽可能快地到达其正确的速率就变成了传输协议设计领域的一个重要问题。更确切地说,工作在高速网络的拥塞控制算法,其收敛速度即将变成一个衡量协议性能的重要标准。
首先,协议的收敛速度会影响到应用层性能,如数据流完成时间(FlowCompletion Time,FCT)。这是因为在高速链路下,大部分的数据流的传输过程往往只有几个RTT,如果它们需要花很长的时间来收敛,那么其实际的传输时间就要比其真正需要的时间更长,从而产生流的拖尾现象,而且带宽利用率也不理想。其次,数据中心网络内部拥塞瞬态突发的现象非常频繁,在处理这些突发拥塞时,如果拥塞控制算法的收敛速度不够快,数据流就很可能不能及时退避,从而造成拥塞控制失败。
另一方面,数据中心网络是一种大规模的异构网络,反向兼容、增值部署、以及对传统协议公平的问题都是必须要考虑的事情,因为任何新的部署操作都不可能将现有的设施全部推倒重来。多种应用服务会同时存在于数据中心网络中,而且它们中的一些很可能由于自身的设计需要而必须使用传统TCP协议,比如,很多使用文件服务器的应用就无法支持新的传输协议。因此,多种应用服务耦合的需求就使得新设计的传输协议必须与传统TCP协议很好地共存。
当前数据中心网络的传输控制协议主要分为逐渐流行的基于ECN策略的一类,比如DCTCP等,以及最近出现的基于延时测量的一类,比如DX等。前一类协议依靠交换机给数据包打标记来使发送端感知拥塞并进行退避,而后一类协议则是通过测量端到端的延时变化来感知网络拥塞程度的变化。虽然这些协议都针对数据中心的网络特性在一定程度对TCP协议栈进行了优化,并且也展现了它们在提供高带宽、低延迟传输方面的优秀性能,但是,随着数据中心网络带宽的不断提升,以及现阶段传统应用仍需沿用传统TCP的需求,新设计的传输协议就必须满足快速收敛和TCP友好性的双重需求。在这一点上,上述两类协议都会因为自身所存在的一些问题而无法做到两全其美。
具体来说,基于ECN策略的协议使用标记包来作为拥塞反馈信号的做法虽然能够准确地判断网络是否发生拥塞,但是由于其退避操作不够准确和及时,使得协议需要经过很多轮RTT的调整才能收敛。另外,这类协议在与传统TCP协议共存时又由于相对保守的退避操作而表现得过于强势。另一方面,基于延时测量的协议在探测到网络发生拥塞时能够做出及时、精准的退避操作,从而能够快速收敛;然而,由于其对网络是否发生拥塞的判断仅仅依赖于观测充满噪声的端到端延时是否增加,所以其拥塞信号的可信度较低。而且,此类协议多以实现交换机零排队为设计目标,因此在与传统TCP协议共存时就会因为退避过早而表现出竞争力不够的弱点。
综上所述,加快超高带宽数据中心网络传输协议的收敛速度并且让其能够和传统TCP很好地共存是一个亟待解决的问题。
发明内容
本发明所解决的技术问题是,针对现有技术的不足,为了加快超高带宽数据中心网络的传输协议收敛速度以及提高协议的TCP友好性,本发明提供了一种数据中心网络中对TCP友好且能快速收敛的调窗方法。
本发明的技术方案包括以下步骤:
一种数据中心网络中对TCP友好且能快速收敛的调窗方法,包括以下步骤:
步骤一:初始化:设置发送窗口初始大小cwnd0、最小往返延时R、最小标记包往返延时E、累积越界排队延时Q0、平均越界排队延时q0和当前发送窗口标记包个数En0;交换机打开ECN机制;初始化发送轮次i=0;
步骤二:发送端每收到一个确认包,则测量当前的往返延时RTT,并根据当前的往返延时RTT更新最小往返延时R;
步骤三:检查当前确认包是否被打上了ECN标记,如果是,则更新最小标记包往返延时E,并计算累积越界排队延时Qi,当前发送窗口标记包个数Eni自加1,然后转步骤四;否则直接转步骤四;
步骤四:检查当前发送窗口的cwndi个确认包是否全部收到,如果没有全部收到,则直接转步骤二;如果全部收到,则判断已收到的确认包中是否有被打上了ECN标记的确认包,如果有,则执行降窗操作:计算平均越界排队延时qi,并根据qi、最小往返延时R、最小标记包往返延时E计算新一轮发送窗口大小cwndi+1,然后将Qi和Eni清零;否则,新一轮发送窗口大小cwndi+1变为cwndi+1;接着,发送轮次i=i+1,转步骤二。
所述步骤一中:发送窗口初始大小cwnd0按TCP默认方式设置;初始化最小往返延
时R=1000;初始化最小标记包往返延时E=1000;累积越界排队延时Q0=0;平均越
界排队延时q0=0;标记包个数En0=0。
所述步骤二中:发送端更新最小往返延时R的公式为:
R=min(RTT,R)
其中,R表示迄今为止记录的最小往返延时,RTT表示测得的当前的往返延时,min(·)表示取最小值。
所述步骤三中:发送端更新最小标记包往返延时E的公式为:
E=min(RTT,E)
其中,E表示迄今为止记录的最小标记包往返延时,RTT表示测得的当前的往返延时,min(·)表示取最小值。
所述步骤三中:累积越界排队延时Qi的计算公式为:
Qi=Qi+(RTT-E)
其中,E表示迄今为止记录的最小标记包往返延时,RTT表示测得的当前的往返延时,Qi表示当前累积越界排队延时。
所述步骤四中:平均越界排队延时qi的计算公式为:
其中,qi表示平均越界排队延时,Qi表示当前累积越界排队延时,Eni表示当前窗口标记包个数。
所述步骤四的降窗操作中:新一轮发送窗口大小cwndi+1的计算公式为:
其中,cwndi表示当前发送窗口大小,R表示迄今为止记录的最小往返延时,E表示迄今为止记录的最小标记包往返延时,qi表示当前发送窗口的平均越界排队延时。
有益效果:
本发明公开了一种数据中心网络中对TCP友好且能快速收敛的调窗方法,发送端实时测量每个确认包的往返延时,并通过判断是否收到带ECN标记的确认包来决定是否执行降窗操作。在降窗之前,发送端综合考虑当前窗口的往返延时样本以及迄今测得的最小往返延时和标记包最小往返延时来计算降窗量的大小。本发明可以提升数据流获取可用带宽的速度,使数据流更快地传输完成,同时还能很好地与传统TCP共存。
附图说明
图1为本发明的流程图。
图2收敛速度测试结果图,其中本发明命名为FFC;图2(a)为DCTCP收敛速度测试结果图,图2(b)为DX收敛速度测试结果图,图2(c)为FFC收敛速度测试结果图。
图3为TCP友好性测试图,其中本发明命名为FFC;图3(a)为DCTCP与TCP共存;图3(b)为DX与TCP共存;图3(c)为FFC与TCP共存。
图4为流完成时间测试图,其中本发明命名为FFC。
图5为同种方法多流间收敛和公平性测试图,其中本发明命名为FFC;图5(a)为DCTCP的测试结果;图5(b)为DX的测试结果;图5(c)为FFC的测试结果。
图6为与TCP流共存时多流间收敛和公平性测试图,其中本发明命名为FFC;图6(a)为各条流平均吞吐率情况;图6(b)为各方法总吞吐率情况。
具体实施方式
下面结合附图对本发明作进一步的说明。
参见图1,图1为本发明的流程图。过程如下:
发送窗口初始大小按TCP默认方式设置;初始化最小往返延时R=1000;初始化最小标记包往返延时E=1000;累积越界排队延时Q0=0;平均越界排队延时q0=0;标记包个数En0=0;交换机打开ECN机制。
发送端每收到一个确认包,测量当前的往返延时RTT,接着更新最小往返延时R,公式为:
R=min(RTT,R)
其中,R表示迄今为止记录的最小往返延时,RTT表示当前测得的往返延时,min(·)表示取最小值。
接着发送端检查当前确认包是否被打上标记,如否就直接进入下一步;如是就更新最小标记包往返延时E,公式为:
E=min(RTT,E)
其中,E表示迄今为止记录的最小标记包往返延时,RTT表示当前测得的往返延时,min(·)表示取最小值;并且,发送端还计算累积越界排队延时Qi,公式为:
Qi=Qi+(RTT-E)
其中,E表示迄今为止记录的最小标记包往返延时,RTT表示当前测得的往返延时,Qi表示当前累积越界排队延时。同时,发送端将当前窗口标记包个数Eni自加1,然后进入下一步。
发送端接下来检查当前窗口的cwndi个确认包是否全部收到,如果没有全部收到,就重复上述过程。
否则,如果已收到的确认包中有标记确认包,则执行降窗操作,计算平均越界排队延时qi,公式为:
其中,qi表示平均越界排队延时,Qi表示当前累积越界排队延时,Eni表示当前窗口标记包个数。并且,发送端还计算新一轮的发送窗口大小,公式为:
其中,cwndi表示当前窗口大小,R表示迄今为止记录的最小往返延时,E表示迄今为止记录的最小标记包往返延时,qi表示当前发送窗口的平均越界排队延时。然后,发送端将Qi和Eni清零,同时发送轮次i=i+1,重复整个过程。
如果已收到的确认包中没有标记确认包,则新一轮窗口大小变为cwndi+1,发送轮次i=i+1,重复整个过程。
本发明利用NS2.35网络仿真平台来实现,并进行了性能测试。
图2是收敛速度测试结果图,目的是为了验证本发明FFC能够快速收敛。实验环境如下:两台发送端主机经由一台交换机向一台接收端主机发送数据。其中一台先开始一条长流并等待其占满瓶颈链路带宽后,另一台主机再开始发送一条长流。场景中所有链路的带宽均为10Gbps,链路的传播延迟为25μs。我们观察每个方法执行时的两条流的吞吐率变化情况。
从图2(a)中可以看出,使用DCTCP,在第二条流开始发送之前,第一条流已经完全占满了瓶颈链路的全部带宽,因此吞吐率达到了10Gbps。从第二条流开始发送起,第一条流的吞吐率开始缓慢下降,同时第二条流的吞吐率开始逐渐上升,最终两条流的吞吐率都收敛到了公平共享的程度(每条流约占瓶颈链路带宽的一半,5Gbps)。从图中可以看出整个收敛过程所经历的时长约为52ms。
在图2(b)中,使用DX来执行上述发送过程。可以看到,第一条流仍然在第二条流开始之前就完全占用了瓶颈链路的带宽,而当第二条流开始发送之后,第一条流的吞吐率一开始有一个急剧下降的过程,这是由于基于延时测量的方法普遍都对拥塞非常敏感的特性,使得先前占满带宽的流迅速地让出带宽。但即使如此,不久,两条流都向着公平共享的速率快速地收敛,并最终都收敛到了5Gbps且非常稳定。同时,最重要的是,DX的收敛过程耗时仅为22.5ms,比DCTCP收敛过程耗时的一半还要少。显然,DX的收敛速度更快。
接下来执行本发明方法FFC,在图2(c)中,第一条FFC的流在200ms以前已经占满了瓶颈链路的带宽,当第二条流进来的时候,两条流都迅速向着收敛速率5Gbps靠近并最终稳定,整个过程耗时只有几毫秒,比其他两种方法的收敛速度都要快很多。
图3是TCP友好性测试图。仍然使用前述的二对一的场景,只不过将事先发送的那条数据流变成TCP的数据流。等TCP流完全占满瓶颈链路的带宽之后,第二条参与测试的流加入进来开始与TCP协议流竞争瓶颈链路带宽。两条流在三次握手时均与接收端协商好打开支持ECN的选项。TCP流在整个实验过程中都一直存在,而测试流则从0.2s开始进入,到0.4s时撤出。最后,观察两条流的吞吐率变化情况。场景中的链路带宽均为1Gbps,基础RTT为100μs,包大小为1KB。
从图3(a)可以看出,DCTCP流的竞争性明显更强,整个竞争过程中基本上抢占了80%的瓶颈链路带宽。原因是当TCP的发送端收到了带ECN标记的ACK之后直接将当前窗口减半,而DCTCP的降窗量最大只有当前窗口的一半,因此DCTCP流获得了更多的带宽。
在图3(b)的测试中由于不需要ECN策略,所以在两条流的三次握手过程并没有打开ECN选项,因此相应交换机的队列管理策略为丢尾策略,DropTail。反观基于延时测量的DX流,在整个竞争过程中表现出的竞争性非常得差。获得的带宽不及TCP流的10%。原因是DX协议只要已检测到排队延时出现就会降窗,而TCP流则是只有出现丢包才会降窗,因此DX流很早就开始降窗,其对拥塞的敏感性使得其在竞争过程中一直处于下风。
在图3(c)中,反观本发明方法FFC,在数据流共存的时期,TCP流和FFC流各自占用了瓶颈链路一半的容量,收敛速度很快且收敛后两条流的速率整体来看也比较稳定,说明了FFC在TCP友好性方面的比其他两个方法性能更好。
图4是为了测试收敛速度提升后对应于层性能(流完成时间,FCT)所带来的收益。在这一次测试中,第一条流仍然先发并占满瓶颈链路的全部带宽。接着,将后续要发送的第二条流的大小分别设置为10KB,50KB,200KB和1MB来进行实验,并记录每次实验中不同大小的第二条流的FCT。此外,设置场景中的链路的带宽为1Gbps,10Gbps和40Gbps来分别进行实验,并观察带宽变化对不同方法的流完成时间的影响。从整体来看,FFC获得了最好的性能,而且其性能优势随着链路容量的增大也越来越明显,这就说明FFC能够适用于超高带宽的链路传输。
图5是为了测试三种方法内部多条数据流之间的收敛和公平性情况。让5条数据流分阶段按先后顺序进入网络,然后按相反的顺利依次离开网络。每次有流加入和离开的时间间隔为0.2s,链路容量为10Gbps,收发双方的基础往返延时为100μs。
在图5(a)中,整体来看DCTCP的各条数据流之间基本能做到收敛和公平,但是在流数增多之后其退避不够精确的问题逐渐凸显出来,所以各条流的吞吐率抖动比较剧烈。即使如此,但在整个实验过程中,瓶颈链路的总吞吐率一直都保持非常高的水平,因此链路利用率很高。
在图5(b)中,很明显DX的各条流的收敛情况非常好,各条流在公平共享的速率上保持着非常平稳的态势,而且几乎没有任何抖动出现。但是,DX对总吞吐率的保护并不到位,可以看到,每当有新流加入和离开的时候,总吞吐率都会有一定的损失,这都是因为DX对拥塞过分敏感而造成的,瓶颈链路的利用率也没有DCTCP高。
在图5(c)中,本发明方法FFC是三种方法中唯一一个既能保证各数据流之间的快速收敛和公平共享,又能保证非常高的总吞吐率和瓶颈链路利用率的方法。各条流的收敛过程快速、平稳,而且总吞吐率始终都维持着几乎满利用链路容量的状态,因此FFC的综合性能更令人满意。
图6是为了测试与传统TCP共存时多流之间的收敛和公平性情况。使用多对一的场景,让多条数据流同时发送,这些流中有TCP的数据流,也有待测试的方法的数据流,也就是多条不同方法的数据流共存在同一场景中。一共发送10条数据流,并且每次实验逐渐增加TCP数据流的数量,从1增加到9,换句话说,场景中待测试流的数量从9条减少到1条。观察并记录每次实验的每条数据流的吞吐率情况,并计算待测数据流的平均吞吐率和TCP流的平均吞吐率,以及待测流的总吞吐率和TCP流的总吞吐率情况。
当DCTCP与TCP共存时,DCTCP流明显表现出更强的竞争性。而且,即使增加TCP流的数量并同时减少了DCTCP的数量,TCP流的平均吞吐率也没有得到明显的提升,如图6(a)所示。此外,随着DCTCP流的数量减少,DCTCP流之间竞争带宽的情况越来越少,而同时网络中处于弱势的TCP流越来越多,所以DCTCP竞争性强的特点也越来越明显。在总吞吐率方面,如图6(b)所示,TCP流的增多以及相应DCTCP流的减少,使得两种协议的流的总吞吐率慢慢接近。因此,虽然TCP流的平均吞吐率没有得到明显提升,但是TCP流的总吞吐率还是得到了一定的提高。在图6(b)中,9条TCP流的总吞吐率才基本接近1条DCTCP流的单流吞吐率。
当DX与TCP共存时,TCP变得更强势,因此无论在哪一种情况下,TCP流的平均吞吐率都要更高。在图6(a)中,随着TCP流变得越来越多,DX流的平均吞吐率没有明显变化,但是TCP流的平均吞吐率随着TCP流数量的增多逐渐下降。这是因为更多的TCP流进入网络,使得TCP流之间竞争带宽的情况变得越来越重。在图6(b)中,TCP流越来越多使得TCP的总吞吐率慢慢升高,而DX流越来越少,使得DX的总吞吐率也呈现缓慢下降的趋势。
当FFC与TCP共存时,在图6(a)中,FFC流和TCP流在所有情况下都能保持基本持平的平均吞吐率。网络中两种方法的流所占的比例即使发生变化,也没有对FFC的TCP友好性产生影响,这一点在图6(b)中也同样能够被观察到。TCP流的总吞吐率和FFC流的总吞吐率之间的比例关系基本和TCP流数与FFC流数的比例关系保持一致,因此FFC的TCP友好性是能够令人满意的。