Chinaunix

标题: BIC和CUBIC的思路 [打印本页]

作者: hritian    时间: 2009-03-10 14:34
标题: BIC和CUBIC的思路

                                                                先说说BIC和CUBIC,虽然现在早就对这个家伙没有了眼前一亮的感觉,不过这毕竟是linux 内核默认的拥塞控制算法,存在的就必然有其合理性。
按照我的理解BIC/CUBIC的核心思想是这样的:
首先,我们来做一个假定,网络上存在的连接数不变,然后每个连接的时延是一样的。再简化一下,网络上就只有连接A和连接B。
A 和 B 同时慢启动,一直到把网络充满了,丢包,A和B都按比例减少20%。如果这时候网络仍然超载,那么接着肯定还会丢包,A和B的速率还会下降,一直降到网络欠载,A和B的速率肯定要增长了, 增长多少呢,网络100%的利用率肯定在我们在现在的速率和上次丢包的速率之间,这就回到了一个问题,在N个顺序排列的数里面找到一个符合我们要求的数,那当然是折半搜索了。
但是网络是动态的,在这个过程中网络中肯定必然的要出现一些连接完成了传输,退出的情况,这时候它就会腾出部分带宽来。这部分带宽就应该由别的连接来填满,但是大家并不知道这部分带宽空出来了,仍然会认为上次丢包时的窗口是最大值,依然会在那一带徘徊一段时间,发现,嘿,还没有丢包呀,看来网络有剩余,大家去把它填满吧。
OK,我们tcp性能的几个角度来分析bic:
先说效率,如我们上面所分析的,BIC/CUBIC的网络利用率应该在80%以上。
公平性,先做个结论再说为什么,bic的rtt不公平性可能以前的算法那样要好一些,但是依然存在。因为,RTT仍然是它的时间单位。
再说收敛性,收敛到效率应该还凑合,但是收敛到公平却很差,我有一个观点,收敛到公平很慢就意味着公平性不好。为什么说收敛到公平的性能不好呢?两个连接的标尺是上次丢包的窗口,当网络处于静态的时候,每次丢包只有20%的带宽拿出来分配,而且还不是公平分配。



本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u3/93004/showart_1858042.html




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2