背景技术
TCP Reno方法自1988年被提出来之后,一直被认为是一种效果很好的Internet网络传输控制方法,而被广大科研人员所接受,沿用到至今。但进入21世纪后,随着吉比特网络、无线网络、传感器网络和卫星网络的不断兴起和普及,传统的TCP拥塞控制方法在这些网络环境下面临着很大的挑战。特别是随着网络技术的飞速发展和接入性能的不断提高,如今全世界的互联主干网络呈现出一种高带宽高延时的网络特性。在这种网络环境下,伴随着网络带宽和往返时延的不断增加,TCP方法因为带宽链路利用率很低、RTT不公平性显著、TCP流抖动频繁等缺点反而成为了限制网络性能的瓶颈所在。
为了解决TCP方法所存在的上述技术问题,技术人员提出了一系列拥塞控制改进方法,如HSTCP、STCP、BIC-TCP、FAST、XCP等等。虽然在带宽利用率上获得了较好的效果,但仍面临着TCP友好性低下、链路丢包率过高以及流之间公平性无法保证等诸多问题。
这些问题主要包括:
(1)TCP友好性低下
虽然新的优秀的拥塞控制方法取代传统的TCP方法将会是今后的大势所趋,但在一定的时期内,仍会出现新方法与传统方法共存同一网络链路的情况。而在这种情况下,如何有效的提高新方法流的吞吐量,又不过分降低传统TCP流的带宽,这是拥塞控制方法所必须具备的要素之一。相比前面所提出来的诸多方法,HSTCP方法和STCP方法在这一点上存在着非常严重的问题。高速流抢占了瓶颈链路的大量可用带宽,而传统的TCP Reno流只获得了很少的吞吐量,几乎被饿死,这是方法设计者所不愿意看到的。
(2)RTT不公平性严重
两个不同RTT流之间的吞吐量比值关系为:
其中d为拥塞控制方法相关参数,传统的TCP方法和AIMD方法的d值都为0.5。而HSTCP、STCP以及BIC-TCP等方法都因为改变了TCP的窗口增长规律,提高了d值,使得RTT不公平性问题不但没减轻,反而更加严重。
(3)触发拥塞丢包事件的概率
HSTCP等拥塞控制方法使得TCP流吞吐量在高带宽延时网络上迅速增加,这一方面大大提高了网络的带宽利用率;但另一方面,对于基于丢包的TCP方法来说,大大提高网络利用率同时意味着接近网络带宽总量的速度也越快。而越快的接近网络带宽总量也暗示着下一次拥塞丢包事件为期不远了。这些方法在提高网络带宽利用率的同时也间接加大了网络的丢包率。
(4)无法准确判断网络拥塞
在现实网络中,TCP方法采用丢包事件来作为网络拥塞的信号。但近年来的一些研究表明,丢包事件不能及时反映网络中的拥塞。而RTT延时信息由于其可变性,相对于丢包事件来说,反应更加灵敏,更能及时地反映出一般网络中的拥塞状况。为此,一些拥塞控制改进方法试图采用RTT延时检测来判断网络的拥塞情况,如FAST TCP和Astart。但是,近年来研究表明,高速网络中基于延时的拥塞避免方式仍存在着一些弊端,在某些环境下也不能反映出真实的网络拥塞情况。它们指出,网络中不断增加的RTT延时和丢包事件并没有直接的对应关系,反而网络中随时可能出现的噪声将会对RTT检测产生干扰,造成方法无法准确有效的控制窗口变化。另一方面,显式速率反馈机制也能够有效的检测出网络的拥塞,如XCP方法。但是这些方法太过于复杂,往往需要在数据包头插入一段很长控制信息位,这对于数据包内现有空间所剩不多的TCP/IP协议栈来说,在实现上将会是很大一个问题。
发明内容
为了解决TCP方法所存在的上述技术问题,本发明提出了一种用于高速网络中的协同工作式拥塞控制方法。这种方法通过发送端监测RTT延时信息和路由器反馈的1比特显式预测信息来判断网络拥塞状态,自适应的调节拥塞窗口。
本发明解决上述技术问题的技术方案包括以下步骤:
1)检测发送端的RTT延时信息S1;
2)在包头中打上1比特的负载信息位S2,路径上每个路由器利用根据自身负载状态所计算出来的S2负载信息与包头中原有的S2状态信息进行一次或运算,并将运算结果又重新打回到包头中,当携带有S2负载信息的包到达接收方时,接收方通过ACK确认包将该信息返回给发送端,获得路由器反馈的1比特预测信息S2;
3)根据RTT延时信息S2和路由器反馈的1比特预测信息S2判断网络拥塞状态,自适应的调节在高速网络下的拥塞窗口。
上述的用于高速网络中的协同工作式拥塞控制方法中,所述步骤1)为估计任一连接在任一路径上路由器缓存队列中的排队包数目;将排队包数目与阈值比较,得到网络延时状态信息S1。
上述的用于高速网络中的协同工作式拥塞控制方法,所述步骤2)中1比特的负载信息位S2计算步骤如下:
预测每个路由器分组到达速率;
计算τ时隙网络路径上任一节点i的负载因子预测值LFi;
将预测所得的负载因子LFi与阈值β比较,得到1比特的拥塞状态信息S2。
本发明的技术效果在于:本方法通过结合网络路径的负载因子和连接在路径上所有路由器缓存中的数据包数目两种拥塞状态信息,可以将网络划分为四种更细的拥塞等级,更能有效的反映出网络的真实状态。并且,将两种拥塞信息机制统一融合起来,可以尽量避免单一拥塞检测模式在某些环境下所产生的误判信息,如延时噪声所带来的RTT抖动情况等等,降低了单方面信息错误对方法可靠性的直接影响。即使某一种检测信息产生了误判,但由于有另一种信息在制约着它,使其错误并不会直接影响到方法机制,也不会对方法的性能产生较大幅度的影响。
下面结合附图和具体实施例对本发明作进一步的说明。
具体实施方式
参见图1,本发明方法的流程图。首先,我们定义下一τ时隙网络路径上任一节点i的负载因子预测值LFi为:
其中,ri表示下时隙该节点所有入口流到达速率之和的预测值,Ci表示链路的服务速率(即链路带宽)。而网络路径P={1,2,......,i,...,m}上下一时隙的负载因子LFP为该路径上所有节点负载因子预测值的最大值,即:
连接C在路径P上所有节点缓存队列中排队的数据包数目之和为:
其中
是连接C在路由器i上排队数据包数目的估计值。
LFP反映的是整个全局网络中瓶颈节点下一时隙的拥塞情况,其值是由共享这条路径的所有连接所决定的。而QLCP则考虑的是单个连接在路径中的拥塞情况,它的值是由单个连接的发送速率所决定。由于网络的复杂性,我们希望看到拥塞控制方法既能够考虑到网络上所有连接所造成的全局负载情况,又要顾及到局部上单个流能以公平的发送速率来共享带宽、处理拥塞。它们之间并不是一个独立的过程,而是一种相互制约、相互作用的联动行为。所以,对于网络路径P的拥塞状态CSP,我们认为必须将其与全局因素LFP和局部因素QLCP相互关联起来,并用以下函数式表示:
上述二者决定了某一时段内网络路径P的真实拥塞状态。二者之间既是相互独立又存在着一定的联系。在本方法中,针对LFP和QLCP两种路径拥塞信息,方法将估测出网络路径的拥塞程度,并做出相应的拥塞窗口机制调整。下面将分别对两种拥塞检测机制的方法给出详细描述。
对于发送端来说,缓存数据包之和QLCP所产生的直接影响,就是发送端所监控到的RTT延时的变化量。发送端根据排队论理论中的Little Formula定理,可以近似的通过监控RTT响应时间变化量来估算该连接的QLCP值,如公式(3)所示:
其中sRTT是发送端所测得的高精度指数平滑往返时间,baseRTT是每流所测得的最小往返时间。这个最小值近似的等于整个连接路径中的传输延时,而(sRTT-baseRTT)则是对当前网络中排队延时的一个估计值。由发送端每秒发送cwnd/sRTT个数据包可知,cwnd*(sRTT-baseRTT)/sRTT从物理意义上可以理解成该连接在路由器缓存队列上所排队包数的估计值。
在发送端,发送方通过监控网络中ACK所带回来的RTT延时情况,采用公式(3)来估计某一连接在路径上路由器缓存队列中所排队包的数目。根据估算出来的路由器缓存队列中排队包数目QLCP以及阈值α,通过下式我们可以得到网络延时状态信息位S1。
其中,阈值α是一个参数变量,它决定着整个方法对网络延时信号的敏感程度。当QLCP大于阈值α时,意味着该连接当前的发送速率已经过大,引起了路由器上的额外排队行为,使得往返延时加大。这时,本方法将S1状态信息设为1,表示路径上排队的包数目超过了我们所期望的值,开始临近拥塞。
另一方面,下一时隙中路径负载因子最大值LFP是由网络路径中拥塞程度最重的节点所造成的,它决定了网络中最大的瓶颈所在。根据网络流量的自相似性,本方法中每个路由器i首先预测分组到达速率(MMSE预测器),然后利用公式(1)来计算下一个τ时刻内自己的负载因子LFi,并将自身的拥塞状态划分为低负载和高负载两个等级。根据这个预测所得的负载因子LFi以及阈值β,通过下式得到1比特的S2拥塞状态信息位。
和ECN机制一样,本发明方法在包头中打上这个1比特的负载信息位S2,路径上每个路由器利用根据自身负载状态所计算出来的S2负载信息与包头中原有的S2状态信息进行一次或运算,并将运算结果又重新打回到包头中。当携带有S2负载信息的包到达接收方时,接收方通过ACK确认包将该信息返回给发送端。通过这种方式,最终发送端以S2状态信息位的形式获取了整个路径P的拥塞状态。
本发明方法中,当发送端和接收端三次握手建立起连接以后,首先进入到“慢启动”模式,这个阶段的拥塞窗口增长方式和传统TCP是一样的,都是针对每一个回来的ACK进行一次窗口加1。而当连接出现了第一次丢包时,方法则进入到“快速恢复”模式。在这个模式下,发送端根据S1和S2状态信息相互组合所得到四种网络拥塞状态,调用四种不同的窗口调节机制来自适应的控制网络流量,使方法能够快速有效的恢复到最佳网络利用状态。具体拥塞窗口变化规则如下表1所示。
表1为“快速恢复”模式拥塞窗口调整机制
S1 |
S2 |
网络状态 |
窗口管理方法 |
窗口变化规律 |
0 |
0 |
网络路径拥塞程度很轻 |
指数增加 |
w=w*k |
1 |
0 |
整个网络路径负载程度较轻,但该流延时增量过大 |
平滑增加 |
w=w+1/w |
0 | 1 |
网络路径中某节点负载程度较高,但该流延时增量较低 |
线性增加 | w=w+1 |
1 |
1 |
网络路径处于重拥塞状态 |
线性降低 |
w=w-1 |
如表1所示,当S1和S2两个网络状态量均为0时,表示这时的网络处于低负载状态,还有很多的剩余带宽没有被充分利用,所以此时本方法采取乘性增加的窗口调整机制,迅速提高网络利用率。当S1=1、S2=0时,此时网络状态有两种可能:一种是网络拥塞度仍较轻,但该连接流速相对过大的情况;而另一种则是因为网络噪声对RTT延时检测所产生的干扰所致。在这种不确定的状态下,本方法采用了一种较为平缓的窗口增长方式,w=w+1/w,以保证网络的可靠运行。而当S1=0、S2=1时则表示网络已经开始拥塞,但拥塞并不是由该连接流所造成的情况。为了提高本方法的公平性,设定此时为加性增加的窗口调整机制。最后,当S1和S2两个网络状态量均为1时,可以肯定这时的网络处于一种重拥塞的状态,本方法对其拥塞窗口进行逐步递减,以此来缓解网络的负载。同样,当发送端接收到丢包反馈信息时,也将其拥塞窗口进行减半操作。
我们在NS2.28网络仿真平台上实现了本方法,并对其性能进行了测试。我们采用图2所示的哑铃型拓扑结构测试本方法的性能。作为对比,我们选择了流行的BIC-TCP、HSTCP、FAST方法和XCP进行了比较,其方法参数均按照NS2中默认的值进行设置。为了更加有效的提高模拟实验的真实性,我们在所有模拟过程中都引入了峰值约占带宽大小5%的泊松分布UDP流,以此来充当真实网络环境下的背景流。默认模拟过程持续480秒。所有流的分组大小均设为1Kbyte。根据真实高速网络中流量模型的特性,本方法中的相关参数设置如下:α=3、β=0.8、k=1.01;而流量预测时间间隔τ的设置,则根据网络中75%~90%的流RTT时间小于200ms的特性,所以我们设置τ=200ms。
首先验证本方法的带宽利用率,结果列在表2中。
表2带宽利用率
Protocol |
Utilization |
C3P |
97.2% |
XCP |
97.8% |
|
Drop-tail |
RED |
BIC-TCP |
97.0% |
95.3% |
HSTCP |
97.2% |
92.1% |
FAST |
96.8% |
95.1% |
表2给出了各方法在带宽利用率上的性能比较。可以看出,在Drop-tail队列中,三者的带宽利用率差不多;但是在RED队列中,BIC-TCP和HSTCP方法的利用率均下降了一些。造成这种现象的主要原因是Drop-tail队列允许数据流充满所有的队列缓存,而RED队列由于早丢弃的机制,数据流并不能占满瓶颈链路上所有的队列缓存,造成整个网络带宽利用率的下降。
接着验证了本方法的TCP友好性,结果描述在图3中。随着网络接入性能的不断提高和拥塞控制方法的不断发展,网络中将会出现多种拥塞控制方法共存的情况。在这种情况下,如何保证各流之间的正常运行,提高拥塞控制改进流同传统TCP Reno流的TCP友好性,是方法设计中的关键要素之一。这一节中,我们给出了五种方法的TCP友好性评价比较。在实验中分别定义两类主机,一类采用拥塞控制改进方法,而另一类则采用的传统TCP Reno。接入链路带宽和延时分别设为1Gbps和1ms,而不同流所共享的瓶颈链路为622Mbps,传输延时80ms。在此基础上,我们分别比较不同拥塞控制流和Reno流共存条件下的发包速率之比。
观察图3,BIC-TCP和HSTCP在大大提高了自身发包速率的同时,也严重影响了Reno流的吞吐率。可以看出,它们抢占了大量的网络剩余带宽资源,导致TCP-Reno流被活活饿死。由此可见,HSTCP和BIC-TCP方法的TCP友好性并不能达到一个另人满意的程度。并且,由于方法自身的侵略性,同时还给网络带来了大量的丢包,加大了整个网络的抖动。观察图3,本方法相对降低了对Reno流的影响,C3P流和Reno流均获得了较为理想的带宽分配。C3P流的瞬时发包速率和Reno流的瞬时发包速率之比约为2∶1,很明显,本方法提高了方法在高带宽延时网络中的TCP友好性。同时,本方法在整个模拟过程中表现得较为稳定,并降低了方法的丢包率。
造成这一结果的主要原因在于本方法所采用的延时检测机制降低了方法流抢占瓶颈路由器上过多额外缓存空间事件的概率。本方法认为单个流最合理的发送速率应当保证该流在路由器缓存队列上的排队包数不超过某一特定阈值。如果路由器缓存队列中排队包大部分均属于同一连接流的话,很显然该流的发送速率过大,因为路由器上的拥塞基本上断定是由它所造成的。本方法将空出来的缓存空间让给Reno流,进一步加大了Reno流的发送速率,减小两个流之间的瞬时吞吐量之比,提高了方法的TCP友好性。
接下来,我们验证了本方法的RTT公平性,结果描述如表3所示。
表3各方法流吞吐量之比
Inverse RTT Ratio |
1 |
3 |
6 |
Reno |
1.116590 |
8.476595 |
16.015658 |
BIC-TCP |
1.033434 |
9.696173 |
30.431101 |
HSTCP |
0.942102 |
92.844748 |
384.833044 |
FAST |
1.125487 |
1.009883 |
19.543154 |
XCP |
0.973584 |
8.153879 |
14.548451 |
C3P |
1.014521 |
2.012452 |
8.445621 |
从表3可以看出,如第二节所述,HSTCP和BIC-TCP在此环境下均表现出严重的RTT不公平性。实验中,往返传输延时越小的流占据了越多的网络带宽。而随着往返延时比率的不断加大,流与流之间的吞吐量比率也越来越大,造成RTT较大的数据流得不到有效的带宽分配,活活饿死。
同样从表3中可以看出,本方法在RTT公平性方面获得了较为显著的改善。流之间吞吐量的比率略等于RTT值之间的比率。这个结果甚至好过TCPReno在同等网络环境下所得到的结果,不管是在Drop-tail队列下还是在RED队列下。C3P方法得到这样较为理想的RTT公平性性能的原因主要在于方法接近拥塞时采用了基于RTT延时检测的拥塞窗口动态调整机制。RTT较小的流刚开始的时候增长速率很快,不断的将两流之间吞吐量比值拉大。但随着该流发送速率的不断加大,它对延时变化量也变得更加敏感。那样,它将先于RTT较大的流进入到窗口递减模式。相反,RTT较大的流这时仍处于窗口递增的模式,使其瞬时吞吐量不断增加,最终使二流的吞吐量比值维持在一个较小的范围内,保证了本方法的RTT公平性。
最后,我们验证了本方法的收敛性和网络自适应性,结果描述如图4、图5。
当有一个新流加入到网络中时,网络重新恢复到公平带宽分配的收敛时间同样也是衡量一个拥塞控制方法性能的要素之一。在实验中,我们建立了四个RTT为100ms的传输连接。其中两个连接在[0:60]秒内随机触发,而另外两个则在[100:160]内随机触发。总的模拟实验持续600秒,瓶颈带宽为622Mbps。为了结果的准确性,我们从第100秒后每隔50秒统计一次吞吐量的公平指数Fairness Index。观察图4,除了HSTCP方法在整个过程中有一些轻微抖动外,各方法流的收敛均比较迅速,体现了较好的带宽分配收敛性。
而对于网络自适应性,我们设定瓶颈链路设为622Mbps,整个网络的RTT延时为84ms。在实验进行到160秒的时候,引入一个300Mbps的UDP CBR流到网络中,320s后停止该流。
参见图5,本方法表现出较好的网络自适应性。当160秒UDP流引入时,方法迅速降低了自己的发包速率,紧接着快速占满了剩余的300M带宽。而当UDP流取消时,方法又能自适应的进入到快速增长模式,重新占用新空出来的剩余带宽。因为在本方法的饱和状态采用了退避式的拥塞窗口管理机制,C3P流在整个模拟过程中都表现得更加稳定。