Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Rate-based Control for Streaming Videos over the Internet Saverio Mascolo Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari – Italy JOINT BEATS/Wireless IP seminar, Hotel Alexandra, Loen, June 4 – 6, 2003

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Outline Introduction Introduction Data and videos Data and videos Protocols at the transport layer: TCP vs. UDP Protocols at the transport layer: TCP vs. UDP Rate-based vs. window-based Rate-based vs. window-based TFRC proposal TFRC proposal ARC (our proposal) ARC (our proposal) Simulations Simulations

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Layering Application layer Application layer Transport layer (TCP/UDP) Transport layer (TCP/UDP) Network layer (IP) Network layer (IP) Link layer Link layer Physical layer Physical layer

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Introduction  Up to now, the most part of Internet traffic is still due to data (ftp, web pages…)  However, the part of Internet traffic due to audio and video streaming is ever increasing  TCP/IP has been quite effective for data but it is not appropriate for audio/videos

Application Data Advertised Window TCP/IP Receive Socket Buffer TCP/IP Application Data TCP flows buffer TCP/IP i TCP/IP j TCP/IP k TCP/IP m Send Socket Buffer TCP/IP Network Internet is a black box

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Data vs. Videos Data and videos have different requirements: Data and videos have different requirements: Data Data Need reliable delivery Need reliable delivery Not senstive to delays, jitter delays Not senstive to delays, jitter delays Videos Videos Not need reliable delivery (a low percentage of lost packet can be tolerated) Not need reliable delivery (a low percentage of lost packet can be tolerated) Senstive to delays, jitter delays Senstive to delays, jitter delays

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Why TCP is not effective for videos? TCP is bursty because it is window based TCP is bursty because it is window based TCP/IP provides reliable delivery but does not guarantee delays and jitter TCP/IP provides reliable delivery but does not guarantee delays and jitter As a consequence, audio and videos are streamed over the UDP protocol, which is not reliable and do not perform congestion control As a consequence, audio and videos are streamed over the UDP protocol, which is not reliable and do not perform congestion control … the Internet will experience congestion collapse unless congestion control is implemented at the transport layer or at the application layer … the Internet will experience congestion collapse unless congestion control is implemented at the transport layer or at the application layer

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo State of the art: TFRC To preserve Internet stability, congestion control should be used for videos (standardized congestion control such as in the case of TCP for data ?) To preserve Internet stability, congestion control should be used for videos (standardized congestion control such as in the case of TCP for data ?) A lot of literature available A lot of literature available Current leading proposal: Transport Friendly Rate Control (TFRC) by S. Floyd et al. Current leading proposal: Transport Friendly Rate Control (TFRC) by S. Floyd et al.

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo References TCP Friendly Rate Control (TFRC): Protocol Specification. Handley, M., Floyd, S., Pahdye, J., and Widmer, J. RFC 3448, Proposed Standard, January TCP Friendly Rate Control (TFRC): Protocol Specification. Handley, M., Floyd, S., Pahdye, J., and Widmer, J. RFC 3448, Proposed Standard, January TCP Friendly Rate Control (TFRC): Protocol Specification TCP Friendly Rate Control (TFRC): Protocol Specification Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer. SIGCOMM Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer. SIGCOMM 2000.

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo TFRC The basic idea is to employ the long-term throughput equation of TCP proposed in Padhye et al., "Modeling the TCP Throughput", Proc. Sigcomm 1998, in order to provide an input rate smoother than TCP: The basic idea is to employ the long-term throughput equation of TCP proposed in Padhye et al., "Modeling the TCP Throughput", Proc. Sigcomm 1998, in order to provide an input rate smoother than TCP:

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo where… X = transmit rate [bytes/second] s= packet size in bytes s= packet size in bytes R= round trip time in seconds p= loss event rate p= loss event rate t_RTO= TCP retransmission timeout=4R b= #of packets acknowledged by a single TCP acknowledgement

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo What is important from the transport layer point of view The formula shows that what TCP “sees” is the packet error rate The formula shows that what TCP “sees” is the packet error rate Thus it is important that the physical layer and link layer (ARQ+FEC) do a good job! Thus it is important that the physical layer and link layer (ARQ+FEC) do a good job! In fact, TCP assumes reliable link=>interprets packet loss as indication of congestion In fact, TCP assumes reliable link=>interprets packet loss as indication of congestion Further improvements can be obtained using modified version of the TCP stack such as Westwood Further improvements can be obtained using modified version of the TCP stack such as Westwood

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Rationale of TFRC The use of the long-term equation aims at providing the following advantages: The use of the long-term equation aims at providing the following advantages: 1) Eliminate the burstiness of TCP due its window- based nature 2)Provide an algorithm friendly toward TCP, i.e. TFRC and TCP MUST coexist getting a fair bandwidth share. (friendliness is clearly a primary concern when proposing a new CC algo)

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Our criticism The long-term equation approximates the TCP throughput (30% error and more), but this is not the main problem… The long-term equation approximates the TCP throughput (30% error and more), but this is not the main problem… Thus, differently from what is affirmed in literature, we have found that TFRC is not friendly towards TCP Thus, differently from what is affirmed in literature, we have found that TFRC is not friendly towards TCP

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Our proposal: The adaptive rate control (ARC) alghorithm Main ideas: Main ideas: control theoretical analysis to design a rate-based version of TCP congestion control control theoretical analysis to design a rate-based version of TCP congestion control end-to-end bandwidth estimation a la Westwood end-to-end bandwidth estimation a la Westwood

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Control analysis background One starting point is the paper: S. Mascolo, “Congestion Control using the Smith principle” Automatica, Dec. 1999

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Without loss of generality the control scheme can be reduced to a Smith Predictor+proportional controller Without loss of generality the control scheme can be reduced to a Smith Predictor+proportional controller x ij (t) G ci (s) ui(t)ui(t) d ij (t)  ri(t)ri(t) + _ k _ fw Ts e  s 1 fb Ts e 

Control law Rate- based Rate- based Window-based Window-based W=AdvertisedWindow – OutstandingPackets W=Cwnd – OutstandingPackets ( this is the classic sliding window control )

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Bandwidth estimate a la Westwood The other starting point is the paper: S. Mascolo et al, “TCP Westwood: e2e bandwidth estimation for TCP congestion control”, ACM Mobicom 01

TCP Westwood Congestion Avoidance Slow start cwnd time Timeout ssthresh BWE*RTTmin Adaptive setting cwnd=ssthr=BWE*RTTmin key feature: window shrinking after congestion based on the measured available bandwidth

Reno TCP time ssthresh cwnd Congestion Avoidance (CA) Timeout “blind” by half window reduction Exponential increasing Linear increasing Slow-start (SS) Typical cwnd dynamics following the AIMD paradigm

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo The ARC algorithm To provide friendliness towards TCP, we properly set w(t) to mimic the slow-start and congestion avoidance phase of TCP. When a congestion episode happens w(t) is reduced a la Westwood TCP, that is, w(t)=B*(RTTmin+1/k) to ensure the depletion of the queues along the path

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo TFRC vs. ARC: main differences TFRC employs a long-term equation => it is not friendly towards Reno TFRC employs a long-term equation => it is not friendly towards Reno ARC employs a dynamic equation => it is responsive and friendly to Reno ARC employs a dynamic equation => it is responsive and friendly to Reno

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Single Bottleneck Scenario RTTs: N Reno sources: 250/N-250ms UDP source: 250ms M Rate based sources: 250/M-250ms- 10 Reno Backward connections: ms N Reno sources UDP source M Rate sources 10 Reno Sinks R1 R2 N Reno Sinks UDP Sink M Rate Sinks 10 Reno sources Forward Traffic Backward Traffic

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo 1 Reno TCP and 1 ON-OFF UDP source over a 2Mbps bottleneck- Without Reverse trafficWith Reverse traffic TCP is bursty due to ACK compression and window-based control. Notice that a piece-wise constant available bandwidth reproduces the case of bandwidth oscillation in 2.5g/3G wireless systems (see Khafizov et al. “Running TCP over IS-2000”, ICC02)

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo 1 TFRC and 1 ON-OFF UDP source over a 2Mbps bottleneck Without Reverse trafficWith Reverse traffic TFRC provides a smoothed sending rate w.r.t. Reno TCP

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo 1 ARC and 1 ON-OFF UDP source over a 2Mbps bottleneck Without Reverse trafficWith Reverse traffic ARC is not sensitive to congestion along the backward path and provides a smoother sending rate w.r.t. Reno TCP

TFRC promptly reacts to bandwidth variations ARC promptly reacts to bandwidth variations and is fairer than TFRC Reno TCP exhibits huge burstyness 10 connections and 1 ON-OFF UDP source over a 10Mbps bottleneck

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Many Connections over a 10Mbps bottleneck ARC and TFRC improves bottleneck utilization w.r.t Reno TCP at low levels of statistical multiplexing

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Multihop Scenario RTTs: C1 connection: 250ms; Cross traffic connections: 50ms Start time: C1:10s; Cross Traffic: 0s. Link Capacities: 1Mbps C1C1 Sink 1 C2C2 R Sink 2 C3C3 Sink 3 R R C5C5 Sink 5 R C4C4 Sink 4 1 th hop 2 th hop

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Homogeneous scenario (all sorces controlled by the same algorithm) N.B. TFRC does not allow the C1 connection to grab its bandwidth share=>TFRC IS NOT FAIR

Reno C1 connection and different type of cross-traffic TFRC cross-traffic does not allow C1 Reno connection to grab its bandwidth share, i.e., TFRC IS NOT FRIENDLY TO RENO

Joint BEATS/WIP Seminar, June 6, 2003 Copyrights Saverio Mascolo Reno cross-traffic, C1 Reno or TFRC or ARC