Algorithms, Games, and the Internet S Kameshwaran 18 Oct, 2002

Refresh Equilibrium Concepts in Game Theory Dominant Strategy Equilibrium Dominant Strategy is the best strategy to any strategy played by other players Combination of dominant strategy (one from each player) is a dominant strategy equilibrium Nash Equilibrium A strategy combination (one from each player) is a Nash equilibrium if each player’s strategy is a best response, given the other players’ strategies Widely used

Refresh Mechanism Design Strategy-proof mechanisms Truth-telling is the dominant strategy for each agent Utilitarian Mechanisms: Maximize the sum of the valuations of all the players VCG pricing mechanisms are strategy-proof for utilitarian mechanisms VCG: Price an agent based on the inputs from the other agents VCG: Not budget-balanced Budget-balance is mandatory if there is in/out payments from/to agents (in payments >= out payments to avoid loss)

Refresh Mechanism Design Bayesian-Nash mechanisms There exists a Bayesian-Nash equilibrium Budget-balance is easy but to prove the existence of BNE may be difficult Algorithmic concepts were only applied to strategy-proof mechanisms No rigorous algorithmic mechanism design approach to Bayesian-Nash mechanisms

Algorithms, Games, and the Internet Objective To show that Game Theory and Mechanism Design are useful tools to model Internet mathematically, by focusing on the following applications Interdomain Routing CPU Marketplace Web Caching P2P File Sharing

Interdomain Routing Internet is comprised of many separate administrative domains or autonomous systems (AS) Routing of packets occurs at two levels: Intradomain: route within single AS Interdomain: route between AS Currently handled by Border Gateway Protocol (BGP)

Interdomain Routing BGP Used for carrying routing information between AS’s Coveys information about AS topology Path vector protocol Node i stores, for each AS j, the lowest-cost AS path from i to j Lowest-cost is in terms of number of hops Each router sends its routing table to its neighbors, which based on this information calculate their own table Routing table exchanges occur when a change is detected

Interdomain Routing BGP Model AS is considered as a node N: Set of nodes (ASs), n=||N|| L: Set of bi-directional links in N, at most one link between two nodes Tij: Intensity of traffic originating from i destined to j ck: Per packet transit cost of node k Transit traffic: Traffic neither originating from or destined for that AS AS do not like to carry transit traffic To compensate for cost each AS is paid a price

Interdomain Routing Objective Minimize the total cost of routing all packets (Utilitarian) AS that do not carry transit traffic pays nothing Use BGP as the substrate Straightforward extensions of existing protocols are easier to deploy than de novo designs There is no central computation in BGP: Each node calculates its routing table and pass it on to its neighbors Modifications to current BGP should not require new infrastructure in terms of computation and communication

Interdomain Routing Algorithmic Mechanism Design (AMD)  Distributed Algorithmic Mechanism Design (DAMD) Mechanism: Optimization (Allocation) Payments AMD deals with the complexity of mechanism from a centralized system perspective DAMD deals with the complexity of mechanism that is implemented across different systems AMD  DAMD :: Algorithms  Distributed Algorithms

Interdomain Routing Strategy-proof pricing mechanism for routing Payment to agent k for carrying transit traffic from i to j = ck (0 if it does not carry traffic) + [Transit cost of least cost path without k – Transit cost of least cost path with k] Unique strategy-proof pricing scheme that belongs to VCG and guarantees no payment to node that carries no traffic

Interdomain Routing DAMD Mechanism using BGP Least cost paths are calculated using ck instead of number of hops Each node while sending the routing table information also sends its transit cost ck Increases the standard BGP table by a constant factor The local computation done at each AS is in the same order of magnitude of current BGP local computation time

Interdomain Routing Conflict: AS as strategic agent and also as obedient computational system Strategy-proof mechanisms were designed in order to avoid the AS lying about its true cost For calculating the prices, the same AS were used How can one be sure that would implement algorithm correctly? It may modify the algorithm to its benefit Verification systems might be possible solutions

Distributed task Allocation: CPU Marketplace Computational Service Providers Users with pervasive devices can offload CPU intensive jobs to the marketplace Fixed pricing (like retail markets) Dynamic Pricing (like auction markets, price is affected by the current demand)

CPU Marketplace One-sided Auction Model : Given: k tasks Agents: n computational facilities (bidders, reverse auction) Agent i’s type: tij, minimum amount of time required by agent i to complete job j (private information) xi: Set of tasks allocated to agent i Agent i’s valuation: -jxitij Goal of the Market: mini jxitij (Minimize the makespan)

CPU Marketplace MinWork approximation Makespan: MinWork Mechanism mini jxitij <= j mini tij mini jxitij >= (1/n) j mini tij MinWork Mechanism Utilitarian: j mini tij (Reverse Auction, the valuations are negative: min instead of max) Payment: Agent is given the payment equal to the second best agent for this task VCG Mechanism: Strategy-proof Equivalent to auctioning each task separately in a Vickrey Auction

CPU Marketplace Is there any other better strategy-proof approximation mechanism? Users with tasks pay the agents What if the users are charged more than they can pay? Use of reserve prices: users have reserve prices and they cannot pay more than that Devise a strategy-proof approximation mechanism with reserve prices

CPU Marketplace Double Auction: Sellers: CPU providers (computational facility) Buyers: Users (Tasks) Budget-Balance is mandatory: Payment to sellers is made from the payments collected from the buyers Devise a Bayesian-Nash Mechanism that is budget-balanced and efficient

Web Caching Web caches enhance performance of web access Eliminate hot spots in the network Reduce access latencies Web-caching Architecture (Current): Set of collaborating caches to interact and serve a client community Intent: To achieve overall system efficiency Assumption: Caches are obedient

Web Caching What if the architecture spans different administrative boundaries? Two incentive issues: Clients reporting to a single cache Caches reporting to the architecture

Web Caching Single Cache in isolation Maximize the utility of requesting clients Caching the frequently requested pages that provide the highest user utility Utility are private information to the clients What are the strategy-proof mechanisms that can elicit truthful valuations from clients?

Web Caching Collaboration among caches Caches incur cost for storing a page If there is no monetary transfer, caches may manipulate other caches to store pages If there is monetary gain, then caches might “compete” to serve highest-value pages and thereby duplicating content: sub-optimal performance Design a mechanism that can distribute the caching load among caches such that performance is maximized Devise a mechanism for web caching architecture where clients are induced to report their true values to the caches and caches are induced to implement optimal resource allocation

Peer-to-Peer File Sharing P2P Sharing of files: original work, public domain works, publicly shared works Gnutella, Freenet, KaZaA Autonomous Distributed Systems Each machine belongs to a different user No central administrative authority Gift Economy Users offer content, access bandwidth, storage, CPU for free

Peer-to-Peer File Sharing Interacting Messages Ping: “Are you there?”: Directed at a Peer Pong: “Yes, I am here” Query: “I am looking for 007 posters” Query Response: “I have the poster. Download from xxx.xxx.xxx.xxx:xx All these messages are forwarded from a Peer to its neighbors

Peer-to-Peer File Sharing Free Rider Problem No individual is willing to contribute towards the cost of something (public goods) when he hopes that someone else will bear the cost instead Everybody in a block of flats may want a faulty light repaired, but no one wants to bear the cost of organizing the repair themselves In P2P, many people just download files contributed by others and never share any of their files Files shared in P2P are ‘public goods’ Free Rider Statistics in Gnutella: 70% of users share no files Few servers become the hot spots: Anonymous?, Copyright?, Privacy? Is it P2P?

Peer-to-Peer File Sharing Gift Economy  Barter Economy MojoNation P2P Awarding “Mojo” for offering resources “Mojo” is exchanged to gain priority access when is system is overloaded What are the performance characteristics of the equilibria that result from barter P2P systems?

Peer-to-Peer File Sharing Barter Economy  Monetary Economy?? Money exchange Can one design monetary P2P systems that provide better performance than barter P2P systems? Incentive Issues of Peers: Caching + Routing Caches: Storing shared files Routers: Routing query and other messages How to model these incentive issues in P2P systems?

References Algorithmic Mechanism Design, Noam Nisan and Amir Ronen, 2001 Distributed Algorithmic Mechanism Design: Recent Results and Future Directions, Joan Feigenbaum and Scott Shenker, 2002 A BGP-based Mechanism for Lowest Cost Routing, Joan Feigenbaum, Christos Papadimitriou, Rahul Sami, and Scott Shenker, 2002 Algorithms, Games, and the Internet, Christos Papadimitriou, 2001

22/10/02 (Tuesday): Constraint Satisfaction Problems and Games Next.. 22/10/02 (Tuesday): Constraint Satisfaction Problems and Games