june 14, 2005acm nossdav ‘05 natural selection in peer-to-peer streaming: from the cathedral to...
TRANSCRIPT
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
Received Bandwidth = 250 Kbps
B
Received Bandwidth = 250 Kbps
Why we need p2p streaming?
Publisher outgoingbandwidth is fixed
Client-server approach
June 14, 2005
ACM NOSSDAV ‘05
publisher Total Outgoing Bandwidth=500 Kbps
A
Received Bandwidth = 166 Kbps
B
Received Bandwidth = 166 Kbps
C
Received Bandwidth = 166 Kbps
Publisher outgoingbandwidth is fixed
Each peer gets diminishing bandwidth as number of peers increase
Client-server approach
Why we need p2p streaming?
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
Publisher outgoingbandwidth is fixed
p2p approach
Natural incentives exist in p2p streaming
Total Outgoing Bandwidth=500 Kbps
Received Bandwidth = 250 Kbps
Received Bandwidth = 250 Kbps
Received Bandwidth = 250 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
Received Bandwidth = 250
C
Received Bandwidth = 250
Publisher outgoingbandwidth is fixed
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
Quote repository ID <bw,lat>
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
500,01
Best market quote
(root,<500,0>)
Join request
Quote repository ID <bw,lat>
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
500,01
Incoming bandwidth=
500 Kbps
Quote repository ID <bw,lat>
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
Quote repository ID <bw,lat>
1 300,L1
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
250,0 1(600)
1 300,L1
2200)
Quote request
Quote repository ID <bw,lat>
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>
Quote repository ID <bw,lat>
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
Quote repository ID <bw,lat>
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
Quote repository ID <bw,lat>
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
Quote repository ID <bw,lat>
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
Throughput CDF: 80% high (0.5-1 Mbps), 20% low (50-500Kbps)
Thro
ugh
put
(Kb
ps)
Peer Index
altruistic strategic
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)
Incoming bandwidth = 500
1 300,l1
2200)
Requesting Market Quote
June 14, 2005
ACM NOSSDAV ‘05
Shuffle-1 Example
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
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)
Incoming bandwidth = 500
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)
Incoming bandwidth = 500
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)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
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)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
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)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
2 200,l2
Local Quote {400,l1}
June 14, 2005
ACM NOSSDAV ‘05
Shuffle-1 Example
BSE
root
root
166,0 1(600)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
2 200,l2
Local Quote {1,400,l1}
June 14, 2005
ACM NOSSDAV ‘05
Shuffle-1 Example
BSE
root
root
166,0 1(600)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
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)
Incoming bandwidth = 250
1 300,l1
2(200)
Incoming bandwidth = 250
2 200,l2Send Join Request
June 14, 2005
ACM NOSSDAV ‘05
Shuffle-1 Example
BSE
root
root
166,0 1(600)
Incoming bandwidth = 500
1 300,l1
2(200)
2 200,l2
Bandwidth Update 400
Bandwidth Update 500
Revised Quote 250
Revised Quote 300
Incoming bandwidth = 400
June 14, 2005
ACM NOSSDAV ‘05
Shuffle-1 Example
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
1 300,l1
2(200)
2 200,l2
Incoming bandwidth = 400
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
Incoming bandwidth 133
Incoming bandwidth 133
Outgoing capacity 100
Outgoing capacity 100
Outgoing capacity 100
Incoming bandwidth 110
Outgoing capacity 500
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
Received Bandwidth = 500
June 14, 2005
ACM NOSSDAV ‘05
Proposed Solution
Total Outgoing Bandwidth=500
Received Bandwidth = 500
Received Bandwidth = 300
Outgoing capacity = 300
June 14, 2005
ACM NOSSDAV ‘05
Proposed Solution
Total Outgoing Bandwidth=500
Received Bandwidth = 500
Received Bandwidth = 300
Outgoing capacity = 300
Received Bandwidth = 300
Outgoing capacity = 500
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
altruistic strategic
Throughput CDF: 60% high (0.5-1 Mbps), 40% low (50-500Kbps)
Th
roughput
(Kbps)
Number of agents
June 14, 2005
ACM NOSSDAV ‘05
Results
Number of agents
Throughput CDF: 80% high (0.5-1 Mbps), 20% low (50-500Kbps)
Th
roughput
(Kbps)
altruistic strategic
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)
Incoming bandwidth = 500
1 275,l1
2(200)
Incoming bandwidth = 300
2 200,l1+l2
3(150)
Request Market Quote
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
1 275,l1
2(200)
Incoming bandwidth = 300
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)
Incoming bandwidth = 500
1 275,l1
2(200)
Incoming bandwidth = 300
2 200,l1+l2
3(150)
Join request
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
1 275,l1
2(200)
Incoming bandwidth = 275
2 200,l1+l2
3(450)
Incoming bandwidth = 275
Send a revised quote of 150
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
1 200,l1
2(200)
Incoming bandwidth = 275
2 200,l1+l2
3(450)
Incoming bandwidth = 275
Sending Bandwidth Update for 230
3 230,l1+l3
June 14, 2005
ACM NOSSDAV ‘05
Example Scenario
BSE
root
root
250,0 1(600)
Incoming bandwidth = 500
1 200,l1
2(200)
Incoming bandwidth = 275
2 200,l1+l2
3(450)
Incoming bandwidth = 275
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