關於三個協議表現，我在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=ti−ti−1−(Ti−Ti−1)$\mathrm{\Delta }d=t_i-t_{i-1}-(T_i-T_{i-1})$)，作為網路擁塞訊號。這種測量方法，不需要兩端之間的時鐘同步。這個公式就是計算資料包之間的抖動，能夠反映中網路中的佇列變化情況。若Δd>0$\mathrm{\Delta }d>0$表明網路中的佇列長隊在增加，排隊時延在增加；若Δd<0$\mathrm{\Delta }d<0$,表明網路中的佇列在減少，排隊時延在減少。但是Δd=0$\mathrm{\Delta }d=0$的情況就比較複雜，1網路利用率不足，但是網路佇列基本為空；2網路佇列滿載，網路流填充網路的速度超出了網路的處理能力；3網路流的傳送速率和網路的處理能力相等。
 REMAT工作組主要有三個草案，GCC[3,11]，NADA[2,10]，SCReAM[4,12]。
 webrtc中的擁塞控制機制就是GCC，網上有博文介紹[8,9]，不提。
 NADA通過獲取路徑的時延引數，控制視訊編碼器的編碼速率Rn$R_n$.NADA主要糅合one way delay(dn$d_n$)，丟包時延(dL$d_L$,將丟包行為轉化為一個懲罰時延，可以設定為1s)，ECN標記時延（dM$d_M$,網路路由器標記擁塞訊號也被轉化為一個懲罰時延，可以設定為200ms）來計算出一個綜合時延(d~$\tilde{d}$,aggregate delay)。第n個包的時延計算如下，其中1Mn$1_n^M$被網路路由器標記了擁塞訊號，1Ln$1_n^L$表示資料包丟包。
dn~=dn+1MndM+1LndL.(1)$\begin{array}{}\text{(1)}& \widetilde{d_n}=d_n+1_n^M{d}_M+1_n^L{d}_L.\end{array}$
向接收端反饋的數值要進行指數平滑：
xn=αdn~+(1−α)xn−1.(2)$\begin{array}{}\text{(2)}& x_n=\alpha \widetilde{d_n}+(1-\alpha )x_{n-1}.\end{array}$
接收端每隔δ=100ms$\delta =100ms$向接收端反饋資料：
x^=x(t)+x(t)−x(t−δ)δτo.(3)$\begin{array}{}\text{(3)}& \hat{x}=x(t)+\frac{x(t)-x(t-\delta )}{\delta }{\tau }_o.\end{array}$
 其中，在webrtc的對NADA的模擬程式碼中(nada.cc)，傳送端回饋的是x(t)$x(t)$,就是平滑後的xn$x_n$(fb.congestion_signal())和導數x(t)−x(t−δ)δ$\frac{x(t)-x(t-\delta )}{\delta }$,x(t−δ)$x(t-\delta )$為計算出的xn−1$x_{n-1}$. τo${\tau }_o$為一個固定值，500ms。照我理解，δ$\delta$是一個固定值，但是接收端反饋的時候,有定時器之類的是有誤差，最後計算出來的是一個修正值x^$\hat{x}$.這個值影響編碼器的參考編碼位元速率,xref$x_{ref}$是一個固定的參考值，w表示流的權重，網路中不同的流有不同的優先順序.編碼器的編碼速率

相關推薦