Providing Controlled Quality Assurance in Video Streaming ...


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • It is honor to be here to present our work, providing controlled quality assurance in video streaming across the Internet. This is a joint work with Prof. Zhang and Rohit. There has been many video streaming techniques, what makes us different from other is that our work concentrate on the quality assurance issue across best-effort networks, which distinguish our work from all existing approaches.
  • A video sessions consists of two flows. The P/B frames are sent using a rUDP flow, but the I frames are sent using either a cTCP flow or a TCP flow. In this set of experiments, we compare cTCP/rUDP sessions with TCP/rUDP sessions in the packet losses and retransmission. The x-axis is the number of concurrent sessions, the y-axis is the average number of packet retransmission or packet losses per sessions. Clearly the cTCP/rUDP sessions have much less packet retransmission and losses. This shows the effectiveness of our application-level rate control mechanism.
  • We run another set of experiments to compare the impact on cTCP/rUDP sessions and TCP/rUDP sessions when new sessions join or exsiting sessions leave. In this set of experiments, the link capacity is set to 5.5 times of the maximum requirement rate of the video, which includes both flows. At the beginning, we have 4 sessions started within 10 minutes; then at segment 10 of the 1 st session, we start the 5 th session; at the segment 13 th of the 1 st sessions, we stop the 3 rd and the 4 th session. The x-axis is the index of segment, and the y-axis is the number of packet loss or retransmission. The top two curves are rUDP packet losses in the 1 st TCP/rUDP session and 1 st cTCP/rUDP session. The bottom two curves are packet retransmission in the 1 st TCP/rUDP session and 1 st cTCP/rUDP session.
  • Through experiments and simulations, we already show that Our Controlled BW Sharing scheme can protect the essential data, and provide stable system performance. By reducing the blind BW competition, we can significantly reduce the packet transmissions and packet drops. Because our transport protocols show predictable behavior, we can further apply application-ware traffic management schemes.
  • Providing Controlled Quality Assurance in Video Streaming ...

    1. 1. Providing Controlled Quality Assurance in Video Streaming across the Internet Yingfei Dong, Zhi-Li Zhang and Rohit Rakesh Computer Networking and Multimedia Research Group Dept. of Computer Science and Engineering University of Minnesota
    2. 2. Motivations <ul><li>The Internet: Service-Oriented Network </li></ul><ul><ul><li>Service Requirement: End-to-End QoS </li></ul></ul><ul><ul><li>Service Delivery System: Content Distribution Networks </li></ul></ul><ul><ul><li>On-Demand Large Stored Video Streaming </li></ul></ul><ul><ul><li>--- High Bandwidth requirements </li></ul></ul><ul><ul><ul><li>Wide-Area Stored Video Delivery System </li></ul></ul></ul><ul><ul><ul><li>Common Approach --- Proxy Server System </li></ul></ul></ul>
    3. 3. Proxy Content Delivery Architecture Proxy Server + VPN
    4. 4. Virtual Private Network(VPN) <ul><li>Network- Layer VPN not Leased-Lines, but Service Level Agreements, </li></ul><ul><ul><li>Coarse-grain average : </li></ul></ul><ul><ul><li>T3 VPN, 99.9% available, 120 ms average RTT monthly average </li></ul></ul><ul><ul><li>No rate guarantee for individual flows </li></ul></ul><ul><ul><li>No packet loss/delay guarantee </li></ul></ul><ul><ul><li>Application-level Traffic Management is needed. </li></ul></ul>
    5. 5. System Constraints and Challenge <ul><li>Constraints </li></ul><ul><ul><li>Limited Buffer Space v.s. Huge Video Volume </li></ul></ul><ul><ul><li>Streaming from central servers is required . </li></ul></ul><ul><ul><li>Aggregate B/W v.s. Individual Flow Requirement </li></ul></ul><ul><ul><li>Bandwidth management must be present. </li></ul></ul><ul><ul><li>Stringent Timing v.s. No Delay/Loss Guarantee </li></ul></ul><ul><ul><li>Reliably prefetching is necessary . </li></ul></ul><ul><li>Challenge </li></ul><ul><ul><li>Quality Assurance across Best-Effort Networks </li></ul></ul>
    6. 6. Outline <ul><li>Motivations and Background </li></ul><ul><li>Staggered Two-Flow Streaming </li></ul><ul><li>Control Bandwidth Sharing </li></ul><ul><li>Conclusion and Current Work </li></ul>
    7. 7. Objective and Approaches <ul><li>Controlled Quality Assurance in streaming on the best-effort Internet by exploiting </li></ul><ul><ul><li>Application Information, such as the priority structure in videos (frame-dependency), and flow rate </li></ul></ul><ul><ul><li>Coarse-grain bandwidth assurance of VPN </li></ul></ul><ul><ul><li>Storage / processing capacity of proxy servers </li></ul></ul>
    8. 8. Priority Structure in Videos <ul><li>Two flows in a video session: </li></ul><ul><ul><li>A Reliable Flow for essential data (e.g., I frames) </li></ul></ul><ul><ul><li>An Unreliable Flow for enhanced data (e.g., P/B) </li></ul></ul>
    9. 9. Segment and Staggered Delivery <ul><ul><li>The Reliable Flow is one segment ahead </li></ul></ul>
    10. 10. Staggered Two-Flow Streaming <ul><ul><li>Reliable Flow : I-frame segments, prefetched and cached at proxy . </li></ul></ul><ul><ul><li>Unreliable Flow : P/B-frames segments, real-time delivery subject to adaptation when congestion in the soft VPN pipe. </li></ul></ul><ul><ul><li>Merging both flows at Proxy Server, then send to clients </li></ul></ul>
    11. 11. Illustration Prefetching Cache Proxy Server Central Server best-effort VPN Competition!! To user k k+1 Unreliable Delivery Reliable Prefetching k k+1 k k Merging k
    12. 12. Interesting Issues <ul><li>Data Plane Issues </li></ul><ul><ul><ul><li>Bandwidth Competition </li></ul></ul></ul><ul><ul><ul><li>Unreliable-Flow Rate Adaptation </li></ul></ul></ul><ul><li>Control Plane Issues </li></ul><ul><ul><ul><li>Application-aware Resource Management </li></ul></ul></ul><ul><ul><ul><li>e.g., Admission Control, VPN management, Video placement and migration </li></ul></ul></ul><ul><li>Implementation Issues </li></ul>
    13. 13. Application-Aware Controlled Bandwidth Sharing <ul><li>Stable and Predictable transport protocols </li></ul><ul><li>Controlled TCP (cTCP) </li></ul><ul><ul><li>Application-aware throughput control: A variant of TCP Reno using a simple TCP model to regulate the injection rate. </li></ul></ul><ul><li>Rate-Controlled UDP(rUDP) </li></ul><ul><ul><li>Generating Piece-wise CBR traffic: Extending UDP on FreeBSD with a periodical injection mechanism limited by a leaky-bucket </li></ul></ul><ul><ul><li>Both are implemented in FreeBSD kernel. </li></ul></ul>
    14. 14. TCP: reliable but not fit to our setting <ul><li>Sliding Window ( W ) Injection Control </li></ul><ul><li>W packets per RTT </li></ul><ul><li>AIMD </li></ul><ul><ul><li>Fluctuation : Greedily Increase, back off to half when loss </li></ul></ul><ul><ul><li>Fairness regardless of flow requirements </li></ul></ul>Packet losses even when sufficient B/W
    15. 15. cTCP: a variant of TCP Reno <ul><li>Flow Target Rate T cTCP </li></ul><ul><li>Target Window Size W target </li></ul><ul><ul><li>using a simple TCP bandwidth model to limit the injection to the flow requirement </li></ul></ul><ul><ul><li>If packet loss </li></ul></ul><ul><ul><li>else </li></ul></ul>No slow-start. No packet losses when given sufficient B/W.
    16. 16. Two cTCP Flows v.s. Two TCP Flows On a 64KBps link, the 1st flow with a target rate 13KBps starts 12 seconds earlier than the 2nd flow with a target rate 27KBps
    17. 17. Experimental Environment <ul><li>Controlled Testbed on FreeBSD4.1 </li></ul><ul><ul><li>3 PCs on a dedicated Gbps Ethernet switch </li></ul></ul><ul><ul><li>A central server and a proxy server </li></ul></ul><ul><ul><li>A bandwidth-and-delay control unit emulates a VPN pipe in between, running IP Dummynet </li></ul></ul><ul><li>Testing Video: a 60-minute MPEG-2 video clip </li></ul><ul><ul><li>Target Rate of I frames, 52 KBps </li></ul></ul><ul><ul><li>Target Rate of P/B frames, 200 KBps </li></ul></ul>
    18. 18. Multiple Sessions: cTCP/rUDP v.s. TCP/rUDP <ul><li>RXs in TCP or cTCP </li></ul><ul><li>rUDP Losses </li></ul>A video session of two flows (cTCP/rUDP or TCP/rUDP)
    19. 19. Multiple Sessions (Arrival / Departure) : cTCP/rUDP v.s. TCP/rUDP <ul><li>C = 5 • 1.1 • Max_Rate </li></ul><ul><ul><li>Starting with 4 sessions; </li></ul></ul><ul><ul><li>Then, add one more; </li></ul></ul><ul><ul><li>Later, terminate two. </li></ul></ul><ul><li>Compare the variations of packet RXs and losses </li></ul>
    20. 20. Summary of Controlled BW Sharing <ul><ul><li>Practical quality assurance of the essential data over best-effort networks </li></ul></ul><ul><ul><li>None / Low Packet Losses </li></ul></ul><ul><ul><li>Stable, Predictable System Performance </li></ul></ul><ul><ul><li>Providing chances for applying simple application-aware traffic management </li></ul></ul><ul><ul><li>TCP-firendly: do not grab BW from others </li></ul></ul><ul><ul><li>Patent Pending </li></ul></ul>
    21. 21. Current and Future Work <ul><li>Quality Assurance issues in Service-Oriented Networks </li></ul><ul><ul><li>Scalability in data plane </li></ul></ul><ul><ul><ul><li>Aggregation at the levels of video, session, and flow. </li></ul></ul></ul><ul><ul><ul><li>Network parameters sharing among sessions. </li></ul></ul></ul><ul><ul><li>Service-Oriented B/W Management in control plane </li></ul></ul><ul><ul><ul><li>Application-ware admission control </li></ul></ul></ul><ul><ul><ul><li>Proxy Placement utilizing the topology info. </li></ul></ul></ul><ul><ul><ul><li>Proxy Caching and Video Placement / Migration . </li></ul></ul></ul><ul><ul><li>High-Quality VOD on Cable Broadband Networks. </li></ul></ul>