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

1
Delay-Aware Push/Pull Protocols for Live Video
Streaming in P2P Systems
http//napa-wine.eu

• Alessandro Russo, Renato Lo Cigno
• DISI University of Trento, Italy
• locigno _at_ disi.unitn.it
• http//disi.unitn.it/locigno

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

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

4
Outline of Talk

• P2P streaming systems, definitions
• Protocols for Chunk Trading
• Push Pull, why both?
• Delay Aware Peer Selection
• Wrap-Up and Future Work

5
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

6
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
7
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

8
Traded Push Pull
Peers to trade with are chosen at random, or
may follow some logic distance, av.
bandwidth, delay, ...
Push can also be blind (many studies assume
so), but duplicated chunks waste bandwidth
9
Node Active and Passive Behavior
Peers transmit and receive chuncks
Peers transmit offers/requests they are active
protocol entities (or clients in Internet
terminology)
the node starts requests/offers
Peers satisfy offers/requests they are passive
protocol entities (or servers in Internet
terminology)
the node receives requests/offers
10
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 w most
  recent available
• In Pull chunks are requested selecting the w
  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

11
The role of Push and Pull Diffusion delay
distribution

• RTT 10,250 ms
• 1,1
• Bp 1.9 ... 3.4 Bs
• Peer Choice R

12
The impact of R/D, parallel tx. a, and window w
RTT 10,250 ms
13
Tail Behavior 95-th percentile, different RTTs
14
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

15
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)

16
THE END

• Thank you!
• Questions?
• Comments?