June 14, 2005ACM NOSSDAV ‘05 Natural Selection in Peer-to-Peer Streaming: From the Cathedral to the Bazaar By : Vivek Vishal Shrivastava Suman Banerjee

June 14, 2005

ACM NOSSDAV ‘05

Natural Selection in Peer-to-Peer Streaming: From the Cathedral to the Bazaar

By : Vivek Vishal Shrivastava

Suman Banerjee

Department Of Computer SciencesDepartment Of Computer Sciences

University of Wisconsin-MadisonUniversity of Wisconsin-Madison

www.cs.wisc.edu/~suman/projects/bazaar

June 14, 2005

ACM NOSSDAV ‘05

Publisher Total Outgoing Bandwidth=500 Kbps

A

Received Bandwidth = 500 Kbps

Publisher outgoingbandwidth is fixed

Client-server approach

Why we need p2p streaming?

June 14, 2005

ACM NOSSDAV ‘05

publisher Total Outgoing Bandwidth=500 Kbps

A


B





June 14, 2005

ACM NOSSDAV ‘05

publisher Total Outgoing Bandwidth=500 Kbps

A


B


C



Each peer gets diminishing bandwidth as number of peers increase



June 14, 2005

ACM NOSSDAV ‘05

publisher

A B

C

p2p approach

What is p2p streaming?

June 14, 2005

ACM NOSSDAV ‘05

How do we get peers to cooperate? Many peers have asymmetric bandwidth links

high receiving capacity low forwarding capacity

Low uplink bandwidth at Internet hosts E.g. DSL, Cable Modems

Reasonable quality of audio/video stream takes at least 350Kbps to encode

Hence, peers may not want to take forwarding responsibilities

Too much uplink bandwidth consumed in forwarding roles

Observation: Many peers are free riders and not altruistic [Saroiu’03]

June 14, 2005

ACM NOSSDAV ‘05

publisher

A B

C


p2p approach

Natural incentives exist in p2p streaming

Total Outgoing Bandwidth=500 Kbps




Client-server approach: received bandwidth = 166 Kbpsp2p approach: received bandwidth = 250 Kbps

Bandwidth share of peers is higher for p2p approach

June 14, 2005

ACM NOSSDAV ‘05

publisher Total Outgoing Bandwidth=500

A

Received Bandwidth = 250

B


C



Bandwidth share of peers is higher than the client-server approach

There exists a natural incentive to share bandwidth even for strategic peers

p2p approach

Understanding natural incentives

June 14, 2005

ACM NOSSDAV ‘05

Our approach summary

we propose a lightweight Bazaar framework

no specific rules imposed on the peers

enables peers to exploit natural incentives in p2p streaming

more peers can receive high bandwidth data

June 14, 2005

ACM NOSSDAV ‘05

Bazaar Streaming Model

Entities in the Bazaar framework A single publisher (ROOT) with fixed outgoing bandwidth Strategic peers attempting to maximize own utility A bootstrap entity (BSE)

• Information repository for the p2p market• Provides appropriate market information to joining peers

Market quote is <Bandwidth, latency> of stream which a peer makes

available to potential downstream peers

June 14, 2005

ACM NOSSDAV ‘05

Bazaar Streaming Model

Utility (content) ∞ benefit (incoming bandwidth) –

cost (forwarding bandwidth) –

cost (latency) Rationale behind exact benefit and cost functions [Chu’04]

bandwidth

perc

eiv

ed u

tilit

y

latencyperc

eiv

ed u

tilit

y

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

Market Quote <500,0>

root

500,0

Quote repository ID <bw,lat>

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

500,0 1

Quote request

Response

(root,<500,0>)root


June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

500,01

Best market quote

(root,<500,0>)

Join request


June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

500,01

Incoming bandwidth=

500 Kbps


June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

500,0 1(600)

Revised Market Quote <250,0>

Market Quote

<300, L1>

If the node is strategic, it will not advertise 500. It will advertise more than 250, which is its parent quote.

Incoming bandwidth=

500 Kbps


1 300,L1

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)

1 300,L1

2200)

Quote request


Incoming bandwidth=

500 Kbps

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)

1 300,L1

2(200)

Response

<root, 250,0>, <1, 300,L1>


Incoming bandwidth=

500 Kbps

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)

1 300,l1

2(200)

Join request

Incoming bandwidth=

500 Kbps


Incoming bandwidth=

300 Kbps

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)

1 275,L1

2(200)

Revised MarketQuote

( 275,L1)

1 sends a revised market update trying to keep it more lucrative

than root

Market Quote (200,L1+L2)

Incoming bandwidth=

500 Kbps


Incoming bandwidth=

300 Kbps

2 200,L1+L2

June 14, 2005

ACM NOSSDAV ‘05

Continuing the example scenario

BSE

root

root

250,0 1(600)

1 150,L1

2(200)

2 200,L1+L2

3(150)

Incoming bandwidth=

500 Kbps


Incoming bandwidth=

275 Kbps

Incoming bandwidth=

275 Kbps

3 150,L1+L3

June 14, 2005

ACM NOSSDAV ‘05

Simulations

simulated on myns p2p network simulator developed at UMD.

using Transit Stub graph with 100 nodes generated using the GT-ITM

topology generator, as our underlying network

simulator uses statically pre-computed routes

links in the underlying network are assumed to have same link delay

June 14, 2005

ACM NOSSDAV ‘05

Simulations

Modes of operation of peers Altruistic

• forward all received• maximize received bandwidth

Strategic • minimize forward bandwidth• maximize received bandwidth

Random• minimize forward bandwidth

Synthetic (bimodal) and Trace-based simulations performed

June 14, 2005

ACM NOSSDAV ‘05

Synthetic Simulations

Participating peers have bimodal capacity distribution

low capacity peers (50Kbps – 450Kbps) high capacity peers (450Kbps – 1Mbps)

Fraction of high capacity peers is varied from 0 to 1

Maximum stream bandwidth = 500Kbps

June 14, 2005

ACM NOSSDAV ‘05

Results

System utility vs peer composition

Syst

em

uti

lity

(norm

aliz

ed)

Fraction of high capacity peers

altruistic

strategic

random

System utility: sum of individual peer utilities, normalized to the minimum achieved among all scenarios

June 14, 2005

ACM NOSSDAV ‘05

Results

Throughput CDF: 20% high (0.5-1 Mbps), 80% low (50-500Kbps)

Thro

ugh

put

(Kb

ps)

Peer Index

altruistic strategic


Thro

ugh

put

(Kb

ps)

Peer Index


Individual peer incoming bandwidth

June 14, 2005

ACM NOSSDAV ‘05

Trace Based Simulations Outgoing capacity of peers is based on the following

live traces Reported in Bharambe et al. [IPTPS’05]

Result summary: As fraction of strategic peers increase, using the Bazaar

framework guarantees that performance does not degrade a lot

Capacity of Peers

High (10 Mbps)

Medium (1.5 Mbps)

Low (100Kbps)

Sigcomm 76 2 22

Slashdot 22 4 74

Gnutella 8 27 65

June 14, 2005

ACM NOSSDAV ‘05

Related Work

Schemes Bandwidth allocation style

Incentive type

Peer type assumed

Payment BasedVCGVCG

Rule BasedTaxation, BitTorrentTaxation, BitTorrent

Altruism BasedESM, NICEESM, NICE

BazaarBazaar

Cathedral

Cathedral

Cathedral

BazaarBazaar

Financial

Rule Based

None

NaturalNatural

Strategic

Strategic

Altruistic

Strategic or AltruisticStrategic or Altruistic

June 14, 2005

ACM NOSSDAV ‘05

Summary

p2p streaming provides natural incentives

Bazaar framework enables efficient tree formation leverages natural incentives performs efficiently in resource poor environments supports arbitrary mix of strategic and altruistic

peers graceful degradation in performance as fraction of

strategic peers increase

June 14, 2005

ACM NOSSDAV ‘05

Thank You !Email: {viveks,suman} @ cs.wisc.edu

Project website: www.cs.wisc.edu/~suman/projects/ba

zaar

June 14, 2005

ACM NOSSDAV ‘05

Discussion

Extend this scheme to a decentralized stock market. Here each peer will enclose its market quote in some kind of heart beat messages and the overall quote will be prepared in an bottom-up fashion

root

3 4

1 2

Self Quote:1

Self Quote :2

Quote:1,2,3

Self Quote :4

Cumulative quote {1,2,3,4}

Now broadcast this global quote

June 14, 2005

ACM NOSSDAV ‘05

Local Reshuffle

Improves efficiency of the overlay structure

Shuffle-k involves peers maximum k levels apart in the overlay

Makes the overlay more robust to local maxima

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)

Incoming bandwidth = 500

1 300,l1

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)


1 300,l1

2200)

Requesting Market Quote

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)


1 300,l1

2(200)

Reply Quote

{{root, 250,0} {1,300,l1}}

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)


1 300,l1

2(200)

Suppose in the previous case peer 2 joins root (on the basis of its own utility

function)

Join Request

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)


1 300,l1

2(200)

Bandwidth update 250

Bandwidth update 250

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


Revised Market Quote of 166,0

Send Quote 200,l2

2 200,l2

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


2 200,l2 Now even peer1s incoming bandwidth is reduced by half. Peer 1 would like to regain its old incoming bandwidth by sending a local quote to its parent

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


2 200,l2

Local Quote {400,l1}

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


2 200,l2

Local Quote {1,400,l1}

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


2 200,l2

Local Quote {1,400,l1}

Now peer 2 considers this revise offer from peer 1 and might switch if its

utility increases according to the new offer

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)


2 200,l2Send Join Request

June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

166,0 1(600)


1 300,l1

2(200)

2 200,l2

Bandwidth Update 400

Bandwidth Update 500

Revised Quote 250

Revised Quote 300


June 14, 2005

ACM NOSSDAV ‘05

Shuffle-1 Example

BSE

root

root

250,0 1(600)


1 300,l1

2(200)

2 200,l2


June 14, 2005

ACM NOSSDAV ‘05

Summary

As the percentage of high capacity peers decrease, our scheme performs closer to that of ideal case

In our scheme, the mean forward and receive bandwidth of the peers follow the same pattern which shows that peers receiving bandwidth from the p2p network also contribute forward bandwidth to the same

Our scheme also performs marginally better than the random scheme.

June 14, 2005

ACM NOSSDAV ‘05

Future Work

Current the scope of our local reshuffling is only limited to the parent node. Introducing a parameter into the system which will control the level of reshuffling will really help in improving performance.

Outgoing Bandwidth limit 400

Incoming bandwidth 133



Outgoing capacity 100





If the yellow node can bring the red ones under itself, then it can increase its own utility But this will require the reshuffling at the level of its grandparent

June 14, 2005

ACM NOSSDAV ‘05

Future Work

Testing the scheme over real-life data set like slashdot

Testing the scheme over varied topology and utility functions. We believe that the performance of the scheme will depend a lot on the type of utility functions used by the peers.

June 14, 2005

ACM NOSSDAV ‘05

References

Selwyn Yuen, Baochun Li, “Strategyproof Mechanisms for Dynamic Multicast Tree Formation in Overlay Networks” , Technical Report, University of Toronto, November 2004

Yuang-Hua Chu, John Chuang, Hui Zhang, “A Case for Taxation in Peer-to-Peer Streaming Broadcast”, SIGCOMM ’04

P.Antoniadis, C.Courcoubetis, “Market Models for Peer-to-Peer content distribution”, Technical Report, MMAPS project, Aug 2002

June 14, 2005

ACM NOSSDAV ‘05

Related work

Lot of research in Incentive based mechanisms for p2p networks

Most of the schemes are developed for p2p file sharing

Some related mechanisms for p2p streaming: Taxation scheme [1] VCG based scheme [2]

June 14, 2005

ACM NOSSDAV ‘05

Related Work (Taxation Scheme)

Proposed in “A case for taxation in Peer-to-Peer Streaming Broadcast”

Introduces the idea of tax from public finance literature into p2p streaming

Publisher is the owner of the content and enforces tax payments on the peers

For peer i , the taxable income is ri and the tax payment is fi

Publisher determines how much bandwidth a peer should contribute to receive a specific bandwidth

June 14, 2005

ACM NOSSDAV ‘05

Related Work (Taxation Scheme)

This scheme maintains the invariate that Σfi > Σri , which means that the total forward bandwidth in the system must be greater than the total receive bandwidth

Utility function used is as follows: Ui= √ri - b*(fi/Fi)*(1-b)*(fi/Fi)4

In the above equation, the last term capture the congestion effect and b lie between [0,1]

June 14, 2005

ACM NOSSDAV ‘05

Example Taxation

fbandwidth = max (t*(r bandwidth-G),0)

t is taxation parameter set statically by the publisher and G is the demogrant pool determined dynamically

The above equation specifies that for a given t & G , in order to receive r amount of bandwidth, a peer should forward f amount of bandwidth

t=1 for Bit Torrent Scheme

t=2 is used by the taxation algorithm

June 14, 2005

ACM NOSSDAV ‘05

Example Taxation

f r

0 1

2 2

4 3

Tax schedule

F R f r U

Peer A

10 3+ 4 3 1.45

Peer B

4 3+ 2 2 1.16

Peer C

1 3+ 0 1 1.0outcome

Linear Taxation with t=2.0, G=1

June 14, 2005

ACM NOSSDAV ‘05

Example Taxation

f r

0 0

2 2

3 3

Tax schedule

F R f r U

Peer A

10 3+ 3 3 1.54

Peer B

4 3+ 2 2 1.16

Peer C

1 3+ 1 1 0.25

outcome

Linear Taxation with t=1.0, G=0 , Bit Torrent Scheme

June 14, 2005

ACM NOSSDAV ‘05

Example VCG Based on celebrated VCG mechanism from

microeconomics

The utility of the peers is modeled as ui= vi + pi

Where vi is the intrinsic valuation of the system, much like the ui of the taxation scheme.

The term pi is called VCG Payment and is used to manipulate the utility of peers to drive the system towards an a state of higher system utility.

June 14, 2005

ACM NOSSDAV ‘05

VCG Scheme According to the scheme used, the

payment for peer i can be computed as pi = Σj≠i (vj – vj

-i)

So the payment received by each peer depends upon the increase in utility of every other peer in the system except itself

So the system pays the peer to the point so that its utility is equal to the value added to the system as a whole

June 14, 2005

ACM NOSSDAV ‘05

VCG Mechanism

Clearly if each peer tries to maximize its utility in the aforementioned manner, then the system utility maximizes

Info Req

Info Req

Info Ack

Info Ack

Join req

Join ack

Node a

Node i Node b

Time

June 14, 2005

ACM NOSSDAV ‘05

Outline

Introduction

Motivation for the problem

Related Work

Proposed Solution

Results

Summary

Future Work

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

Total Outgoing Bandwidth=500


June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution




Outgoing capacity = 300

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution







June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

So we try to harness this inherent incentive in the system to construct an improved overlay for data streaming

A simple market mechanism helps us to achieve the aforementioned goal

June 14, 2005

ACM NOSSDAV ‘05

Outline

Introduction

Motivation for the problem

Related Work

Proposed Solution

Results

Summary

Future Work

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

We extend the utility function used in taxation scheme by adding a latency component to the function

This latency component is concave in shape and captures the decrease in perceived data quality due to delays ui(ri, fi, Fi)= bi(ri) – ci(fi ,Fi) + latency(li)

• Where latency(li) = 1/√latency of peer i wrt publisher

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

Clustering reduces the effective bandwidth for each peer

As peers join under the publisher, the utility of other peers already joined to the publisher decreases marginally

This gives a natural incentive to the peers who have already joined the publisher, to forward bandwidth and try to attract the incoming peer under its own self.

This willingness of forwarding bandwidth will depend on the outgoing capacity of the peer

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

If the peer has a decent outgoing bandwidth link, then it will be in its favor to forward bandwidth to the incoming peer and conserve its own incoming bandwidth from the publisher

So every peer in the system will have a natural incentive (of varying degrees), to forward bandwidth to the incoming peers

The degree of incentive will depend on its utility function (outgoing link capacity)

June 14, 2005

ACM NOSSDAV ‘05

Proposed Solution

Our solution is based on a loose market mechanism without any specific rules being imposed on the peers

In p2p streaming, if the peers do not forward bandwidth to their peer community, then all the peers will try to join the publisher directly

June 14, 2005

ACM NOSSDAV ‘05

Results



Th

roughput

(Kbps)

Number of agents

June 14, 2005

ACM NOSSDAV ‘05

Results

Number of agents


Th

roughput

(Kbps)


June 14, 2005

ACM NOSSDAV ‘05

Introduction

streaming applications

audio/video dissemination over internet

high cost of bandwidth required by the publisher/broadcaster in server client models

June 14, 2005

ACM NOSSDAV ‘05

Models of p2p streaming

two entities publisher : makes the data stream available on

the Internet peer : interested in the stream join the p2p

system

peers construct an overlay structure in a distributed fashion and disseminate the stream along the overlay

increases scalability of the system

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 275,l1

2(200)


2 200,l1+l2

3(150)

Request Market Quote

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 275,l1

2(200)


2 200,l1+l

2

3(150)

Reply Quote {{root,250,0}{1:275,l1}{2:200,l1+l2}}

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 275,l1

2(200)


2 200,l1+l2

3(150)

Join request

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 275,l1

2(200)


2 200,l1+l2

3(450)


Send a revised quote of 150

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 200,l1

2(200)


2 200,l1+l2

3(450)


Sending Bandwidth Update for 230

3 230,l1+l3

June 14, 2005

ACM NOSSDAV ‘05

Example Scenario

BSE

root

root

250,0 1(600)


1 200,l1

2(200)


2 200,l1+l2

3(450)


3 230,l1+l3

June 14, 2005

ACM NOSSDAV ‘05

Results

(Sigcomm): 22% low(100Kbps) 2% medium(1.5Mbps) 76% high(1.5Mbps)

Th

roughput

(Kbps)

Number of peers

June 14, 2005

ACM NOSSDAV ‘05

Results

(Gnutella): 65% low(100Kbps) 27% medium(1.5Mbps) 8% high(1.5Mbps)

Th

roughput

(Kbps)

Number of peers

June 14, 2005

ACM NOSSDAV ‘05

Results

(Slashdot): 74% low(100Kbps) 4% medium(1.5Mbps) 22% high(1.5Mbps)

Th

roughput

(Kbps)

Number of peers

Documents

June 14, 2005ACM NOSSDAV ‘05 Natural Selection in Peer-to-Peer Streaming: From the Cathedral to the Bazaar By : Vivek Vishal Shrivastava Suman Banerjee