Performance Evaluations of DCCP for Bursty Traffic in Real-time Applications Author: Shigeki Takeuchi,Hiroyuki Koga, Katsuyoshi Iida, Youki Kadobayashi, Suguru Yamaguchi Proceedings of the The 2005 Symposium on Applications and the Internet (SAINT'05) Speaker: Jia-Yu Wang

Outline Introduction TCP-like Congestion Control (CCID2) Simulation Results Conclusions Reference

Introduction_1 Datagram Congestion Control Protocol (RFC 4340) TCP UDP DCCP Reliable Yes No Connect-oriented Congestion Control Sequence Number No receive window. DCCP is a congestion control protocol, not a flow control protocol.

Introduction_2 Unreliable No re-transmissions Reliable handshakes for connection setup and teardown Has modular congestion control Can detect congestion and take avoiding action Different algorithms can be selected – CCID TCP-like Congestion Control (CCID2) TCP Friendly Rate Control (CCID3) Packet sequence numbers CCID3:以方程式為基礎的 congestion control格式作出的回應，比CCDI2更順利(穩定、流暢)。

TCP-like Congestion Control (CCID2)_1 The CCID2 algorithm is based on the AIMD (Additive Increase Multiplicative Decrease) AIMD：additive-increase & multiplicative-decrease ( 累加遞增 & 倍增遞減 )當察覺無壅塞情形時，加快傳送速度；當壅塞情形嚴重時，降低傳輸速度。 當察覺壅塞時，TCP會降低CongWin來降低傳送速率，是以"倍數遞減"(multiplicative decrease)； TCP Congestion control

TCP-like Congestion Control (CCID2)_2 Differences between CCID 2 and straight TCP congestion control include the following: CCID 2 applies congestion control to acknowledgements The congestion window cwnd have units of packets in DCCP As an unreliable protocol, DCCP never retransmits a packet CCID2:與tcp相似，sender維持一個congestion window and sends packets 直到 that window is full. 當接收到一個擁塞回應，就會減少一半的congestion window . 和TCP不同的地方：1. CCID2應用擁塞控制到acknowledgements,這個機制目前不是tcp的標準規範 2.tcp使用byte為單位,dccp使用packet。 3.dccp是一個不可靠的協定，所以不會重傳封包

TCP-like Congestion Control (CCID2)_3 Sender端會先發送dccp-data封包，然後根據receiver發送的dccp-ack封包的ack vector來調整sender自己的擁塞視窗。 然後receiver端會看sender的ack ratio來進行，收到幾個dccp-data封包來回傳dccp-ack封包。 使用ack ratio有利於減少ack封包對網路頻寬的占用，另外，ack封包的減少，在slow start階段， 會減緩sender端擁塞視窗的增長速度，避免擁塞視窗以指數成長。

Simulation Model NS2(Network Simulator – v.2.26) 可以設定傳輸延遲(propagation delay)，以及buffer size。另外所有模擬時間為60秒，測試的時間為55秒，0秒先跑第一個flow，5秒在跑第二個flow。

Comparison of DCCP and UDP_1 (α=20ms,β=5ms,γ=10ms,buffer size b=40 packets)

Comparison of DCCP and UDP_2 Summary of stationary throughput in Mb/s:2UDP+2TCP and 2DCCP+2TCP

DCCP and TCP flows_1 Interactions between DCCP and TCP:TCP flow first (α=3ms,β=3ms,γ=10ms,buffer size b=20 packets) 如果tcp先開始，到最後頻寬分配會平均 Interactions between DCCP and TCP:TCP flow first

DCCP and TCP flows_2 如果dccp先開始，最後dccp會吃掉比較多的頻寬 Interactions between DCCP and TCP: DCCP flow first

DCCP and TCP flows_3 使用不同的TCP演算法沒有明顯的差異。總頻寬使用率約為93%(10Mb/s) Summary of stationary throughput in Mb/s: DCCP + TCP

Two DCCP flows_1 Interactions between two DCCP flows DCCP 1 5.69 Mb/s

Two DCCP flows_2 說明DCCP2 第5秒到第15秒之間的封包值。DCCP預設的ack ratio為2，這邊模擬ack ratio為1和2。 圖中在5.1秒時發生了兩個packet lost。在初始值為2的地方最後會發生time out的情況在最後一個封包。 Y軸的sequence number是除以50後的餘數。 之所以要預設ack ratio為2是由於為了預防slow start程指數性成長。

Effect of propagation delay (α=3ms,β=3ms,γ=10ms,buffer size b=20 packets) 網路參數的影響，傳輸延遲的影響，模擬使用dccp與tcp從0秒開始。 Bottlenecked link delay設定為5ms-40ms。 Propagation delay γ versus throughput : b=20 packet

Effect of bottlenecked router buffer size 修改buffer size為5~40個packet，可以發現在小的buffer size(低於20)會有比較公平的網路頻寬分配， 在較大buffer size(高於20)就會開始發生不公平的網路頻寬分配，這是由於大的buffer size會導致比較長時間的RTT。 Buffer size versus throughput: γ = 10 ms

Conclusions The bandwidth consumption of DCCP can be adjusted to accommodate TCP flows. The fairness between TCP and DCCP flows depends heavily on RTT. The fairness among DCCP flows is not satisfactory. 1.DCCP的頻寬消耗可以作調整來容納TCP flow。 2.Tcp和dccp之間要公平的分配頻寬，很大的部份取決於RTT 3.在DCCP之間公平的分配頻寬是不太令人滿意的，因為在slow start階段沒有穩定的成長。 這可以經由選擇initial ack ratio 值來改善。

Reference Datagram Congestion Control Protocol (RFC 4340) CCID2-TCP-like Congestion Control (RFC 4341) CCID3-TCP-Friendly Rate Control (TFRC) (RFC4342) Performance Evaluations of DCCP for Bursty Traffic in Real-time Applications