Congestion Control Enabled VoIP by Flexible Bit-Rate 利用可變速率方法賦予網路電話壅塞控制能力 研究生: 丁諭祺 指導教授: 連耀南

Outline 緒論 背景與相關研究 數據壅塞控制協定頻寬競爭分析 可變速率方法 實驗與效能評估 結論

第一章 緒論

緒論 現行的網路應用程式，多使用UDP或TCP來傳遞資料。 UDP TCP 沒有確認封包的設計，無法得知網路情況，故傳輸速率經應用程式設定之後，在整個傳輸的過程中便不再改變。 TCP 加入確認封包、重送機制和連線逾時的概念，可以透過壅塞控制機制，在傳輸的過程中改變傳輸速率，調節傳送端與接收端之間的網路負載。 當整體網路中TCP的比例較大時，透過TCP的壅塞控制機制，還可以容忍UDP不進行壅塞控制的行為。 但隨著多媒體網路應用的興起(如VoIP)，這類的網路應用程式多使用UDP作為傳輸協議，網路中的UDP封包將占大多數，僅透過TCP的壅塞控制來做調節，將不足以維持整體網路的穩定。

緒論 因此DCCP這種具有壅塞控制機制的傳輸協議被提出，期望取代UDP成為不可靠傳輸的主流協議。 但DCCP在加入了壅塞控制機制後： 可能不利於頻寬競爭 也能不適用於講求時效性的網路應用程式 本研究將以實驗證明DCCP無法完全取代UDP，並針對時效性的應用程式(如VoIP)提出一套有效的壅塞控制機制，在保證一定的傳輸品質下，促進整體網路的和諧。

DCCP DCCP的設計初衷在於加入壅塞控制機制，取代現有的UDP，成為不可靠傳輸協議的主流 DCCP是不可靠的傳輸協議 DCCP的使用者可透過壅塞控制編號(CCID)選擇不同的壅塞控制機。

DCCP-Based VoIP 目前VoIP應用程式大多採用UDP作為傳輸協議，若將傳輸協議改為DCCP，是否能維持原本所需的傳輸效能，並維持穩定的通話品質。 面臨問題 DCCP是否能競爭到公平的頻寬？ DCCP的壅塞控制機制，是否適合運用在VoIP？

問題1 - 頻寬競爭 不同於沒有壅塞控制機制的UDP，加入壅塞控制機制的DCCP，在面對其他傳輸協議的頻寬競爭之下，是否能維持一定的傳輸效能？

問題2 – DCCP壅塞控制機制 目前的VoIP在通話過程中，語音壓縮率是固定的，因此每秒所產生的資料量是固定的。 現行的DCCP壅塞控制機制，是透過調整封包發送間隔來降低傳送速率，當傳輸速率低於VoIP所需，VoIP產生的封包會暫存於buffer之中，語音封包傳送至接收端的時間勢必加長。 透過暫緩送出封包的壅塞控制機，可能無法適用在VoIP之上。 VoIP是非常講究時效性

研究目的與方法 以實驗探討目前DCCP的壅塞控制機制，在其他傳輸協議競爭下，是否能公平地分享頻寬。 針對VoIP做壅塞控制來促進網路的和諧，並維持一定的品質；以往的觀點只針對VoIP自身的品質而言，忽略到整體網路的情況。 協助避免網路壅塞 尤其當網路中VoIP數量非常多時，避免網路壅塞更顯得重要 提出一套偵測網路壅塞的方法，加上VoIP應用程式的配合，在通話的過程中透過改變語音壓縮率，舒緩網路壅塞的情形，並維持一定的通話品質。

Outline 緒論 背景與相關研究 數據壅塞控制協定頻寬競爭分析 可變速率方法 實驗與效能評估 結論

第二章 背景與相關研究

DCCP壅塞控制機制 DCCP目前定義了CCID2與CCID3兩種不同的壅塞控制方法。 TCP-like (CCID2) [RFC4341] TCP Friendly Rate Control (CCID3) [RFC 4342] CCID2制定的壅塞控制機制和TCP相當類似的，差別在於沒有重送機制。 CCID3是以網路參數代入公式，估計發送端的傳輸速率，是種以控制傳輸速率的壅塞控制機制。 CCID3被建議做為傳輸多媒體網路應用程式的壅塞控制方法

DCCP CCID3 CCID3是使用公式方式來估計傳輸速率，X值的結果就是估計出的傳輸速率。 s= the packet mean size in bytes p=packet loss rate RTT=Round Trip Time RTO=TCP Retransmission TimeOut value in seconds

VoIP語音封包產生流程 從發話者的麥克風收到聲音，藉由網路傳送語音資料，再由收聽者的喇叭放出聲音的流程如下： Encode的過程中 壓縮率高→語音封包小→所需頻寬越低→音質越差 壓縮率低→語音封包大→所需頻寬越高→音質越佳 目前的VoIP在通話過程中，語音壓縮率是固定的，因此每秒所產生的資料量是固定的。

VoIP通話品質指標 主觀MOS 用耳朵聽 客觀 Delay Jitter Packet Loss

Outline 緒論 背景與相關研究 數據壅塞控制協定頻寬競爭分析 可變速率方法 實驗與效能評估 結論

第三章 數據壅塞控制協定頻寬競爭分析

Can DCCP replace UDP ? DCCP的目的在於加入壅塞控制機制，並取代UDP成為不可靠傳輸協議的主流，但目前建議用來傳輸多媒體資料的CCID3壅塞控制機制，如果運用在講究即時性的網路服務上(如VoIP)，是否能保有一定的效能呢？

目標與實驗方法 目標 實驗方法 以實驗的方式，說明DCCP無法完全取代UDP成為不可靠傳輸協議的主流。 使用NS-2模擬器，模擬將UDP改為DCCP後，傳輸VoIP網路電話，觀察Throughput、Packet Delay Time、Packet Loss Rate變化。

實驗網路拓樸 實驗拓樸是越洋網路電話的設計

實驗參數 Parameters Value VoIP Packet Size 40 Bytes (Payload only) VoIP Inter-Packet Interval 20 ms TCP Versions Tahoe, Reno, NewReno, SACK, Vegas TCP Packet Size 1460 bytes Router Buffer Size 20 packets Buffer Management Scheme DropTail (FIFO) Link Bandwidth 0.25~10 Mbps Number of VoIP session 1 (Full Duplex) Number of TCP session 5

頻寬抗侵略性實驗 我們使用UDP(或DCCP)傳輸一通網路電話，每隔10秒鐘增加1條TCP資料流進入網路，直到網路中有5條TCP資料流，所有TCP資料流於90秒停止傳輸。

VoIP First (vs. NewReno) 在第一條TCP資料流進入一直到第五條TCP資料進入，可以看到以UDP傳輸的VoIP通話其Throughput維持穩定。 在第一條TCP資料流進入之後，以DCCP傳輸的VoIP通話，其Throughput無法維持所需效能。 打三角的地方代表TCP資料流進入的時間點

VoIP First (vs. NewReno) 在我們設計的越洋網路拓樸中，可以看到UDP的Delay Time能維持在350毫秒以下。 超過350毫秒的封包，我們將之視為Packet Loss，可以看到DCCP的封包遺失率慘不忍睹。

頻寬競爭力實驗 實驗開始時網路中就存在5條TCP資料流，網路電話UDP(或DCCP)在實驗的第20秒進入直到第80秒結束。

TCP First (vs. NewReno) 當網路中存在五條TCP資料流時，可以看到20至80秒間以UDP傳輸的VoIP通話其Throughput維持穩定。 當網路中存在五條TCP資料流時，可以看到20至80秒間以DCCP傳輸的VoIP通話其Throughput相當低。 總共有五條TCP資料流，這邊只畫出第一條TCP資料流的Throughput變化

TCP First (vs. NewReno) UDP的Packet Delay Time能維持在350毫秒以下，DCCP最高達800毫秒。 超過350毫秒的封包，我們將之視為Packet Loss，可以看到DCCP的封包遺失率甚至接近100%。

Quality of VoIP (DCCP-based) Period (sec) 0-10 10-20 20-30 30-40 40-50 50-60 vs. Tahoe Throughput Ratio(%) 100 25.12 25.23 25.47 21.61 16.59 Delay Time (ms) 73 395 415 424 470 548 Loss Rate 74.86 75.32 78.09 83.85 vs. Reno 29.67 32.01 23.01 16.94 20.21 319 343 438 498 497 70.13 68.40 77.97 82.81 79.82 vs. NewReno 29.79 25.82 20.68 21.26 15.89 322 441 468 477 545 70.01 74.97 79.58 78.32 84.54 vs. SACK 21.73 17.64 17.76 15.77 16.12 443 490 513 536 554 78.43 82.35 82.70 83.97 84.08 vs. Vegas 72.78 52.45 33.18 19.63 12.62 194 321 412 543 627 26.64 48.79 67.36 80.85 87.89 Throughput比較的基準是0-10秒沒有任何TCP資料流的情況

小結 以UDP為基礎的VoIP能維持300毫秒以下的封包延遲，且在TCP競爭下依然能保持20%以下的封包遺失率；而DCCP對於TCP資料流的競爭，封包遺失率甚至超過80%，而且當只有一條TCP資料流時，Throughput降至初始值的30%。

DCCP CANNOT replace UDP 從實驗結果來看，使用DCCP傳輸VoIP，不論在頻寬的競爭和抗侵略性都遠輸UDP，最大的問題是CCID3是以控制傳輸速率的壅塞控制機制，為了控制傳輸速率，必須延長封包送出的間隔。 傳輸速率=封包大小/Inter-Packet Time

Outline 緒論 背景與相關研究 數據壅塞控制協定頻寬競爭分析 可變速率方法 實驗與效能評估 結論

第四章 可變速率方法

可變速率方法(Flexible Bit-Rate) 目前的VoIP在通話前會先設定好傳輸速率，固定其Bit-Rate，在整個傳輸的過程中不再改變。 可變速率方法能在通話的過程中，在網路頻寬足夠時使用較低的縮率提高語音品質，在網路頻寬不足的情況下使用較高的壓縮率來適應網路頻寬。

頻寬不足時以不同Bit-Rate傳輸語音 經過頻寬不足的網路傳輸，Bit-Rate=5.75Kbps的錄音 經過頻寬不足的網路傳輸，Bit-Rate=16.8Kbps的錄音 在頻寬不足的情況下，不同的Bit-Rate對於通話品質的影響

頻寬不足時以不同Bit-Rate傳輸語音 很明顯在網路頻寬不足的情況下，使用較低Bit-Rate傳輸音質高於使用較高的Bit-Rate來傳輸。 Sender 送出封包數 Receiver 接收封包數 Bit-Rate (Kbps) Loss Rate 封包遺失率 MOS 326 7.75 3.01 9.8 3.30 305 12.8 0.0644 3.22 279 16.8 0.1285 2.15 254 20.6 0.2225 1.81

手動調整Bit-Rate 使用者發現音質不佳時，手動調整Bit-Rate的錄音 手動調整 Bit-Rate=16.8 MOS變化 紅色的線代表我們收聽的品質 Bit-Rate=5.75

小結 當語音品質變差時，在網路壅塞的情況下確實能藉由手動調整Bit-Rate來提高通話品質。 在實驗中觀察到一些網路壅塞現象，我們利用這些現象設計一套自動調整機制。

網路壅塞現象 我們在實驗中觀察到，當網路壅塞時，封包與封包的間隔時間(Inter-Packet Arrival Time)會變長，可利用此現象判斷網路是否壅塞。

網路壅塞偵測 VoIP是以CBR的方式傳送語音封包，故在接收端連續收到兩個封包的間隔時間應該在一個固定的範圍之內；當網路壅塞時，接收端連續兩個封包的間隔會拉長，偵測到此現象視為網路壅塞。

網路壅塞偵測 我們假設連續兩個封包的間隔時間為 𝑡 𝑖 ，且服從常態分配，則兩封包間隔時間可用 𝑡 1 , 𝑡 2 ,…, 𝑡 𝑁 表示，其平均值為 𝑡 (公式1)，標準差為 σ 𝑡 (公式2) 。 𝑡 = 1 𝑁 𝑖=1 𝑁 𝑡 𝑖 σ 𝑡 = 1 𝑁−1 𝑖=1 𝑛 𝑡 𝑖 − 𝑡 2

網路壅塞偵測 依照常態分配之經驗法則，我們可以推測： 所以就經驗法則，只有少數的封包間隔時間會是在平均數加減三個標準差之外。 下一個封包間隔時間 𝑡 𝑖 在 𝑡 − σ 𝑡 , 𝑡 + σ 𝑡 範圍之機率為68.3%。 下一個封包間隔時間 𝑡 𝑖 在 𝑡 −2 σ 𝑡 , 𝑡 +2 σ 𝑡 範圍之機率為95.4%。 下一個封包間隔時間 𝑡 𝑖 在 𝑡 −3 σ 𝑡 , 𝑡 +3 σ 𝑡 範圍之機率為99.7%。 所以就經驗法則，只有少數的封包間隔時間會是在平均數加減三個標準差之外。

降低Bit-Rate 利用常態分配之經驗法則，並避免不斷的調整Bit-Rate，我們設計下一個封包間隔時間 𝑡 𝑛𝑒𝑤 小於 𝑡 +3 σ 𝑡 視為網路狀況正常，如果 𝐭 𝐧𝐞𝐰 超過 𝐭 +𝟑 𝛔 𝐭 則判斷為網路壅塞，連續超過α次則送出降低一個等級Bit-Rate的指令給發話端。 Quality Bit-Rate(Kbps) 3.95 1 5.75 2 7.75 3 9.8 4 12.8 5 16.8 6 20.6 7 23.8 8 27.8 9 34.2 10 42.2

提升Bit-Rate 當發話端在Low Bit-Rate的狀態，此時發話端每間隔β秒提升發送語音的Bit-Rate一個等級，直到Bit-Rate回到通話初始值。 α 連續發生Inter-Packet Arrival Time超過[ 𝑡 +3 σ 𝑡 ]的次數 β 在Low Bit-Rate的狀態下，每隔β秒發話端調升Bit-Rate一個等級。

Example 時間點 間隔時間(ms) 𝑇 1 32.98 𝑇 2 35.02 𝑇 3 32.59 𝑇 4 33.61 𝑇 5 32.92 𝑇 6 32.52 𝑇 7 32.56 𝑇 8 39.41 𝑇 9 38.58 𝑇 10 平均間隔時間 𝑡 =33.6044 標準差σ 𝑡 =1.646931 𝑡 +3 σ 𝑡 =38.54519 α=3 封包間隔時間連續超過3次，受話端會向發話端送出降低一級Bit-Rate的指令。

Outline 緒論 背景與相關研究 數據壅塞控制協定頻寬競爭分析 可變速率方法 實驗與效能評估 結論

第五章 實驗與效能評估

實驗拓樸 發話端PC使用中華電信光世代連上網際網路，下載速率約10Mbps、上傳速率為2Mbps；另外收話端PC則透過台灣學術網路(TANet)連上網際網路。 實驗中的網路瓶頸點在於中華電信光世代僅提供2Mbps的上傳速率，網路壅塞情形將在此發生。

實驗參數 Parameters Value VoIP Packet Size 15 ~ 106 Kb (Payload only) VoIP Inter-Packet Interval  30 ms VoIP Codec  Speex Link Bandwidth Uplink:2Mbps Downlink:10Mbps Number of VoIP session  0-100

Packet Size(Byte, Payload only) Speex Codec Quality Bit-Rate(Kbps) Packet Size(Byte, Payload only) MOS 3.95 10 2.258 1 5.75 15 2.7158 2 7.75 20 3.0106 3 9.8 25 3.3009 4 12.8 32 5 16.8 42 3.5314 6 20.6 52 7 23.8 60 3.6134 8 27.8 70 9 34.2 86 3.9381 42.2 106 4.0925

以UDP傳輸VoIP 我們使用UDP傳輸網路電話，在通話的過程中不改變Bit-Rate。 實驗中每隔5秒增加10通VoIP語音通話進入網路，直到網路中有著100通VoIP同時進行傳輸，實驗時間共100秒。

Packet Loss Rate與MOS變化

Packet Loss Rate(UDP-based) 白色的是封包遺失率介於0%到10%之間 黃色的是封包遺失率介於10%到20%之間 紅色的是封包遺失率大於20%

Constants Bit-Rate與MOS變化

以DCCP傳輸VoIP 我們使用DCCP傳輸網路電話，在通話的過程中不改變Bit-Rate。 實驗中每隔5秒增加10通VoIP語音通話進入網路，直到網路中有著100通VoIP同時進行傳輸，實驗時間共100秒。

Packet Loss Rate與MOS變化

Packet Loss Rate(DCCP-based)

Constants Bit-Rate與MOS變化

以Flexible Bit-Rate傳輸VoIP 實驗過程中，每隔5秒鐘增加10通電話，直到網路中同時存在100通網路電話。

Packet Loss Rate與MOS變化

Packet Loss Rate(Flexible Bit-Rate)

Flexible Bit-Rate與MOS變化 我們可以看到透過調整Bit-Rate，能使100通voip維持一定的通話品質

三種方式Packet Loss Rate比較

三種方式MOS比較

小結 可變速率方法能有效提高網路中同時通話人數，實驗中在同時通話數達到100通時，MOS分數比UDP和DCCP傳輸VoIP提高56%；整體封包遺失率在2%以下，相較於UDP的23%與DCCP的45%，有相當顯著的改善。

第六章 結論

結論 DCCP無法完全取代UDP 時效性的網路應用程式如果要提供壅塞控制機制的話，最好不要改變送出封包的Inter-Packet Time，而是改變其Packet Size。 過去調整Bit-Rate的觀點只針對VoIP自身的品質而言，並無考慮到整體網路的情況。 以往的VoIP數量可能沒那麼多，所以壅塞控制可能無關痛癢；但數量多時，就有責任必須參予Congestion Control。

Thank you!