1. Reza Rejaie Computer and Information Science Department University of Oregon Antonio Ortega Integrated Media Systems Center University of Southern California NOSSDAV 2003 Monterey, California 6/3/2003 PALS: Peer-to-Peer Adaptive Layers Streaming

2. Motivation Peer-to-Peer (P2P) networks emerge as a new communication paradigm that improves: Scalability, robustness, load balancing, etc Research on P2P network has mostly focused locating a desired content, not on delivery Audio/Video streaming applications are becoming increasingly popular over P2P network “streaming” a desired content to a peer rather than swapping files, e.g. sharing family videos.  How can we support streaming applications in P2P networks?

3. Streaming in P2P Networks Each peer might have limited resources Limited uplink bandwidth or processing power Several peers should collectively stream a requested content, this could achieve: Higher available bandwidth, thus higher delivered quality Better load balancing among peers Less congestion across the network More robust to peer dynamics But streaming from multiple peers presents several challenges …

4. Challenges How to coordinate delivery among multiple senders? How to cope with unpredictable variations in available bandwidth? How to cope with dynamics of peer participation? Which subset of peers can provide max. throughput, thus max. quality?

5. P2P Adaptive Layer Streaming (PALS) PALS is a receiver-driven framework for adaptive streaming from multiple senders All the machinery is implemented at receiver Using layered representation for streams  Applicable to any multi-sender scenario

6. Justifying Main Design Choices Why receiver-driven? Receiver is a permanent member of the session Receiver has knowledge about delivered packets Receiver knows current subset of active senders Receiver observes each sender’s bandwidth Minimum load on senders => more incentive! Minimum coordination overhead! Why layered representation for stream? Both MD and layered encoding should work Efficiency vs robustness PALS currently uses layered encoded stream

7. Assumptions & Goals Assumptions: All peers/flows are cong. controlled Content is layered encoded All layers are CBR with the same BW* All senders have all layers* List of senders is given * Not requirements Goals: To maximize delivered quality Deliver max no of layers Minimize variations in quality

8. Basic Framework Receiver: periodically requests an ordered list of packets from each sender. Sender: simply delivers requested packets with the given order at the CC rate Benefits of ordering the requested list: Receiver can better control delivered packets Graceful degradation in quality when bw suddenly drops Periodic requests => less network overhead

9. Basic Framework Internet Peer 0 bw (t) 2 1 CCC buf 1 2 bw (t) 3 3 buf Decoder Demux C buf 0 bw (t) 0 BW 0 1 2 Peer 1 Peer 2 Receiver keeps track of EWMA BW from each sender  EWMA overall throughput  estimate total no of pkts to be delivered during a period (K) Allocate K pkts among active layers (Quality Adaptation) Controlling bw0(t), bw1(t), …, Assign a subset of pkts to each sender (Packet assignment) Allocating each sender’s bw among active layers Keep senders sync. with receiver

10. Key Components of PALS Quality adaptation (QA): to determine quality of delivered stream, i.e. required packets for all layers during each interval Sliding Window (SW): to keep all senders synchronized with the receiver & busy Packet Assignment (PA): to properly distribute required packets among senders Peer Selection (PS): to identify a subset of peers that provide maximum throughout  We present sample mechanisms for QA, SW and PA.

11. Quality Adaptation Same design philosophy as unicast QA but different approach: Receiver-based Delay in the control loop Multiple senders Periodic adaptation, rather than on per-packet basis Two degrees of control Add/drop top layer(s) Adjust inter-layer bandwidth distribution bw (t) 2 1 CCC buf 1 2 bw (t) 3 3 buf Decoder Demux C buf 0 bw (t) 0 Filling phase Draining phase t BW ave bw str bw

12. Quality Adaptation (cont’d) The goal is to control buffer state: Total amount of buffered data Distribution of buffered data among active layers Controlling evolution of buffer state by regulating inter-layer bandwidth allocation (bw0, bw1,..) Efficient buffer state: min no of buffering layers with skewed distribution Efficient buffer state depends on the pattern of variations in bandwidth which is unknown at receiver Alternative solutions: Use measurement to derive the pattern Assume a fix target buffer dist., e.g. buf(i) = n*buf(i+1)

13. Quality Adaptation (cont’d) Run QA algorithm periodically, to plan for one period, Assume EWMA BW remains fix and estimate no of incoming packets Determine fill/drain phase, and no of layers to keep Filling Phase: 1) Sequentially, fill up layers up to next target buffer state with n layers 2) Sequentially, fill up layers up to the target buffer state with n+1 layers 3) Add a new layer, go to Step 1. Drain Phase: 1) Sequentially, drain layers down to previous target buffer state 2) Drop the top layer, go to Step 1 bw (t) 2 1 CCC buf 1 2 bw (t) 3 3 buf Decoder Demux C buf 0 bw (t) 0

14. Sliding Window Keep senders loosely synchronized with receiver’s playout time: Sliding window, send a new request to each sender per window Overwriting, a new request overwrites old one time t p L 0 D L 1 L 2 t min Period Playout time

15. Sliding Window (cont’d) Window size controls the tradeoff between responsiveness vs control overhead. Should be a function of RTT. Difficult to manage senders with major diff in RTT Keep senders busy when BW is underestimated. Reverse Flow Control (RFC): send a new request to a sender before it runs out of packets  How should QA mechanism be coupled with the receiver’s requests to different senders?

16. Coupling QA & SW Synchronized Requesting Send new requests to all senders simultaneously when slides the window forward + QA uses overall BW, rather than per-sender BW - fast sender becomes idle or overwriting slow senders - hard to manage senders with major difference in RTT. Asynchronous Requesting Send a new request to a sender when RFC signals + Effectively manages different senders separately - Requires different approach to QA, i.e. QA should factor in individual BW

17. Packet Assignment Given a pool of required packets in one interval, how to assign packets to senders? Number of assigned packets to a sender depends on its BW Need to cope with sudden decrease in BW Order each requested list based on importance of packets How to order all packets? How to divide them among senders?

18. Packet Assignment (cont’d) Criteria for ordering packets, e.g. lower layers or lower playout time. Weighted round robin packet assignment Ideal patternefficient pattern

19. Preliminary Evaluation Synchronized requesting Configurations 3 PAL senders over RAP connections with diff RTT 10 TCP background flows window size = 4 * SRTT spal2 spal1 spal0 20ms 5 Mb 10 TCP 5ms 10 Mb 15ms 10 Mb 25ms 10 Mb

20. Scenario I

21. Scenario II

22. Related Work Streaming from multiple senders MD [Apostolopoulos et al.] CC streaming [Nguyen et al.] Streaming in P2P networks: form distribution trees from peers CoopNet [Padmanabhan et al.] Existing systems, e.g. Abacast, chaincast,… Structuring a distribution tree e.g. Zigzag [Tran et al.] Other receiver-driven adaptation, RLM [McCanne et al.]

23. Conclusion & Future Work PALS, a receiver-driven framework for streaming from multiple senders Receiver-based QA from multiple senders Keeping sender loosely synchronized Distributing load/packets among senders Future work Extensive simulation, to obtain deeper understanding of the dynamics in PALS Measurement-based derivation of BW variations Peer selection mechanism Effect of peer dynamics Supporting VBR streams and MD encoding

24. Reza Rejaie CIS Department, University of Oregon Antonio Ortega Integrated Media Systems Center University of Southern California PALS: Peer-to-Peer Adaptive Layers Streaming