【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB

介绍

Sender Side Bandwidth Estimation 发送方带宽预估。Sender Side BWE 是新方案，利用的是 RTCP 中的 TransportCC 协议。

Receiver Estimated Maximum Bitrate 接收端预估最大码率。REMB 是旧方案，利用的是 RTCP 中的 REMB 协议。

背景

WebRTC 中的拥塞控制算法有三种：GCC、BBR、PCC。GCC 是 WebRTC 的默认算法，GCC 包含基于丢包和延迟两种情况的算法。以下所有内容都是 GCC 中的。

拥塞控制的源码在：目录 src/modules/congestion_controller/ 下

GCC 全称 Google Congestion Control。

GCC 由于新旧版本兼容原因有三种实现的方式。

根据丢包情况计算带宽。
根据延迟情况在接收端计算带宽。旧方案，使用卡尔曼滤波器。
根据延迟情况在发送端计算带宽。新方案，使用最小二乘法作线性回归。

为什么要切换方案

也就是新的比旧的好在哪？

Google 给的官方解释是：> https://groups.google.com/g/discuss-webrtc/c/ZyKcu3E9XgA/m/hF0saddeLgAJ

所有决策逻辑都在一端们会让测试新算法变得简单。
发送端知道自己发送的数据流是什么类型，可以在发送普通视频和做屏幕广播时选择不同的算法。

当然更实际的好处是：新的方案在应对峰值流量的能力上比旧的好。

基于丢包的拥塞控制

基本思想：丢包率小，提高码率；丢包率大，降低码率；丢包率适中，不进行调整。

A s ( t k ) = { A s ( t k − 1 ) ( 1 − 0.5 f l ( t k ) ) f l ( t k ) > 0.1 1.05 ( A s ( t k − 1 ) ) f l ( t k ) < 0.02 A s ( t k − 1 ) o t h e r w i s e A_s(t_k) = \begin{cases} A_s(t_{k-1})(1-0.5f_l(t_k))&f_l(t_k)>0.1\\ 1.05(A_s(t_{k-1}))&f_l(t_k)<0.02\\ A_s(t_{k-1})&otherwise\\ \end{cases} As(tk)=⎩ ⎨ ⎧As(tk−1)(1−0.5fl(tk))1.05(As(tk−1))As(tk−1)fl(tk)>0.1fl(tk)<0.02otherwise

A s ( t k ) A_s(t_k) As(tk) 即为 t k t_k tk 时刻的带宽估计值， f l ( t k ) f_l(t_k) fl(tk) 即为 t k t_k tk 时刻的丢包率。

基于延迟的拥塞控制

最小二乘法求线性回归方程

基本思想：以时间为x轴，延迟梯度为y轴。对其中的点做一元线性拟合求斜率。斜率越大说明网络越拥塞。

一元线性方程： y = a x + b y = ax + b y=ax+b

求线性回归方程系数a： a = ∑ i = 1 n ( x i − x ˉ ) ( y i − y ˉ ) ∑ i = 1 n ( x i − x ˉ ) 2 a=\frac{\sum_{i=1}^{n}{(x_i-\bar{x})(y_i-\bar{y})}}{\sum_{i=1}^{n}{(x_i-\bar{x})^{2}}} a=∑i=1n(xi−xˉ)2∑i=1n(xi−xˉ)(yi−yˉ)

关键技术

InterArrival 到达间隔

一帧视频往往是由多个 RTP 包发送的，所以首先将 RTP 的数据按照 5ms 分组，之后对相邻的两组数据包进行计算。

5ms 是 GCC 草案中提出的：The Pacer sends a group of packets to the network every burst_time interval. RECOMMENDED value for burst_time is 5 ms.

理论上，WebRTC 是按照包组为单位进行计算的。但为理解的方便，后面将包组统一理解为一个数据包。

计算内容包括：

发送时刻差： △ t i m e s t a m p = T 2 − T 1 △timestamp = T_2-T_1 △timestamp=T2−T1
接收时刻差： △ a r r i v a l = t 2 − t 1 △arrival = t_2-t_1 △arrival=t2−t1
数据包大小差： △ s i z e = G 2 − G 1 △size = G_2-G_1 △size=G2−G1 虽然很多博文里都提到计算数据包大小差，但实际后面都没有用到。

TrendlineEstimator 趋势线预估

通过上述的三个值，可以计算：

一个包的延迟： d e l a y i = △ a r r i v a l − △ t i m e s t a m p delay_i = △arrival - △timestamp delayi=△arrival−△timestamp

每个包累计的延迟： a c c d e l a y i = ∑ d e l a y 0 + d e l a y 1 + . . . + d e l a y i acc_{delay_i} = \sum delay_0 + delay_1 + ... + delay_i accdelayi=∑delay0+delay1+...+delayi

WebRTC 中对累计的延迟做了平滑处理，也就是取了之前的累计延迟的 90%，取了当前包累计延迟的 10% ，从而减少了变化幅度。 s m o d e l a y i = α ∗ s m o d e l a y i − 1 + ( 1 − α ) ∗ a c c d e l a y i smo_{delay_i} = α * smo_{delay_{i-1}} + (1-α) * acc_{delay_i} smodelayi=α∗smodelayi−1+(1−α)∗accdelayi 这里 α = 0.9 α = 0.9 α=0.9

现在有了平滑后的延迟梯度，有了每个包的到达时间。那么时间为 x 轴，延迟梯度为 y 轴。

如果随着时间的变化延迟梯度增加，也就是 y = a x + b y = ax + b y=ax+b 这条线的斜率 a > 0 a > 0 a>0，说明网络情况差。
如果随着时间的变化延迟梯度保持不变，也就是 y = a x + b y = ax + b y=ax+b 这条线的斜率 a = 0 a = 0 a=0，说明网络稳定。
如果随着时间的变化延迟梯度减小，也就是 y = a x + b y = ax + b y=ax+b 这条线的斜率 a < 0 a < 0 a<0，说明网络情况在好转。

WebRTC 中使用最小二乘算法计算出了 a a a 的值。

阿里云(WebRTC 拥塞控制 | Trendline 滤波器) 个人觉得算法这部分将的比别的好 https://developer.aliyun.com/article/781509

剩余计算公式：

对包的累计延迟和包的平滑延迟求平均：

x i = ∑ d e l a y 0 + d e l a y 1 + . . . + d e l a y i i x_i = \frac{\sum delay_0 + delay_1 + ... + delay_i}{i} xi=i∑delay0+delay1+...+delayi y i = ∑ s m o d e l a y 0 + s m o d e l a y 1 + . . . + s m o d e l a y i i y_i = \frac{\sum smo_{delay_0} + smo_{delay_1} + ... + smo_{delay_i}}{i} yi=i∑smodelay0+smodelay1+...+smodelayi

每个包组的传输时间为： t r a n s i = t i − f i r s t _ a r r i v a l i trans_i = t_i - first\_arrival_i transi=ti−first_arrivali

趋势斜率分子： n u m e r a t o r i = ∑ k = 0 i ( t r a n s k − x k ) ∗ ( s m o d e l a y k − y k ) numerator_i = \sum\limits_{k=0}^i(trans_k - x_k) * (smo_{delay_k} - y_k) numeratori=k=0∑i(transk−xk)∗(smodelayk−yk)

趋势斜率分母： d e n o i n a t o r i = ∑ k = 0 i ( t r a n s k − x k ) 2 denoinator_i = \sum\limits_{k=0}^i(trans_k - x_k)^2 denoinatori=k=0∑i(transk−xk)2

趋势斜率为： t r e n d l i n e i = n u m e r a t o r i d e n o i n a t o r i trendline_i = \frac{numerator_i}{denoinator_i} trendlinei=denoinatorinumeratori

Overuse Detector 过载检测器

上述步骤已经计算出斜率 a a a ，过载检测器就会利用 a a a 与阈值 γ γ γ 进行比较，从而决策当前网络所处状态。

由于实际计算出的 a a a 非常小，所以 WebRTC 对其进行了放大，会用 a ∗ 包组数量 ∗ 增益系数 a * 包组数量 * 增益系数 a∗包组数量∗增益系数。

而阈值也是需要动态计算的，阈值计算公式： γ i = γ i − 1 + Δ t i ∗ k i ∗ ( ∣ m i ∣ − γ i − 1 ) γ_i = γ_{i-1} + Δt_i * k_i * (|m_i| - γ_{i-1}) γi=γi−1+Δti∗ki∗(∣mi∣−γi−1)

Δ t i Δt_i Δti 表示距离上一次更新阈值的时间。 k i k_i ki 表示一个系数。 m i m_i mi 表示上面说的被放大后的 a a a 。

k i k_i ki 的取值规则如下： k i = { k d = 0.039 ∣ m i ∣ < γ i − 1 k u = 0.0087 o t h e r w i s e k_i = \begin{cases} k_d=0.039&|m_i|<γ_{i-1}\\ k_u=0.0087&otherwise\\ \end{cases} ki={kd=0.039ku=0.0087∣mi∣<γi−1otherwise k d k_d kd 与 k u k_u ku 分别决定阈值增加以及减小的速度。

WebRTC 将当前网络所处状态分为三个。

overuse： m ( t i ) > γ ( t i ) m(ti) > γ(ti) m(ti)>γ(ti) 并且持续时间超过 100ms
underuse： m ( t i ) < − γ ( t i ) m(ti) < -γ(ti) m(ti)<−γ(ti) 并且持续时间超过 100ms
normal： − γ ( t i ) < m ( t i ) < γ ( t i ) -γ(ti) < m(ti) < γ(ti) −γ(ti)<m(ti)<γ(ti)

AIMD Rate Controller 码率控制器

AIMD 的全称是 Additive Increase Multiplicative Decrease，意思是：和式增加，积式减少。直白点就是：增加的时候用加法，减少的时候用乘法。增加的时候慢一点，降低的时候快一点。

但是，AIMD 是 TCP 底层的码率调节概念，WebRTC 没有完全照搬，而是有自己一套算法。

该模块同样也维护了一个状态机：码流控制状态机。

保存当前码流改变的状态：Decrease 正在降低码率，Hold 正在保持码率，Increase 正在增加码率。

计算出当前网络状态后，根据码流控制器状态机，按照和式增加，积式减少的原则，估算出下一时刻发送端应该发送码流的大小。

A r ( t i ) = { α A r ( t i − 1 ) α = 1.08 σ = I n c r e a s e β R r ( t i ) β = 0.85 σ = D e c r e a s e A r ( t i − 1 ) σ = H o l d A_r(t_i) = \begin{cases} αA_r(t_{i-1})&α = 1.08 \ σ=Increase\\ βR_r(t_i)&β=0.85 \ σ=Decrease\\ A_r(t_{i-1})&σ=Hold\\ \end{cases} Ar(ti)=⎩ ⎨ ⎧αAr(ti−1)βRr(ti)Ar(ti−1)α=1.08 σ=Increaseβ=0.85 σ=Decreaseσ=Hold

当前是 Increase 状态，如果吞吐量 R r R_r Rr 和链路容量（历史吞吐量的指数平滑）相差较大，则对当前码率（上次更新的码率）使用乘性增加；如果相差较小，则使用加性增加。

当前是 Decrease 状态，直接将当前吞吐量 R r R_r Rr * 0.85 作为新码率，如果该码率可能仍大于上一个调整后的码率，则使用链路容量 R r R_r Rr * 0.85 作为新码率。

据此，得到基于延时预估出来的码率。

【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB相关推荐

【WebRTC】拥塞控制 GCC 类图
GoogCcNetworkController : 整个 congestion_controller 模块的中心类,是对外的接口 AcknowledgedBitrateEstimatorInterfa ...
webrtc QoS -服务质量总结
什么是QOS QoS(Quality of Service,服务质量)指一个网络能够利用各种基础技术,为指定的网络通信提供更好的服务能力,是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技 ...
WebRTC Qos策略
1.WebRTC 用于提升 QoS 的方法: NACK.FEC.SVC.JitterBuffer.IDR Request.PACER.Sender Side BWE.VFR(动态帧率调整策略) htt ...
WebRTC的拥塞控制和带宽策略（转）
网络的波动带来的卡顿直接影响着用户的体验,在WebRTC中设计了一套基于延迟和丢包反馈的拥塞机制(GCC)和带宽调节策略来保证延迟.质量和网路速度之间平衡,本文中重点是介绍基于trendline滤波的 ...
【webrtc QOS】视频帧率、分辨率自适应
[[webrtc]openh264编码:QP 解析] (https://zhangbin.blog.csdn.net/article/details/123382213) 我们了解了werbtc 使用 ...
webrtc QOS FEC原理
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/CrystalShaw/article/ ...
webrtc QOS方法二.1（FEC原理）
一.概述 webrtc冗余打包方式有三种:Red(rfc2198).Ulpfec(rfc5109).Flexfec(草案).其中Red和Ulpfec要成对使用. 二.RedFEC 简单将老报文打包到新 ...
WebRTC拥塞控制算法——GCC介绍
刘心坤网易资深研发工程师对高性能网络设备.系统软件的开发等领域有浓厚的兴趣作者简介网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题,它对网络传输的质量有严重的影响, 网络拥塞是导 ...
webrtc QOS 丢包测试发现问题
一.组网环境二.预置参数或者 1.Client1.Client2.信令服务器连接在一个以太网交换机上.保证Client1与Client2走P2P. 2.在Client2上使用Network Emu ...

【WebRTC】QoS 拥塞控制 GCC 理论 Sender Side BWE 或 REMB

介绍