TCP 漕河泾算法(tcp_caohejing)

Posted 2022-11-26 dog250

题目没意义，要说意义，大致类似于 Vegas，Reno，Tahoe，Westwood，地名。

周三傍晚发一则朋友圈：

总之，名字就是个名字，跟 tcp_vegas，tcp_reno，tcp_tahoe 学的。

模拟高速公路开车，见机行事。总体设计很简单，传输系统在 up 和 down 两个 state 间转换：

• 如果 up 状态测得实际 delivery rate 增益小于 a%，转为 down，gain < 1。
• 如果 down 状态测得实际 delivery rate 损失大于 b%，转为 up，gain > 1。

例如，125% 增益下，delivery rate 增量小于 5% 就以 75% 降速(也可连续 2 次，3 次小于 5% 再降速增加鲁棒性)，一旦降速，delivery rate 肯定降低，降低率大于一定阈值，再改为 125% 增益加速。简单讲就是漫踱步。

Caohejing 算法把 BBR 的固定状态机改成视测量增益而动。 同样挤占力度，带宽越大，加速比越小，因此大流总会降速，小流正好向上，直到变成大流，算法在异步状态下轮作属大概率事件。此即 “微收敛”， 预期公平性非常棒，事实也确实很棒。

也可使用 AIMD，加速用加法，减速用乘法，取消固定收敛时刻，在 up 态，pacing 加法递增，down 态乘法递减，同样观测 delivery rate 增量，也属高尚。

先放一个表达大意的代码：GitHub - marywangran/tcp-caohejing: TCP 漕河泾算法

基本就是 Vegas 的变体，在丢包前开始收敛。但还是有大不同。

Vegas 根据 RTT 信号收敛，而 Caohejing 根据实测带宽收敛，哪个更靠谱？

Vegas 比 Caohejing 更复杂，但不能说 Vegas 一定比 Caohejing 先进。各种测量，计算的背后是各种不切实际的假设，把理想假设去掉后，就只剩 delivery rate 了。

事情总向着简单，如手动挡和自动挡汽车，讲速率的时候，谁还提什么操控。

谈谈丢包和重传。

对 Caohejing 算法，拥塞丢包可以自动被发现，因为采集带宽肯定低了，速率也就降下来了，但这里问题来了，是保持简单方式统一处理，还是单独用数据包守恒处理丢包？若后者，显然不美，又回老路，但选择前者，又会被诟病重传率高。

或许高重传率就是高带宽利用率必须付出的代价。高重传率最终会落实到碳排放，但由于传输效率低导致信息延时到达，消耗的成本将造成同等量级碳排放，一切皆守恒。

端到端协议，获取链路信息需要代价，换句话说，带宽探测就需要多发数据，采集反馈，而此行为的风险就是丢包。

so what？

本来我忍不住在 tcp_caohejing_cong_control 函数里加上 if (rs->losses > 0) 判断的，然后按照数据包守恒原则处理丢包，但放弃了。

我特意在代码里加了 conservation 参数，可通过下面命令关闭：

echo 0 >/sys/module/tcp_caohejing/parameters/conservation

关闭后意味着让算法根据 delivery rate 自适应收敛，这是高尚的。

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