关于三个协议表现,我在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
)
\Delta d=t_i-t_{i-1}-(T_i-T_{i-1})
Δd=ti−ti−1−(Ti−Ti−1)),作为网络拥塞信号。这种测量方法,不需要两端之间的时钟同步。这个公式就是计算数据包之间的抖动,能够反映中网络中的队列变化情况。若
Δ
d
>
0
\Delta d>0
Δd>0表明网络中的队列长队在增加,排队时延在增加;若
Δ
d
<
0
\Delta d<0
Δd<0,表明网络中的队列在减少,排队时延在减少。但是
Δ
d
=
0
\Delta d=0
Δd=0的情况就比较复杂,1网络利用率不足,但是网络队列基本为空;2网络队列满载,网络流填充网络的速度超出了网络的处理能力;3网络流的发送速率和网络的处理能力相等。
REMAT工作组主要有三个草案,GCC[3,11],NADA[2,10],SCReAM[4,12]。
webrtc中的拥塞控制机制就是GCC,网上有博文介绍[8,9],不提。
NADA通过获取路径的时延参数,控制视频编码器的编码速率
R
n
R_n
Rn.NADA主要糅合one way delay(
d
n
d_n
dn),丢包时延(
d
L
d_L
dL,将丢包行为转化为一个惩罚时延,可以设置为1s),ECN标记时延(
d
M
d_M
dM,网络路由器标记拥塞信号也被转化为一个惩罚时延,可以设置为200ms)来计算出一个综合时延(
d
~
\tilde{d}
d~,aggregate delay)。第n个包的时延计算如下,其中
1
n
M
1_n^M
1nM被网络路由器标记了拥塞信号,
1
n
L
1_n^L
1nL表示数据包丢包。
(1)
d
n
~
=
d
n
+
1
n
M
d
M
+
1
n
L
d
L
.
\tilde{d_n}=d_n+1_n^Md_M+1_n^Ld_L.\tag{1}
dn~=dn+1nMdM+1nLdL.(1)
向接收端反馈的数值要进行指数平滑:
(2)
x
n
=
α
d
n
~
+
(
1
−
α
)
x
n
−
1
.
x_n=\alpha\tilde{d_n}+(1-\alpha)x_{n-1}.\tag{2}
xn=αdn~+(1−α)xn−1.(2)
接收端每隔
δ
=
100
m
s
\delta=100ms
δ=100ms向接收端反馈数据:
(3)
x
^
=
x
(
t
)
+
x
(
t
)
−
x
(
t
−
δ
)
δ
τ
o
.
\hat{x}=x(t)+\frac{x(t)-x(t-\delta)}{\delta}\tau_o.\tag{3}
x^=x(t)+δx(t)−x(t−δ)τo.(3)
其中,在webrtc的对NADA的仿真代码中(nada.cc,这个代码目前在新版本webrtc的代码中已经不见了),发送端回馈的是
x
(
t
)
x(t)
x(t),就是平滑后的$x_n
(
f
b
.
c
o
n
g
e
s
t
i
o
n
s
i
g
n
a
l
(
)
)
和
导
数
(fb.congestion_signal())和导数
(fb.congestionsignal())和导数\frac{x(t)-x(t-\delta)}{\delta}
,
,
,x(t-\delta)
为
计
算
出
的
为计算出的
为计算出的x_{n-1}$.
τ
o
\tau_o
τo为一个固定值,500ms。照我理解,
δ
\delta
δ是一个固定值,但是接收端反馈的时候,有定时器之类的是有误差,最后计算出来的是一个修正值
x
^
\hat{x}
x^.这个值影响编码器的参考编码码率,
x
r
e
f
{x_{ref}}
xref是一个固定的参考值,w表示流的权重,网络中不同的流有不同的优先级.编码器的编码速率
R
∈
[
R
m
i
n
,
R
m
a
x
]
R\in[R_{min},R_{max}]
R∈[Rmin,Rmax].路径时延参数增大的时候,降低编码速率,减少数据包的产生,反之,则增大编码速率。
(4)
R
n
=
R
m
i
n
+
w
(
R
m
a
x
−
R
m
i
n
)
x
r
e
f
x
^
.
R_n=R_{min}+w(R_{max}-R_{min})\frac{x_{ref}}{\hat{x}}.\tag{4}
Rn=Rmin+w(Rmax−Rmin)x^xref.(4)
上面说的是参考编码速率,文中还要根据发送端的缓冲区,决定最终的编码器控制速率
R
v
R_{v}
Rv以及缓冲区数据的向外的发送速率
R
s
R_{s}
Rs.发送端的缓冲区数据较多的时候,要相应地下调
R
v
R_{v}
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
[19] Improved coexistence and loss tolerance for delay based TCP congestion control