Delay-Aware Push/Pull Protocols for Live Video Streaming in P2P Systems Alessandro Russo, Renato Lo Cigno DISI – University of Trento, Italy disi.unitn.it

ICC NGS, Cape Town, June P2P Multimedia Streaming P2P is cool, but why streaming? And why live, real-time 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

ICC NGS, Cape Town, June 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

ICC NGS, Cape Town, June Outline of Talk P2P streaming systems, definitions Protocols for Chunk Trading Push & Pull, why both? Delay Aware Peer Selection Wrap-Up and Future Work

ICC NGS, Cape Town, June P2P Streaming Systems As in the previous talk... yes, we do talk to each other before presentations  1 source generates media chunks at Bs Mbit/s  Peers receive and transmit chunks The system is unstructured and chunks swarms through the overlay topology  No fixed distribution tree  Each peer is connected to a subset of the other peers Neighborhoods are stable (in this study) Peers are autonomous and not synchronized: they evolve solely based on the protocol, no other coordination supposed

ICC NGS, Cape Town, June Network Model We consider an n-regular topology with symmetric connectivity  Good approx. of a random topology  Easy to construct and maintain Access is the bottleneck and ADSL-like Both upload and download bandwidth follow a simplified reservation sharing mechanism (on UDP) Congestion is avoided setting a maximum to parallel transmissions 3-regular topology

ICC NGS, Cape Town, June Chunk Trading Each peer  Receives chunks from the other peers  Redistributes chunks to neighbour peers Two main drivers of the Chunk Trading Logic:  The protocol  The scheduling (local choices of Peers and Chunks) We focus here on the protocol  Scheduling is “plain” (or trivial if you prefer) Major “fights” discuss benefits of Push or Pull-based protocols (these latter called also data-driven... with no reason ) Indeed there is no reason to use one OR the other, they can be mixed in the same application

ICC NGS, Cape Town, June Traded Push & Pull Push can also be “blind” (many studies assume so), but duplicated chunks waste bandwidth Peers to trade with are chosen at random, or may follow some “logic”: distance, av. bandwidth, delay,...

ICC NGS, Cape Town, June Node Active and Passive Behavior Peers transmit and receive chuncks Peers transmit offers/requests: they are active protocol entities (or clients in Internet terminology) Peers satisfy offers/requests: they are passive protocol entities (or servers in Internet terminology) the node starts requests/offers the node receives requests/offers

ICC NGS, Cape Town, June Selecting Peers and Chunks Peers are selected in the neighborhood  At random – R  Following a distribution weighted by 1/RTT: Delay Aware – D  Selected peers are “poisoned” to avoid deterministic patterns and starvations (e.g. one peer very close and the others far away) In Push: chunks are offered selecting the  most recent available In Pull: chunks are requested selecting the  most needed, i.e., those closer to the playout time (or oldest) Push and Pull phases are asynchronous and compete for the bandwidth resources  Offers are put forward and requests satisfied only if there are available resources on the local link  Model suitable for applications that enforce some sort of shaping Signaling and data transmission are sequential

ICC NGS, Cape Town, June The role of Push and Pull: Diffusion delay distribution RTT = [10,250] ms  = 1,1 Bp = Bs Peer Choice = R

ICC NGS, Cape Town, June The impact of R/D, parallel tx.  and window  RTT = [10,250] ms D R

ICC NGS, Cape Town, June Tail Behavior: 95-th percentile, different RTTs Delay Aware bandwidth reduction

ICC NGS, Cape Town, June Summary and Future Work – Summary Analysis and insight in a flexible protocol (Push/Pull) for P2P streaming Assessment of the impact (very positive) of selecting peers in your neighborhood based on their RTT, one of the few easy-to-measure network characteristics Study of some tuning parameters of the basic protocol

ICC NGS, Cape Town, June Summary and Future Work – Work... Implementation of Push/Pull in GRAPES libraries: done! Implementation of P2PTV streamers in NAPA-WINE peers based on Push/Pull protocols, to compare with other offer/select protocols: under way Exploration of tradeoffs between building delay-aware topologies with random peer choice, vs. random topologies vs delay-aware peers selection: to be done Integration of delay-aware techniques with other network- aware strategies: in discussion & first tests Improvements and open issues for parallel signaling and chunk transfer: under way (both simulation & implementation)

ICC NGS, Cape Town, June THE END Thank you! Questions? Comments?