1. 11/4/2003ACM Multimedia 2003, Berkeley, CA1 PROMISE: Peer-to-Peer Media Streaming Using CollectCast Mohamed Hefeeda 1 Joint work with Ahsan Habib 2, Boyan Botev 1, Dongyan Xu 1, Bharat Bhargava 1 1 Department of Computer Sciences, Purdue University 2 School of Information and Management Systems, UC Berkeley Support: NSF

2. 2  Peer-to-Peer (P2P) systems gained much attention in recent years -File sharing, CFS, distributed processing, streaming  Peers characterized as [Saroiu, et al. 02] -Highly diverse -Dynamic -Have limited capacity, reliability  Problem -How to select and coordinate multiple peers to render the best possible quality streaming? Motivations

3. 3  Previous work either -Assume one sender, e.g., [Tran, et al. 03] [Bawa, et al. 02] Ignores peer limited capacity -Or, multiple senders but no careful selection, e.g., [Padmanabhan, et al. 02] [Nguyen & Zakhor 02] Ignores peer diversity and network conditions  Our Solution -CollectCast -PROMISE

4. 4 Outline  Overview of CollectCast  Peer model  Peer selection  Rate and data assignment  Monitoring and adaptation  Topology inference and labeling  Simulations  PROMISE and experiments on PlanetLab  Conclusion and future work

5. 5 CollectCast  CollectCast is a new P2P service -Middleware layer between a P2P lookup substrate and applications -Collects data from multiple senders  Functions -Infer and label topology -Select best sending peers for each session -Aggregate and coordinate contributions from peers -Adapt to peer failures and network conditions

6. 6 CollectCast (cont’d)

7. 7 Peer Model  Peers are… -Heterogeneous, limited in capacity, failure- prone  Peer model -Offered rate R p < R 0 Maximum rate peer p can (or is willing) to contribute Captures heterogeneity and limited capacity -Availability A p (t) The fraction of time peer p is available for streaming Captures reliability

8. 8 Peer Model (cont’d)  Availability A p (t) -A collection of random variables (stochastic process) -Discrete time -Captures relation between time of day and bandwidth usage -A p (t i ) describes behavior of peer p at time t i

9. 9 Peer Selection  Given a set of candidate peers, select sending peers  Three approaches -Random Selection -End-to-End Selection -Topology-Aware Selection (used in CollectCast)

10. 10 Peer Selection: End-to-End  Considers: R p, A p (t) and e2e available bandwidth and loss rate  Ignores: Shared path segments

11. 11 Peer Selection: Topology-Aware  Considers: R p, A p (t), e2e available bandwidth and loss rate, and Shared path segments

12. 12 Topology-Aware Selection (cont’d)  Goodness Topology -Directed graph that interconnects candidate peers and receiving peer -Edge ≡ one or more links with no branching points (we call it path segment) -Each segment is labeled with a quality or goodness metric -Built in two steps Network tomography techniques are used to infer and label topology with loss rate and available bandwidth Transform network metrics to a combined logical goodness metric

13. 13 Topology-Aware Selection (cont’d)  Assume we have an inferred topology with loss rate and available bandwidth (later, we discuss how to get that)  We define segment goodness as:  w: weight based on available bandwidth and level of sharing  x: binary random variable that depends on loss rate:

14. 14 Topology-Aware Selection (cont’d)  Segment weight is a per-peer metric  Example -Consider segment 5->3 -P6  w = 1 -P5  w = 0

15. 15 Topology-Aware Selection (cont’d)  Peer goodness: How good this peer is for the session  Active Peer Selection Problem: Given the goodness topology, find the set of active peers that maximizes the expected aggregate rate at the receiver, provided that the receiver in-bound bandwidth is not exceeded

16. 16 Topology-Aware Selection (cont’d)  Mathematically, find P actv that  Given this formulation, a simple iterative algorithm finds the best active set

17. 17 End-to-End Selection  Formulated in a similar (but much simpler) way:

18. 18 Rate and Data Assignment  Erasure Codes (FEC) in CollectCast -To tolerate packet losses -We use them in (somewhat) adaptive way -Media file is divided into data segments -Each is pre-encoded separately using FEC(α u ) -α u : is the maximum loss tolerance level -Example: Let α u =1.25  can tolerate up to 25% loss rate Original segment size Δ = 120 packets  Encoded segment size = 160 packets, from which any 120 packets can reconstruct the original segment  We use Tornado codes [Byers, et al. 98] Fast decoding, albeit with little decoding inefficiency

19. 19 Rate and Data Assignment (cont’d)  FEC Adaptation -We send at rate α R 0 not at α u R 0, where α l ≤ α ≤ α u -α: is the currently needed loss tolerance level, which is based on the current network conditions: -That is, we send at aggregate rate that will likely yield the desired rate R 0 after losing L ∑ % of the packets. -Example: Let α u =1.25, Δ = 120 packets  encoded segment size = 160 Let α = 1.125  We send at 1.125 R0  we send only 138 -Therefore, we alleviate some of the FEC concerns

20. 20 Rate and Data Assignment (cont’d)  Rate assignment: proportional to the peer’s offered rate  Data assignment: proportional to the assigned rate  For the previous example, if we have three peers: -P1 with offered rate R 0 /2, P2 with R 0 /4, P3 with R 0 /2  -Assigned rates: 0.45R 0, 0.225R 0, 0.45 R 0 -Assigned data: 55, 28, 55 packets

21. 21 Monitoring and Adaptation  Peer failure -Detect in two ways Control channel (TCP) Rate degradation -Replace/switch Update the topology with current measurements Solve the maximization problem, provided that the current good peers are included in the active set  May not be optimal, but  Do not want to tear down all current connections

22. 22 Monitoring and Adaptation (cont’d)  Network fluctuations -Compute β = (R ∑ - R 0 )/R 0 -If β < 0 (network is losing more than the current tolerance level) Compute α new If α new ≤ α u, assign new rates Else add/replace peer(s) -Else if β > threshold (we are sending redundant packets) Reduce α, assign new rates -Else (we are just fine) Do nothing

23. 23 Topology Inference  Network Tomography -Infer internal network characteristics from e2e probing [Coates, et al., 02], [Bestavros, et al. 02], [Harfoush, et al. 03] -Premise in literature Applications may achieve significant performance gain Few applications make use of it Why? Techniques are generic and quite expensive -Our contribution Adapt some of them to problem in hand Show a concrete example for the potential benefits -CollectCast is orthogonal to inference techniques Few years later  better techniques CollectCast is ready!

24. 24 Topology Inference (cont’d)  Measuring available bandwidth -Basic technique [Jain & Dovrolis 02] End-to-end path available bandwidth (not segment-wise) Idea: one-way delay differences of a periodic packet stream is a good indication for the available bandwidth -Our approach Not interested in the “exact” bandwidth, rather Can a path accommodate the aggregate rate from peers? One peer may not be able to send at R 0, coordinate multiple of them to do the task. It’s a P2P world!! Conservatively mark all segments with the min avail bw Send real data (from the movie) as probes! Trade-off unneeded accuracy with much less overhead

25. 25 Topology Inference: Example  Let us estimate avail bw metric on segment 5  3

26. 26 Topology Inference: Loss Rates  We already have them e2e -During avail bw measurements, record lost packets -We know data packets that are supposed to be sent  Segment-wise loss rates -Passive network tomography [Padmanabhan, et al. 03 ] -Think of it as a system identification problem -Use ideas from image processing (restoration) field Bayesian inference using Gibbs sampling  Assume initial distribution  Use measured data and initial distribution to compute posterior distribution  Iterate

27. 27 Topology Inference: Overhead  Communication overhead -We use real data for probing  -Little communication overhead! -Receiver needs larger buffer, though (order of Mbytes) -Longer start up time (still order of seconds)  Processing overhead -To run estimation procedures and construct topology -Not a big concern (order of milliseconds) Small topologies (10 – 25 nodes) Fast processors  Frequency of update -Internet path properties (loss, bw, delay) exhibit relative constancy, at least in order of minutes [Zhang, et al. 01]

28. 28 Simulations  Compare selection techniques in terms of -The aggregated received rate, and -The aggregated loss rate -With and without peer failures  Impact of peer availability on size of candidate set  Size of active set  Load on peers

29. 29 Simulation: Setup  Topology -On average 600 routers and 1,000 peers -Hierarchical (Internet-like)  Cross traffic -We approximate its effects through Attaching stochastic loss model to links  Two-state Markov chain  Captures temporal dependence in packet losses [Yajnik et al., 99 ] Randomly vary link bandwidth  Uniform in [0.25R 0, 1.5R 0 ] G B p q

30. 30 Simulations: Setup (cont’d)  Streaming session -Rate R 0 = 1 Mb/s -Duration = 60 minutes -Loss tolerance level α u = 1.2  Peers -Offered rate: uniform in [0.125R 0, 0.5R 0 ] -Availability: uniform in [0.1, 0.9] -Diverse P2P community  Results are averaged over 100 runs with different seeds

31. 31 Aggregate Rated: No Failures  Careful selection pays off!

32. 32 Aggregate Rate: With Peer Failures  Good performance, but starts to degrade as we encounter many failures  How large should the candidate set be?

33. 33 Size of Candidate Set  Size of candidate set increases with low availability

34. 34 Load on Individual Peers  Average load on individual peers less than 0.25R 0  CollectCast does not burden peers

35. 35 PROMISE and Experiments on PlanetLab  PROMISE is a P2P media streaming system built on top of CollectCast  Tested in local and wide area environments  Extended Pastry to support multiple peer look up

36. 36 PlanetLab Experiments*  PROMISE is installed on 15 nodes  Use several MPGE-4 movie traces  Select peers using topology-aware (the one used in CollectCast) and end-to-end  Evaluate -Packet-level performance -Frame-level performance and initial buffering -Impact of changing system parameters -Peer failure and dynamic switching *Most of these results are presented in the extended version of the paper

37. 37 Packet-Level: Aggregated Rate  Smoother aggregated rate achieved by CollectCast

38. 38 Frame-Level: #Frames Missed Deadline  Much fewer frames miss their deadlines with CollectCast  CollectCast requires, on the average, half of the initial buffering time to ensure all frames meet their deadlines

39. 39 System Parameters: Segment Size  Larger segments  more packets  longer time to reconstruct  more delayed frames  Small segments  better quality but more overhead  Segment size of 1 to 2 seconds strikes a balance

40. 40 Conclusions  New service for P2P networks (CollectCast) -Infer and leverage network performance information in selecting and coordinating peers  PROMISE is built on top of CollectCast to demonstrate its merits  Internet Experiments show proof of concept -Streaming from multiple, heterogeneous, failure- prone, peers is indeed feasible  Extend P2P systems beyond file sharing  Concrete example of network tomography

41. 41 Future Work  Extend CollectCast beyond physical network characteristics -Consider peer trustworthiness/reputation into peer selection -Graph labeled with trust metric -Would enable security-sensitive applications on top of CollectCast

42. 42 Thank You!

43. 43 Questions?  The extended version of the paper is available at … http://www.cs.purdue.edu/homes/mhefeeda/promise