BBR 遭遇 CUBIC
BBR 动力学仅在纯 BBR 与模型匹配，否则需要各种技巧和其它算法共存，BBRv2 便是这种妥协。
本文着重说 BBR 之 ProbeRTT。
该状态有意思，它的收敛机制如此精致。以一大一小两流为例，大流指它侵入 buffer，足以影响 minrtt 采集：
- 大流进入 ProbeRTT，清让 buffer，大流小流同时采到 minrtt。
- 小流进入 ProbeRTT，采集到偏大 minrtt，待大流进入 ProbeRTT，两流同时采到 minrtt。
只要所有 BBR 流配置相同 ProbeRTT 窗口，收敛点就天然同步，就是 BBR 带宽/时间 图上向下凸起的那些小尖。
像高架桥面或铁轨上那些接缝，固定距离就要咯噔一下，BBR 对于一些流媒体也存在该问题，同步卡顿。随机化 ProbeBRR 窗口可解决，比如 5s～15s 内随机进入 ProbeRTT。
每条流 ProbeRTT 间隔随机，并不影响所有流依然在同一时间采到 minrtt，这是根本。
所有流采到 minrtt 那一刻开始，BBR 在 ProbeBW 状态收敛到公平，参见下文 “ProbeBW状态probe阶段BBR如何公平收敛” 一节：
The math behind dynamics of TCP BBR
走出理想，来到现实世界。
BBR 没有和 CUBIC 公平收敛的动力学，只能靠调参。
实践中发现与 CUBIC 共存，不抢 buffer，BBR 自己都立不稳，无法稳定维持状态机，此时带宽数据依然比 CUBIC 好，并非受益于 BBR 的模型，而是：
- BBR 可以憋住 10 rounds 的 maxbw 不退让。
- BBR 丢包状态依然试图稳住状态机并在恢复后 undo。
不过重传率也增加了，这已在透支资源维持状态机。至于 ProbeBW 中的 probe/drain，几乎完全乱套，因为 BDP 不再可信。
与 CUBIC 共存，ProbeRTT 将会给 BBR 带来厄运而不是机会，突然主动降低 inflight 给了其它流 buffer 依然未满的假象，等 BBR 退出 ProbeRTT 时，依然无法采集 minrtt，反而出让的带宽也让人给占了。
ProbeRTT 目标是采集 minrtt，当确认该目标无法达成，不再进 ProbeRTT 是良策，而不是将 4 inflight 改成 70%，后者依然无法采到 minrtt，又何必。
看起来有两个选择：
- 降低 minrtt 的期望，维持 CUBIC 状态下 midrtt 作为 minrtt。
- 依照 BBRv2 的做法，比例降低 inflight。
理想 BBR 的姿势很容易被现实的 buffer 打乱，它太依赖 pacing ，还是上文，看 “probe挤占导致的排队问题以及解法” 。
有 trick 可应对，长流有效。
在进入 ProbeRTT 前后分别测量 srtt 和 delivery rate，看结果是否有大改观，可区分 RTT 升高是否自己所为，若非自己所为，则记入链路画像。
若自己 ProbeRTT，RTT 依然居高不下，可判定自己未占 buffer，若一个窗口内采集到相仿的 minrtt，则对方同为 BBR，不进 ProbeRTT 概率减少，否则增加。每次进入 ProbeRTT 与否，全凭该概率决定，此举将 ProbeRTT 与 采集 minrtt 分离，不再依赖。
解释一下：
第一次 ProbeRTT 后，至少可保证自己 inflight 是 4(或者 10)，此时的递增 RTT 肯定是别人所为，下次ProbeRTT，若 RTT 还高，大概率可说明还是别人造成，因为按照 BBR 规则不会占 buffer，既然不是我所为，再降 inflight 也无法采集 minrtt，纯吃亏，也就不再进入这次 ProbeRTT。
minrtt 不必每次都通过 inflight = 4 获得，确认 buffer 不是自己所为，可继承最近相对可信的 minrtt，或取两次 10s 间最小 RTT，把别人造成的排队延时都算进去。
总之，要在连接中持续刻画一幅链路画像，它将越来越准确。
CUBIC， BBR，25 Gbps，50 us 链路，无丢包，1000 pkts buffer，5v5，看下效果：
调参概率 10 倍增益，本意是 BBR 在 150 秒后吊打 CUBIC。修改偏好可以维持公平，但不吊打显示不出区别。
本准备去南汇赶海听潮，虽没法和深圳盐田大小梅沙，大鹏南澳杨梅坑比，但至少也是个海…无奈小小明天有个考试，就去不成了，本想今晚在酒店调试这个，就在这大热天的下午折腾完了。这次不放代码，因为不能总放，连 stap poc 也不放了。昨晚有朋友提示，跟那些长篇大论后面贴一个公众号二维码的作者相比，和那些大厂高 P 相比，我就是个 SB，他们拿了我太多输出，我却依然显得怡然自得。我回味无穷，也非常感谢
BBR 遭遇 CUBIC相关推荐
- BBR/Vegas/CUBIC拥塞控制算法对比
文章目录 环境 结果统计 结果分析 总结 发生丢包时的反应 环境 基于本地通信,通过tcconfig设置丢包率,rtt和带宽上限. 测试程序阻塞发包. 结果统计 Vegas BBR CUBIC 不做任 ...
- Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现
Facebook的测试结果显示,COPA较于常用算法CUBIC及BBR v1存在一定优势,来看看具体表现. 文 / Nitin Garg 译 / Adrian Ng 原文 https://engine ...
- 从TCP拥塞本质看BBR算法及其收敛性(附CUBIC的改进/NCL机制)
本文试图给出一些与BBR算法相关但却是其之外的东西. 1.TCP拥塞的本质 注意,我并没有把题目定义成网络拥塞的本质,不然又要扯泊松到达和排队论了.事实上,TCP拥塞的本质要好理解的多!TCP拥塞绝大 ...
- BBR 会取代 CUBIC 吗?
先说结论:不会.还是那句话,TCP 拥塞控制的问题根本就不是技术问题,而是社会学问题. 先列举一些既证事实. 实验测量事实: BBR vs CUBIC,1 v 1,Buffer 小于一定阈值,BBR ...
- BBR到底好在哪里？
BBR到底好在哪里? 都说BBR好,特别是在长传场景,一试就知道,也有很多分析BBR细节的文章,但很少有在理论上详细对比BBR和传统Loss based CCA的,BBR到底好在哪里,周末例行写作,今 ...
- [译] Cilium：基于 BPF+EDT+FQ+BBR 更好地带宽网络管理
译者序 本文翻译自 KubeCon+CloudNativeCon Europe 2022 的一篇分享:Better Bandwidth Management with eBPF. 作者 Daniel ...
- 深夜聊聊Bufferbloat以及TCP BBR
这篇文章的写作动机来源于知乎上的一个问题,有人问既然Bufferbloat是个问题,为什么路由器的缓存还要设计那么大.起初,我也是觉得缓存越大越好,这个就像人们拼命比拼谁的电脑内存大一样,因为在一般人 ...
- Google's BBR拥塞控制算法如何对抗丢包
我不知道该怎么说.总之,便舍船,从口入,我看不到黄发垂髫并怡然自乐!我不会说什么,除了咒骂! 在BBR之前,存在着两种拥塞控制算法,基于丢包的和基于时延的,不管哪一种都是基于探测的,换 ...
- TCP BBR 短评
盯着 BBR 带宽吊打 CUBIC 时,要看它为此能力而付出的代价. BBR 在轻微丢包( < 1% )场景重传率比 CUBIC 高 6-10 倍,稍重到重丢包场景可超过 20 倍甚至上百倍,这 ...
最新文章
- Windows10下Python3做OpenGL的编程
- 微生态、生信和植物领域最新资讯合集，不看你就亏大啦！！！
- viewport实现html页面动态缩放/meta viewport/viewport
- oracle的本地安装和PUTTY+XMING远程连接安装和oracle翻页功能
- SOLID 原则的可靠指南
- 2.5D屏幕有什么好处？
- gerrit 数据迁移_gerrit importer 使用方法
- 【转】HBase架构解析
- SVN实现自动更新（Windows平台）
- 【cherry键盘白送】有人在云上送来一波双十一福利
- jsp银行排队叫号系统
- CoFlash 基本操作说明和Flash编程算法
- 调用百度地图API去掉地图左下角的百度LOGO方法
- 电子密码锁的设计(Verilog HDL实现)
- 微信 java抓取_【java】微信文章抓取
- 电视剧《乡村爱情2》之演员表（ZT）
- easyExcel中导入文件参数校验实现方案
- Camera知识问答
- 2006世界杯32强
- 考虑不同充电需求的电动汽车协调充电调度方法 提出了一种电动汽车（EV）的协调充电调度方法
热门文章