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

 本文主要是对于[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=ti−ti−1−(Ti−Ti−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通过获取路径的时延参数，控制视频编码器的编码速率Rn.NADA主要糅合one way delay(dn)，丢包时延(dL,将丢包行为转化为一个惩罚时延，可以设置为1s)，ECN标记时延（dM,网络路由器标记拥塞信号也被转化为一个惩罚时延，可以设置为200ms）来计算出一个综合时延(d~,aggregate delay)。第n个包的时延计算如下，其中1Mn被网络路由器标记了拥塞信号，1Ln表示数据包丢包。
dn~=dn+1MndM+1LndL.(1)
向接收端反馈的数值要进行指数平滑：
xn=αdn~+(1−α)xn−1.(2)
接收端每隔δ=100ms向接收端反馈数据：
x^=x(t)+x(t)−x(t−δ)δτo.(3)
 其中，在webrtc的对NADA的仿真代码中(nada.cc)，发送端回馈的是x(t),就是平滑后的xn(fb.congestion_signal())和导数x(t)−x(t−δ)δ,x(t−δ)为计算出的xn−1. τo为一个固定值，500ms。照我理解，δ是一个固定值，但是接收端反馈的时候,有定时器之类的是有误差，最后计算出来的是一个修正值x^.这个值影响编码器的参考编码码率,xref是一个固定的参考值，w表示流的权重，网络中不同的流有不同的优先级.编码器的编码速率R∈[Rmin,Rmax].路径时延参数增大的时候，降低编码速率，减少数据包的产生,反之，则增大编码速率。
Rn=Rmin+w(Rmax−Rmin)xrefx^.(4)
 上面说的是参考编码速率，文中还要根据发送端的缓冲区，决定最终的编码器控制速率Rv以及缓冲区数据的向外的发送速率Rs.发送端的缓冲区数据较多的时候，要相应地下调Rv
这是论文[2]的大概意思，但是作者向IETF提交的草案，则在不断演进，其中的公式已经发生了很大的变化[10].好像是为了增加系统的稳定性，没办法，不是控制论出身，看不太懂。
 SCReAM[4]是爱立信出品的一个拥塞控制算法，用在其OPENWEBRTC(基于gstreamer)代码库中，文章没有公式，综合了LEDBAT[13]和TCP的拥塞控制机制，单向时延超过阈值，降窗；出现丢包，降窗。这个算法，要是应用，会饿死媒体流的。
 拥塞控制算法，在网络拥塞的时候，带宽退让；探测到可用带宽时，及时占有。
[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.