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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010643777/article/details/78623129

 关于三个协议表现,我在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=titi1(TiTi1)),作为网络拥塞信号。这种测量方法,不需要两端之间的时钟同步。这个公式就是计算数据包之间的抖动,能够反映中网络中的队列变化情况。若Δ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个包的时延计算如下,其中1nM被网络路由器标记了拥塞信号,1nL表示数据包丢包。
(1)dn~=dn+1nMdM+1nLdL.
向接收端反馈的数值要进行指数平滑:
(2)xn=αdn~+(1α)xn1.
接收端每隔δ=100ms向接收端反馈数据:
(3)x^=x(t)+x(t)x(tδ)δτo.
 其中,在webrtc的对NADA的仿真代码中(nada.cc),发送端回馈的是x(t),就是平滑后的xn(fb.congestion_signal())和导数x(t)x(tδ)δ,x(tδ)为计算出的xn1. τo为一个固定值,500ms。照我理解,δ是一个固定值,但是接收端反馈的时候,有定时器之类的是有误差,最后计算出来的是一个修正值x^.这个值影响编码器的参考编码码率,xref是一个固定的参考值,w表示流的权重,网络中不同的流有不同的优先级.编码器的编码速率R[Rmin,Rmax].路径时延参数增大的时候,降低编码速率,减少数据包的产生,反之,则增大编码速率。
(4)Rn=Rmin+w(RmaxRmin)xrefx^.
 上面说的是参考编码速率,文中还要根据发送端的缓冲区,决定最终的编码器控制速率Rv以及缓冲区数据的向外的发送速率Rs.发送端的缓冲区数据较多的时候,要相应地下调Rv
这是论文[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

没有更多推荐了,返回首页