PROMISE: Peer-to-Peer Media
Streaming Using CollectCast


Presented by:
Randeep Singh Gakhal
CMPT 886, July 2004
Introduction
• P2P networks are becoming more important given
  their inherent scalability
• Traditionally, P2P architectu...
Challenges of P2P Streaming
  Authors illustrate four key challenges given the
  dynamic characteristics of a P2P network ...
Overcoming the Challenges
• The PROMISE system provides a solution
  based on the following ideas:
  • Selecting sending p...
PROMISE Architecture
• PROMISE peers operate on any P2P substrate
  that provides the following services:
  • Connectivity...
PROMISE Architecture
PROMISE Operation
1. Issue lookup request for object (movie) to the
   substrate
2. Substrate lookup returns 10-20 peers
3...
PROMISE Operation
5. Receiver assigns each sender a sending rate
   based on offered rate and network statistics
6. Receiv...
P2P Service
•    At the application layer, each peer runs a P2P
     service called CollectCast
•    CollectCast is respon...
Peer Characterization
• Each peer is characterized by two variables:
  • Offered rate, R p : The maximum sending rate a pe...
Peer Selection
• Searching gives the receiver a set of potential
  senders of the video stream
• How to decide? Two steps:...
Topology Inference
• Construct a logical topology:
  • We can get an approximate logical topology by
    performing tracer...
Topology Inference
• Annotate logical topology with available
  bandwidths:
  • Test whether a path can handle the aggrega...
Topology Inference
• Annotate topology with loss rate:
  • Tests of bandwidth also provide loss rate
    information
  • U...
Determining Sender Quality
•   Using the bandwidth and loss annotations for
    the segments in our topology, we:

    1. ...
Segment Goodness
• The goodness of segment ij is:
                    gi   j   wi   j   Xi   j
  where:
  • wi j is a wei...
Segment Goodness
• The weight of segment ij is a value on the
  interval [0,1] and is a function of:
  • the bandwidth of...
Peer Goodness
• Given the goodness measure of each segment, we
  now calculate the goodness of each peer
• Calculate goodn...
Active Peer Selection
• To determine which peers to actually use, we
  must solve an optimization problem
• We want to max...
Data Assignment
• The question remains: “who sends what?”
• Each movie is divided into segments
• The receiver assigns a s...
Dynamic Switching
• Peer failure detected by:
  • Timeouts on TCP channel
  • Degradation in UDP data stream
• Look for re...
Evaluation
• Authors developed a simulation to evaluate
  CollectCast and PROMISE:
  • 1000 hosts and 600 routers
  • Cand...
Performance (no peer failures)
Performance (peer failures)
Conclusions
• PROMISE provides a P2P media streaming
  solution built on an application level service
  called CollectCast...
Reference
1.   M. Hefeeda, A. Habib, D. Xu, B. Bhargava, and B. Botev, CollectCast: A
     Peer-to-Peer Service for Media ...
Upcoming SlideShare
Loading in …5
×

[slides]

176 views
142 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
176
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

[slides]

  1. 1. PROMISE: Peer-to-Peer Media Streaming Using CollectCast Presented by: Randeep Singh Gakhal CMPT 886, July 2004
  2. 2. Introduction • P2P networks are becoming more important given their inherent scalability • Traditionally, P2P architectures provide distributed filesharing • Video streaming is a more challenging problem given its strict resource requirements • Hefeeda et al propose an application level P2P video streaming system that aggregates simultaneous streams from multiple peers called PROMISE
  3. 3. Challenges of P2P Streaming Authors illustrate four key challenges given the dynamic characteristics of a P2P network : 1. A sender can terminate its transmission at any time 2. The bandwidth from one of the senders can change 3. The connection between a sender and receiver can exhibit variable end-to-end bandwidth, loss, and failure rate 4. The connections between the receiver and the senders are NOT independent
  4. 4. Overcoming the Challenges • The PROMISE system provides a solution based on the following ideas: • Selecting sending peers judiciously • Constantly monitoring statistics at each sender and general network status • Switching to alternate senders when service from a sender reaches an unacceptable level
  5. 5. PROMISE Architecture • PROMISE peers operate on any P2P substrate that provides the following services: • Connectivity between peers • Management of peer membership • Object lookup • PROMISE is agnostic to the type of substrate employed
  6. 6. PROMISE Architecture
  7. 7. PROMISE Operation 1. Issue lookup request for object (movie) to the substrate 2. Substrate lookup returns 10-20 peers 3. Receiver creates logical topology annotated with bandwidths and loss rates of segments 4. Use annotation to determine: • active sender set: peers that will give best quality streaming session • standby sender set: peers that will substitute failed or degraded peers from active sender set
  8. 8. PROMISE Operation 5. Receiver assigns each sender a sending rate based on offered rate and network statistics 6. Receiver initiates two connections to each sender in active set: • UDP connection for video stream packets • TCP connection for control packets from receiver 7. If anything goes awry with a sender, receiver switches to a different sender and updates network statistics
  9. 9. P2P Service • At the application layer, each peer runs a P2P service called CollectCast • CollectCast is responsible for: 1. Selecting the best sending peers 2. Inferring and monitoring underlying network characteristics 3. Assigning streaming rates and data segments to the sending peers 4. Deciding when a change of sending peers is needed
  10. 10. Peer Characterization • Each peer is characterized by two variables: • Offered rate, R p : The maximum sending rate a peer can contribute to the system. • Availability, Ap : A random variable over [0,1] measuring the probability of the peer being available for streaming • The rate and availability information is collected and maintained by CollectCast
  11. 11. Peer Selection • Searching gives the receiver a set of potential senders of the video stream • How to decide? Two steps: • CollectCast inferrs a network topology using network tomogrophy techniques • We can then calculate a quantitative measure of the segments in the topology, the “goodness”, and then extend to derive the best set of peers
  12. 12. Topology Inference • Construct a logical topology: • We can get an approximate logical topology by performing traceroute in parallel to all senders • Consecutive links become one segment
  13. 13. Topology Inference • Annotate logical topology with available bandwidths: • Test whether a path can handle the aggregate rate from peers using that path • Each peer on shared segment sends at rate and receiver monitors trend in delay differences, looking for an increasing trend as a sign of queuing • Each path is relabeled with bandwidth equal to the bandwidth of the slowest segment
  14. 14. Topology Inference • Annotate topology with loss rate: • Tests of bandwidth also provide loss rate information • Using Bayesian inference, can develop distribution of segment losses • Overhead of Topology Inference? • Recall that the set consists of only 10-20 peers • Authors claim their approach has a delay on the order of seconds
  15. 15. Determining Sender Quality • Using the bandwidth and loss annotations for the segments in our topology, we: 1. Calculate a goodness measure for each segment. 2. Calculate a goodness measure for each peer based on the segments in the path between the receiver and the peer.
  16. 16. Segment Goodness • The goodness of segment ij is: gi j wi j Xi j where: • wi j is a weight factor based on the available bandwidth and level of sharing of the segment • X i j is a binary random variable that depends on the loss rate on the segment. It is 1 when a packet is not lost.
  17. 17. Segment Goodness • The weight of segment ij is a value on the interval [0,1] and is a function of: • the bandwidth of the segment • the aggregate rate of peers sharing the segment • The weight is 1 if the aggregate rate of peers sharing the segment is less than segment bandwidth • Weight is less than 1 if aggregate rate exceeds segment bandwidth
  18. 18. Peer Goodness • Given the goodness measure of each segment, we now calculate the goodness of each peer • Calculate goodness of each peer, G p using: • segment goodness of all segments between receiver and sender • sender availability, Ap Gp Ap gi j Ap wi j xi j i j path( p ,r ) i j path( p ,r ) • Goodness close to one indicates high availability for that peer and a reliable path from the peer to the receiver
  19. 19. Active Peer Selection • To determine which peers to actually use, we must solve an optimization problem • We want to maximize the expected aggregated rate at the receiver within the bounds of the receiver bandwidth • Authors enumerate all possible sets of 3-5 peers that satisfy constraints and then select optimum • Given small input size (10-25 peers), they claim that each call takes only a few tens of milliseconds
  20. 20. Data Assignment • The question remains: “who sends what?” • Each movie is divided into segments • The receiver assigns a set of packets to each peer in proportion to its actual streaming rate • The sender is notified of the packets it is to send for each segment over the control channel
  21. 21. Dynamic Switching • Peer failure detected by: • Timeouts on TCP channel • Degradation in UDP data stream • Look for replacement peer(s) for failed peer by re-evaluating optimization except with set of current active peers as part of the final solution • By keeping existing active peers, we may get a globally non-optimal solution, however, it is more practical
  22. 22. Evaluation • Authors developed a simulation to evaluate CollectCast and PROMISE: • 1000 hosts and 600 routers • Candidate peers (~20) and the receiver were selected randomly • Peers selected using: • CollectCast topology aware technique • An end-to-end technique that does not consider overlapping links • A random technique that selects the active peer set at random
  23. 23. Performance (no peer failures)
  24. 24. Performance (peer failures)
  25. 25. Conclusions • PROMISE provides a P2P media streaming solution built on an application level service called CollectCast • CollectCast provides: • Matching of a requesting peer with the set of senders most likely to provide the highest quality stream • Dynamic adaptation to network fluctuations and peer failure • Bases decisions on inferred network topology and conditions
  26. 26. Reference 1. M. Hefeeda, A. Habib, D. Xu, B. Bhargava, and B. Botev, CollectCast: A Peer-to-Peer Service for Media Streaming, ACM/Springer Multimedia Systems Journal, Submitted, October 2003. 2. M. Hefeeda, A. Habib, B. Botev, D. Xu, B. Bhargava, PROMISE: Peer- to-Peer Media Streaming Using CollectCast, In Proc. Of ACM Multimedia, ACM Multimedia 2003, pages 45-- 54, Berkeley, CA, November 2003.

×