delay-aware push/pull protocols for live video streaming in p2p systems

Delay-Aware Push/Pull Protocols for Live Video Streaming in P2P Systems

Alessandro Russo, Renato Lo CignoDISI – University of Trento, Italy

locigno @ disi.unitn.ithttp://disi.unitn.it/locigno

http://napa-wine.eu

www.disi.unitn.it/locigno ICC 2010 - NGS, Cape Town, June 26 2010 2

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


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


Outline of Talk

P2P streaming systems, definitions

Protocols for Chunk Trading

Push & Pull, why both?

Delay Aware Peer Selection

Wrap-Up and Future Work


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


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


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


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, ...


Node Active and Passive BehaviorPeers 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 startsrequests/offers

the node receivesrequests/offers


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


The role of Push and Pull: Diffusion delay distribution

RTT = [10,250] ms = 1,1Bp = 1.9 ... 3.4 BsPeer Choice = R


The impact of R/D, parallel tx. and window

RTT = [10,250] ms D

R


Tail Behavior: 95-th percentile, different RTTs

Delay Aware

bandwidth reduction


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


Summary and Future Work – Work ... Implementation of Push/Pull in GRAPES libraries: done!

http://napa-wine.eu Implementation of P2PTV streamers in NAPA-WINE

peers based on Push/Pull protocols, to compare with other offer/select protocols: under wayhttp://napa-wine.eu

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)

www.disi.unitn.it/locigno ICC 2010 - NGS, Cape Town, June 26 2010

THE END

Thank you!

Questions? Comments?

delay-aware push/pull protocols for live video streaming in p2p systems

Documents