如何写一个好的拥塞控制算法

随手写点感想。

有人说CUBIC带宽利用率低,有人说BBR存在这样那样的问题,于是很多魔改版本纷至沓来,于是各式各样的实验室CC寒武纪大爆发,最终还是出不了实验室,最终还是这样那样的问题。

问题的根源在哪里?如何才能写一个好的拥塞控制算法?

在我看来,类似Linux内核中的CUBIC,Vegas,BBR,PCC这样的一个C文件里几个回调函数的CC,几乎已经接近这种形式CC的极限了,很难再有突破。

这种形式的算法能利用的信息太少,熵太高,需要更多的信息,但没有。能直接采集到的信息是什么?仅仅是从不断到来的ACK中采集到的确认情况以及并不精确的RTT。

希望通过平滑积累ACK信息的瞬时值而获得更多的信息,十有八九就是靠猜。

如果想写一个很厉害的拥塞控制算法,无非就一点,那就是更多的信息,问题是,信息从何而来?就两个渠道:

  • ACK反馈更多信息。
  • ACK信息积累成大数据,AI分析。

对于第一点,IDC内部已经如火如荼,比如交换机可以设置ECN,比如HPCC,交换机可以设置更丰富的信息带回到sender指导拥塞控制。

对于第二点也不难理解,从单独的瞬时ACK中很难获得精确信息,多次平滑累积本身就是有损的拟合,但如果把每一次信息都记下来,组成一张大散点图,就可以发现其中的一些模式特征了,这就是有用的信息。

甚至可以两者结合。TCP头部空间有限,无法携带太多的信息,但交换机,sender,receiver三者可以将AI计算的结果形成字典,交换机只需要塞入一个字典索引,sender,recerver就可以根据该索引检索到相应的模式了,进而采取对应的action。


浙江温州皮鞋湿,下雨进水不会胖。

你可能感兴趣的:(TCP)