BBR 对 buffer 的侵占

这篇具有很好参考价值的文章主要介绍了BBR 对 buffer 的侵占。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

BBR 声称 anti-bufferbloat 且内置状态机有主动 drain,所以题目中使用了 “侵占”,也可以用 “吞占”。

BBR ProbeBW ProbeUP 阶段以 1.25x 的增益加速,退出条件:inflight >= 1.25 * maxbw * minrtt。

BBR ProbeBW Drain 阶段以 0.75x 的增益降速。

单流场景下,当 bw full,即使 buffer 排队 maxbw 亦不再增加,接下来的 Drain 阶段可将 queue 完全退回。但与多条异步 Loss-based 流共存场景,当 bw full,即使 buffer 排队,ProbeUP 总能挤出一点带宽(带宽占比越大,加速比越小),maxbw 增量 < 25%,而异步流 base queue delay 几乎不变,BBR 测得 BDP 会随 ProbeUP 一点点增加,幸好有个 ProbeRTT 可以主动回退 queuing,但要在 10s 之后。

用固定 10s 控制 buffer 侵占强度以及公平性不太合理,但也只能靠这个。要么就调参?10s -> 5s?无论怎样,BBR 的侵占行为是固有的。

在现实中我们并没有观测到上述怪象,多亏 BBR 还有个 cwnd 作为 secondary controller。如果 cwnd 真如其论文所述,是一个 secondary controller,只需要在 inflight >= cwnd_gain * BDP 时切回 Reno 执行 AIMD 即可,但有趣的是, 与 Loss-based 流共存时,最终 inflight 总是 >= cwnd_gain * BDP,这算是劣币驱良币还是被大融合同化,最终的世界还是属于 AIMD。

BBRv2 差不多就是这意思,融入 AIMD 对 Loss 的反应,但还保留着一张脸。BBRv2 本文不谈,先从 cwnd the secondary controller 开始。

BBR 作为 rate-based cc,如果每一次测量都准确,BBR 按照 delivery rate 测量值对 pacing rate 进行调整即可,在 BBR 状态机约束下按计算的 pacing rate 一直发下去,完全不必引入 cwnd 作为 secondary controller。

但现实中,每次测量滞后至少一个 RTT,时间不可倒流,未来不可预测,BBR 不得不为未来保留 buffer,这是固有的。本文描述 BBR 和 Loss-based 流共存时 cwnd 的意义。

因为 Loss-based 流导致 RTT baseline 可任意改变,若不限制 BBR cwnd,BBR 会被带偏。BBR 只根据测量值被动收敛,不会主动降速,而 ProbeUP 总能挤出带宽,BBR 便陷入和 Loss-based 流的军备竞赛,最终在 Loss-based 流一次次收缩后挤占整个 buffer,这和 BBR 的设计背道而驰。

BBR 引入 cwnd 作为 secondary controller 的动机可能是承认设计上不完备(这是缺陷,BBR 流之间的收敛全靠抢加速比)后的兜底。问题是,cwnd 多大合适,足够大,又不至于太大,足够小,又不至于太小。
cwnd 在传统 cc 意义上等同于 BDP,而 BDP 用 inflight 考量,考虑下图展示的场景:
BBR 对 buffer 的侵占

Loss-based 流的固有排队场景,设 p = b / B,BBR 各测量量如下:

maxbw = (1 - p) * C (发生在 ProbeUP 阶段)

minrtt = p * B / C + R

BDP = (1 - p) * C * (p * B / C + R)

另一方面,ProbeUP 倾向于超速发送探测来挤占带宽,此时的 max-inflight 是 B * (1 - p) + R * maxbw。
设:

BDP = f§ = (1 - p) * C * (p * B / C + R)

max-inflight = g§ = B * (1 - p) + R * (1 - p) *C

B,C,R 为常数,p 不等于 1 时, 化简上式:

f§ 正比于 F§ = C * (p * B / C + R) = p * B + R * C

g§ 正比于 G§ = B + R * C

由于 p 只能在区间 (0, 1) 无限接近 1,因此 F§ < G§。

这意味着 ProbeUP 时的 inflight 被 BDP 限制,BBR 为 BDP 乘以一个 cwnd_gain 以摆脱 cwnd-limited,该值一定要大于 ProbeUP 的 pacing_gain 来承载对未来的过估预测(简单波动原理,ProbeUP gain 的效果一定要在一个 RTT 后才能被 sender 感知,在此之前 sender 根据 maxbw * minrtt 计算的 BDP 体现不出 gain 效果,因此 BDP 需要至少不小于 pacing_gain 的同步增益系数),但又不能太大以避免对 Loss-based 流的过度侵占。

cwnd_gain = g

cwnd = g * BDP 正比于 F’§ = g * F§

比较 F’§ 与 G§,当 F’§ < G§,属 cwnd-limited,F’§ >= G§,BBR 可执行正常逻辑,不受 cwnd 限制。

BBR 限定 cwnd_gain = 2,解释是:

Raising ProbeBW’s cwnd_gain to two allowed BBR to continue sending smoothly at the estimated delivery rate, even when ACKs are delayed by up to one RTT. This largely avoids stalls.

但这只是问题的一面,问题的另一面在当前 BBR 流以外,就是上文提到的那些。

我比较讨厌 BBR 论证的 “精确性”,但凡测量值,都是滞后的,当你测量到某值时,产生该值的瞬间已过去,用这个值预测未来,必须留 buffer。这是测不准的根本:
BBR 对 buffer 的侵占

本质上讲,在 co-existence 场景, RTT 测不准,delivery rate 也测不准。所以围绕精确测量的精确推导,都是瞎扯。明明是统计量,偏要算个精确值。

为什么 cwnd_gain 是 2,而不是 2.8,而不是 3,也不是 1.8,这个 2 只是一个 buffer 量,是一个要参数。问这个问题就像问交换机 buffer 要配多大一样,要用统计方法,而不是单流行为计算。

BBR 的精确计算,就像热力学发展之前,人们对测量温度的态度一样,企图通过测量每一个分子来计算温度。
回到上面关于 g 值的问题。设 cwnd = g * BDP = max-inflight,所以:

g * p = p

所以,当 p < 1 / g,cwnd-limited,p >= 1 / g,BBR 可正常 ProbeUP。因此 BBR 在 ProbeBW 状态 ProbeUP 阶段最多占据 1 / g 的 buffer,这有效保护了其它 Loss-based 流。

可见,g 越大,BBR 越倾向于占更多 buffer,ProbeUP 是 MI 过程,间隔 8 rounds 的 ProbeUP 比长 RTT Loss-based 流的 AIMD 周期短很多,由于 ProbeUP 几乎一定会挤占出带宽,Drain 不会起太大作用,BBR 在这种情况下更有侵占性。

相反的一面,g 越小,BBR 越低效,g 无限接近于 1 时,p 接近于 1,BBR 总是 cwnd-limited,失去 ProbeUP 的空间。
cwnd_gain = 2 意思是,BBR 流最多仅能使用 1 - 1 / g = 1 / 2 的 buffer。

如文初所述,BBR 没有主动降速机制,不响应外部信号(即使丢包也会记住此前的 maxbw),这意味着它无法识别 Loss-based 流数量,无论与 1 条还是 n 条 Loss-based 流共存,对于 BBR 单流而言,它都有能力侵占(注意这个用词) 1 / g 的 buffer,BBR 流之间的共存靠加速比收敛,但对和 Loss-based 流共存时的收敛无能为力。

因此 g 的值与 BBR 流的数量,与 Loss-based 流的数量,以及每条流的 RTT 均有关系,这是个根据场景可调的参数,不可能被 “Delayed and Stretched ACKs” 完全覆盖。类似的还有,pacing_gain = 1.25,2885 / 1000… 为什么是 10s 而不是 8s:

The RTprop filter window (10 seconds) is short enough to allow quick convergence if traffic levels or routes change, but long enough so that interactive applications (e.g., Web pages, remote procedure calls, video chunks) often have natural silences or low-rate periods within the window where the flow’s rate is low enough or long enough to drain its queue in the bottleneck.

这些都是经验值,而不是算出来的。不过以上引用的解释是不是意味着我不能将 RTprop filter window 从 10s 改到 5s 了?管他呢,BBR 已经漏了。

我说过用 E = maxbw / minrtt 来收敛,就能覆盖各种情况了。参见 拉弗曲线与 BBR 收敛点,更合理的 BBR。

所以,BBR 只是一个单流算法,BBR 假设 bw 不再增加且 RTT 开始增加时,即到达最佳点,但这只是自我视角,一旦背景流侵入,退出,Probe,BBR 的假设几乎全失效,完全被吊着走,除了 ECN,没有任何外部信号指示其收敛,BBRv2 好一些,响应丢包而限制 inflight_lo,但也只是稍微。

BBR 之所以看起来好,完全因为人们只关注吞吐,而高吞吐则来自 BBR 的大开合行为,maxbw-filter 维持 10 rounds,minrtt-filter 维持 10s,而 maxbw,minrtt 均是采集到即生效,大开合周期太久,以至于对背景流的感知能力及其差,BBR 敏感度可谓愚钝级。

论 co-existence 吞吐能力,BBR 只比你将 cwnd 单纯调大这种行为好一点点。此外,值得一提的是,Linux 4.9 以后的内核降低了每个人玩大开合的门槛,只要实现 cong_control 回调函数就可以 bypass 几乎所有 Linux TCP 拥塞状态机,只需在这个函数里写一句 cwnd = 1000000000000,仅以吞吐考量而不论代价,你的算法就差不了。

冷眼旁边后对 BBR 再也不是初测时那种认知了,甚至没了当初的态度。模型确实勾画出了带宽的正确利用方式,但也仅此而已,BBR 自身都没能正确使用带宽。BBR 在共存流场景表现非常糟糕,其自身并没有内置任何自适应收敛机制且不对外界信号进行即时反馈,只会遗忘,而遗忘需要时间。在不应该的场合,BBR 对丢包又反应过激,不过这个我准备单独讨论。总之,BBR 不是一个名副其实的好的算法。

浙江温州皮鞋湿,下雨进水不会胖。文章来源地址https://www.toymoban.com/news/detail-417921.html

到了这里,关于BBR 对 buffer 的侵占的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • udx大带宽大延迟网络与xquic bbr, tcp bbr实测比较

    quic在其白皮书中声称可以在大延迟大带宽网络中表现良好,为此我对比过目前xq,lsq,pq,tq几种实现,因为这些都是开源项目通过不断的折腾,向这方面研究的同学索取不同版本的实现进行实际测试。 经过,对不同国家的主机,到国内的实测总结出 其实quic说是在大代宽,高延迟

    2024年02月17日
    浏览(41)
  • 拼多多anti-token分析

    前言:拼多多charles抓包分析发现跟商品相关的请求头里都带了一个anti-token的字段且每次都不一样,那么下面的操作就从分析anti-token开始了 1.jadx反编译直接搜索 选中跟http相关的类对这个方法进行打印堆栈 结合堆栈方法调用的情况找到具体anti-token是由拦截器类f.a方法调用的

    2024年02月10日
    浏览(54)
  • hive anti join 的几种写法

    t_a 表的记录如下 c1 | :———— | a | b | c | 生成 SQL 如下: t_b 表的记录如下 c1 b m 生成 SQL 如下: 我们要在t_a 中出现,而不在 t_b中出现的记录。 结果需要为: c1 a c 写法1 — 使用not in 写法2 —使用 left join 关联上的去掉 这种写法不容易读懂。 注意 left join 中 b.c1 is null 不能谓

    2024年02月09日
    浏览(44)
  • CentOS 8开启bbr

    CentOS 8 默认内核版本为 4.18.x,内核版本高于4.9 就可以直接开启 BBR,所以CentOS 8 启用BBR非常简单不需要再去升级内核。 开启bbr 使代码生效 然后重启下系统。 3. 检查

    2024年02月07日
    浏览(33)
  • 当 BBR 面对时延抖动

    写在前面: 涉及启发式的策略一般倾向于设置 alpha,beta 参数,比如 Vegas: cwnd / basertt - cwnd / rtt alpha; cwnd ++ cwnd / basertt - cwnd / rtt beta; cwnd – 难点在于调参,每个环境都要调一组参数,费时良久。 就着一个实际的 RTT 抖动场景,一个新想法是按比例分配平滑 RTT 和瞬时 RTT 对当

    2023年04月10日
    浏览(36)
  • BBR 真的抗丢包吗?

    看 BBR 论文 展示的一幅猛图: 很多人惊讶于 BBR 竟然对丢包无感,稍微近看一点,BBR 只是在 20% 以内的丢包率下对丢包无感,更深入探究,会发现抗 20% 丢包率与 pacing_gain = 1.25 有关。 但这个图还是欺骗了绝大多数人。 注意横轴标度,loss rate = 1% 之前采用 10 倍标度,1% 往后采

    2024年02月01日
    浏览(38)
  • anti-virus scanning 杀毒软件 Oracle Home

      Oracle Database Cloud Schema Service - Version N/A and later Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later Oracle Cloud Infrastructure - Database Service - Version N/A and later Oracle Database Backup Service - Version N/A and later Oracle Database Cloud Exadata Service - Version N/A and later Information

    2024年02月12日
    浏览(46)
  • Linux系统开启服务器BBR加速教程

    BBR是Google提出的一种拥塞控制算法,目的是在网络拥塞时提高TCP性能,可以有效提高网络速度。下面是在Linux系统上开启BBR加速的教程: 1. 检查当前的内核版本是否支持BBR: ```bash uname -r ``` 如果版本号为4.9以上,则当前内核支持BBR。 2. 修改系统内核参数: ```bash echo \\\"net.cor

    2024年02月15日
    浏览(44)
  • Linux系统部署BBR服务器加速软件

       BBR简介:   BBR是谷歌的黑科技,也可以理解为用来加速网络的软件,如果服务器在海外,会发现丢包率很高,线路还会时断时续。所以,不用点黑科技,肯定是没办法使用。而BBR加速能充分利用网络带宽 BBR的作用就是尽量跑满带宽,并且尽量不要有排队的情况。BBR可

    2024年02月19日
    浏览(47)
  • 最新PDD批发Anti-Content参数逆向分析与算法还原

    【🏠作者主页】: 吴秋霖 【💼作者介绍】:擅长爬虫与JS加密逆向分析!Python领域优质创作者、CSDN博客专家、阿里云博客专家、华为云享专家。一路走来长期坚守并致力于Python与爬虫领域研究与开发工作! 【🌟作者推荐】:对爬虫领域以及JS逆向分析感兴趣的朋友可以关

    2024年04月16日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包