webrtc 拥塞控制相关

RFC8836 对实时交互式音视频应用的拥塞控制算法需求进行了较为全面的总结

• 延迟 拥塞控制算法应该尽可能降低延时，尤其是算法本身引入的延时。与此同时仍然需要提供可用的带宽水平。
  
  -吞吐率：在相应场景下吞吐率应尽可能高。
• 公平性：拥塞控制算法应该能够和其他实时流量和 TCP 流量公平地共享链路带宽。
• 避免“饿死”：媒体流在与 TCP 流竞争中不应被“饿死”，也不能把 TCP 流“饿死”。
• 收敛速度：在媒体流启动阶段尽可能快地收敛到稳定状态。
• 网络支持：算法不应要求特殊网络特性支持。
• 稳定性：算法应该在媒体流变化时保持稳定，比如媒体流暂时的传输中断
• 快速响应：算法应该快速响应网络环境的变化，比如瓶颈带宽变化、链路延时变化等。

所以

一是如何快速准确地进行网络拥塞探测；

二是采取适当的拥塞应对措施尽量避免拥塞以及尽可能快地从拥塞状态恢复

基于丢包的算法（Loss-based) 为了探测链路容量而不断增加发送带宽，直至丢包事件发生

基于延时的算法（Delay-based） 对延时的测量来判断网络拥塞, 重点考虑需求总结中的避免“饿死”问题。

基于延时的算法一般通过测量 RTT（round-trip time 往返延时）或者 OWD（one-way delay 单向延时）来判断拥塞。

RTT 测量比较直观，但是由于是测量双向延时的总体情况，因此反向的延时变化会对媒体流方向的网络拥塞判断造成干扰。OWD 延时观测则避免了这个问题。如下图所示：

OWD 通过观测发送间隔与接收间隔的变化来判断网络排队延时的状况。

根据发送端所采取的其他弱网对抗策略，可能的速率调节手段包括调节音视频编码器速率、调节重传速率、调节 FEC 冗余度等.

webrtc 1.0 REMB

• 发送端采用基于丢包
  
  丢包率<2%，增加发送带宽 8%；
  
  丢包率 2% ~ 10%，发送带宽保持不变；
  
  丢包率>10%，降低发送带宽（1-0.5*丢包率）。
• 接收端采用基于延时的算法
  
  通过统计单向延时变化并通过卡尔曼滤波对当前的传输延时进行估计，再结合当前的实际接收带宽评估一个最佳的目标带宽，通过 RTCP 消息反馈给发送端。发送端取两个算法结果的最小值作为最终的目标带宽。

webrtc 2.0 gcc

新的框架改进了网络延时估计算法，通过对单向延时变化数据进行线性回归分析，评估当前网络排队延时变化趋势，即判断出延时正在增加、没有变化、正在降低三种趋势，再结合当前发送速率，给出最佳目标带宽估计。

除了改进拥塞探测算法，新的框架也引入了主动带宽探测机制，优化了整个拥塞控制算法的性能，经过比较，在启动阶段收敛速度、网络环境变化的响应速度上都有比较明显的改进

丢包重传ARQ

首次请求延时：应结合其他策略考虑发现丢包时是否立即请求，比如结合 FEC 策略考虑。

重复请求间隔考虑：同一个数据包重复请求间隔要大于当前 RTT。

请求次数限制：结合当前 RTT 与容忍的最大延时来计算。

发送端重传带宽限制：重传带宽作为总传输带宽的一部分，不能超出总体带宽限制。

重传包回传机制：建议采用单独的 RTP 码流发送，利于丢包率统计与重传带宽计算。

前向纠错

ULPFEC：ULP（Uneven Level Protection，不均等保护）根据数据包重要程度使用不同级别的保护策略。

FlexFEC：Flexible Forward Error Correction，此标准在 RTP 协议框架下定义了交织与非交织的奇偶校验 FEC 编码包格式。

丢包重传和FEC 配合

抖动延时的估计，Google 在其 WebRTC 框架中用了两种方法

1. 音频 直方图加遗忘因子

图中的 Iat 意为间隔达到时间，WebRTC 通过对音频包到达间隔用直方图进行统计，取 95 分位数的延时时长作为音频抖动延时。

2. 视频抗抖动方面，WebRTC 采用不同于音频的抖动延时估计算法，通过对实际的帧尺寸变化与延时变化数据的测量与统计，利用卡尔曼滤波器动态地进行最优抖动延时估计。

融云说的

拥塞控制方面，基于 Google GCC 算法进行改进。除了统计单向延时变化进行拥塞趋势判断之外，同时对丢包模式进行进一步分析，提升带宽预测的准确率。

抗丢包方面，基于 FlexFEC 框架，采用高修复能力的 FEC 编码，并进行综合调优来提升抗丢包能力。

优化 ARQ 与 FEC 机制的配合，力求抗丢包付出的代价最小。抗抖动方面，采用场景适应性更强的抖动延时估计方法，力求提升流畅度的同时减少延时。