端到端拥塞控制的本质(2）

前文：端到端拥塞控制的本质

我用更加真实的高斯分布的时延替换 sin，这是合理的，因为统计复用系统起作用的两条铁律就是大数定律和中心极限定理，即便是经理也绕不过，如果时延如高斯分布，发送速率和 cwnd 如何随行。
我昨日做了几个仿真，比如昨天的想法里发的如下图示：

附言如下：

我取了更加真实的高斯分布的随机数模拟即时 rtt，让算法随行，确实速率可以跟随，而 cwnd 只是简单将速率和平滑 rtt 相乘，显然也跟随了。可以很明显看出速率会随着平滑 rtt 此消彼长，这才是真正的拥塞控制。完全自主的基于时延的拥塞控制，关键是它可以自适应和 loss–based 的共存。

下面是另一个展示：

清晰可见，cwnd 小的时候，一定伴随 rate 低下，且 srtt 升高，后者是因，前面是果。

真正的拥塞控制本身就应该基于时延，时延是拥塞唯一的判断标准。

loss-based cc 只是借用了一个现成机制，buffer 总是有限，它总是会满的，满了就会丢，这显然是一种消极的应对方式。如果 buffer 真的可以无限呢，岂不是拥塞随着 buffer 的增加越发加剧，事实上在摩尔定律作用下，buffer 内存确实越来越便宜，此时就必须依赖 red，因此，red 并不是仅仅针对全局同步，而是应对渐大的 buffer。

如果哪天发现了几近免费的内存颗粒，buffer 几乎可以无限扩展，aimd 势必要求 red 变得更加复杂，aimd 依赖一个 “丢包事件”，而这个事件并没有在算法内部闭环，它完全依赖 buffer 的大小以及 aqm 的配置，aimd 并不是可扩展的算法。

但现实的力量最大，aimd + red 是现实部署中最普遍的，因此所有的 cc 都要适应它，而不是它去适应新式 cc，aimd 明明就摆在那里。

就算当年范氏 aimd 管道没有成为拥塞控制共识，早晚也还是会出现这种 aimd 管道，这是一个很不稳定的博弈平衡点。即便最初 vegas 部署在 95% 的节点，只要有 1% 的节点执行 aimd，很容易就会抢占更多带宽，促使 vegas 不得不引入 probe 机制，这就是 bbr。

至于其它那些企图细粒度控制的算法，呵呵哒。总量大粒度小，只能宏观调控，概率论是工具，微观操作是做不到的。这是客观规律，别不信邪。

以后这种文字少写了，老婆不让搞了，觉得天天弄这些显得不务正业，让接点私活儿做点正经事，但我也不知道哪些算是正经项目。

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