提高 IDC 网络带宽利用率
提高带宽利用率和拥塞控制有很多部分是重叠的。在确保拥塞不发生的前提下提高带宽利用率是拥塞控制的目标之一。
于是，设计一个 “高带宽利用率的拥塞控制算法” 就是一件高尚的事。BBR 就声称为了提高带宽利用率而生。现实中真的需要这样吗？
对于 IDC 网络这种知根知底相对确定的场景。反而可以换一个方向思考：
- 与其提高单一算法的带宽利用率，不如设计一个退避算法，检测到背景流即退避。将优先级低但又持续的业务流量映射到该算法。
非常类似 ledbat 和 tcp lp(Low Priority) 算法，不争抢，只捡漏。
如此，两类流量互补，便可以实现拥塞控制的两个基本全局目标：
- 减少全局拥塞丢包。
- 减少全局带宽浪费。
二者都提高了带宽利用率。归根结底就是将业务流调度到算法的问题。当丢包足够低，带宽利用率足够高，仍然不满足流量需求，只能扩容。
还有一个更有意思的算法，Aeolus：
https://conferences.sigcomm.org/events/apnet2020/material/PPT/aeolus-sigcomm2020_shuihai.pdf
Aeolus 旨在解决 PCC 面临的下列问题：
- 初始化传输时没有 pacing rate 可供参考。
- 初始化传输时需要一个额外 RTT 获取 credit。
Aeolus 巧妙利用了 ECN 交换机 “丢 Non-ECT 包而放行 ECT 包” 的特性：
- 第一个 RTT 的包携带 Non-ECT ，线速发送，此后的包携带 ECT，以实际情况发送。
- 若将发生拥塞，交换机会丢掉 Non-ECT 包，对已经建连的 ECT 流无影响，丢包将在下一个 RTT 重传。
- 若未发生拥塞，Non-ECT 包与 ECT 包均通过，对于大多数只需要 1 个 RTT 就完成的事务，收益甚大。
对于第一个 RTT 的包，这也是一种退避互补的算法：你来了就把带宽让给你，你不来我就用。
Aeolus 之所以巧妙，来自于其研发团队对一个事实的深入调研：
- 随着 IDC 带宽的持续增加，RTT 不变的情况下，每个 RTT 传输的数据量持续增加，越来越多的事务将在越来越少的 RTT 内完成。
虽然 Aeolus 针对 PCC，但该思想可用于任何传输协议，甚至 TCP。对 PCC，线速传输第 1st RTT 的收益在于：
- 赌赢了即结束，完全受益。
- 赌输了，丢包挪到下一个 RTT 重传且不影响 scheduled 包，与不使用 Aeolus 相比无区别。
这个策略非常高尚。
通过下列命令可对任意数据包设置 ECT，CE，以学 Aeolus 的样子：
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x00/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x01/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x02/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x03/0x03
当然，也可以修改 DCTCP 算法。改法不一而足。
Aeolus 的思路很巧妙，但却并不一定非要在第一个 RTT 内 clear ECT，启用 ECT 后，在 “任何觉得丢包优于 set CE“ 的时候，均可以 clear ECT。可以统计丢包率，丢包率大于一定阈值时，让交换机丢包而不是自己控制更能缓解拥塞。
我本想写一个 Netfilter 模块去 match nf_conntrack 的 account 字段，将一个 TCP 连接的前 n 个包的 ECT 标志 clear 掉，想到上述这段话后，就改成 stap -g 了，抓住 sock 之后，更精细判断丢包率以及别的指标，权衡要不要 clear ECT。
在 IDC 网络，ECN 机制可以非常简单地辅助区分服务，达到流量分类的目的，在队列达到一定阈值时，丢 Non-ECT 包而放行 ECT 包，缓解拥塞。问题就转换成为哪些包 set ECT 了。
IDC 网络拥塞控制要换个思路，不能一味追求端到端算法的精妙，而要充分利用可以利用的一切基础设施提供的信息，比如用额外的流量补充带宽的浪费，又比如 ECN。周日起得早，买蟹前，写点思考。
浙江温州皮鞋湿，下雨进水不会胖。