TCP BBR之全局同步

缘起于一场技术交流,我以一篇短文作为总结。


先给一个TCP魔数:

rtt=(1α)×rtt+α×rttnow r t t = ( 1 − α ) × r t t + α × r t t n o w

其中 α α 18 1 8 ,为什么是 18 1 8 而不是 19 1 9 ?答案是调得一手好参数!这显然是一个很谢特的回答。

  然而我接受这坨谢特,因为我无法证明我有更加完美的。TCP的代码中到处充斥着这种魔术数字,近的说Google BBR吧,为什么ProbeBW内部状态机是6个匀速,为什么ProbeRTT的忍耐周期是10秒,等等等等,使我不得开心颜。

  好吧,你会说这是经验值,我并不反对,因为我没有理由反对,你说这是实测数据所得,我也无话可说,你说10就是10,你说8就是8,这个你说了算,我和作者的分歧点不在这,我们的分歧在于,这种魔术数是作为常量起作用还是作为概率期望起作用,换句话说,给定数字8,你会认为8就是8,而我会认为大概率会是8,但仍然正态分布为7或者9,6或者10…,我的理解有误吗?

  我发现一个可以类比的现象,即军队过桥,一般都会取消正步,代之以碎步通过,就是为了避免共振造成桥梁坍塌。但这一点是不是可以用于非桥梁的情况呢?我是讨厌整齐划一的,所以我喜欢美军的方式,结果导向,而不是PLA那般的过程管理,跑步跑得齐其意义是什么,我至今不知道。

  TCP BBR拥塞控制算法里面的诸多魔数,让我感知到了全局同步,虽然桥梁是否坍塌还有待观察。每一条BBR流就是一个军人,他必须不能和其它军人的步伐协调一致…我不知道这样做是不是正确。我无法证明,但可以事实证明。


请按照下列建议修改BBR代码:

  • 移动指数平均之外的所有魔数全部作为统计期望而不是常数;
  • 期望值保持和常数值完全一致,不要自行修改。

解释一下第二点。

  不要觉得自己多么高明,把 54 5 4 改成 64 6 4 就能有什么进展,这都是臆想和YY,你要知道这些魔数的来历,而你可能根本就没有导出这些魔数的环境,特别是在国内,完全没有这种环境。所以,除了相信它,不要质疑它。

  你以为让BBR Startup探测更加猛烈一些就能取得更好的效果吗?你错了,你没有找到平衡点,偶尔的场景你会觉得高效,但大多数情况下,你忽略了更差的表现,不是吗?

  我并没有试图推翻这些魔数,而只是代之以期望。你想要的是17个10,我却认为以下的序列更合理:8,8,9,9,9,10,10,10,10,10,10,10,11,11,11,12,12。

  你,认为呢?

你可能感兴趣的:(TCP BBR之全局同步)