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

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

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

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

PROMISE Architecture

PROMISE Operation 1.Issue lookup request for object (movie) to the substrate 2.Substrate lookup returns 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

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

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

Peer Characterization Each peer is characterized by two variables: Offered rate, : The maximum sending rate a peer can contribute to the system. Availability, : 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

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

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

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

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 peers Authors claim their approach has a delay on the order of seconds

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.

Segment Goodness The goodness of segment i  j is: where: is a weight factor based on the available bandwidth and level of sharing of the segment is a binary random variable that depends on the loss rate on the segment. It is 1 when a packet is not lost.

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

Peer Goodness Given the goodness measure of each segment, we now calculate the goodness of each peer Calculate goodness of each peer, using: segment goodness of all segments between receiver and sender sender availability, Goodness close to one indicates high availability for that peer and a reliable path from the peer to the receiver

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

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

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

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

Performance (no peer failures)

Performance (peer failures)

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

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 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 , Berkeley, CA, November 2003.