多路径 TCP 调度的另一面

参考前面的文章 一个原教旨的多路径 TCP 和 MP-BBR 公平性推演，一直都破而不立，不能光说怎样不好，还得说说现状情况下，该如何是好。

如果 receiver 乱序重排的能力有限(拜 TCP 所赐)，如果非要在多路径上传输 TCP，如果不考虑公平性，单单如何提高吞吐确实难，要找出来原因, 才能彻底解决它，得先分析问题。

设一条 TCP 连接存在两条子路径(subflow)：

• 快路径(Path1)：带宽 B1，单向时延 D1；
• 慢路径(Path2)：带宽 B2，单向时延 D2，且 B1 ≥ B2, D1 ≤ D2。

发送策略：

• 固定间隔 Round-Robin：每间隔 T 时间，轮流在 Path1 和 Path2 上各发送 1 个包；
• 单快路径(Path1 Only)：所有数据仅通过 Path1 发送，间隔 T 时间发送 1 个包。

假设：

• 所有数据包大小均为 L 字节；
• 接收端需按序重组数据，乱序包会导致阻塞。

分析 Round-Robin 吞吐量：

• 发送速率
  • Round-Robin 策略下：
    • 每 2T 时间发送 2 个包，Path1 和 Path2 各 1 个；
    • 平均发送速率：$\frac{2L}{2T}=\frac{L}{T}$。
  • 路径带宽限制
    • Path1 的带宽 B1 满足：$\frac{L}{T}\le B_1$；
    • Path2 的带宽 B2 需满足：$\frac{L}{T}\le B_2$；
    • 由于 B1 ≥ B2，若 $\frac{L}{T}>B_2$，Path2 会丢包，因此最大稳定发送速率需满足：$\frac{L}{T}\le B_2$ ⇒ $T\ge \frac{L}{B_2}$，即 T 不能太小，否则慢路径无法及时传输。
• 接收端乱序阻塞
  • 数据包到达时间
    • Path1 的包到达时间：D1 + k⋅2T，k 为轮次；
    • Path2 的包到达时间：D2+k⋅2T
  • 乱序条件
    • 若 D2 + k⋅2T > D1 + (k + 1)⋅2T，即 D2 − D1 > 2T，则 Path2 会阻塞 Path1，快路径要等慢路径。
  • 有效吞吐量
    • 由于乱序阻塞，系统吞吐量受限于慢路径的到达速率，慢路径形成漏桶短板；
    • 每 2T 时间可交付 2 个包，但实际受 D2 限制，因此 ${\mathrm{Goodput}}_{RR}=\frac{2L}{2T+\max (0,D_2-D_1-2T)}$，若 D2−D1>2T，则吞吐量进一步下降。

再分析单快路径的吞吐量：

• 发送速率：
  • 每 T 时间发送 1 个包，速率 $\frac{L}{T}\le B_1$。
• 无乱序问题，所有包按顺序到达，接收端无需等待。
• 有效吞吐量：${\mathrm{Goodput}}_{Single}=\frac{L}{T}$

效率对比的结论非常明确，${\mathrm{Goodput}}_{Single}\ge \mathrm{Goodpu}{\mathrm{t}}_{\mathrm{RR}}$，当且仅当 Path1 与 Path2 效率相同时取等号，两条路径差异越大，吞吐下降越明显，这就是拖后腿。

力气小的经理和力气大的工人一起扛砖头，不如让力气大的自己去扛，两人的协调性成本太大，正与 TCP 乱序重组协调性成本太大一致。怎么办？好办！

让力气小的经理自己去搬他自己的砖，不要和力气大的工人协调。换到 TCP，还是老方法论，横竖一颠倒，转换一个视角，将空洞留在 sender 而不是 receiver。

怕在 receiver 处快路径等慢路径，那就慢路径笨鸟先飞，先到了等快路径即可，落实到具体操作也简单：

• 在 sender 处，快路径从发送队列头部正序发送，慢路径从发送队列尾部反序发送(最后我再解释为什么)，它们处理各自的丢包重传，慢路径直到和快路径 gap 小于阈值 $K=f(\mathrm{RTT})$(亦可为一个经验值常量) 后停止发送，推动下一个窗口。

这很好解释，协调性不一致会付出成本时，解除协调性耦合即可，耦合就会导致木桶效应，各干各的更合适。

直观上理解，如果我们有 4GB 的文件，一快一慢两条路径，快路径依次发送 0，1，2，3，…，慢路径依次发送 4G - 1，4G - 2，4G - 3，…，假设它们在 X 字节处相遇，设快路径平均吞吐为 B，总传输时间将会从 $\frac{4GB}{B}$下降到 $\frac{X}{B}$。

至于 receiver 缓冲区问题，那不是问题，由于已经完全解耦了两个路径的传输，也就成了两个独立的流，各自维护接收缓冲区，最后将它们拼接在一起也行。

另一个问题，看起来以上策略仅对下载大块数据有效，对强调时延稳定性的业务不好使，其实也未必，问题的关键在于业务能容忍多大的 buffer 时延，只要该 buffer 大于多路径最大 BDP，就能应用此方案，只是把上面的 4GB 换成了该 BDP + a。

总之，总要拿个什么来交换成本，以获得收益，越复杂越不划算。举个例子，对于获得肉类的需求而言，驯养食肉动物的转化率远没有食草动物高，因为食肉动物处在食物链更上的生态位，它更复杂，也更不划算，复杂性本身就是成本的组分。

Linux Kernel 自带的 MPTCP 调度算法跟我这个看起来类似，但它没有反着发，而是再慢路径直接发送 $\mathrm{seq}=\mathrm{SE}{\mathrm{Q}}_{\mathrm{curr}}+\alpha \cdot {\mathrm{BDP}}_f,其中\alpha =\frac{{\mathrm{RTT}}_s}{{\mathrm{RTT}}_f}$，思路依然是让慢路径序列号往后错，但它仍倾向于精确拼接，企图两边正好配合，但这是不可能的，慢路径非常容易与快路径耦合，一旦被快路径赶上，Seq 在快慢路径交错传输和重传，就会引发持续性 HoL 抖动，而这个错开量 $\alpha \cdot {\mathrm{BDP}}_f$ 由于 RTT 和吞吐率本身的测量误差几乎不可能太准确，也就难怪效果不好了。

之所以倒着发，为了保证慢路径后段一定与快路径解耦(确保后边的数据已经完全准备好)，即使 gap 算大了，仅靠快路径自身也能很快接上慢路径已经准备好的数据，而如果 gap 算小了，则影响更小，换句话说，即使抖动也是一瞬间，且快路径主导补洞。

当然，TCP 本身并不支持倒序发送，那这个就不是 TCP 了。既然不是 TCP，索性就多做一点，连 RTT 测量问题也给解了。学学 Swift，到处打标时间戳就很高尚。

其实要更精确地测量两条路径的 RTT 差异非常容易，无论哪条路径收到一份数据需要确认时，将确认报文同时发到多条路径上，sender 只需要比较两个确认报文的时间差，并乘以快路径的吞吐即可获得偏移量，两个问题遗留：

• 这可能只是反向单向时间戳之差，而正向时间戳更需要，让 receiver 采集数据包时间戳信息并回送回来；
• 确认报文双发会不好浪费带宽，会，但并不严重，且这是小包加速的典型套路。

既然重新做协议，不要尽抄 TCP 就是了，但要尽量保持简单。

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