a strategy-proof pricing scheme for multiple resource type...

A Strategy-proof Pricing Scheme for Multiple Resource Type

Allocations

Marian Mihailescu and Yong Meng Teo Department of Computer Science National University of Singapore

Overview

•  Introduction and Related Work

•  Our Approach

•  Proposed Mechanism

•  Example

•  Simulation Results

•  Conclusions and Future Work

2 38th International Conference on Parallel Processing, 22-25 September 2009, Vienna, Austria

Introduction

•  Large scale resource sharing   Grid

  Peer-to-peer

  Cloud Computing

•  Fundamental problem: resource allocation

•  Difficulty: rational users   Maximize their own interest in sharing

  Affect the performance of the system


Mechanism Design

Problem

•  Mechanism design problem

  Outcome specification

  Set of user valuations for a specific outcome

Solution

•  Mechanism

  Social choice function f determines the outcome

  User payment

4

•  Provides a framework to design protocols that give rational agents incentives to interact in particular ways, such that social welfare is “maximized” at equilibrium

€

M = ( f , p1,..., pn )

€

f (t1…tn ) =maxo uii∑

€

pi

€

vi(ti,o)

38th International Conference on Parallel Processing, 22-25 September 2009, Vienna, Austria

•  Computational Efficiency   Optimal allocation requires

NP-complete algorithm

Desired Properties

Economic

•  Multiple Resource Types   A buyer request contains more than one

resource type

•  Strategy-proof   Users gain higher welfare from participating

and have no incentives to declare false information

•  Budget Balance   Sum of all user payments is 0, and allocations

do not result in deficit or surplus

•  Economic Efficiency   Resources are allocated to the user that values

them the most; total welfare is maximized

Computational


•  Computational Efficiency   Optimal allocation requires

NP-complete algorithm

Myerson-Satterthwite

Impossibility Theorem:

no mechanism achieves strategy-proof, budget balance

and economic efficiency

at the same time

Desired Properties

Economic

•  Multiple Resource Types   A buyer request contains more than one

resource type

•  Strategy-proof   Users gain higher welfare from participating

and have no incentives to declare false information

•  Budget Balance   Sum of all user payments is 0, and allocations

do not result in deficit or surplus

•  Economic Efficiency   Resources are allocated to the user that values

them the most; total welfare is maximized

Computational


Related Work

Property Proportional

Share Bargaining Auctions

Combinatorial Auctions

Economic

Multiple Resource Types ✔ ✔ ✕ ✔

Strategy-proof ✕ ✕ ✔ ✔

Budget Balance ✔ ✔ ✔ ✕

Pareto Efficiency ✕ ✕ ✕ ✔

Computational

Algorithm Complexity low low low high

Tycoon (2004) [8] REXEC (2000) [4] Nimrod/G (2002) [2]

Popcorn (1998) [14] Spawn (1992) [18]

Mirage (2005) [3] Bellagio (2004) [1]


Our Approach

8

Pareto Efficiency

Computational Efficiency

Budget Balance

Strategy-proof

Multiple Resource Types

Trade-off

Trade-off


Market-based Resource Allocation Problem

•  Buyers submit requests for multiple resource types

•  Buyer private information   Maximum price the buyer is willing to pay such that, for each

resource type, resources are allocated to satisfy its request

•  Sellers publish each resource type separately

•  Seller private information for each resource type   Underlying costs for the respective resource type, such as power

consumption, bandwidth costs, etc.

•  For a particular request, the goal is to allocate resources such that the underlying costs are minimized


Winner Determination

•  Centralized market-maker   Manage requests and resources

  Determine winners and compute payments

•  Reverse Auction based Winner Determination   Select one request (buyer winner)

  For each resource type in the request o  Select resources with minimum cost (seller winner)


Payment Functions

•  Seller payment function

•  Buyer payment function €

ps =0 s does not contribute resources to allocate the request

−cM |s=∞ + cM |s=0 s contributes with resources to allocate the request

€

pb = − pss∈S∑

11

€

cM |s=∞ minimum cost to allocate the request without the resources of seller scM |s=0 minimum cost to allocate the request when the resource cost of seller s is 0VCG payment function: strategy-proof, Pareto-efficient, NOT budget-balanced


Payment Functions

•  Seller payment function

•  Buyer payment function €

ps =0 s does not contribute resources to allocate the request

−cM |s=∞ + cM |s=0 s contributes with resources to allocate the request

€

pb = − pss∈S∑

12

€

cM |s=∞ minimum cost to allocate the request without the resources of seller scM |s=0 minimum cost to allocate the request when the resource cost of seller s is 0


Achieved Properties

•  Multiple Resource Type

•  Seller Payment Function:   Strategy-proof   Economic Efficiency

•  Buyer Payment Function:   Strategy-proof (FCFS buyer requests)   Budget Balance

•  Computational Efficiency


Example

14

S1 CPU $1

S2 DISK $2 S3

DISK $1

S2 CPU $2

B1 CPU+DISK $5

B2 CPU+DISK $6


Proposed Mechanism

15

Market Maker

Resources

Requests

CPU [S1] = $1 CPU [S2] = $2

DISK [S2] = $2 DISK [S3] = $1

CPU + DISK [B1] = $5 CPU + DISK [B2] = $6


Buyers Sellers

CPU DISK

B1 ($5) S1 ($1) S2 ($2)

B2 ($6) S2 ($2) S3 ($1)


Payment Computation

Proposed Mechanism

16

Market Maker

Resources

Requests

CPU [S1] = $1 CPU [S2] = $2

DISK [S2] = $2 DISK [S3] = $1



Agent Payment

S1 2 + 1 = 3 0 + 1 = 1 -3 + 1 = -2

S3 1 + 2 = 3 1 + 0 = 1 -3 + 1 = -2

B1 - - 2 + 2 = 4

cM |s=! cM |s=0


Optimal Allocation

17

Market Maker

Resources

Requests

CPU [S1] = $1 CPU [S2] = $2

DISK [S2] = $2 DISK [S3] = $1



Total Welfare Exchange

w/o S1 6 – 2 – 1 = 3 B2 buys from S2, S3

w/o S2 6 – 1 – 1 = 4 B2 buys from S1, S3

w/o S3 6 – 1 – 2 = 3 B2 buys from S1, S2

w/o B1 6 – 1 – 1 = 4 B2 buys from S1, S3

w/o B2 5 – 1 – 1 = 3 B1 buys from S1, S3

maximum 6 – 1 – 1 = 4 B2 buys from S1, S3


Payment Computation

Optimal Allocation

18

Market Maker

Resources

Requests

CPU [S1] = $1 CPU [S2] = $2

DISK [S2] = $2 DISK [S3] = $1



Agent Payment

S1 -1 – (4 – 3) = -2

S3 -1 – (4 – 3) = -2

B2 6 – (4 – 3) = 5


Implementation

•  Discrete event auctions simulator

•  jCase – open-source combinatorial auctions simulator

•  FreePastry-based implementation on PlanetLab

Impact of Untruthful Users

5.5

6

6.5

7

7.5

8

8.5

1000 2000 3000 4000 5000 6000 7000 8000

Nu

mb

er o

f S

ucc

essf

ul

Req

ues

ts (

log

)

Number of Requests

truthful10% untruthful, 10% price change10% untruthful, 20% price change30% untruthful, 10% price change30% untruthful, 20% price change


Comparison with Traditional One-sided Auctions

2

3

4

5

6

7

8

9

10

24 48 72 96 120 144 168

Num

ber

of

Succ

essf

ul

Req

ues

ts (

log)

Simulation Time (hours)

traditional auctions, 1 rttraditional auctions, 4 rttraditional auctions, 8 rt

traditional auctions, 16 rt

proposed mechanism, 1 rtproposed mechanism, 4 rtproposed mechanism, 8 rtproposed mechanism, 16 rt

20

Price Diversity

(%)

Successful Buyer Requests (%)

Traditional Auctions

Proposed Increase

(%)

Under-Demand

10 66.4 78.9 26.5

20 66.4 79 27.1

40 66.3 79 26.6

Balanced Market

10 54.7 69.2 18.9

20 54.6 69.3 19.0

40 54.5 69.0 19.2

Over-Demand

10 33.5 39.1 16.7

20 33.8 39.1 15.6

40 33.6 39.1 16.3

Comparison with Combinatorial Auctions

Pricing Mechanism

Number of Users

Properties Performance

IC BB EE Runtime Succ. Buyer Requests (%)

Alloc. Seller Items (%)

Combinatorial Auctions (VCG)

20 40 80

✔ ✔ ✔

-1,402 -1,544 -1,557

2,470 6,321

14,384

9.6 min 2.5 hrs

67.4 hrs

44.5 52.5 54.2

44.8 57.2 64.0

Combinatorial Auctions

(Threshold)

20 40 80

✕ ✕ ✕

5 9 6

2,491 6,223

14,567

9.8 min 2.5 hrs

49.5 hrs

44.4 49.6 58.8

48.3 59.8 65.1

Proposed

20 40 80 100 200 500

✔ ✔ ✔

✔ ✔ ✔

0 0 0 0 0 0

1,871 5,483

11,561 14,369 28,564 65,948

1 sec 3 sec 5 sec 7 sec

20 sec 1.9 min

36.3 48.5 52.8 54.1 53.5 52.6

32.5 55.3 68.0 71.6 76.5 80.2

•  Scalability   Centralized market-maker that processes requests sequentially

  Vertical – increase the number of resource types

  Horizontal – increase the number of users

•  Monopolistic Sellers [Pham, H.N. et.al., An Approach to Vickrey-based Resource Allocation in the Presence of Monopolistic Sellers, In Proc. 7th Australasian Symposium on Grid Computing and e-Research (AusGrid 2009), pp. 77-83, Wellington, New Zealand]

Limitations

22

S1 CPU $1

S3 DISK $1

B1 CPU+DISK $5

S2 CPU $2

S2 DISK $2

B2 CPU+DISK $6


Conclusions

•  Resource pricing and allocation scheme that:   Allocates multiple resource types

  Provide incentives for rational buyers and sellers

  Achieves budget balance

  Computational efficiency

•  Future Work   Distributed pricing scheme – improve horizontal and

vertical scalability


Questions ?

[email protected]

Thank you !

[email protected]

Y. M. Teo and M. Mihailescu, A Strategy-proof Pricing Scheme for Multiple Resource Type Allocations, in Proceedings of 38th International Conference on Parallel Processing, pp. 172-179, IEEE Computer Society Press, Vienna, Austria, September 22-25, 2009

a strategy-proof pricing scheme for multiple resource type...

Documents