随手写点感想。
有人说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。
浙江温州皮鞋湿，下雨进水不会胖。