11

EquiCastEquiCastScalable Multicast with Selfish Scalable Multicast with Selfish

UsersUsers

Idit Keidar, Roie Melamed, Ariel OrdaIdit Keidar, Roie Melamed, Ariel OrdaTechnionTechnion

22

Users Are Typically SelfishUsers Are Typically Selfish

• Not willing to share upload bandwidthNot willing to share upload bandwidth

• Need Need incentivesincentives in order to contribute in order to contribute their available resourcestheir available resources

What's in it for

me?

Share with thy neighbor

33

The ProblemThe Problem

• Long session of single-source Long session of single-source multicast multicast – Push-data: software updates, file Push-data: software updates, file

distributiondistribution

• Peer-to-peer disseminationPeer-to-peer dissemination

• Selfish usersSelfish users

44

Additional Design GoalsAdditional Design Goals

• Low overheadLow overhead– Independent of network size (scalability)Independent of network size (scalability)

• FairnessFairness– Equally distribute multicast load among all Equally distribute multicast load among all

nodesnodes

• Scalable latency, increasing at most like Scalable latency, increasing at most like

O(log N), where N is the number of O(log N), where N is the number of nodesnodes

55

The GameThe Game

• Model the system as a non-Model the system as a non-cooperative gamecooperative game

• The players: N nodesThe players: N nodes

• Choose Choose strategies strategies that minimize their that minimize their selfish costselfish cost

• Dominating strategy: yields better Dominating strategy: yields better cost regardless of other users’ actions cost regardless of other users’ actions

66

The Cost Function for Node The Cost Function for Node NiNi

Source’s strategy

N1’s strategy

Number of packets Ni received

Why this function?

Number of packets Ni sent

Total number of data packets

77

Architecture: K-Regular Random Architecture: K-Regular Random GraphGraph

N2N1

N4N3

N6

N51) Each node’s

degree is k 2) The diameter is O(log N)

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

88

The Source’s ProtocolThe Source’s Protocol

S

N2N1

N4N3

N6

N5

P1-P10P1-P10

P11-P20

P11-P20

P21-P30

P21-P30

Round #1Round #2Round #3

99

Gossip-Based MulticastGossip-Based Multicast

• Data is disseminated through gossip Data is disseminated through gossip over the overlay’s linksover the overlay’s links

1010

Phase I: Gossip Phase I: Gossip

N2N1

N4N3

N6

N5I have packets P1,

P3, P8, and P9

I have packets P1, P4, P6, and P7

1111

Phase II: Process Gossip, Phase II: Process Gossip, Send RequestsSend Requests

N2N1

N4N3

N6

N5Send me packets

P1, P3, and P9

Send me packets P4, P6, and P7

1212

Phase III: Send DataPhase III: Send Data

N2N1

N4N3

N6

N5 Packets P1, P3,

and P9

Packets P4, P6, and P7

1313

If All Nodes Cooperate If All Nodes Cooperate [Melamed and Keidar, NCA 2004][Melamed and Keidar, NCA 2004]

• Fairness: all nodes send the same number of Fairness: all nodes send the same number of packetspackets– Due to overlay’s properties and S’s random Due to overlay’s properties and S’s random

injectionsinjections• Pair-wise fairness: help each neighbor as much Pair-wise fairness: help each neighbor as much

as it helps meas it helps me– Due to overlay’s properties and S’s random Due to overlay’s properties and S’s random

injectionsinjections• Low overhead: no redundant packets sentLow overhead: no redundant packets sent

• How do we achieve these nice properties with How do we achieve these nice properties with selfish users?selfish users?

1414

In Selfish Environments… In Selfish Environments…

• Monitor neighbors' Monitor neighbors' contributioncontribution– Compare against Compare against

expected throughputexpected throughput

• Disconnect from Disconnect from neighbors that do neighbors that do not deliver the not deliver the goodsgoods– Cannot be on a per-Cannot be on a per-

round basis, due to round basis, due to randomnessrandomness

N1 sent me 17 packetsN2 sent me 21 packets

…

1515

Monitoring NeighborsMonitoring Neighbors

• Allow slack in imbalance in order to Allow slack in imbalance in order to account for randomnessaccount for randomness

• Define lower bound L on allowed Define lower bound L on allowed imbalanceimbalance

• In each round, for each neighbor n:In each round, for each neighbor n:– neighbor_balance[n] += received messages - neighbor_balance[n] += received messages -

expected throughputexpected throughput– if (neighbor_balance[n] < L) "n is in trouble!"if (neighbor_balance[n] < L) "n is in trouble!"

What does it mean?Should I disconnect from n?

1616

When Node n is in TroubleWhen Node n is in Trouble

• A cooperative neighbor n has a non-zero A cooperative neighbor n has a non-zero probability of having an overdraft of L probability of having an overdraft of L – Disconnecting from cooperative nodes is not a Disconnecting from cooperative nodes is not a

good ideagood idea

• A bail-out option: n can ask S to send w A bail-out option: n can ask S to send w data packets to a given neighbor on behalf data packets to a given neighbor on behalf of nof n– n must send w empty packets to Sn must send w empty packets to S– w ≤ expected throughputw ≤ expected throughput– Such packets accepted only for neighbors with a Such packets accepted only for neighbors with a

sub-par balancesub-par balance

1717

Problem with Asking S to Problem with Asking S to HelpHelp• Too lenient towards nodes with a Too lenient towards nodes with a

negative balancenegative balance– No penalty for having a low balanceNo penalty for having a low balance– Nodes not motivated to have positive Nodes not motivated to have positive

balancebalance•A selfish node may let its balance drop without A selfish node may let its balance drop without

the risk of being disconnectedthe risk of being disconnected

• Over-use of this mechanism overloads Over-use of this mechanism overloads SS

1818

Negative Balance FinesNegative Balance Fines

• A neighbor sends an additional fine A neighbor sends an additional fine packet for every round with a packet for every round with a negative balancenegative balance

• Does not affect the sender’s balanceDoes not affect the sender’s balance– Motivates nodes to have non-negative Motivates nodes to have non-negative

balance as much as possiblebalance as much as possible– Thus, minimizes requests from SThus, minimizes requests from S

2020

An Emulated NodeAn Emulated Node

• In case of a disconnection, S can emulate a In case of a disconnection, S can emulate a selfish rational EquiCast node eselfish rational EquiCast node e

• e’s interface is identical to the interface of e’s interface is identical to the interface of an EquiCast node except… an EquiCast node except… – n’s balance with respect to e is initialized to Ln’s balance with respect to e is initialized to L– In each round, n must send a fine packet to eIn each round, n must send a fine packet to e

•Hence, a node prefers to maintain a connection with a Hence, a node prefers to maintain a connection with a non-emulated node over an emulated onenon-emulated node over an emulated one

2121

The Need for L – Lower Bound The Need for L – Lower Bound on Balanceon Balance

• If we have a per-round fine, why do If we have a per-round fine, why do we need L?we need L?

• For high data throughput and low For high data throughput and low overhead, fines are small overhead, fines are small – E.g., 1 fine packet per 50 data packetsE.g., 1 fine packet per 50 data packets

• Without L, a selfish node would send Without L, a selfish node would send only fine packetsonly fine packets

2222

Upper Bound on BalanceUpper Bound on Balance

• Each node selfishly chooses its own Each node selfishly chooses its own upper bound on its balance wrt its upper bound on its balance wrt its neighborsneighbors

• Parameter HParameter H

2323

Throughput and GoodputThroughput and Goodput

• Expected incoming rate per link per Expected incoming rate per link per round:round:– 1 gossip1 gossip– 1 request1 request– ½ fine½ fine– Tens of data packets (goodput) Tens of data packets (goodput)

•May come from source instead of neighborMay come from source instead of neighbor

}overhead

2424

Proof of Proof of CooperationCooperation

2626

Protocol-obedient strategy Protocol-obedient strategy (POS)(POS)

• Choose your own HChoose your own H

• Maintain connections only with nodes Maintain connections only with nodes whose identities are received from Swhose identities are received from S– choose any subset of them in each choose any subset of them in each

roundround

• Run the protocol's code as is for each Run the protocol's code as is for each of these connectionsof these connections

2727

k-POSk-POS

• A POS in which a node maintains A POS in which a node maintains exactly k connections in each round exactly k connections in each round throughout the entire multicast throughout the entire multicast session is called a k-POSsession is called a k-POS

2828

LemmaLemma

• A k-POS strictly dominates every POS A k-POS strictly dominates every POS in which n maintains connections with in which n maintains connections with j nodes, where j≠kj nodes, where j≠k

• Rationale:Rationale:– If j<k, then the cost is infiniteIf j<k, then the cost is infinite

•Due to bandwidth limitations (see paper)Due to bandwidth limitations (see paper)

– If j>k, then the overhead is largerIf j>k, then the overhead is larger•Maintaining connections with k nodes suffices Maintaining connections with k nodes suffices

in order to receive all the multicast packetsin order to receive all the multicast packets

2929

Theorem 1Theorem 1

• If all nodes choose If all nodes choose strongly dominating strongly dominating strategies*strategies* out of the set of POSs, then out of the set of POSs, then– every node maintains connections with its every node maintains connections with its

initial k neighborsinitial k neighbors– every node receives all the multicast every node receives all the multicast

packetspackets

* Strongly dominating strategy: assume Strongly dominating strategy: assume nothing nothing on what others do (except POS)on what others do (except POS)

3030

Theorem 1 – Proof SketchTheorem 1 – Proof Sketch

• Each node chooses a k-POS in order Each node chooses a k-POS in order to minimize its costto minimize its cost

• A node prefers to maintain a A node prefers to maintain a connection with a non-emulated connection with a non-emulated node over an emulated onenode over an emulated one– Each node maintains connections with Each node maintains connections with

its initial k neighbors and receives from its initial k neighbors and receives from them (and from S on behalf of them) all them (and from S on behalf of them) all the multicast packetsthe multicast packets

3131

Theorem 2:Theorem 2: Unilateral Unilateral Defection from the Protocol Defection from the Protocol Does not HelpDoes not Help• If all the nodes, except for one If all the nodes, except for one

(rational) node n, choose a strategy (rational) node n, choose a strategy out of the set of possible POSs, then out of the set of possible POSs, then n also chooses a POSn also chooses a POS

3232

Theorem 2 – Proof SketchTheorem 2 – Proof Sketch

• nn does not communicate with nodes does not communicate with nodes whose identities were not received whose identities were not received from from SS, since all other nodes choose , since all other nodes choose POSsPOSs

• Since all of n’s neighbors choose Since all of n’s neighbors choose POSs, in order to achieve a finite cost POSs, in order to achieve a finite cost n must maintain these k connections n must maintain these k connections – I.e., n chooses a K-POSI.e., n chooses a K-POS

3333

Theorem 3Theorem 3

• If If – all of a node n’s initial k neighbors are all of a node n’s initial k neighbors are

rational and choose POSs and rational and choose POSs and – n cannot locate an identity of a node n cannot locate an identity of a node

that does not choose a POS, that does not choose a POS,

• then … [same good things as then … [same good things as before]before]

3434

Theorem 4: Choosing HTheorem 4: Choosing H

• Each node chooses a non-negative H Each node chooses a non-negative H parameter with each of its neighborsparameter with each of its neighbors

3838

Conclusions - AlgorithmConclusions - Algorithm

• Combination ofCombination of– Fine for negative balance; Fine for negative balance; – Help from source at balance L; andHelp from source at balance L; and– Emulated nodesEmulated nodes

achieves cooperation and high achieves cooperation and high throughputthroughput

• Emulated nodes are available as a Emulated nodes are available as a safety net, but will never be used if all safety net, but will never be used if all nodes are rationalnodes are rational

3939

Conclusions – Proof Conclusions – Proof

• POS captures “reasonable” behaviorPOS captures “reasonable” behavior

• If all users run POSsIf all users run POSs– cooperating is a cooperating is a strongly dominating strongly dominating

strategystrategy– everything works greateverything works great

• Unilateral defection from POS Unilateral defection from POS (hacking the protocol's code) does (hacking the protocol's code) does not helpnot help

4040

Related WorkRelated Work

4141

Incentive-Based SolutionsIncentive-Based Solutions

• Two approaches:Two approaches:– A user receives a service only if it A user receives a service only if it

contributes upload bandwidth or disk contributes upload bandwidth or disk space for some other usersspace for some other users•Examples: Samsara, BitTorrent, Ngan et al.Examples: Samsara, BitTorrent, Ngan et al.

– The quality of service experienced by a The quality of service experienced by a node is proportional to its contribution node is proportional to its contribution to the systemto the system•Examples: GIA, Habib et al., Feldman et al.Examples: GIA, Habib et al., Feldman et al.

4242

Incentive-Based Content Incentive-Based Content DistributionDistribution

• BitTorrent, AvalancheBitTorrent, Avalanche– No scalable dissemination of single No scalable dissemination of single

streamstream– Assumes altruismAssumes altruism

•Why does it work?Why does it work?

– ““How to cheat BitTorrent and why nobody does” [Hales, Patarin]•Will nobody cheat forever?Will nobody cheat forever?

4343

Incentive-Based Multicast Incentive-Based Multicast [Ngan et al.][Ngan et al.]

• Detection of selfish nodesDetection of selfish nodes

• Periodic reconstruction of multicast trees Periodic reconstruction of multicast trees that exclude previously misbehaving nodesthat exclude previously misbehaving nodes

• Drawbacks:Drawbacks:– Not all users are selfishNot all users are selfish– High overhead: When the group size is 2000 High overhead: When the group size is 2000

nodes, each node sends nearly 400 control nodes, each node sends nearly 400 control messages every two minutes, in addition to data messages every two minutes, in addition to data messagesmessages

4444

Related Work: SummaryRelated Work: Summary

• First p2p incentive-based service thatFirst p2p incentive-based service that– Uses a Uses a game theory game theory approachapproach– Proves that cooperation is dominating Proves that cooperation is dominating

strategystrategy– Proves that solution “works” in selfish Proves that solution “works” in selfish

environmentsenvironments

4545

Dynamic Dynamic SettingSetting

DEC (Dynamic DEC (Dynamic EquiCast)EquiCast)

4646

DEC (Dynamic EquiCast)DEC (Dynamic EquiCast)

• DEC is very similar to EquiCastDEC is very similar to EquiCast

• Changes compared to EquiCast:Changes compared to EquiCast:– The overlayThe overlay– The cost functionThe cost function– A protocol to initialize the balances upon A protocol to initialize the balances upon

a join or leave operationa join or leave operation

4747

The OverlayThe Overlay

• We use a k-regular overlay that We use a k-regular overlay that supports join and leave operationssupports join and leave operations

– E.g., [Law and Siu, 2003], composed of E.g., [Law and Siu, 2003], composed of k/2 Hamiltonian cyclesk/2 Hamiltonian cycles

– For proving cooperation, we only need For proving cooperation, we only need the regularity propertythe regularity property

4848

The Cost FunctionThe Cost Function

• Obtained from EquiCast’s cost Obtained from EquiCast’s cost functionfunction

• Requires each node to receive t*p Requires each node to receive t*p data packets, where t is the number data packets, where t is the number of rounds in which the node receives of rounds in which the node receives the service, instead of all the data the service, instead of all the data packetspackets

4949

A Join OperationA Join Operation

N2N1

N1.my_balance[N2]=10N1.neighbor_balance[N2]

=-5

N2.my_balance[N1]=-5N2.neighbor_balance[N1]

=10

N

5050

A Join OperationA Join Operation

N2N1

N1.my_balance[N]=10N1.neighbor_balance[N]=-

5

N2.my_balance[N]=-5N2.neighbor_balance[N]=

10

N

S

Send N N.neighbor_balance[N1]+ N.neighbor_balance[N2]=10+(-5)=5 data packets

WHY???

N.my_balance[N1]=-5N.neighbor_balance[N1]=10N.my_balance[N2]=10N.neighbor_balance[N2]=-5