火山引擎智能拥塞控制算法 VICC(Volcano Intelligent Congestion Control)是一种自适应的拥塞控制算法,旨在解决全球不同网络环境下,不同音视频应用对带宽利用率和延时的差异化要求。它结合了传统拥塞控制算法(如 GCC 和 BBR)的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应带宽探测幅度、自适应丢包检测策略、自适应抗抖动能力和自适应 Padding。通过这些自适应调整,VICC 算法能够提升各种复杂弱网下的带宽利用率,同时在满足不同延时的条件下,尽量提升带宽的稳定性,为用户提供更好的音视频体验。
实时音视频应用的网络传输面临诸多方面的挑战,其中包括:
带宽利用率:为了提供高质量的音视频体验,需要充分利用网络带宽,这就要求网络传输算法具有高效的带宽探测能力。
延迟和响应时间:实时音视频应用要求快速的响应时间和超低延迟,这就要求网络传输技术具有快速的传输速度和低延迟的特性。
可靠性和稳定性:网络传输过程中可能会出现拥塞、丢包等问题,这会影响到音视频的质量和稳定性,因此要求网络传输技术具有可靠性和稳定性,能够保证数据的正确传输和恢复。
公平性和资源分配:在多用户场景下,需要保证网络传输的公平性和资源分配的合理性,以避免某些用户获得过多的资源,导致其他用户的服务质量下降。
除了上述挑战,实时音视频传输还需要关注体验指标,如实时性、流畅性、清晰度、音画同步性等,这些指标对于提供高质量的音视频体验至关重要。
为了快速提升线上用户弱网相关的体验,火山引擎根据抖音集团真实用户的负反馈数据打磨研发了“音视频卡顿归因模型”,它可以对线上音视频卡顿的所有 case 进行自动归因和聚类,为弱网问题的优化和优先级给出有效指导。
根据模型对线上用户音视频卡顿反馈的归因和聚类,我们发现,当前引起线上卡顿问题的主要原因是上下行大小缓存问题。
大小缓存的描述,可以参考:https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-congestion-control-00.txt
大缓存:Deep buffers,at bottleneck links with deep buffers, congestion happens before packet loss.
小缓存:shallow buffers, in shallow buffers, packet loss happens before congestion.
自 Google 开源 WebRTC 实时音视频框架以来,GCC 作为默认拥塞控制算法备受行业研究和关注,而 WebRTC 在演进过程中,也在不断演进集成 BBR、PCC 等拥塞控制算法,以期望进一步提升实时音视频的传输性能。
下文以 GCC 和 BBR 算法为例,我们来看一看当前主流拥塞控制算法的特性和不足。
GCC 算法是专为实时音视频传输设计的拥塞控制算法,但随着网络环境日益复杂、音视频应用场景越来越丰富,GCC 算法难以提升上限以获得更好的音视频传输体验。
GCC 算法带宽估计与触发拥塞延时示意图GCC 算法的关键特征
GCC 算法的发送/接收码率的联动是非连续性的。在检测到拥塞之前,发送码率和接收码率是不联动的;检测到拥塞之后,发送码率和接收码率才开始联动。如果要降低非联动过程中的网络延迟,GCC 算法需要过降带宽排空非联动过程中网络中堆积的数据。另外,GCC 的网络探测速度也较慢。
GCC 算法存在的问题
GCC 算法的几个主要问题中,最核心的问题是带宽估计的准确性(带宽利用率)和拥塞检测的有效性(对网络的冲击)存在很难调和的矛盾,导致这个问题的主要原因是:
GCC 算法的带宽估计强依赖拥塞检测,即,只有在算法判断为网络拥塞的情况下,才能进行带宽估计;
GCC 算法的拥塞控制灵敏度受到带宽估计的影响很大, 意味着当实际发送码率越贴近真实带宽,拥塞检测受到的干扰越大
BBR 算法是互联网通用的拥塞控制算法,其设计目标追求高带宽利用率、低拥塞延迟和丢包,BBR 在通用互联网领域具备良好的性能表现,但因其设计目标和算法特性,不适应于实时音视频传输场景。
BBR 算法带宽估计与触发拥塞延时示意图BBR 算法的关键特征
和 GCC 算法不同,BBR 算法的发送/接收码率的联动是连续性的,它实时跟踪接收码率,同时根据拥塞检测的结果,来调整发送窗口(cwnd)的大小,并最终影响发送码率。
BBR 算法存在的问题
虽然 BBR 在带宽估计准确性上等能力要高于 GCC,但它也存在一些明显的问题:
突发拥塞时收敛速度慢;
当链路丢包高于一定阈值时,吞吐量断崖式下跌;
抗抖动能力一般;
反向链路丢包延时影响上行带宽估计;
探测最小延迟剧烈降窗不适用实时音视频传输;
由于 GCC 和 BBR 等算法在实时音视频传输场景存在一些不足,火山引擎网络传输团队自研了 VICC 算法,旨在优化上述问题的同时,也为火山引擎实时音视频业务提供更加良好的用户体验。
VICC 算法主要通过网络状态统计进行自适应带宽估计决策,并作出带宽评估动作,以提升各种复杂网络下拥塞控制的性能表现。在近一年的实验室和线上业务打磨过程中,我们深入分析了不同算法原理及现网痛点弱网问题,输出了 40+ 项最佳工作点及 9 篇技术专利,线上业务的各项指标,特别是视频卡顿率、首帧时长等也得到了显著的改善。
火山引擎智能拥塞控制算法 VICC 架构图评估当前网络状态的重要指标之一是网络状态统计参数,而准确的基础网络状态参数是提高带宽估计准确性和带宽利用率的关键基石。VICC 算法提供了多种基础网络状态参数,部分基础网络状态统计参数如下:
VICC 算法结合了传统拥塞控制算法的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应抗干扰能力、自适应丢包检测、自适应带宽探测幅度、自适应拥塞排空等。
VICC 继承并优化了 GCC 和 BBR 拥塞检测能力,通过对发送码率、接收码率及延迟参数的关系进行建模,观察延迟参数变化趋势及其关联性,以及对于延迟参数的容忍程度进行拥塞响应,从而快速排空网络拥塞。
和 GCC / BBR 相比,VICC 拥塞响应及收敛速度更快。
GCC / BBR / VICC 拥塞响应及收敛速度比较(线上实测)拥塞响应越灵敏,意味着在网络抖动场景下容易误判,导致算法抗干扰能力下降。VICC 使用蚁穴算法来对抗网络抖动和乱序,通过接收码率和发送码率来度量网络透过率,并结合观察延迟参数变化趋势及关联性,提升自适应抗干扰能力。
VICC 可以对抗 2000ms 以内的延迟抖动幅度,抗抖动能力显著比 GCC 和 BBR 强。
GCC / BBR / VICC 抗抖动能力比较(线上实测)灵活可配置的拥塞检测灵敏度
在自适应拥塞检测的基础上,VICC 还会根据业务偏好,提供灵活可配置的拥塞检测灵敏度模式设置,以适用于不同业务场景的诉求,并做好拥塞响应灵敏和抗干扰能力强的 trade-off。
以火山引擎 RTC 典型应用场景为例,互娱、企业通讯等场景一般可以容忍 200-300ms 的延时,而远程车控、云游戏等场景只能容忍 50-100ms 的延时。VICC 提供多种模式来适应不同场景的延时需求,在延时容忍度较高的场景,VICC 可以通过延迟拥塞响应时间来获得更高的带宽估计的稳定性,在延时容忍度较低的场景,VICC 可以通过快速拥塞响应来降低网络拥塞延迟。
火山引擎 RTC 典型应用场景通过对发送码率、接收码率及丢包参数的关系进行建模,并微幅调整发送码率,检测接收码率和丢包参数之间的关联性,VICC 可以自适应检测出丢包为随机丢包和拥塞丢包。一旦识别出随机丢包后,VICC 可以准确地对随机丢包进行系数补偿,以达到不误降带宽的效果。
和 GCC / BBR 相比,VICC 随机丢包抗性可达到 70% 以上。
GCC / BBR / VICC 随机丢包抗性比较(线上实测)考虑实时音视频传输对于延迟的容忍,根据延迟参数的程度、自适应上探幅度及下探幅度,在保留竞争力的同时,VICC 避免了因为频繁探测引入的网络延迟堆积问题。同时,在检测到拥塞缓解后,VICC 通过对发送码率、接收码率及延迟参数的关系进行建模,迅速提升带宽上探幅度和调整时间窗口;在探测到带宽满足音视频传输体验后,再逐步放慢上探幅度和时间间隔。
当网络存在瓶颈带宽时,VICC 的带宽探测相对 GCC 和 BBR 更平稳。当瓶颈带宽发生变化时,VICC 可以快速跟踪实际瓶颈带宽。
GCC / BBR / VICC 带宽探测平稳度比较VICC 使用自适应 Padding 策略来解决带宽下溢叠加复杂弱网场景下的带宽估计,在精准探测网络带宽的同时,尽量避免网络冲击和带宽浪费。在决策需要发送 Padding 时,会先根据带宽估计值设定目标发送码率,并实时度量接收码率,同时动态调整目标码率。
VICC 自适应 Padding 策略示意图通过对拥塞响应速度、带宽探测幅度、丢包检测策略、抗抖动能力等一系列的“自适应调整”,VICC 算法能够提升各种复杂弱网下的带宽利用率,同时在满足不同延时的条件下,尽量提升带宽的稳定性,为用户提供更好的音视频体验。
为了更直观地展示 VICC 算法对于用户音视频体验的提升效果,我们在不同类型的弱网环境下进行了音视频通话测试,通过比较对端画面的实时性和流畅性来比较 VICC 算法和市场上同类算法的拥塞控制能力。
在上行 70% 丢包网络环境下,使用了 VICC 算法的火山引擎 RTC 依然保持稳定传输,几乎没有表现出卡顿。
模拟上行 70% 丢包网络下的 VICC 和市场同类算法表现比较
当网络突发上行 300kbps 限速小缓存时,使用了 VICC 算法的火山引擎 RTC 出现了短暂的卡顿,但算法很快进行了对抗,迅速恢复稳定和流畅,对用户的体验影响较小。
模拟上行 300kbps 限速小缓存网络下的 VICC 和市场同类算法表现比较
VICC 算法经过了字节内部质量专项评估实验室打磨和验证后,在火山引擎线上业务上也进行了充分的流量验证,在视频通话、屏幕共享等场景中,视频卡顿率和首帧指标得到了显著的改善,其中,视频通话卡顿率下降 27%、首帧延时下降 100ms+;屏幕共享卡顿率下降 15%,首帧延迟下降 200ms。 同时,使用自适应 Padding 策略后,现网上下行码率也得到了明显的改善,其中,上行Padding码率下降 90%,下行下降 70%。
VICC 算法上线后对视频卡顿、首帧和 Padding 码率指标的改善
在网络环境高度复杂的背景下,影响用户体验的因素众多,有时通用算法难以精准匹配所有场景的环境特点,因此,一些特定场景的用户体验难以做到极致,无法实现“个性化场景自适应”的目标。
未来,我们将根据线上问题归因聚类建模,对用户网络场景精准识别,提升网络场景识别算法的准度和范围,并以此为驱动,针对不同的弱网场景进行全链路的差异化优化,使算法在各类网络模型下的收敛达到最优,持续提升用户体验。
点击阅读原文了解火山引擎 RTC 更多信息。