漫话拥塞控制：Capacity-Seeking 与 QoE

IETF117 CCWG 大会链接：IETF117-CCWG-20230725-2200，更详细信息以及讨论：https://github.com/ietf-wg-ccwg/wg-materials/tree/main/ietf117。

短评：

1. 传统拥塞控制算法几乎都在不断冒险上探更多带宽，并在过程中忍受丢包，但真的需要更多带宽吗？
2. 传统拥塞控制算法对公平性有严格要求，但真的需要在各个流之间均分带宽吗？
3. 传统拥塞控制肇始于文件传输，那么今天互联网流量中，文件传输到底占据多大比重？
4. …

当谈到拥塞控制时，几乎所有拥塞控制算法都有一个默认假设：保证公平性的前提下占据更多带宽。

这也是 Capacity-Seeking 算法的基础。

但这个默认假设在当今的流量背景下要重新审视其必要性：

• 当今带宽资源逐渐丰盈，而公平性在资源受限场景意义更大(贫穷才需要公平，所谓不患寡而患不均)。
• 当今生产性流量越来越在乎 QoE，类似直播流量并不需要尽可能大的带宽，但需要保持低卡顿。
• 无论从资源利用率还是公平性考虑，拥塞控制都需要重评估。

IETF117 CCWG 大会 上，有人提到 “拥塞控制” 这个词在当代容易引起误解，应换成类似速率优化器等其它词。算法应以避免饥饿为目标，而不应执着专注于几个连接获得完全公平的带宽，也不应执着于尽可能获得更大的带宽。确实，在大文件传输占比逐步下降的过程中，拥塞控制应该转移到 BoE-Based。

我的意思是，当然，即使采用了 QoE-Based 算法，以流媒体传输为例，人人都想看最高清，仍免不了 application 自行 probe up，试图找到更多带宽以增强 QoE，但和单纯 Capacity-Seeking 相比，去除了所有流公平均分带宽的拥塞控制约束，这是 QoE-Based 算法最大的意义，让所有流在自组织意义上去自行公平。这就好比高速公路上的汽车，车技好有急事的开得快些，新手或更注重安全距离的开得慢些，虽然大家没有公平共享车道资源，但总体上大家都很满意，这就是 QoE，主打一个主观感受，而非客观约束。

下面简单评价传统的和新式的拥塞控制算法。

10Gbps 剩余带宽，一条直播流只需 1Gbps，按传统拥塞控制观点，这是 application-limited 流，拥塞控制无用武之地，但在 cubic 治下，若不小心丢了一个包，inflight 依然会降 30%，在 bbr 治下，为支持 bbr 状态机，隔段时间 inflight 就主动下降，这无疑会影响 QoE。对于这条对带宽需求不大的流而言，掣肘的不是网络实际状况，而是拥塞控制算法。
对毫无 QoE 的 Capacity-Seeking 大文件传输，固定大小文件在逐渐增长的带宽看来越来越小。1Gbps 带宽下花 10 分钟下载完的文件在 10Gbps 带宽下只需要 1 分钟，没有对网络的总流量产生影响，人畜无害。

但对生产性流量，比如直播，编码流量随网络有效带宽变化而变化，而提供有效带宽的正是拥塞控制算法。以 bbr 为例，如果 bbr 高估有效带宽，直接结果是更多流量被注入网络，由于算法误判增加网络总流量，这是预期之外的。

传统算法对带宽高估，相比文件传输仅引入重传流量，生产性流量会直接引入额外正常流量，丢包重传流量可通过 RED 等大大缓解，但额外生产性流量却无法缓解，因为它是直接对算法结果的反馈。

生产性流量严重依赖传统算法的带宽预估结果，但传统算法由于可利用的信息量非常有限，对带宽的误估是一定的，传统算法对拥塞的反馈周期是 RTT 级，额外流量可在至多若干 RTT 内收敛，但生产性流量的反馈周期却长很多，至少要覆盖抗抖 buffer，额外注入的流量对网络整体拥塞的影响因此严重得多。

与基于传统算法的认知相反，生产性流量倾向于基于 QoE 指标指导数据生产速率，而不是基于传统算法的丢包，延时，抖动等指标，同样的，生产性流量关注 QoE 公平，而非带宽公平，大家都获得不错的体验，不必非要获得相同的带宽。
另一方面，IETF117 CCWG 大会 “Guidelines for Internet Congestion Control at Endpoints” 这一趴也提到，网络拥塞是统计复用网络上必然会发生的事件，没什么大不了的，而持续的网络拥塞却是应该避免的，换句话说，瞬时拥塞是常态，持续拥塞是灾难，这两件事应该分别被处理，然而一直以来的传统算法都没将这两件事分别对待。

这给出一个看起来矛盾但有用的启示，当拥塞发生时，如何判定它是瞬时的还是持续的，瞬时拥塞持续多久才需进行反应，当拥塞真正持续时，减少 “这次” 的发送量优于减少 “总” 发送量。但如果在相对较短但又不是瞬时的 “一小段时间” 时间内在减少了发送量后仍无法改善 QoE，说明这次拥塞事件事不关己，但拥塞控制是全局动作，所以又不能高高挂起，只需维持小发送量，不必继续无效收敛。

评论区谈到措辞问题，当试图用 “带宽优化” 替代 “拥塞控制” 时，在心理上更容易让人走向自私，谈到 “优化” 这个词，都是自私的，但拥塞控制却可以让人在心理上保持收敛。特别是 QoE-Based 算法，更要 “自觉” 进行某种控制，而不是一味地盲目优化。类比文处我举的高速公路的例子，QoE-Based 算法缺乏内在的全局收敛机制，结局并非某种资源的公平分配，而是大家感觉都还行，显然更不适合使用 “优化” 这个词，就好像高速公路上不提倡变道超车一样，但也并不阻止。

至于文件传输，也许可以将它纳入 QoE 范畴，比如最简单的限速措施，现代网络带宽已足够大，凭什么让贪婪的 Capacity-Seeking 算法独享。

最后说说重传，现代网络丢包很罕见，如果 QoE-Based 算法生效，重传亦可激进，因为拥塞丢包也罕见。
当然，对于传统算法领域内部，一叶以障目，传统算法就是全部。

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