Rate Control For Streaming Video - From Wired To Wireless
Rate Control for Streaming Video – from Wired to Wireless Minghua Chen minghua@eecs.berkeley.edu EE290T, Spring 04’ Video and Image Processing Lab, Department of EECS University of California at Berkeley http://www-video.eecs.berkeley.edu Note: parts of the figures are adapted from slides from I. Stoica, S. Floyd, H. Balakrishnan and W. Tan. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 1/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 2/45
Rate control - stable, efficient and fair share of networks What is rate control (or congestion control) End-host changes its sending rate based on feedback from network (e.g. packet loss) Goal: achieve "title", in a distributed manner M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 3/45
Rate control - stable, efficient and fair share of networks What is rate control (or congestion control) End-host changes its sending rate based on feedback from network (e.g. packet loss) Goal: achieve "title", in a distributed manner How to do rate control? negative feedback, e.g. packet loss, decrease sending rate otherwise increase it. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 3/45
Rate control - stable, efficient and fair share of networks What is rate control (or congestion control) End-host changes its sending rate based on feedback from network (e.g. packet loss) Goal: achieve "title", in a distributed manner How to do rate control? negative feedback, e.g. packet loss, decrease sending rate otherwise increase it. Why rate control at all? M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 3/45
Rate control - stable, efficient and fair share of networks What is rate control (or congestion control) End-host changes its sending rate based on feedback from network (e.g. packet loss) Goal: achieve "title", in a distributed manner How to do rate control? negative feedback, e.g. packet loss, decrease sending rate otherwise increase it. Why rate control at all? Bandwidth is shared. If not, serious congestion collapse In October of ’86, first "congestion collapse": throughput from LBL to Berkeley dropped from 32Kbps to 40bps, factor-of-thousand drop! M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 3/45
Rate control : avoid congestion collapse M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 4/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 5/45
TCP – Transport Control Protocol First version - Reno, proposed by Jacobson in 1988 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 6/45
TCP – Transport Control Protocol First version - Reno, proposed by Jacobson in 1988 In avoidance stage: W be the window size: ( 1 , upon each ack; W W W W upon each packet loss. 2 , M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 6/45
TCP – Transport Control Protocol First version - Reno, proposed by Jacobson in 1988 In avoidance stage: W be the window size: ( 1 , upon each ack; W W W W upon each packet loss. 2 , Window based Additive increase and multiplicative decrease (AIMD) Assume every packet loss is a sign of congestion. Event driven: iff ACK arrive or time out Sending rate W · pkt size / RTT M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 6/45
TCP – Transport Control Protocol First version - Reno, proposed by Jacobson in 1988 In avoidance stage: W be the window size: ( 1 , upon each ack; W W W W upon each packet loss. 2 , Window based Additive increase and multiplicative decrease (AIMD) Assume every packet loss is a sign of congestion. Event driven: iff ACK arrive or time out Sending rate W · pkt size / RTT In slow start stage: W W 1 upon each ACK; W W/2 if packets loss M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 6/45
TCP: sawtooth behavior Huge variance in sending rate probably huge variance in receiving throughput. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 7/45
TCP: steady state average sending rate Each cycle delivers 12 ( W2 W ) W2 time. Thus sending rate: 1 p packets, in W 2 round trip 1.22S T RT T p S - packet size; RT T - round trip time; p - end-to-end packet loss rate M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 8/45
TCP: Great success but limited to data TCP is of great success Every computer runs TCP A huge area of research M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 9/45
TCP: Great success but limited to data TCP is of great success Every computer runs TCP A huge area of research Requirement on streaming video Smooth quality smooth throughput smooth sending rate No "pause" prefer non-window based rate control M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 9/45
TCP: Great success but limited to data TCP is of great success Every computer runs TCP A huge area of research Requirement on streaming video Smooth quality smooth throughput smooth sending rate No "pause" prefer non-window based rate control TCP doesn’t suit for streaming video Huge variation in sending rate Window based control Unnecessary retransmission M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 9/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 10/45
TFRC - TCP-Friendly Rate Control TCP-friendly – In long term, consume no more bandwidth than TCP. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 11/45
TFRC - TCP-Friendly Rate Control TCP-friendly – In long term, consume no more bandwidth than TCP. Various approaches on rate control for streaming video since 1998 LDA - Sisalem and Schulzrinne NOSSDAV 98 Vicisano et.al INFOCOM 98 RAP - Rejaie et.al INFOCOM 99 Padhye et.al UMass Tech. report 98 Whetten and Conlan GlobalCast 98 TFRC - Floyd et.al SIGCOMM 00 Bansal and Balakrishnan INFOCOM 01 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 11/45
TFRC - TCP-Friendly Rate Control TCP-friendly – In long term, consume no more bandwidth than TCP. Various approaches on rate control for streaming video since 1998 LDA - Sisalem and Schulzrinne NOSSDAV 98 Vicisano et.al INFOCOM 98 RAP - Rejaie et.al INFOCOM 99 Padhye et.al UMass Tech. report 98 Whetten and Conlan GlobalCast 98 TFRC - Floyd et.al SIGCOMM 00 Bansal and Balakrishnan INFOCOM 01 TFRC is popular Solid theoretical foundation Real experiment support, e.g. Tan and Zakhor TOM 99, . M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 11/45
TFRC - Goal: smooth rate control Stable Fair Efficient Rate based Application decide to retransmit or not Smoother than TCP M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 12/45
TFRC - match TCP average sending rate Use TCP’s sending rate equation for the acceptable sending rate as a function of loss rate p and RTT kS T RT T p Also has a complicated version equation M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 13/45
TFRC - match TCP average sending rate Use TCP’s sending rate equation for the acceptable sending rate as a function of loss rate p and RTT kS T RT T p Also has a complicated version equation Control process Receiver: report to sender the estimated p and RT T , one per RT T Sender: send video @ the computed rate M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 13/45
TFRC vs TCP: UCL- AICIR M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 14/45
TFRC vs TCP: Hongkong- Berkeley M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 15/45
Several observations TFRC is more suitable for streaming video Smooth sending rate Decouple rate control and error control M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 16/45
Several observations TFRC is more suitable for streaming video Smooth sending rate Decouple rate control and error control So, until now we have Wired DATA TCP VIDEO TFRC M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 16/45
Several observations TFRC is more suitable for streaming video Smooth sending rate Decouple rate control and error control So, until now we have Wired DATA TCP VIDEO TFRC TFRC and TCP all assume packet loss is a sign of congestion Decrease the sending rate when packet loss happen May suffer underutilization when packet loss are not necessary a sign of congestion. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 16/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 17/45
Packet loss may caused by channel error Wireless channel is not perfect, channel error also cause packet loss packet loss / congestions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 18/45
Packet loss may caused by channel error Wireless channel is not perfect, channel error also cause packet loss packet loss / congestions Break down TCP and TFRC’s assumption that packet loss is ONLY caused by congestion M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 18/45
Packet loss may caused by channel error Wireless channel is not perfect, channel error also cause packet loss packet loss / congestions Break down TCP and TFRC’s assumption that packet loss is ONLY caused by congestion Is it serious? On Lucent WaveLAN, TCP achieves 22% utilization on wireless [Balakrishnan, talk 98’] In 1xRTT CDMA network, TFRC achieves 56% utilization on wireless [Chen and Zakhor, Infocom ’04] M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 18/45
Design new protocols for wireless? Practical issue Change every computer? Use different protocols depending on wired or wireless? Needs to answer a fundamental question first What is the minimal cost to pay, to make it possible to remain high utilization? Modification to application layer? Transport layer? Network Layer? Hardware? M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 19/45
TCP over wireless: Tons of efforts Differentiate between congestion and physical channel loss Apply traditional wired-line rate control M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 20/45
TCP over wireless: Tons of efforts Differentiate between congestion and physical channel loss Apply traditional wired-line rate control Changes needed to the infrastructure Balakrishnan et.al. SIGCOMM 96 Ding and Jamalipour PIMRC 01 Ratnam and Matta International Journal of Communications 03 Cobb and Agrawal ISCC 95 Choi et.al. IWMWCN 02 Chiasserini and Meo Globecom 01 Huang et.al. ACM WWMM 02 ECN or ELN based Balakrishnan and Katz Globecom 98 Yang et.al. Globecom 02 End-to-end statistics based Biaz and Vaidya SASSET 99 Lee et.al. SPIE 03 Samaraweera Proceeding of communications 99 Sinha et.al. WCNC 99 Cen et.al. MMCN 02 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 20/45
Explicit Congestion Notification (ECN) Use ECN as a sign of congestion, rather than packet loss Solve the problem perfectly Need to modify router Need to modify protocols Yaling Yang, Honghai Zhang, Kravets R. Channel quality based adaptation of TCP with loss discrimination. [Conference Paper] GLOBECOM’02 - IEEE Global Telecommunications Conference. Conference Record (Cat. No.02CH37398). IEEE. Part vol.2, 2002, pp.2026-30 vol.2. Piscataway, NJ, USA M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 21/45
Indirect TCP: split the connection Optimize for wired and wireless separately Single point failure Need to modify base station Violates end-to-end semantics A. Bakre and B. R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. In Proc. 15th International Conf. on Distributed Computing Systems (ICDCS), May 1995. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 22/45
Link-layer: local retransmission e.g. Snoop: Maintain end-to-end semantics Need to modify base station Fail to work if asymmetric forward and feedback routes Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, and Randy Katz. A Comparison of Mechanisms for Improving TCP Performance over Wireless Links. Proc. ACM SIGCOMM Conference, Stanford, CA, USA, Aug 1996. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 23/45
Performance Characterization I M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 24/45
Cross layer information integration Assume wireless packet loss can be notified from the link layer on end host. Fail to work if wireless is not the last link. Not sure about how practical it is. F. Yang, Q. Zhang, W. Zhu, and Y.-Q. Zhang, "’End-to-End TCP-Friendly Streaming Protocol and Bit Allocation for Scalable Video over Mobile Wireless Internet", IEEE Infocom 2004 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 25/45
End-to-end statistics based Need to modify protocols Not sure about the accuracy under various topologies S. Biaz, N. H. Vaidya, "Discriminating congestion loss from wireless losses using inter-arrival times at the receiver", Proc. of IEEE Symposium on Application-specific System and Software Engr. and Techn., pp. 10-17, Richardson, TX, Mar 1999. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 26/45
Several questions unanswered What is the best performance to pursue? How many possible ways to pursue the best performance? Differentiate between congestion and physical channel loss is just one class of approach What is the best approach? Is it possible to achieve the best performance, by only modifying the application layer, i.e. the minimum cost? M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 27/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 28/45
Motivation Rate control is important: fully utilize wireless bandwidth fair to TCP-based applications M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 29/45
Motivation Rate control is important: fully utilize wireless bandwidth fair to TCP-based applications TFRC (TCP-friendly Rate Control) and TCP assume packet loss is caused by congestion wire-line Internet M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 29/45
Motivation Rate control is important: fully utilize wireless bandwidth fair to TCP-based applications TFRC (TCP-friendly Rate Control) and TCP assume packet loss is caused by congestion wire-line Internet Wireless physical channel also causes packet loss: In 1xRTT CDMA network, TFRC achieves 56% utilization on wireless M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 29/45
Motivation Rate control is important: fully utilize wireless bandwidth fair to TCP-based applications TFRC (TCP-friendly Rate Control) and TCP assume packet loss is caused by congestion wire-line Internet Wireless physical channel also causes packet loss: In 1xRTT CDMA network, TFRC achieves 56% utilization on wireless Open issues Wired Wireless DATA TCP VIDEO TFRC ? M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 29/45
Goal: highest throughput, lowest end-to-end packet loss rate A simple scenario Bw - available wireless bandwidth pw - packet loss rate due to channel error pc - packet loss rate due to congestion on node 2 p pw pc (1 pw ) - end-to-end packet loss rate Assumptions for analysis wireless packet loss process is stationary wireless link is the bottleneck M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 30/45
Goal: highest throughput, lowest end-to-end packet loss rate A simple scenario Bw - available wireless bandwidth pw - packet loss rate due to channel error pc - packet loss rate due to congestion on node 2 p pw pc (1 pw ) - end-to-end packet loss rate Assumptions for analysis wireless packet loss process is stationary wireless link is the bottleneck Maximum throughput: Bw (1 pw ) p pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 30/45
Conditional for Underutilization Since p pw , TFRC sending rate T : kS kS T Tb rtt p rtt pw k - constant S - packet size rtt - end-to-end round trip time M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 31/45
Conditional for Underutilization Since p pw , TFRC sending rate T : kS kS T Tb rtt p rtt pw k - constant S - packet size rtt - end-to-end round trip time M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 31/45
Conditional for Underutilization Since p pw , TFRC sending rate T : kS kS T Tb rtt p rtt pw k - constant S - packet size rtt - end-to-end round trip time Sending rate at maximum if and only if pc 0, i.e. no congestion Tmax Tb M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 31/45
Conditional for Underutilization Since p pw , TFRC sending rate T : kS kS T Tb rtt p rtt pw k - constant S - packet size rtt - end-to-end round trip time Sending rate at maximum if and only if pc 0, i.e. no congestion Tmax Tb A sufficient and necessary condition for underutilization Tb B w M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 31/45
Existing Work Differentiate between congestion and physical channel loss put only pc into account when doing rate control M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 32/45
Question Can we achieve best possible performance using an end-to-end solution? Best is defined as: Maximize throughput Minimize end-to-end packet loss rate M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 33/45
Proposal : open multiple TFRC connections Example case: Bw 2.5Tb , open n TFRC: n 1: throughput Tb (1 pw ), p pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 34/45
Proposal : open multiple TFRC connections Example case: Bw 2.5Tb , open n TFRC: n 1: throughput Tb (1 pw ), p pw n 2: throughput 2 Tb (1 pw ), p pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 34/45
Proposal : open multiple TFRC connections Example case: Bw 2.5Tb , open n TFRC: n 1: throughput Tb (1 pw ), p pw n 2: throughput 2 Tb (1 pw ), p pw n 3: throughput Bw (1 pw ), p pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 34/45
Proposal : open multiple TFRC connections Example case: Bw 2.5Tb , open n TFRC: n 1: throughput Tb (1 pw ), p pw n 2: throughput 2 Tb (1 pw ), p pw n 3: throughput Bw (1 pw ), p pw n nopt 2.5: throughput Bw (1 pw ), p pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 34/45
Optimal Number of Connections Exists for Given Settings Bw 1 M bps Propergation delay: rtt min 168 ms S 1000 bytes pw varies from 0.0 - 0.16 NS-2 simulation M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 35/45
Optimal Number of Connections Exists for Given Settings 1e 06 Throughput (bps) Bw 1 M bps Propergation delay: rtt min 168 ms S 1000 bytes pw varies from 0.0 - 0.16 NS-2 simulation 800000 600000 400000 200000 n 1 0 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0.18 end-to-end packet loss rate 0.8 0.7 0.6 average rtt n 1 0.5 0.4 0.3 0.2 0.1 0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 35/45
Bw 1 M bps Propergation delay: rtt min 168 ms S 1000 bytes pw varies from 0.0 - 0.16 NS-2 simulation Throughput (bps) Optimal Number of Connections Exists for Given Settings n 4 n 4 n 1 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0.18 end-to-end packet loss rate 0.8 0.7 0.6 average rtt 1e 06 900000 800000 700000 600000 500000 400000 300000 200000 100000 0 0.5 0.4 0.3 0.2 0.1 0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 35/45
Bw 1 M bps Propergation delay: rtt min 168 ms S 1000 bytes pw varies from 0.0 - 0.16 NS-2 simulation Throughput (bps) Optimal Number of Connections Exists for Given Settings n 8 n 8 n 4 n 1 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0.18 end-to-end packet loss rate 0.8 0.7 0.6 average rtt 1e 06 900000 800000 700000 600000 500000 400000 300000 200000 100000 0 0.5 0.4 0.3 0.2 0.1 0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 35/45
Bw 1 M bps Propergation delay: rtt min 168 ms S 1000 bytes pw varies from 0.0 - 0.16 NS-2 simulation Throughput (bps) Optimal Number of Connections Exists for Given Settings n 32 n 32 n 8 n 4 n 1 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0.18 end-to-end packet loss rate 0.8 0.7 0.6 average rtt 1e 06 900000 800000 700000 600000 500000 400000 300000 200000 100000 0 0.5 0.4 0.3 0.2 0.1 0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 35/45
Experimental Evidence 1xRTT CDMA data network 8 runs, 30 minutes each number of conn.’s one two three throughput rtt pkt loss (kbps) (ms) rate 57 1357 0.018 48.2 45.6 94 2951 0.032 33.2 31.9 27.8 93 2863 0.046 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 36/45
How to Implement - MULTFRC ave rtt - average rtt rtt min - propagation delay ave rtt rtt min - queuing delay M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 37/45
How to Implement - MULTFRC ave rtt - average rtt rtt min - propagation delay ave rtt rtt min - queuing delay M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 37/45
How to Implement - MULTFRC ave rtt - average rtt rtt min - propagation delay ave rtt rtt min - queuing delay Inversely Increase and Additively Decrease (IIAD) on number of connections: n ( if ave rtt rtt min γ rtt min; n β, n n α/n, otherwise. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 37/45
How to Implement - MULTFRC ave rtt - average rtt rtt min - propagation delay ave rtt rtt min - queuing delay Inversely Increase and Additively Decrease (IIAD) on number of connections: n ( if ave rtt rtt min γ rtt min; n β, n n α/n, otherwise. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 37/45
How to Implement - MULTFRC ave rtt - average rtt rtt min - propagation delay ave rtt rtt min - queuing delay Inversely Increase and Additively Decrease (IIAD) on number of connections: n ( if ave rtt rtt min γ rtt min; n β, n n α/n, otherwise. Empirically choose α β 1, and γ 0.25 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 37/45
NS-2 Simulation Settings pw varies from 0.00 - 0.08 in an increment of 0.02 wireless link is simulated using a wired link exponential error model packet size S 1000 bytes measure throughput every 10 seconds, end-to-end packet loss rate every 30 seconds, average rtt every 100 packets M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 38/45
MULTFRC: Performance Characterization Bw 1 M bps, rtt min 168 ms 0.09 Throughput (bps) 900000 800000 700000 600000 500000 MULTFRC optimal 400000 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 pw 9 0.25 8 0.24 7 0.23 average rtt (s) number of connections 0 end-to-end packet loss rate 1e 06 6 5 4 3 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 pw 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 pw 0.22 0.21 0.2 0.19 2 0.18 1 0.17 0 0 0.16 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 pw M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 39/45
Adaptivity to Channel Condition Bw 1 M bps, rtt min 168 ms, pw : 0.02 0.08 0.02 1e 06 0.34 0.32 0.3 average rtt (s) Throughput (bps) 800000 600000 400000 0.26 0.24 0.22 0.2 200000 0.18 0.16 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) 0.12 end-to-end packet loss rate 12 10 number of connections 0.28 8 6 4 2 0 0.1 0.08 0.06 0.04 0.02 0 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 40/45
MULTFRC Does not Starve TCP Bw 1 M bps. TCP: 0-9000s; MULTFRC: 3000-6000s pw 0 1e 06 1e 06 one TCP MULTFRC total bandwidth 800000 Throughput (bps) 800000 Throughput (bps) pw 0.04 600000 400000 200000 600000 400000 200000 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) 0.12 end-to-end packet loss rate 0.12 end-to-end packet loss rate one TCP MULTFRC total bandwidth 0.1 0.08 0.06 0.04 0.02 0 0.1 0.08 0.06 0.04 0.02 0 0 1000 2000 3000 4000 Time (s) 5000 6000 7000 8000 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Time (s) M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 41/45
MULTFRC: Works in Practice A PC in EECS domain UC Berkeley A laptop connected via 1xRTT CDMA network Average over 8 runs, each lasts for 30 minutes scheme throughput rtt packet loss ave. # (kbps) (ms) rate of conn. one TFRC 54 1624 0.031 N/A MULTFRC 86 2512 0.045 1.8 M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 42/45
Several Observations Limitation: need to detect route change to update the propagation delay estimate, i.e. rtt min. Need more both theoretical works and real experiments to understand and evaluate it. It implies that it is possible to achieve the best performance, by only modifying the application layer. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 43/45
Outline Background on rate control Rate control for data over wired network Rate control for streaming video over wired network Rate control for data over wireless Rate control for streaming video over wireless Conclusions and discussions M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 44/45
Towards the best approach Open issues Wired Wireless DATA TCP ? VIDEO TFRC ? Fundamentally, TCP over wireless and streaming video over wireless have the same problem Multiple connections seems to be a promising solution for the problem Rigors model and analysis is of urgent need to provide a full understanding and to guide the control of number of connections. M. Chen, EE290T : rate control for streaming video – from wired to wireless – p. 45/45
Requirement on streaming video Smooth quality)smooth throughput)smooth sending rate No "pause")prefer non-window based rate control TCP doesn't suit for streaming video Huge variation in sending rate Window based control Unnecessary retransmission M. Chen, EE290T : rate control for streaming video - from wired to wireless - p. 9/45
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
line video streaming is Dynamic Adaptive Streaming over HTTP (DASH) that provides uninterrupted video streaming service to user-s with dynamic network conditions and heterogeneous devices. No-tably, Netflix's online video streaming service is implemented us-Permission to make digital or hard copies of all or part of this work for
OTT STREAMING VIDEO PLAYBOOK FOR ADVANCED MARKETERS 7. OTT Streaming Video vs. CTV (They're Not the Same Thing) While OTT streaming video content can be seen on any internet-connected screen, the majority of OTT streaming viewing—at least in the U.S.—occurs on a connected TV. For example, 80% of Hulu viewing
video server, server-client transmission, and a video client, Zeus can be easily replicated for future live 360 video streaming studies . limited insight to live 360 video streaming. Live 360 video streaming. Jun et al. [33] investigated the YouTube
% N:total number of video streams % :Desired video rate, i.e., the user requested % rate for video stream i % :Data rate after optimization or transcoded % video rate (min means the data rate required to % provide the minimum video resolution of 360p; 0 % means video stream i is dropped) % : Link data rate between AP/BS and user i
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
ASME 2019 Updates 2.27.1.1.1 A communications means between the car and a location staffed by authorized personnel who can take appropriate action shall be provided. 2.27.1.1.3 The communications means within the car shall comply with the following requirements: a) In jurisdictions enforcing NBCC, Appendix E of ASME A17.l/CSA B44, or in jurisdictions not enforcing NBCC, ICC/ ANSI A117.1, ADAAG .
