04/18/23 ACM Multimedia 2003, Berkeley, CA 1

PROMISE: Peer-to-Peer Media Streaming Using CollectCast

Mohamed Hefeeda1

Joint work withAhsan Habib2, Boyan Botev1, Dongyan Xu1, Bharat Bhargava1

1Department of Computer Sciences, Purdue University 2School of Information and Management Systems, UC Berkeley

Support: NSF

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

Motivations

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

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

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

CollectCast (cont’d)

7

Peer Model

Peers are…- Heterogeneous, limited in capacity, failure-

prone

Peer model- Offered rate Rp < R0

• Maximum rate peer p can (or is willing) to contribute

• Captures heterogeneity and limited capacity

- Availability Ap(t)• The fraction of time peer p is available for streaming

• Captures reliability

8

Peer Model (cont’d)

Availability Ap(t)- A collection of random variables (stochastic process)

- Discrete time

- Captures relation between time of day and bandwidth usage

- Ap(ti) describes behavior of peer p at time ti

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

Peer Selection: End-to-End

Considers: Rp, Ap(t) and e2e available bandwidth and loss rate Ignores: Shared path segments

11

Peer Selection: Topology-Aware

Considers: Rp, Ap(t), e2e available bandwidth and loss rate, and Shared path segments

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

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:

jijiji w xg

otherwise,0

on lost ispacket a if,1 jiji

notx

14

Topology-Aware Selection (cont’d)

Segment weight is a per-peer metric

Example- Consider segment 5->3

- P6 w = 1

- P5 w = 0

p

rsjiSssji

pji R

Rb

w ,)( ,0max,1min

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

rpjiji

pjip

rpjijipp w xAgAG )(

16

Topology-Aware Selection (cont’d)

Mathematically, find Pactv that

Given this formulation, a simple iterative algorithm finds the best active set

uPp

pl

Pppp

RRR

RE

actv

actv

oSubject t

Maximizes G

17

End-to-End Selection

Formulated in a similar (but much simpler) way:

rprp

p

rpp

rpp

rp

rprppp

R

bRbR

w

w

lx

xAG

1

otherwise,

,1

,

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

Rate and Data Assignment (cont’d)

FEC Adaptation- We send at rate α R0 not at αu R0, 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 R0 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

actv

actv

Ppp

Ppprp

R

Rl

L 11

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 R0/2, P2 with R0/4, P3 with R0/2 - Assigned rates: 0.45R0, 0.225R0, 0.45 R0

- Assigned data: 55, 28, 55 packets

p

Pxx

p RR

RR

actv

0ˆ

0

ˆ

2 R

RD pp

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

Monitoring and Adaptation (cont’d)

Network fluctuations- Compute β = (R∑ - R0)/R0 - 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

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

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

Topology Inference: Example

Let us estimate avail bw metric on segment 53

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

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

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

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.25R0, 1.5R0 ]

G B

p

q

30

Simulations: Setup (cont’d)

Streaming session- Rate R0 = 1 Mb/s

- Duration = 60 minutes

- Loss tolerance level αu = 1.2

Peers- Offered rate: uniform in [0.125R0, 0.5R0]

- Availability: uniform in [0.1, 0.9]

- Diverse P2P community

Results are averaged over 100 runs with different seeds

31

Aggregate Rated: No Failures

Careful selection pays off!

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

Size of Candidate Set

Size of candidate set increases with low availability

34

Load on Individual Peers

Average load on individual peers less than 0.25R0

CollectCast does not burden peers

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

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

Packet-Level: Aggregated Rate

Smoother aggregated rate achieved by CollectCast

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

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

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

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

Thank You!

43

Questions?

The extended version of the paper is available at …

http://www.cs.purdue.edu/homes/mhefeeda/promise