1 / 49

EcoRep: An Economic Incentive Model for Mobile-P2P networks

EcoRep: An Economic Incentive Model for Mobile-P2P networks. Anirban Mondal (University of Tokyo, JAPAN) Sanjay K. Madria (University of Missouri-Rolla, USA) Masaru Kitsuregawa (University of Tokyo, JAPAN). Contact Email address: anirban@tkl.iis.u-tokyo.ac.jp. INTRODUCTION.

mikaia
Download Presentation

EcoRep: An Economic Incentive Model for Mobile-P2P networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EcoRep: An Economic Incentive Model for Mobile-P2P networks Anirban Mondal (University of Tokyo, JAPAN) Sanjay K. Madria (University of Missouri-Rolla, USA) Masaru Kitsuregawa (University of Tokyo, JAPAN) Contact Email address: anirban@tkl.iis.u-tokyo.ac.jp

  2. INTRODUCTION Ever-increasing popularity and proliferation of mobile technology Mobile user statistics for JAPAN Jan 31, 2006 (http://www.wirelesswatch.jp/)

  3. Proliferation of mobile devices M-P2P Paradigm

  4. Proliferation of mobile devices + Popularity of the P2P paradigm e.g., Kazaa M-P2P Paradigm

  5. Proliferation of mobile devices + Popularity of the P2P paradigm e.g., Kazaa M-P2P Paradigm

  6. Proliferation of mobile devices + Popularity of the P2P paradigm e.g., Kazaa M-P2P Paradigm • M-P2P network: Mobile Hosts (MHs) interact in a P2P fashion • Sometimes, base station infrastructure does not exist • Current infrastructures are beginning to support P2P interactions among mobile devices e.g., Microsoft’s Zune

  7. M-P2P APPLICATION SCENARIOS

  8. M-P2P APPLICATION SCENARIOS Find the cheapest Levis Jeans in a shopping district

  9. M-P2P APPLICATION SCENARIOS Find the cheapest steak restaurant nearby me

  10. M-P2P APPLICATION SCENARIOS

  11. M-P2P APPLICATION SCENARIOS Which museum room do I visit next?

  12. M-P2P APPLICATION SCENARIOS

  13. M-P2P APPLICATION SCENARIOS What are the traffic conditions a few miles ahead?

  14. Challenges in M-P2P networks Low data availability • frequent network partitioning due to mobility

  15. Challenges in M-P2P networks Dynamic data replication Low data availability • frequent network partitioning due to mobility

  16. Challenges in M-P2P networks Dynamic data replication Low data availability • frequent network partitioning due to mobility Free-riding (limited resources of MHs)

  17. Challenges in M-P2P networks Dynamic data replication Low data availability • frequent network partitioning due to mobility Free-riding (limited resources of MHs) Economic Incentive model

  18. Challenges in M-P2P networks Dynamic data replication Low data availability • frequent network partitioning due to mobility Free-riding (limited resources of MHs) Economic Incentive model This motivates us to investigate an economic incentive model for dynamic replication in Mobile-P2P networks.

  19. Main contributions • An economic model for M-P2P networks • A query issuing mobile peer pays the price of the service to the query serving mobile peer • Virtual currency model • Discourages free-riding • Fairness in replica allocation • by considering the origin of queries for data items

  20. Related Works • Economic models have been discussed primarily for resource allocation in distributed systems. • They do not address fairness in replica allocation and P2P concerns such as free-riding. • They do not address M-P2P issues such as frequent network partitioning and mobile resource constraints. • [Ouri:04] has proposed an M-P2P economic model • [Ouri:04] aims at data dissemination, while we consider on-demand services. • [Ouri:04] does not consider replication. • Works on free-riding discuss utility functions to capture user contributions and trust issues • These works are completely orthogonal to replication issues associated with free-riding. • Existing P2P replication protocols are not adequate for M-P2P due to mobility issues. • [Hara:05] presents M-P2P replica allocation methods with periodic and aperiodic updates • [Hara:05] does not consider economic issues, load sharing and tolerance to weaker consistency.

  21. ARCHITECTURE OF EcoRep • EcoRep considers a hybrid super-peer architecture • some of the MHs act as the ‘Super-peers’ (SPs). • SPs have high processing capacity, high available bandwidth and high energy. • Neighbouring SPs periodically exchange their regional information concerning MH characteristics (e.g., load, energy) to facilitate replication. • In case of SP failures, neighbouring GNs could take over the responsibility of the failed GN. • SPs can also collaborate for search and replication across different regions.

  22. QUERY PROCESSING IN EcoRep • When an MH enters a region R, it registers with the SP S in R. • S provides the MH with the list of data items currently available in R. • EachMH periodicallysends its list of data items and replicas to its corresponding SP. • SP periodically broadcasts the list of available items within its region to the MHs in its region. • A query issuing MH M can distinguish whether its query is local or global. • EcoRep supports both local and remotequerying. • Local queries: Broadcast mechanism (need not pass via SP) • Remote queries: SP forwards query to its neighbouring SPs.

  23. Core idea • Services • providing data • providing computational power e.g., convert to PDF • message relay services • Every service has a price • Service-requestor pays the price of the service to the service-provider. • Revenue of an MH is how much currency it has • MH spends currency on obtaining services • MH earns currency by providing services

  24. Computation of data item price • Price of data item d depends on • access frequency

  25. Computation of data item price • Price of data item d depends on • access frequency • number of MHs served by d (fairness issue)

  26. Computation of data item price • Price of data item d depends on • access frequency • number of MHs served by d (fairness issue) • number of existing replicas of d

  27. Computation of data item price • Price of data item d depends on • access frequency • number of MHs served by d (fairness issue) • number of existing replicas of d • (replica) consistency of d

  28. Computation of data item price • Price of data item d depends on • access frequency • number of MHs served by d (fairness issue) • number of existing replicas of d • (replica) consistency of d • average response time for queries on d

  29. Computation of data item price • Price of data item d depends on • access frequency • number of MHs served by d (fairness issue) • number of existing replicas of d • (replica) consistency of d • average response time for queries on d

  30. Interaction between revenue and load • MH M could have high revenue but low load due to • serving only a few requests for some high-priced data items, but not issuing any queries • M could have low revenue but high load due to • serving a large number of access requests for low-priced data items • Even if M earns high amounts of virtual currency, M’s revenue could still be low if M issues several queries for high-priced data items.

  31. Interaction between revenue and load • MH M could have high revenue but low load due to • serving only a few requests for some high-priced data items, but not issuing any queries • M could have low revenue but high load due to • serving a large number of access requests for low-priced data items • Even if M earns high amounts of virtual currency, M’s revenue could still be low if M issues several queries for high-priced data items. There is no direct correlation between the revenue and load of an MH.

  32. Revenue and Load in EcoRep • We use a parameter ג that can be tweaked to adjust the relative importance of revenue and load during replica allocation. • We use normalized values of revenue and load to correctly reflect the relative weights of revenue and load. • We consider three cases: • Revenue and load are both assigned equal weights: ג = R + L • Revenue is assigned higher weight than load: ג = 2R + L • Revenue is assigned lower weight than load: ג = R + 2L

  33. EcoRep replica allocation • Each SP performs replica allocation within the region that it covers. • Periodically, each MH sends to its SP • current (x,y) coordinates • revenue value • the prices of items stored at itself • load • energy • available memory space status • SP collates the (x,y) coordinate information of all the MHs in its region to estimate the network topology during the time of replica allocation. • The algorithms provide revenue and load-balance • Revenue-balance avoids starvation of MHs and encourages MH participation in the network • Load-balance reduces query response times

  34. EcoRep Replica Allocation (CONT.) • Key idea: Assign higher-priced data items to MHs with either low revenue or low load (spectrum of algorithms with different weights for revenue and load). • Replica allocation criteria • Revenue • Load • k-hop neighbours of MH which access the data max number of times • Available memory space • Probability of MH availability • Query redirection to replicas is based on • Revenue • Load • Probability of MH availability

  35. Replica allocation algorithm

  36. Replica allocation algorithm Higher-priced data items are given preference

  37. Replica allocation algorithm { Bringing the data nearer to the origin of most of the requests for the data

  38. Replica allocation algorithm { Consideration of memory space, energy, load and probability of availability of MHs

  39. Replica allocation algorithm Revenue-balance and load-balance

  40. Replica allocation algorithm Recomputing the price of data items after replica allocation as price depends upon no. of existing replicas

  41. Performance Study • Metrics • Average Response time ART • Data Availability • Traffic (hop-count) during replica allocation

  42. Effect of Revenue Threshold

  43. Effect of fair replica allocation

  44. Performance of AReL

  45. Effect of variations in the workload skew

  46. Effect of variations in the reallocation period TP

  47. Effect of variations in the number of MHs

  48. Practical deployment issues • What should be the exchange rate between virtual money and real money? • 1000 units of virtual currency = ? Yen • How to ensure collection of payments? • Escrow method?? • Should real money be used? • High cost of micro-economic transactions • Virtual money should work as long as it is of value to M-P2P users • Example: MTV could give Bob 50 units of virtual money if he agrees to stream a video-clip in a busy market-place 25 times on a Sunday. Bob could buy some MTV products using the 50 units he obtains.

  49. SUMMARY • A mobile peer needs incentives to provide services to other mobile peers • Incentives are likely to improve participation of mobile peers  higher available bandwidth, larger pool of memory space, multiple paths to answer a query etc • Our works aim at enticing non-cooperative peers to provide service in M-P2P networks

More Related