PROMISE: Peer-to-Peer Media Streaming Using CollectCast M. Hefeeda, A. Habib, B. Botev, D. Xu, and...

PROMISE: Peer-to-Peer Media Streaming Using CollectCast

M. Hefeeda, A. Habib, B. Botev,

D. Xu, and B. Bhargava

ACM Multimedia 2003, November 2003

Outline

Motivation CollectCast

A new application level P2P service PROMISE operation

Selecting best peers Rate and data assignment Dynamic switching

Simulation results

Service Model

Video-on-Demand (multiple sources)

A peer can request a video from other peers, or operate as a video server.

No other streaming methods (e.g., multicast, batch, chaining, or caching) are involved in this paper.

Motivation

Problems: A sender may failed. The outbound bandwidth of a sender may change. The connections from senders to the receiver may

have different network constraints (end-to-end bandwidth, loss, and failure rate).

The underlying network topology should also be considered.

CollectCast

Developed based on “Pastry”. The three main functions:

Inferring the underlying network topology and providing performance information (for sender selection)

Monitoring the status of peers and connections Dynamically switching while a peer failure or the

rate of this peer is degraded

PROMISE Sender selection

Active sender set Standby sender set

Selection algorithm (select “best” sources) Random selection Topology-aware selection End-to-end selection

Rate and data assignment Forward Error Correction (FEC) Derive the upper/lower bound rates (required by the

selection algorithm) Dynamic switching (fault tolerant)

PROMISE operation.

: Virtual router.

: Receiver

: Peer

: Candidate peers

Internet

Selecting best peers.

The selection techniques: Random

Randomly choose some peers for delivery. Topology-aware

Infer the underlying network topology and its characteristics, then consider the goodness of each segment of the path.

End-to-end consider the “goodness” of individual paths and the

availability of peers.

Goodness

Segment goodness Loss rate Delay Jitter Available bandwidth

Peer goodness Availability (The fraction of time a peer is available for

serving) The goodness of all segments comprising the

path to the receiver.

Topology-Aware Selection(1/3)

:The goodness of the segment .

: segment weight (the available bandwidth and level of sharing on the segment )

: A binary random variable that depends on the loss rate.

:Available bandwidth on .

Rp : a fixed offered rate.

Topology-Aware Selection(2/3)

Example: (for P6)

bij = 0.5

Rs = 0.25

Rp = 0.5

5.05.0/25.05.0,0max,1min)6( jiw

Topology-Aware Selection(3/3)

• : peer goodness• Availability of the sender (Ap) (The fraction of time a peer is available

for serving.)• The goodness of all segments comprising the path

s.t.

Illustrative example

Example:

{P3,P5,P6} =1*0.8+1*0.8+(0.25/0.5)*0.9 =2.05

We can find the peer sets

{P2,P3,P6} has the maximum expected rate 2.4。

: The goodness of a peer p.

: The fraction of time a peer is available for serving.

: path weight

: A binary random variable that depends on the loss rate.

End-to-End Selection

:A fixed offered rate :Available bandwidth on .

Illustrative example

Example:

{P3,P5,P6} =1*0.8+1*0.8+1*0.9 =2.5

We can find the peer sets

{P3,P5,P6} and {P1,P2,P3,P5} have the maximum expected rate 2.5。

Rate and data assignment(1/2)

Use Forward Error Correction (FEC) We use the notation FEC(α) to indicate that the

system can tolerate up to (α-1)% packet loss rate. Ex: FEC(1.25): 25% of packets can be lost.

αhas two bounds: αu; αl , which are the maximum and minimum loss tolerance levels. We use the constraints : Ru = αuR0 and Rl = αlR0 to selection the peers.

Rate and data assignment(2/2) Data segments are pre-encoded using FEC(αu). The lower bound αl is determined by the expected aggregated lo

ss rate. Rate assignment

Each peer is assigned an actual sending rate proportional to its offered rate.

Data assignment Ex: {P1, P2, P3} is the active set. Let P1, P2, and P3 are assigne

d the same sending rate. Then P1 will send the first 1/3 of the video, P2 will send the next 1/3 of the video, and P3 will send the remain parts of the video.

Problem: This is not “streaming“! Ex: P1 may deliver a 1Mbps video at 333Kbps. Sol: P1 delivers {1, 4, 7, 10, …}, P2 delivers {2, 5, 8, 11, …}, and P3 d

elivers {3, 6, 9, 12, …}

Dynamic switching (1/2) A peer failure is detected in two ways:

From the TCP control channel established (e.g., connection reset). If the rate coming from this peer is degraded.

Once a failure is detected, the active set is adjusted by replacing the failed peer with new one(s).

The replacing method is: Choose the replacement peers using the topology-aware selection

from the standby peers. Why not yield a globally optimal solution?

The newly chosen set can be totally different from the old one. (require tearing down all of the old connections and establishing new ones.)

The topology is partially updated, so we use the information gathered at the beginning of the streaming session.

Dynamic switching (2/2)Example:

The possible active sets are{P4, P6},{P3, P5, P6}, {P2,P5, P6}, {P1, P5, P6}, {P3, P4, P5},{P2, P4, P5}, {P1, P4, P5}, {P1, P3, P4}, {P2, P3, P4},{P2, P3, P6}, {P1, P3, P6}, {P1, P2, P4}, {P1, P2, P6}, and {P1, P2, P3, P5}.

Let the active set be {P2, P3, P6}.

If P2 is now failed, the new active set will be {P3, P5, P6} or {P1, P3, P6}.

Simulation results (1/5)

Simulation results (2/5)

Simulation results (3/5)

Simulation results (4/5)

Simulation results (5/5)

?