1 / 22

Scheduling P2P Multimedia Streams: Can We Achieve Performance and Robustness?

Scheduling P2P Multimedia Streams: Can We Achieve Performance and Robustness?. Luca Abeni, Csaba Kiraly , Renato Lo Cigno DISI – University of Trento, Italy kiraly@disi.unitn.it. P2P Multimedia Streaming. P2P is cool, but why streaming? Think of out-of-country TV broadcasting

emmy
Télécharger la présentation

Scheduling P2P Multimedia Streams: Can We Achieve Performance and Robustness?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scheduling P2P Multimedia Streams: Can We Achieve Performance and Robustness? Luca Abeni, Csaba Kiraly, Renato Lo Cigno DISI – University of Trento, Italy kiraly@disi.unitn.it

  2. P2P Multimedia Streaming • P2P is cool, but why streaming? • Think of out-of-country TV broadcasting • easier to get Internet connection than a satellite dish • Think of the cost of starting a new TV channel • traditional TV broadcasting vs. client-server vs. P2P • P2P-TV could become one of the dominant multimedia applications on the Internet • Some systems already deployed: PPLive, TVAnts, CoolStreaming, … with hundreds of channels already available IMSAA 2009, Bangalore, 9-11 December 2009

  3. P2P Multimedia Streaming contd. • P2P-TV is resource-hungry • previously unseen traffic volumes to/from the users • 1+ mbit/s sustained download • Even higher upload (if available) • P2P-TV is challenging to design • large peer count with heterogeneous networking resources • This is not VoD, potentially millions of users watching the same live channel • tight delay constraints • This is not file sharing, delay is the design objective IMSAA 2009, Bangalore, 9-11 December 2009

  4. Achieve Performance & Robustness • Several design challenges • organizing and maintaining the P2P overlay • scheduling information transmission between peers • etc. • In this work, we • concentrate on scheduling for chunk-based P2P streaming • study different combinations of peer and chunk selection strategies • propose a new peer selection strategy that achieves both performance and robustness IMSAA 2009, Bangalore, 9-11 December 2009

  5. Outline of Talk • P2P streaming systems, definitions • The scheduling problem • Chunks selection strategies (RUc, LUc, DLc) • Peers selection strategies (RUp, MDp, ELp, BAWp) • The optimal ones … are these robust? • Bandwidth-Aware ELp Algorithm (BAELp) • Algorithms Comparison IMSAA 2009, Bangalore, 9-11 December 2009

  6. P2P Streaming Systems • A source generates encoded audio/video • This media stream is divided into chunks • Various peers receive the encoded media and contribute to the diffusion, by forwarding received chunks to other peers • The system is unstructured • No fixed distribution tree • Each peer is connected to a small subset of the other peers (neighbourhood) • Chunks are exchanged among neighbour peers IMSAA 2009, Bangalore, 9-11 December 2009

  7. The Scheduling Problem • Each peer • Receives chunks from the other peers • Redistributes chunks to neighbour peers • Scheduling decision at the sender peer • Which chunk to send? (chunk selection) • To which neighbour send a chunk?(peer selection) • 2 variants • Chunk first selection (XXc/XXp) • Peer first selection (XXp/XXc) We concentrate on chunk first selection! IMSAA 2009, Bangalore, 9-11 December 2009

  8. Chunk Selection • Random Useful (RUc): • select among the chunks useful to at least one neighbour with uniform random choice • Rationale: • If there is enough bandwidth, sooner or later useful chunks get there • easy to implement, widely used as baseline performance • Latest Useful (LUc): • Rationale: spread new chunks as fast as possible • Shown to be fragile: older chunks can be "overtaken“ by newer ones, stopping their diffusion • This fragility increases as neighbourhood size is reduced IMSAA 2009, Bangalore, 9-11 December 2009

  9. Chunk Selection contd. • Deadline-based scheduler (DLc): • Rationale: embed meta-information in the chunk instance • Each copy of each chunk is associated a scheduling deadline, initialized to the chunk generation time • Deadline of the chunk instance in the sender peer is postponed each time chunk is sent • The useful chunk with the earliest deadline is selected • shown to overcome problems of LUc • No “overtaking” effect • good performance with small neighbourhood size We will use DLc in this paper! IMSAA 2009, Bangalore, 9-11 December 2009

  10. Peer Selection • Random Useful Peer (RUp): • Uniform random choice among the peers that need the given chunk • Bandwidth Aware Peer scheduler (BAWp): • Rationale: peers with high upload bandwidth has high redistribution potential • randomly selects a target (as in RUp); the probability of selecting Pj is proportional to its output bitrate. IMSAA 2009, Bangalore, 9-11 December 2009

  11. Peer Selection contd. Earliest-Latest Peer (ELp): • Rationale: key to fast diffusion is to choose a peer that can re-distribute the chunk • Check the latest chunk owned by each peer • And select as a target the peer with the earliest latest chunk IMSAA 2009, Bangalore, 9-11 December 2009

  12. The Optimal Ones • ELp • shown to be optimal in idealized conditions • Homogeneous peers: for each peers • upload bandwidth = stream bandwidth • What happens in heterogeneous networks? • BAwp • Shown to achieve good performance in largely heterogeneous networks • But it falls back to RUp for homogeneous networks! Are any of these robust to various network scenarios? IMSAA 2009, Bangalore, 9-11 December 2009

  13. IMSAA 2009, Bangalore, 9-11 December 2009

  14. Bandwidth-Aware ELp Algorithm • Goal: blend the best properties of bandwidth aware heuristics with ELp optimality • 1st approach: hierarchical scheduling • ELBAp: use EL first. If there is a tie, apply BA among winners • BAELp: BA first, EL after IMSAA 2009, Bangalore, 9-11 December 2009

  15. Bandwidth-Aware ELp Algorithm • 2nd approach: weighted combination • Instead of minimizing L(Pj , t) • the ID of the latest chunk of neighbour node Pj • Consider also • Expected arrival of the chunk to Pj, • though the bandwidth of the sender s(Pi) • Redistribution potential of Pj • through the bandwidth of the target peer s(Pj). • Maximize: t − L(Pj , t) + Bw(s(Pj)/s(Pi)) • Where BW is a weightassigned to the upload bandwidth IMSAA 2009, Bangalore, 9-11 December 2009

  16. Algorithms Comparison • We use the P2PTVSim simulator • Open source, event-driven, chunk level simulation • available at http://www.napa-wine.eu • Critical resource is the overall upload bandwidth in the system • We model the network as upload bandwidth limits at the peer’s access link • Download bandwidth assumed to be unlimited • We study three bandwidth distribution scenarios • Each scenarion has a [0..1] heterogeneity parameter IMSAA 2009, Bangalore, 9-11 December 2009

  17. Bandwidth Distribution Scenarios • We fix the average upload bandwidth at 1 (the source rate) • The 3-class scenario • ADSL like bandwidth distribution • High-, mid- and low-bandwidth classes • h: heterogeneity factor [0..1] IMSAA 2009, Bangalore, 9-11 December 2009

  18. Bandwidth Distribution Scenarios contd. • Uniformly distributed scenario • Peer bandwidth taken from a uniform distribution [1-ΔB,1+ΔB] • To avoid artifacts due to class-based distributions • Free-rider scenario • With peers that only leach, do not contribute IMSAA 2009, Bangalore, 9-11 December 2009

  19. 3-class scenario • 90th percentile as a function of heterogeneity • neighbourhood size 20 • playout delay 50 • 600 peers • 2000 chunks. • Uniform scenario IMSAA 2009, Bangalore, 9-11 December 2009

  20. Excess resources • What if excess upload bandwidth is available? • Performance improves and differences diminish • BAELp uses bandwidth more efficiently neighbourhood size 20; playout delay 50; Uniform with B = 0.8;N = 1000 peers, Mc = 2000 chunks. IMSAA 2009, Bangalore, 9-11 December 2009

  21. Free-riders • What if some users don’t (or can’t) contribute? • Non BA algorithms (even ELBAp) fail at 15-20% of free-riders • BAELp remains top performer neighbourhood size 100; playout delay 50: F90 versus the fraction of the free riders. B = 1, N = 1000 peers, Mc = 2000 chunks. IMSAA 2009, Bangalore, 9-11 December 2009

  22. Summary and Future Work • Summary • We have compared several scheduling algorithms from previous literature, showing their weaknesses • Designed the BAELp algorithm, which outperforms other algorithms in a large number of scenarios • Our future work • Formal analysis of BAELp, and its weight parameter • Improve simulations with video trace driven chunk generation and evaluation of the received video quality IMSAA 2009, Bangalore, 9-11 December 2009

More Related