网站升级维护中页面,山东新闻今天最新消息,wordpress显示系统,台州网站搜索引擎优化看一下 pacing 流失速的成因#xff1a;
一段时间收不到 ack#xff0c;丢了 ack 自时钟#xff0c;cwnd 将耗尽#xff0c;bbr 虽有 cwnd_gain(上图没有表现)#xff0c;但在该 cwnd_gain 下不依赖 ack 持续坚持发送多久取决于 cwnd_gain 的数值。
bbr 失速的后果在于…看一下 pacing 流失速的成因
一段时间收不到 ack丢了 ack 自时钟cwnd 将耗尽bbr 虽有 cwnd_gain(上图没有表现)但在该 cwnd_gain 下不依赖 ack 持续坚持发送多久取决于 cwnd_gain 的数值。
bbr 失速的后果在于它是 pacing 流即使收到了迟到但正常的 acksender 也无法 burst 发送失速期间挤压的数据bbr 依然按照 pacing_gain * max-win-filtered bw 生成 pacing rate
考虑到现网环境中 delayed ack聚合 ackack 丢失lro/gro 很常见bbr 引入 extra_cwnd 作为 cwnd 的动态补偿缓解失速问题bbr pacing 流理论上耗尽 cwnd 时仍有 extra_cwnd 可作为继续发送的配额
这种动态自适应解决了盲目静态增加 cwnd_gain 削弱限制 inflight 初衷带来 shallow buffer 下的高丢包问题。
问题是如何在理论上失速的那一刻知道未来的 extra_cwnd这是在预测未来。常规的方法是 “用历史预测未来”无论保持一个 round-win-filter 还是移动指数平均(EWMA)均可用曾经的 extra_cwnd 经过运算得到当前 extra_cwnd即 cwnd cwnd extra_cwnd。
这似乎是解决失速问题的唯一方式。
为什么收到迟到但正常的 ack 后立即执行 probe up 为什么不行呢如图所示
bbr 是精确调制的 pacing 流除非有空闲带宽资源出让probe up 的结果无论理论上还是实际中都不好。理论上迟到但正常的 ack 是下行链路的独立问题如果当前记忆中稳定的 bw 恰好合适上行链路 probe up 行为会造成 queuing接下来的 drain to target 将回滚掉 probe up 的结果相当于 probe up 做无用功在现实的多流共存场景probe up 行为一定会挤占些 bw 出来伤害公平性。
ack 是 TCP(and QUIC) 本身属性它的行为不应作为 bbr 状态机转换的驱动因素但路径属性的变化却可以比如 minrtt 改变后就适合立即进行 probe up 下面的内容为独立但相关的新内容。
无论 extra_cwnd or 是否检测到更小的 rtt 后立即 probe up均涉及启发判断是否准确无论过估的 extra_cwnd 还是在不该 probe up 时 probe up误判代价均是丢包增加。而提高判断的准确性需要更多的 “微观知识”这意味着算法需要捕捉更多的细节。
比如算法是否能捕捉下面的细节呢
聚合 ack 典型的模式(更陡峭些但图示为了表达意思缓和了)显然这种情况下要在一个更长的周期计算 extra_cwndrtt 变化快但不必频繁 probe up。问题是如何精确捕捉到这种 “模式”TCP 自身并没有甄别出这种模式所需的 “知识”。
另一方面确实只需要遵守一个大原则而不是精确刻画微观。就像足球每一场比赛从每一个细节上看是完全随机的但结果很大程度上却是可预测的这是既精确又模糊的艺术。但若仅考虑统计特征显然这些微观细节必然会被湮没这本身就是一对矛盾。
在 rtt 测量方法 中我展示的方法或许能解决这个问题这更像一种基于神经网络的机器学习方法模型训练好了链路画像自然就明确了至于微观细节也就无需再关注就像 chatgpt 的 “原理”没人知道 why但事实上它就是能写出像人写的文本这本事是涌现出来的。
皮鞋没有蹬上露着白袜子。
浙江温州皮鞋湿下雨进水不会胖。
