漫话拥塞控制: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 算法生效,重传亦可激进,因为拥塞丢包也罕见。

当然,对于传统算法领域内部,一叶以障目,传统算法就是全部。

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

相关推荐
weixin_442643421 小时前
推荐FileLink数据跨网摆渡系统 — 安全、高效的数据传输解决方案
服务器·网络·安全·filelink数据摆渡系统
阑梦清川1 小时前
JavaEE初阶---网络原理(五)---HTTP协议
网络·http·java-ee
FeelTouch Labs2 小时前
Netty实现WebSocket Server是否开启压缩深度分析
网络·websocket·网络协议
长弓三石4 小时前
鸿蒙网络编程系列44-仓颉版HttpRequest上传文件示例
前端·网络·华为·harmonyos·鸿蒙
xianwu5434 小时前
反向代理模块
linux·开发语言·网络·git
follycat4 小时前
[极客大挑战 2019]HTTP 1
网络·网络协议·http·网络安全
xiaoxiongip6665 小时前
HTTP 和 HTTPS
网络·爬虫·网络协议·tcp/ip·http·https·ip
JaneJiazhao5 小时前
HTTPSOK:智能SSL证书管理的新选择
网络·网络协议·ssl
CXDNW5 小时前
【网络面试篇】HTTP(2)(笔记)——http、https、http1.1、http2.0
网络·笔记·http·面试·https·http2.0
无所谓จุ๊บ6 小时前
树莓派开发相关知识十 -小试服务器
服务器·网络·树莓派