Packet Video TCP Video Streaming to Bandwidth-Limited Access Links Puneet Mehra and Avideh Zakhor Video and Image Processing Lab University of California, Berkeley

Packet Video Talk Outline Goals & Motivation Our Approach Experimental Results Related Work Conclusion

Packet Video Goal Efficient video streaming using TCP to bandwidth- limited receivers Key Assumptions: Receivers have limited-bandwidth last mile connections to Internet … and run multiple concurrent TCP networking apps Constraints: Should not modify senders or network infrastructure

Packet Video Motivation Increasingly access links are the net. Bottleneck! Limited Bandwidth (B/W)  Less than 1.5MBps Users run concurrent apps  compete for limited B/W Most Traffic on Internet is TCP [HTTP, P2P, FTP] TCP handles recovery of lost packets TCP has congestion control UDP Streaming difficult w/ firewalls Problem: TCP shares bottleneck B/W according to RTT May Not provide enough B/W for streaming apps

Packet Video Example Situation High RTT Med. RTT Low RTT Congestion Most Bandwidth!

Packet Video Talk Outline Motivation & Goals Our Approach Experimental Results Related Work Conclusion

Packet Video Our Approach We developed a receiver-based bandwidth sharing system (BWSS) for TCP [INFOCOM 2003] Key Idea: Break fairness among TCP flows to allow user-specified B/W allocation Approach: Limit throughput of low-priority connections to provide B/W for high-priority ones Ensures full utilization of access link Doesn’t require changes to TCP/senders or infrastructure

Packet Video BWSS Overview

Packet Video Target Rate Allocation Subsystem Some apps need minimum guaranteed rate(video), others don’t (ftp) User assigns each flow: Priority, minimum rate and weight Bandwidth allocation algorithm: Satisfy minimum rate in decreasing order of priority Remaining B/W shared according to weight T1T1 User Prefs. σ TnTn

Packet Video Flow Control System (FCS) w – TCP window RTT – Flow RTT MSS – TCP MSS

Packet Video σ – Calculation Subsystem Goal: Choose σ to maximize link utilization. U = Σ i R i (σ) Approach: Use increase/decrease in measured throughput to guide increase/decrease of σ R1R1 RNRN σ = Σ i T i T 1 = R 1 σ U W2W2 W1W1 Link Capacity T 2 = R 2 T 1 = R 1 T 2 ≠ R 2 T 2 = R 2

Packet Video Talk Outline Motivation & Goals Our Approach Experimental Results Related Work Conclusion

Packet Video Experimental Setup RUDE

Packet Video Experimental Details ETH0 NIST NET Emulator BW = 960 Kbps Delay = 30 ms BWSS – Shared Library APP_1 APP_n APP_2 Invisible to Apps User Level App  easy to deploy

Packet Video TCP vs BWSS Internet Experiments Video streamed at 496Kbps Congestion on access link from 30s to 60s Standard TCP not good enough during congestion TCP BWSS

Packet Video BWSS Reduces Required Pre-Buffering BWSS provides 4X reduction in pre-buffering over standard TCP

Packet Video SureStream TM Experimental Setup RUDE

Packet Video RealVideo SureStream TM Internet Experiments Takeaway: standard TCP not good enough for streaming TCP TCP w/ BWSS Video encoded at 450Kbps, 350Kbps, 260Kbps & 64Kbps Congestion on access link from 60s to 100s (320Kbps) Despite congestion, video streams at steady rate. Poor streaming quality

Packet Video RealVideo SureStream TM Internet Experiments UDP TCP w/ BWSS Takeaway: BWSS can break fairness among flows locally, and provide additional B/W for video apps. UDP SureStream unable to stream at 450KBps till after congestion Constant streaming at 450Kbps

Packet Video Related Work – TCP Streaming Network-Based Approaches Receiver-based Delay Control (RDC) [NOSSDAV 2001] receivers delay ACK packets based on router feedback Mimic a CBR connection End-Host Approaches Time-lined TCP (T-TCP) [ICNP 2002] TCP Real-Time Mode (TCP-RTM) [ICNP 2002] Must modify both sender & receiver to allow skipping “late” packets

Packet Video Conclusions BWSS allows flexible allocation of link B/W Breaks fairness among TCP flows “locally” in manner unavailable to TCP-Friendly UDP protocols BWSS enables efficient video streaming over TCP to bandwidth-limited receivers Better performance than standard TCP In some cases, better performance than congestion-aware UDP Future Work: Incorporating UDP flows

Packet Video Questions?