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

 关于三个协议表现，我在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通过计算前后数据包的接收时间差与发送时间差($\Delta d=t_i-t_{i-1}-(T_i-T_{i-1})$)，作为网络拥塞信号。这种测量方法，不需要两端之间的时钟同步。这个公式就是计算数据包之间的抖动，能够反映中网络中的队列变化情况。若$\Delta d>0$表明网络中的队列长队在增加，排队时延在增加；若$\Delta d<0$,表明网络中的队列在减少，排队时延在减少。但是$\Delta 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$表示数据包丢包。
$$\widetilde{d_n}=d_n+1_n^M{d}_M+1_n^L{d}_L.\text{\hspace{1em}(1)}$$
向接收端反馈的数值要进行指数平滑：
$$x_n=\alpha \widetilde{d_n}+(1-\alpha )x_{n-1}.\text{\hspace{1em}(2)}$$
接收端每隔$\delta =100ms$向接收端反馈数据：
$$\hat{x}=x(t)+\frac{x(t)-x(t-\delta )}{\delta }{\tau }_o.\text{\hspace{1em}(3)}$$
 其中，在webrtc的对NADA的仿真代码中(nada.cc，这个代码目前在新版本webrtc的代码中已经不见了)，发送端回馈的是$x(t)$,就是平滑后的$x_n $(fb.congestio{n}_{s}ignal())和导数$\frac{x(t)-x(t-\delta)}{\delta}$,$x(t-\delta)$为计算出的$x_{n-1}$. ${\tau }_o$为一个固定值，500ms。照我理解，$\delta$是一个固定值，但是接收端反馈的时候,有定时器之类的是有误差，最后计算出来的是一个修正值$\hat{x}$.这个值影响编码器的参考编码码率,$x_{ref}$是一个固定的参考值，w表示流的权重，网络中不同的流有不同的优先级.编码器的编码速率$R\in [R_{min},R_{max}]$.路径时延参数增大的时候，降低编码速率，减少数据包的产生,反之，则增大编码速率。
$$R_n=R_{min}+w(R_{max}-R_{min})\frac{x_{ref}}{\hat{x}}.\text{\hspace{1em}(4)}$$
 上面说的是参考编码速率，文中还要根据发送端的缓冲区，决定最终的编码器控制速率$R_v$以及缓冲区数据的向外的发送速率$R_s$.发送端的缓冲区数据较多的时候，要相应地下调$R_v$
这是论文[2]的大概意思，但是作者向IETF提交的草案，则在不断演进，其中的公式已经发生了很大的变化[10].好像是为了增加系统的稳定性，没办法，不是控制论出身，看不太懂。
 最近作者，发布了NADA在ns3上的仿真代码[17]。我运行仿真，配置一个点到点链路，链路带宽2M，单项时延100ms。在只有nada流的时候，可以看到nada的带宽利用率还是非常高的，而且速率非常平稳。

 下面我们对比下，一条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
[19] Improved coexistence and loss tolerance for delay based TCP congestion control