tcp inflight 守恒拥塞控制(tcp_ccr)的正确性

每个人都知道报文不在 buffer 排队的情况是最佳的,bbr 企图让流保持在这个最佳状态,但没人能把握到刚刚好。

流独占带宽,它可自主排空 buffer,并很容易观察和确认这结果,这也是 bbr 的假设,所以我说 bbr 是一个基于单流模型的算法,若多流共享带宽,它们需要一起退 buffer 才能同时到达最佳状态,先不说统计复用网络中这种情况绝对不可能发生,单说这些流互补沟通,互不信任就够了,多流场景,最佳状态是个不稳定平衡。

我提出 inflight 守恒并非空穴来风,因为这是保持稳定状态的基石,问题是需要一个算法将状态自动收敛到这个状态,这就是现实最优解。

把追求的目标改变一下,不再分别将 maxbw 和 minrtt 视作最优,而将它们结合,将 max(bw / rtt) 视作最优就完事了,这是一个稳定的收敛点。bw / rtt 明确表达出 "大的 bw 可能需要更大 rtt 来兑换" 的意思,在整体效能看来,这种大 bw 得不偿失,并不值得追求。bbr 的问题在于 maxbw 并非总在 minrtt 的状态获得,它们之间的 gap 越大,计算偏差越大,这就是我将 bbr 看作用大开合换吞吐的原因。

将 bw 与 rtt 做除法,"尽可能小的 rtt 同时获得尽可能大的 bw" 就是最优,最优不绝对,而是当前状态下的最优,它是相对解:

为了展示它的正确性,简单推导一下它的收敛性就能看到,无论是效率还是公平,全部包含在 max(bw / rtt) 这个状态中。

设流 1,流 2 共享带宽 b,流 1 所占 buffer 为 x,流 2 所占 buffer 为 q,那么流 1 获得的带宽为 b ∗ x x + q b*\dfrac{x}{x+q} b∗x+qx ,而当前的排队时延为 x + q b \dfrac{x+q}{b} bx+q ,流 1 的排队效能为:
E = b ∗ x x + q x + q b = b 2 ∗ x ( x + q ) 2 E=\dfrac{\dfrac{b*x}{x+q}}{\dfrac{x+q}{b}}=\dfrac{b^2*x}{(x+q)^2} E=bx+qx+qb∗x=(x+q)2b2∗x

求解 E 的最大值:

只有平分 buffer 才彼此都高效。在我的这个算法中,inflight = bw_when_max(bw / rtt) * minrtt + ...,之所以用 minrtt 而不是当前 rtt,minrtt 用来算 inflight 时保证平分尽可能小的 buffer。排队时延大家都一样,公平均分小 buffer 而不是大 buffer,避免一损俱损。

显然我简化了某些事,正常的式子应该算总时延,而不仅仅是排队时延的效能:
E = b ∗ x x + q R + x + q b E=\dfrac{\dfrac{b*x}{x+q}}{R+\dfrac{x+q}{b}} E=R+bx+qx+qb∗x

其中 R 为传播时延,该式子表明,inflight 守恒算法在数据中心更有用。如果对待广域网,R 作用更大,计算结果节能偏离均分稳定点更多,但它依然是收敛点,只是开合幅度更大些罢了,观感就是震荡稍微频繁。

接下来看 inflight 公式的余项 (minrtt / (rtt * bw)) * beta,这里面有两个负反馈,其中 bw 负反馈只为提高收敛过程的公平性(就算没有它,也是会收敛,只是慢),而 minrtt / rtt 这个项显然还需要一个参数,该参数的目标是:

如果 minrtt 增加导致主项 bw * minrtt 增加,那么增加的幅度刚好不大于余项 (minrtt / (rtt * bw)) * beta 减小的幅度,所以分母 rtt 要做成一个下凸的函数,比如 rtt^p,调 p(但后续值得再商榷)。

于是乎:

  • 在 winmax 中追踪 alpha rounds 的 bw / rtt,将其 bw 记为 b;
  • 在 winmin 中追踪 k*alpha rounds 的 rtt,记为 minrtt;
  • 保持 inflight = b * minrtt + (minrtt / (rtt^p * bw)) * beta。

效果是:

  • sender 测量 e = delivery rate / srtt 跟踪最大值;
  • sender 测量跟踪 minrtt,以主动尽可能少排队;
  • sender 以最大 e 当时的 delivery rate 与 minrtt 做 bdp,获得 inflight 主项;
  • 当 minrtt 膨胀时,余项 (minrtt / (rtt^p * bw)) * beta 通过自损将总 inflight 拉回;
  • 在理论基础上,所有共享流均分带宽,且不 "太严重" 排队;
  • 在理论基础上,所有流都要排一些报文在 buffer,用来 probe or drain。

虽然在逐渐复杂化,但千万不要偏离宗旨。为啥主项用 max(bw / rtt) 时的 bw 而不是 maxbw,因为整个式子在追踪的是 "最佳效能",把代价算进去了,而不是最佳带宽;为啥又要用 minrtt 而不是当前 srtt,因为要主动避免排队,排队是要代价换收益且得不偿失,要坚决避免;那为啥余项越来越复杂,这也是没办法,但它显然不会太复杂,我都是照着 cubic 做的,因为 cubic 负反馈就很好。

本质上,所有流对探测到的结果都要有共识,这是拥塞控制以及提高带宽利用率的根本,bbr 显然做不到这一点。

bbr 无法识别自己探测到带宽是空闲带宽还是从共享流那里挤出来的带宽,每条流都这样,就只能挤来挤去。但即便是老掉牙的 reno/cubic,都比 bbr 对现象有共识。

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

相关推荐
EasyNVR17 分钟前
国标GB28181视频监控平台EasyCVR保驾护航休闲娱乐“九小场所”安全运营
网络·安全
Ai野生菌28 分钟前
工具介绍 | SafeLLMDeploy教程来了 保护本地LLM安全部署
网络·人工智能·安全·大模型·llm
melck1 小时前
liunx日志查询常用命令总结
java·服务器·网络
【云轩】2 小时前
《混沌钟的RISC-V指令集重构》
网络·安全
EasyGBS2 小时前
视频设备轨迹回放平台EasyCVR打造视频智能融合新平台,驱动智慧机场迈向数字新时代
网络·人工智能·安全·音视频
EasyGBS3 小时前
视频设备轨迹回放平台EasyCVR综合智能化,搭建运动场体育赛事直播方案
网络·安全·音视频
低头不见5 小时前
tcp的粘包拆包问题,如何解决?
网络·网络协议·tcp/ip
SKYDROID云卓小助手6 小时前
三轴云台之相机技术篇
运维·服务器·网络·数码相机·音视频