EquiCast
Scalable Multicast with Selfish Users
Idit Keidar, Roie Melamed, Ariel Orda
Technion
1
Users Are Typically Selfish
• Not willing to share upload bandwidth
• Need incentives in order to contribute
their available resources
Share
with thy
neighbor
What's in
it for me?
2
The Problem
• Long session of single-source multicast
– Push-data: software updates, file distribution
• Peer-to-peer dissemination
• Selfish users
3
Additional Design Goals
• Low overhead
– Independent of network size (scalability)
• Fairness
– Equally distribute multicast load among all
nodes
• Scalable latency, increasing at most like
O(log N), where N is the number of nodes
4
The Game
• Model the system as a non-cooperative
game
• The players: N nodes
• Choose strategies that minimize their
selfish cost
• Dominating strategy: yields better cost
regardless of other users’ actions
5
The Cost Function for Node Ni
Total number of
data packets
Source’s
strategy
N1’s strategy
Number of packets
Ni sent
Why this function?
Number of packets
Ni received
6
Architecture: K-Regular Random Graph
N5
1) Each node’s
degree is k
2) The diameter
is O(log N)
N1
N2
N6
N4
N3
3) All nodes were created equal: the expected distance between
a given node and a random node in the overlay equals the
average distance between a pair of nodes in the overlay
7
P11-P20
The Source’s Protocol
Round #3
#1
#2
P1-P10
N5
S
P1-P10
P21-P30
N1
N2
N6
N4
P21-P30
N3
P11-P20
8
Gossip-Based Multicast
• Data is disseminated through gossip over
the overlay’s links
9
Phase I: Gossip
I have packets P1,
P3, P8, and P9
N1
N5
N2
N6
N4
N3
I have packets P1,
P4, P6, and P7
10
Phase II: Process Gossip,
Send Requests Send me packets P4,
P6, and P7
Send me packets P1,
P3, and P9
N1
N5
N2
N6
N4
N3
11
Phase III: Send Data
Packets P4, P6, and
P7
Packets P1, P3, and
P9
N1
N5
N2
N6
N4
N3
12
If All Nodes Cooperate
[Melamed and Keidar, NCA 2004]
• Fairness: all nodes send the same number of
packets
– Due to overlay’s properties and S’s random injections
• Pair-wise fairness: help each neighbor as much
as it helps me
– Due to overlay’s properties and S’s random injections
• Low overhead: no redundant packets sent
• How do we achieve these nice properties with
selfish users?
13
In Selfish Environments…
• Monitor neighbors'
contribution
– Compare against
expected throughput
• Disconnect from
N1 sent me 17 packets
N2 sent me 21 packets
…
neighbors that do not
deliver the goods
– Cannot be on a perround basis, due to
randomness
14
Monitoring Neighbors
• Allow slack in imbalance in order to account for
•
randomness
Define lower bound L on allowed imbalance
• In each round, for each neighbor n:
– neighbor_balance[n] += received messages expected throughput
– if (neighbor_balance[n] < L) "n is in trouble!"
What does it
mean?
Should I
disconnect
from n?
15
When Node n is in Trouble
• A cooperative neighbor n has a non-zero
probability of having an overdraft of L
– Disconnecting from cooperative nodes is not a good
idea
• A bail-out option: n can ask S to send w data
packets to a given neighbor on behalf of n
– n must send w empty packets to S
– w ≤ expected throughput
– Such packets accepted only for neighbors with a subpar balance
16
Problem with Asking S to Help
• Too lenient towards nodes with a negative
balance
– No penalty for having a low balance
– Nodes not motivated to have positive balance
• A selfish node may let its balance drop without the
risk of being disconnected
• Over-use of this mechanism overloads S
17
Negative Balance Fines
• A neighbor sends an additional fine packet
for every round with a negative balance
• Does not affect the sender’s balance
– Motivates nodes to have non-negative balance
as much as possible
– Thus, minimizes requests from S
18
An Emulated Node
• In case of a disconnection, S can emulate
a selfish rational EquiCast node e
• e’s interface is identical to the interface of
an EquiCast node except…
– n’s balance with respect to e is initialized to L
– In each round, n must send a fine packet to e
• Hence, a node prefers to maintain a connection
with a non-emulated node over an emulated one
20
The Need for L – Lower Bound on
Balance
• If we have a per-round fine, why do we
need L?
• For high data throughput and low
overhead, fines are small
– E.g., 1 fine packet per 50 data packets
• Without L, a selfish node would send only
fine packets
21
Upper Bound on Balance
• Each node selfishly chooses its own upper
bound on its balance wrt its neighbors
• Parameter H
22
Throughput and Goodput
• Expected incoming rate per link per round:
}
– 1 gossip
– 1 request
overhead
– ½ fine
– Tens of data packets (goodput)
• May come from source instead of neighbor
23
Proof of Cooperation
24
Protocol-obedient strategy
(POS)
• Choose your own H
• Maintain connections only with nodes
whose identities are received from S
– choose any subset of them in each round
• Run the protocol's code as is for each of
these connections
26
k-POS
• A POS in which a node maintains exactly k
connections in each round throughout the
entire multicast session is called a k-POS
27
Lemma
• A k-POS strictly dominates every POS in
which n maintains connections with j
nodes, where j≠k
• Rationale:
– If j<k, then the cost is infinite
• Due to bandwidth limitations (see paper)
– If j>k, then the overhead is larger
• Maintaining connections with k nodes suffices in
order to receive all the multicast packets
28
Theorem 1
• If all nodes choose strongly dominating
strategies* out of the set of POSs, then
– every node maintains connections with its
initial k neighbors
– every node receives all the multicast packets
* Strongly dominating strategy: assume
nothing on what others do (except POS)
29
Theorem 1 – Proof Sketch
• Each node chooses a k-POS in order to
minimize its cost
• A node prefers to maintain a connection
with a non-emulated node over an
emulated one
– Each node maintains connections with its
initial k neighbors and receives from them
(and from S on behalf of them) all the
multicast packets
30
Theorem 2: Unilateral Defection
from the Protocol Does not Help
• If all the nodes, except for one (rational)
node n, choose a strategy out of the set of
possible POSs, then n also chooses a POS
31
Theorem 2 – Proof Sketch
• n does not communicate with nodes
whose identities were not received from S,
since all other nodes choose POSs
• Since all of n’s neighbors choose POSs, in
order to achieve a finite cost n must
maintain these k connections
– I.e., n chooses a K-POS
32
Theorem 3
• If
– all of a node n’s initial k neighbors are rational
and choose POSs and
– n cannot locate an identity of a node that
does not choose a POS,
• then … [same good things as before]
33
Theorem 4: Choosing H
• Each node chooses a non-negative H
parameter with each of its neighbors
34
Conclusions - Algorithm
• Combination of
– Fine for negative balance;
– Help from source at balance L; and
– Emulated nodes
achieves cooperation and high throughput
• Emulated nodes are available as a safety
net, but will never be used if all nodes are
rational
38
Conclusions – Proof
• POS captures “reasonable” behavior
• If all users run POSs
– cooperating is a strongly dominating strategy
– everything works great
• Unilateral defection from POS (hacking the
protocol's code) does not help
39
Related Work
40
Incentive-Based Solutions
• Two approaches:
– A user receives a service only if it contributes
upload bandwidth or disk space for some
other users
• Examples: Samsara, BitTorrent, Ngan et al.
– The quality of service experienced by a node
is proportional to its contribution to the
system
• Examples: GIA, Habib et al., Feldman et al.
41
Incentive-Based Content
Distribution
• BitTorrent, Avalanche
– No scalable dissemination of single stream
– Assumes altruism
• Why does it work?
– “How to cheat BitTorrent and why nobody
does” [Hales, Patarin]
• Will nobody cheat forever?
42
Incentive-Based Multicast
[Ngan et al.]
• Detection of selfish nodes
• Periodic reconstruction of multicast trees that
•
exclude previously misbehaving nodes
Drawbacks:
– Not all users are selfish
– High overhead: When the group size is 2000 nodes,
each node sends nearly 400 control messages every
two minutes, in addition to data messages
43
Related Work: Summary
• First p2p incentive-based service that
– Uses a game theory approach
– Proves that cooperation is dominating
strategy
– Proves that solution “works” in selfish
environments
44
Dynamic Setting
DEC (Dynamic EquiCast)
45
DEC (Dynamic EquiCast)
• DEC is very similar to EquiCast
• Changes compared to EquiCast:
– The overlay
– The cost function
– A protocol to initialize the balances upon a
join or leave operation
46
The Overlay
• We use a k-regular overlay that supports
join and leave operations
– E.g., [Law and Siu, 2003], composed of k/2
Hamiltonian cycles
– For proving cooperation, we only need the
regularity property
47
The Cost Function
• Obtained from EquiCast’s cost function
• Requires each node to receive t*p data
packets, where t is the number of rounds
in which the node receives the service,
instead of all the data packets
48
A Join Operation
N
N1
N1.my_balance[N2]=10
N1.neighbor_balance[N2]=-5
N2
N2.my_balance[N1]=-5
N2.neighbor_balance[N1]=10
49
S
A Join Operation
N.my_balance[N1]=-5
N.neighbor_balance[N1]=10
N.my_balance[N2]=10
N.neighbor_balance[N2]=-5
N1
N1.my_balance[N]=10
N1.neighbor_balance[N]=-5
Send N
N.neighbor_balance[N1]+
N.neighbor_balance[N2]=
10+(-5)=5 data packets
WHY???
N
N2
N2.my_balance[N]=-5
N2.neighbor_balance[N]=10
50