实时视频流的拥塞控制-NADA，GCC，SCReAM

程序员文章站 2022-07-06 16:20:50

...

关于三个协议表现，我在ns3仿真平台上进行了对比，相应的技术报告，参考[18]。
本文主要是对于[1]的翻译. I’m not the master of knowledge, and I am his prophet.
IETF成立了RMCAT(RTP Media Congestion Avoidance Techniques)工作组，制定在RTP协议之上的拥塞控制机制。[5]中的首段话，指明只要是经由网络的数据流，都应该有拥塞控制机制，说的很好，抄在这里：

Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.

假设一条经由网络的数据流没有任何拥塞控制机制，盲目地向网络中发送数据包，当突发包的长度大于某个值，超出了瓶颈链路的处理能力，网络中的队列管理机制就要发挥作用，进行丢包。丢包行为本身就是一种资源浪费的策略，耗费了网络的处理能力，数据包却没有到达目的地。所以，网络中的数据流要根据反馈信号，调整数据包的发送速率，与网络中流的数量和处理能力适配。当前，端到端的拥塞控制机制主要有两类：基于丢包反馈的(TCP Reno,BIC,CUBIC)，基于时延测量的(TCP Vegas, TCP Fast)。其实还有第三类，基于拥塞的拥塞算法(BBR),算是一种混合了丢包与时延的方案，因为网络的丢包，以及时延的增加，这个会影响BBR的即时带宽的计算，也就影响BBR的发送包的速率。
对于实时视频流，更偏向于采用基于时延的拥塞控制策略，因为基于丢包的拥塞控制策略，通过向网络中填充数据包，发现可用带宽，可导致端到端时延的震荡。但是目前路由器上队列长度的很深，导致了很大的端到端时延.Excessively large buffer may leads to latency of seconds which is referred as buffbloat problem, and packet loss is a rare event. 鉴于网络的视频流量逐渐占据主流，所以出现了CoDel[6]与PIE[7]，通过丢包来控制路由器中的队列长度，保证较小的端到端时延，保证QoE。端到端较小的时延，是通过队列主动丢包实现的，让丢包的流在发现丢包之后，调整发送速率。
[5]中指明了实时媒体流进行拥塞控制要达到的目标：

metrics	Requirement
Latency	Possibly lower than 100ms
Packet losses	Should be minimized, FEC mechanism may be employed
Throughput	Should be as high as possible
Burstiness	A smooth sending-rate should be produced
Fairness	Should fairly share the bandwidth with real-time and data flows
Starvation	Media flows should not be starved when competing with TCP flows
Network support	No special network support should be required to operate

因此基于时延的参数主要有三种：Round Trip Time,One-Way Delay, One-Way Delay Variation.
基于RTT时延的拥塞控制机制有TCP Vegas,TCP FAST.RTT将反向链路的时延考虑在内，反向链路的拥塞可能影响正向链路的发送速率。Tcp Vegas的经验表明，基于时延的拥塞控制算法，同基于丢包的拥塞控制算法竞争瓶颈链路带宽时，会被饿死。OWD，测量的是单向路径时延，有接收端与发送端时钟同步的需要，而且OWD有一个“late comer effect”，后到的流增加了网络上的处理时延，使得之前的流逐渐出让带宽，导致先前的流饿死。OWDV通过计算前后数据包的接收时间差与发送时间差( $Δ d = t_{i} - t_{i - 1} - (T_{i} - T_{i - 1})$ )，作为网络拥塞信号。这种测量方法，不需要两端之间的时钟同步。这个公式就是计算数据包之间的抖动，能够反映中网络中的队列变化情况。若 $Δ d > 0$ 表明网络中的队列长队在增加，排队时延在增加；若 $Δ d < 0$ ,表明网络中的队列在减少，排队时延在减少。但是 $Δ d = 0$ 的情况就比较复杂，1网络利用率不足，但是网络队列基本为空；2网络队列满载，网络流填充网络的速度超出了网络的处理能力；3网络流的发送速率和网络的处理能力相等。
REMAT工作组主要有三个草案，GCC[3,11]，NADA[2,10]，SCReAM[4,12]。
webrtc中的拥塞控制机制就是GCC，网上有博文介绍[8,9]，不提。
NADA通过获取路径的时延参数，控制视频编码器的编码速率 $R_{n}$ .NADA主要糅合one way delay( $d_{n}$ )，丢包时延( $d_{L}$ ,将丢包行为转化为一个惩罚时延，可以设置为1s)，ECN标记时延（ $d_{M}$ ,网络路由器标记拥塞信号也被转化为一个惩罚时延，可以设置为200ms）来计算出一个综合时延( $\tilde{d}$ ,aggregate delay)。第n个包的时延计算如下，其中 $1_{n}^{M}$ 被网络路由器标记了拥塞信号， $1_{n}^{L}$ 表示数据包丢包。
$\begin{matrix} (1) & \tilde{d_{n}} = d_{n} + 1_{n}^{M} d_{M} + 1_{n}^{L} d_{L} . \end{matrix}$
向接收端反馈的数值要进行指数平滑：
$\begin{matrix} (2) & x_{n} = α \tilde{d_{n}} + (1 - α) x_{n - 1} . \end{matrix}$
接收端每隔 $δ = 100 m s$ 向接收端反馈数据：
$\begin{matrix} (3) & \hat{x} = x (t) + \frac{x (t) - x (t - δ)}{δ} τ_{o} . \end{matrix}$
其中，在webrtc的对NADA的仿真代码中(nada.cc)，发送端回馈的是 $x (t)$ ,就是平滑后的 $x_{n}$ (fb.congestion_signal())和导数 $\frac{x (t) - x (t - δ)}{δ}$ , $x (t - δ)$ 为计算出的 $x_{n - 1}$ . $τ_{o}$ 为一个固定值，500ms。照我理解， $δ$ 是一个固定值，但是接收端反馈的时候,有定时器之类的是有误差，最后计算出来的是一个修正值 $\hat{x}$ .这个值影响编码器的参考编码码率, $x_{r e f}$ 是一个固定的参考值，w表示流的权重，网络中不同的流有不同的优先级.编码器的编码速率 $R \in [R_{m i n}, R_{m a x}]$ .路径时延参数增大的时候，降低编码速率，减少数据包的产生,反之，则增大编码速率。
$\begin{matrix} (4) & R_{n} = R_{m i n} + w (R_{m a x} - R_{m i n}) \frac{x_{r e f}}{\hat{x}} . \end{matrix}$
上面说的是参考编码速率，文中还要根据发送端的缓冲区，决定最终的编码器控制速率 $R_{v}$ 以及缓冲区数据的向外的发送速率 $R_{s}$ .发送端的缓冲区数据较多的时候，要相应地下调 $R_{v}$
这是论文[2]的大概意思，但是作者向IETF提交的草案，则在不断演进，其中的公式已经发生了很大的变化[10].好像是为了增加系统的稳定性，没办法，不是控制论出身，看不太懂。
最近作者，发布了NADA在ns3上的仿真代码[17]。我运行仿真，配置一个点到点链路，链路带宽2M，单项时延100ms。在只有nada流的时候，可以看到nada的带宽利用率还是非常高的，而且速率非常平稳。
实时视频流的拥塞控制-NADA，GCC，SCReAM
下面我们对比下，一条NADA流同一条TCP流竞争带宽的情况，我在仿真的[20,100]秒，启动了一条TCP流。可以看到，在tcp流存在的情况下，NADA，基本上也能占用到一个合理的带宽。

SCReAM[4]是爱立信出品的一个拥塞控制算法，用在其OPENWEBRTC(基于gstreamer)代码库中。
SCReAM在算法启动的时候，采用类似TCP慢启动模式，在没有发生丢包之前，以快速模式增加编解码器的码率。

      else if (parent->inFastStart && rtpQueueDelay < 0.1f) {
            /*
            * Increment bitrate, limited by the rampUpSpeed
            */
            increment = rampUpSpeedTmp*(kRateAdjustInterval_us * 1e-6f);
            /*
            * Limit increase rate near the last known highest bitrate or if priority is low
            */
            increment *= sclI*sqrt(targetPriority);
            /*
            * No increase if the actual coder rate is lower than the target
            */
            if (targetBitrate > rateRtpLimit*1.5f)
                increment = 0;
            /*
            * Add increment
            */
            targetBitrate += increment;
            wasFastStart = true;
        }

拥塞控制算法，在网络拥塞的时候，带宽退让；探测到可用带宽时，及时占有。
[1]De Cicco L, Carlucci G, Mascolo S. Congestion control for webrtc: Standardization status and open issues[J]. IEEE Communications Standards Magazine, 2017, 1(2): 22-27.
[2]Zhu X, Pan R. NADA: A unified congestion control scheme for low-latency interactive video[C]//Packet Video Workshop (PV), 2013 20th International. IEEE, 2013: 1-8.
[3]Carlucci G, De Cicco L, Holmer S, et al. Congestion Control for Web Real-Time Communication[J]. IEEE/ACM Transactions on Networking, 2017, 25(5): 2629-2642.
[4]Johansson I. Self-clocked rate adaptation for conversational video in LTE[C]//Proceedings of the 2014 ACM SIGCOMM workshop on Capacity sharing workshop. ACM, 2014: 51-56.
[5]Congestion Control Requirements for Interactive Real-Time Media draft-ietf-rmcat-cc-requirements-09
[6]Nichols K, Jacobson V, McGregor A, et al. Controlled delay active queue management[J]. Work in Progress, 2013.
[7]Pan R, Natarajan P, Piglione C, et al. PIE: A lightweight control scheme to address the bufferbloat problem[C]//High Performance Switching and Routing (HPSR), 2013 IEEE 14th International Conference on. IEEE, 2013: 148-155.
[8]WebRTC基于GCC的拥塞控制(上) - 算法分析
[9]WebRTC基于GCC的拥塞控制(下) - 实现分析
[10]NADA: A Unified Congestion Control Scheme for Real-Time Media draft-ietf-rmcat-nada-05
[11]A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web draft-alvestrand-rtcweb-congestion-03
[12]Self-Clocked Rate Adaptation for Multimedia draft-ietf-rmcat-scream-cc-13
[13]基于UDP拥塞控制-LEDBAT
[14]Winstein K, Sivaraman A, Balakrishnan H. Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks[C]//NSDI. 2013: 459-471.
[15]Zaki Y, Pötsch T, Chen J, et al. Adaptive congestion control for unpredictable cellular networks[C]//ACM SIGCOMM Computer Communication Review. ACM, 2015, 45(4): 509-522.
[16] Zhu X, Pan R, Prabhu M S, et al. Layered internet video adaptation (LIVA): Network-assisted bandwidth sharing and transient loss protection for video streaming[J]. IEEE Transactions on Multimedia, 2011
[17]ns3-rmcat
[18]The performance comparison of GCC, NADA and SCReAM

相关标签：视频流拥塞控制网络

上一篇：如何向ubuntu18.04背景图片库添加自己的图片

下一篇： Hadoop HA 搭建