BIC和CUBIC的思路

hritian

                                                                先说说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