网络拥塞控制(九)CUBIC
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
⽹络拥塞控制(九)CUBIC
接上⽂,在BIC-TCP提出后不久,North Carolina State University的研究⼈员在根据BI-TCP的⼀些缺点后,再次提出了CUBIC的算法,CUBIC不仅仅是简单的对BIC-TCP存在问题的⼀些修正,它的整个算法都已经做了较⼤的调整。
先看下BIC-TCP的缺点:⾸先就是抢占性较强,BIC-TCP的增长函数在⼩链路带宽时延短的情况下⽐起标准的TCP来抢占性强,它在探测阶段相当于是重新启动⼀个慢启动算法,⽽TCP在处于稳定后窗⼝就是⼀直是线性增长的,不会再次执⾏慢启动的过程。
其次,BIC-TCP的的窗⼝控制阶段分为
binary search increase、max probing,然后还有Smax和Smin的区分,这⼏个值增加了算法上的实现难度,同时也对协议性能的分析模型增加了复杂度。
CUBIC在设计上简化了BIC-TCP的窗⼝调整算法,在BIC-TCP的窗⼝调整中会出现⼀个凹和凸(这⾥的凹和凸指的是数学意义上的凹和凸,凹函数/凸函数)的增长曲线,CUBIC使⽤了⼀个三次函数(即⼀个⽴⽅函数),在三次函数曲线中同样存在⼀个凹和凸的部分,该曲线形状和BIC-TCP的曲线图⼗分相似,于是该部分取代BIC-TCP的增长曲线。
另外,CUBIC中最关键的点在于它的窗⼝增长函数仅仅取决于连续的两次拥塞事件的时间间隔值,从⽽窗⼝增长完全独⽴于⽹络的时延RTT,之前讲述过的HSTCP存在严重的RTT不公平性,⽽CUBIC的RTT独⽴性质使得CUBIC能够在多条共享瓶颈链路的TCP连接之间保持良好的RRTT公平性。
来看下具体细节:当某次拥塞事件发⽣时,Wmax设置为此时发⽣拥塞时的窗⼝值,然后把窗⼝进⾏乘法减⼩,乘法减⼩因⼦设为β,当从快速恢复阶段退出然后进⼊到拥塞避免阶段,此时CUBIC的窗⼝增长开始按照“凹”式增长曲线进⾏增长,该过程⼀直持续直到窗⼝再次增长到Wmax,紧接着,该函数转
⼊“凸”式增长阶段。
该⽅式的增长可以使得窗⼝⼀直维持在Wmax附近,从⽽可以达到⽹络带宽的⾼利⽤率和协议本⾝的稳定性。
窗⼝的增长函数如下:
W(t) = C * (t-K)3 + Wmax, 其中C和β为常量。
t为当前时间距上⼀次窗⼝减⼩的时间差,⽽K就代表该函数从W增长到Wmax的时间周期,。
当收到ACK后,CUBIC计算利⽤该算法计算下⼀个RTT内的窗⼝增长速度,即计算W(t+RTT),该值将作为cwnd的⽬标值,根据cwnd的⼤⼩,CUBIC 将进⼊三种不同模式,如果cwnd会⼩于在标准TCP下经过上次拥塞之后的时刻t窗⼝将会达到的值(该值是通过标准TCP的窗⼝增长函数计算出来的),那么CUBIC就处于标准TCP模式,如果⼩于Wmax,那么位于凹阶段的,如果⼤于Wmax,那么处于凸阶段。
鉴于CUBIC⽐BIC-TCP更出⾊的表现,在Linux2.6.18版本后,CUBIC取代了BIC-TCP,成为缺省的TCP算法。
当然,CUBIC也有其缺点,⽐如在凸增长阶段的快速增长可能导致⽹络流量的突发性,从⽽造成⼀定的丢包。
内核代码请参考/net/ipv4/tcp_Cubic.c,详细理论证明和伪代码实现请参考。