![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](https://image.slidesharecdn.com/pv-powerpoint2183/85/PV-Powerpoint-4-320.jpg)
![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](https://image.slidesharecdn.com/pv-powerpoint2183/85/PV-Powerpoint-7-320.jpg)
![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](https://image.slidesharecdn.com/pv-powerpoint2183/85/PV-Powerpoint-20-320.jpg)
PV Powerpoint
- 1. TCP Video Streaming to Bandwidth-Limited Access Links Puneet Mehra and Avideh Zakhor Video and Image Processing Lab University of California, Berkeley
- 2. Talk Outline Goals & Motivation Our Approach Experimental Results Related Work Conclusion
- 3. 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
- 4. 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
- 5. Example Situation High RTT Med. RTT Low RTT Congestion Most Bandwidth!
- 6. Talk Outline Motivation & Goals Our Approach Experimental Results Related Work Conclusion
- 7. 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
- 9. 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 T 1 User Prefs. σ T n
- 10. Flow Control System (FCS) w – TCP window RTT – Flow RTT MSS – TCP MSS
- 11. σ – Calculation Subsystem Goal: Choose σ to maximize link utilization. U = Σ i R i ( σ ) Approach: Use increase/decrease in measured throughput to guide increase/decrease of σ R 1 R N σ = Σ i T i T 1 = R 1 σ U W 2 W 1 Link Capacity T 2 = R 2 T 1 = R 1 T 2 ≠ R 2 T 2 = R 2
- 12. Talk Outline Motivation & Goals Our Approach Experimental Results Related Work Conclusion
- 14. Experimental Details Invisible to Apps User Level App easy to deploy ETH0 NIST NET Emulator BW = 960 Kbps Delay = 30 ms BWSS – Shared Library APP_1 APP_n APP_2
- 15. 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
- 16. BWSS Reduces Required Pre-Buffering BWSS provides 4X reduction in pre-buffering over standard TCP
- 17. SureStream TM Experimental Setup RUDE
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. Questions?