视频网站建设框架,wordpress 不发送邮件,中国世界排名前200的大学,汝州建站公司我吹捧 bbr 时曾论证过它在和 buffer 拧巴的时候表现如何优秀#xff0c;但这一次说 vegas 时#xff0c;我说的是从拥塞控制这个问题本身看来#xff0c;vegas 为什么好#xff0c;并且正确。
接着昨天 tcp vegas 鉴赏 继续扯。
假设一群共享带宽的流量中有流量退出或有…我吹捧 bbr 时曾论证过它在和 buffer 拧巴的时候表现如何优秀但这一次说 vegas 时我说的是从拥塞控制这个问题本身看来vegas 为什么好并且正确。
接着昨天 tcp vegas 鉴赏 继续扯。
假设一群共享带宽的流量中有流量退出或有新流量进入剩余流如何感知到这事。loss-based 算法按照自己的步调填充 buffer 直到丢包它们无法感知任何资源变化而 bbr 则通过定期的 probe 来探测但如果在 probe 之前有其它 bbr 流先行 probe则后 probe 的流什么都拿不到。虽然它们都没有能力自动感知到资源变化但它们无疑都希望自己能做到这一点。
本质上大家都被灌输了 capacity-search 思想想方设法要榨干最后 1k 的带宽却往往适得其反包括 bbr 在内的绝大多数算法引入越搞越复杂的 probe 机制却没有收到应有的收益而 vegas 采用松弛策略反而自动做到了带宽利用率的最优化。
vegas 依靠 alpha diff (expected - actual) * basertt beta 自动做到这一点。
如果有流量退出所有流都会感知到 rtt 变小actual 变大diff 往左偏置只要偏过左值 alphavegas 就会增加 cwnd 以适应这一变化。也就是说流量退出腾出的 buffer 由大家公平瓜分了。
如果有流量进入所有流都会感知到 rtt 变大actual 变小diff 往右偏置只要偏过右值 betavegas 就会减少 cwnd 以适应这一变化每条流都会腾出一些 inflight 分享给新进入的流。
vegas 是真正的拥塞控制。vegas 不做 capacity-search我们看到即使有流退出也不会有单独的流抢走大多数带宽因为 rtt 变化信号是大家同时可捕捉同时可反应的(相比之下loss 信号则依赖比如说 red 丢谁没丢谁)。
再看 rtt 公平性。
diff cwnd (1 - basertt / lastrtt) cwnd (1 - basertt / (basertt queuing_delay)) cwnd (1 - 1 / (1 queuing_delay / basertt)) 设 basertt 是 ycwnd 为 xqueuing_delay 为常数 qdiff x(1 - 1 / (1 q / y)) 要想把 diff 限制在相同的 alphabeta 区间内大家的 q 都是同一个y 越大x 越大但带宽却一致vegas 完美自适应 rtt。
不光如此rtt 越小带宽感知越灵敏因为 rtt 越大抖动代价越大所谓尾大不掉这不光影响自己还影响其它流的公平性因此 rtt 越大越趋向稳定。rtt 越大获得的份额越小。其实 vegas 是按 bdp 分配带宽的rtt 越大buffer 占比越小这是公平的根源。下面是简单的论证。
依旧设 basertt 是 ycwnd 为 x由于有流退出 q 由 2 减少到 1diff 的 diff 为 q 变化前后两个 diff 相减可表示为 z -x / ((y 2)(y 1))直观画图如下(就不求偏导了)
我们已经知道y 越大x 相对越大如图所示(如果短肥管道箭头贴着 x 轴沿 y 轴存在 rtt 不公平本文暂不谈)z 趋向于箭头指向的方向在那里平面非常平缓这意味着diff 受 basertt 影响非常小对变化的感知力一致进而能获得瓜分同样份额的 buffer这就是公平的根源。
下面又是个有趣的重头戏。
vegas 对 loss 完全无感因此它不得不修改 tcp 重传算法以适配它自己 “夹逼 diff 区间” 的算法。reno 早已深入人心并且基于 loss-based reno 对拥塞控制做了标准化有趣的是包括 reno 在内的所有 loss-based cc 几乎都在使用 aimd 进行控制而它们控制的并不是拥塞vegas 专门控制拥塞的算法因为是后来的反倒让人觉得奇怪。
vegas 不再使用 3 个dupack 触发重传而采用了一种时间序方法我这里截一个 vegas 原始论文 的图
仔细看这不就是 rack 嘛关于 rack 可参考 rack 与 fack。rack 时间序最早正是来源于 vegas它实际上在 rack 发布之前就早已被很多家公司运用。
时间序的一个重要作用就是解耦了重传和丢包检测。曾经重传依赖于某种丢包信号比如 3 次 dupack 本身就算一种奇技淫巧一旦等不到 3 次 dupack这个机制就完全失效其意义非常有限但时间序重传不再依赖对端反馈可源源不断提供可供传输的报文剩下的交给拥塞控制。
有了时间序重传机制就可以将丢包检测和重传分离vegas 可完全不在乎 loss 而完全通过夹逼 diff 到 alphabeta 区间完成拥塞控制完全不再区分参与 diff 计算的是新数据还是重传数据简洁而唯美。
linux tcp 内置了拥塞状态机如今已经合入了 rack 作为除 dupack 之外的另一种触发重传的选择并且已经支持 cong_control 回调完全接管整个拥塞控制而绕开拥塞状态机(比如 prr 会被绕开因为如果不将 loss 做信号也就没必要对 loss 反应那么大)我觉得可以实现一版完备的真 vegas 了言外之意此前的 vegas 是假的。
最后vegas 改进了慢启动不再盲目乘以 2而是在慢启动期间加入了 diff 判断从而择机退出慢启动 or 改变激进程度。
总之从头看到尾vegas 只有 diff 判断任何时候(无论慢启动重传等)只要算 diff 并和 alphabeta 比较就行了在这么简单的逻辑下前面也简单论证过vegas 的公平性和效率都非常好。
我曾经写过一个 cugas cubic vegas但其实还不如将它变成 bbr 呢如果世界上只有一种 vegas 就会非常稳定因为天生公平的算法就不会引入很多公平性和效率之间的权衡问题进而也不会引入号称能解决这些问题结果只是新晋一员卷客看看现在的拥塞控制领域那些不雅又奇怪的算法。
浙江温州皮鞋湿下雨进水不会胖。
