关于H-TCP拥塞控制算法

关于HTCP拥塞控制算法

说实话，当年我在看HTCP 和BIC系列的时候更喜欢的是HTCP。
HTCP 的核心思路是这么一个理念：
首先网络拥塞的程度可以通过时延抖动来反映一部分情况，如果网络拥塞很严重，那么这个时候时延抖动应该会很厉害，或者说这个时延的时延和不拥塞时延的时候差别就比较大；
然后，如果我的拥塞窗口不断增加，还处于不拥塞状态的时候，说明啥，说明网络可能还有很大的剩余带宽，这个时候我慢慢的增加拥塞窗口其实是对网络带宽的浪费，这个时候我应该更快的增加拥塞窗口。

基于以上两个理念，就有了ICCRG里的三个标准之一HTCP。我们依然把他的算法分成AI和MD两个部分；
在网络拥塞的状态下，htcp根据两个因素来判断网络拥塞的严重程度，从而调整乘性减的比例，首先的连接的吞吐量是不是有较大的变化：
htcp计算带宽吞吐量的思路是看发送端一个周期内（RTT）发送的数据包被全部确认所花的时间，将两者相除就可以得到其吞吐量：
if (ca->packetcount >= tp->snd_cwnd - (ca->alpha >> 7 ? : 1)
        && now - ca->lasttime >= ca->minRTT
        && ca->minRTT > 0) {
        __u32 cur_Bi = ca->packetcount * HZ / (now - ca->lasttime);

        if (htcp_ccount(ca) <= 3) {
            /* just after backoff */
            ca->minB = ca->maxB = ca->Bi = cur_Bi;
        } else {
            ca->Bi = (3 * ca->Bi + cur_Bi) / 4;
            if (ca->Bi > ca->maxB)
                ca->maxB = ca->Bi;
            if (ca->minB > ca->maxB)
                ca->minB = ca->maxB;
        }
        ca->packetcount = 0;
        ca->lasttime = now;
    }
htcp对于时延抖动的定义很简单  minRTT/maxRTT，值越小说明时延抖动越大，值越大，说明时延抖动越小；
基于以上两个网络状况也就得到了htcp的MD公式：
if (use_bandwidth_switch) {
        u32 maxB = ca->maxB;
        u32 old_maxB = ca->old_maxB;
        ca->old_maxB = ca->maxB;

        if (!between(5 * maxB, 4 * old_maxB, 6 * old_maxB)) {
            ca->beta = BETA_MIN;
            ca->modeswitch = 0;
            return;                   //如果这次拥塞和上次拥塞的吞吐量发生了剧烈变化，那么我们应该稳妥一点，多拿出一点带宽来重新分配
        }
    }

    if (ca->modeswitch && minRTT > msecs_to_jiffies(10) && maxRTT) {
        ca->beta = (minRTT << 7) / maxRTT;
        if (ca->beta < BETA_MIN)
            ca->beta = BETA_MIN;
        else if (ca->beta > BETA_MAX)
            ca->beta = BETA_MAX;
    } else {
        ca->beta = BETA_MIN;
        ca->modeswitch = 1;
    }
//如果时延抖动很大，说明网络拥塞严重;

在AI状态下，算法的问题就转换成了每个往返时延增加多少拥塞窗口，同时还和连接的最小时延（或者我们理解为物理时延）扯上了关系。
首先是不拥塞的时间越长，每个拥塞窗口增加的值就越大：
         factor = 1 + (10 * diff + ((diff / 2) * (diff / 2) / HZ)) / HZ;
     diff =  htcp_cong_time(ca) - HZ; 也就是不拥塞的时间 - 1s；
也就是说HTCP以1s为阈值，不拥塞状态长于1s的时候就开始增加每个时延增加拥塞窗口（或者叫加速度吧），时间越长增加的就越大；

我最早看到的算法，好像是没有关系到最小时延的，看起来它在新版本里加入了这个功能：
u32 scale = (HZ << 3) / (10 * minRTT);
/* clamping ratio to interval [0.5,10]<<3 */
scale = min(max(scale, 1U << 2), 10U << 3);
factor = (factor << 3) / scale;
在时延越小的时候，增加的越少，时延越大的时候增加的越多，这个思路从RTT公平性的角度是可取的；
最后
    ca->alpha = 2 * factor * ((1 << 7) - ca->beta);//如果上次减少的比例小，那么我们增加的比例也同样需要减少，如此会更加稳妥的防止网络爆棚；

算法基本如此了，最后是我的个人评价：
总的来说，相比之下我对htcp的评价比bic协议族要高，htcp的公平性做的很好，他的设计明显在大时延网络环境下能够提高连接的网络利用率，（小时延的时候实际上网络已经能够很好的利用网络了，所以基本没有变化），同时在大时延网络和小时延网络间有更好的公平性，这一点无论是在AI 和MD上有很清晰的体现；（哎，本人在公平性上有点偏执）
htcp有个非常明显的特征，就是他是针对高带宽时延积网络设计的（请各位看官，切记要留意我这句话），个中原因恕我表达能力有限无法表达，只能请大家意会了；
我还有几个疑问：
用minRTT/maxRTT 做为时延抖动的变化依据是不是合理？
如果连接发起时，网络已经处于拥塞状态，并且一直处于拥塞状态，基于时延抖动的算法，是不是有问题？（我还没想明白）
通过处于非拥塞状态的时间来做为拥塞程度的标志，是不是合理，越往后越可能接近网络拥塞，这个时候加速度越大？
最后还有一个是我没有完全想明白作者意图的，就是两次拥塞间吞吐量变化大的，就直接用最大的减性因子？

                                                                                                              泓日天