MoB: A Mobile Bazaar for Wide-area Wireless Services

1. Rajiv ChakravortySulabh AgarwalSuman Banerjee U. of Wisconsin-Madison Ian Pratt U. of Cambridge MoB: A Mobile Bazaar for Wide-area Wireless Services Presented by NR

2. Introduction • Growing usage of mobile devices • various types and form factors, e.g., PDAs, smartphones, portable PCs • Increased availability of wireless data networks • Higher bandwidth cellular data networks • 802.11 WLAN hotspots • Intermittent Internet connectivity • WLAN coverage is spotty, more so for public hotspots • Cellular coverage also not ubiquitous • often suffers from high latency, low bandwidth, link stall, etc.

3. Introduction • Leads to poor performance of networked applications on mobile devices

4. Introduction • Solution: Mobile Bazaar (MoB) • Architecture to improve data services for wide-area wireless users • Open market, collaborative • New model for data services • Decoupling of infrastructure providers from services providers • Fine-grained competition over provisioning • Service interactions of arbitrary timescales • Flexible composition of services

5. Fine-grained competition • Coarse-grained competition • User chooses one cellular provider • Signs a long-term contract (in the order of hours to years) • Exercises choice with large time gaps • User might not be able to access the Internet • in regions where his provider has poor coverage • In MoB, fine-grained competition • Choose and change providers at arbitrarily small timescales • Can choose the current “best” provider • Can temporarily choose multiple providers simultaneously

6. Fine-grained competition • Users can resell unused resources • e.g., idle cell-phone resells bandwidth to nearby laptop experiencing a slow connection • Micropayments system supports resource trades • Advantages • Ad-hoc purchase of additional resources from nearby users • a way to boost application performance on demand • Infrastructure provider is no longer the service provider • Users no longer limited to services and rates offered by their infrastructure provider • Greater competition like in long-distance telephone services

7. Services in MoB • Goal of MoB: enable incentive-induced service collaboration between independent mobile devices. • Example: bandwidth aggregation service customer traders

8. Services in MoB • Example, in detail • Customer device is a wireless user (C1)that is stationary in either • static public environment (e.g., coffee shop or shopping mall) • mobile environment (e.g., moving bus or train) • Typically surrounded by other networked devices (e.g., cellphones, laptops, PDAs) • 3G-enabled cellphone (T1) • PDA with an 802.11 wireless interface (T2) • C1 discovers nearby T1,T2,T3. Then connects to a subset T1,T3 and purchases their available bandwidth.

9. Services in MoB • Possible services to trade • High-bandwidth connectivity • Location determination • PDA equipped with navigational tool but without GPS • Can purchase location info. from any in-range MoB trader • Time synchronization • Mobile game-console participates in a multi-player game • Needs accurate time synchronization • Network Time Protocol (NTP) can be fairly expensive • Can buy global time info. from a nearby cellphone trader

10. Services in MoB • Possible services to trade (cont’d) • Web proxy caching • User browsing the web over a slow and expensive cellular link • Can buy cached copies from its wireless vicinity (proxy on-demand) • Bandwidth aggregation for media streaming • GPRS user wants to receive high-quality video stream • Can buy spare bandwidth from multiple nearby 3G cellphones • Use app.-level proxy to intelligently stripe stream over these connections

11. Services in MoB • Possible services to trade (cont’d) • Peer-to-peer data search • User conducting legal filesharing through Gnuetalla or KaZaA • May have to deal with loss of connectivity and high-costs • Can try first to look for data available in the local environment • Like in Microsoft’s Zune • Traffic filtering • A resource-constrained wireless device • In addition to buying bandwidth, can pay for malicious content filtering

12. Services in MoB • Services are advertised anddiscovered using the ServiceLocation Protocol (SLP, RFC2608) • Difficulties of managing multi-hop paths • Cost distribution • Accountability in case of failure • In MoB all interactions are pairwise (single-hop) • Anyway multi-hop interactions will be relatively rare • Composed service interactions are also treated independently • A nearby Italian restaurant recommendation

13. Services in MoB • Service interactions are implemented in the application layer • Suppose C2 is performing P2P file d/l from T3 via X • Two independent TCP connections, one for each hop • All multi-hop interactions are composed of multiple single-hop app.-layer service interactions • Conversely, in ad-hoc networks an on-demand network-layer end-to-end path is used

14. Pricing and Reputation • MoB is an open market with no regulation on advertised services or prices (think eBay) • Market forces will probably govern pricing • This has to be supported by • A reputation and trust management system • A billing and accounting system • Can potentially be offered as third-party services • In this paper, implemented as one system called Vito

15. Applicable environments • An environment with many opportunities of collaboration between in-range devices • A study of resource sharing opportunities • How long a user stays in a coffee-shop? • Two different measurement techniques • Time-sheet at the counter, sign-in and sign-out • On site observer monitoring for two hours • Results • More than 2/3 spent more than 2 minutes • At least 50% spent 10+ minutes • A significant fraction spent over 30 minutes • Conclusion: significant opportunities of long-lived MoB interactions

16. Salient features • Open market architecture • Any device can autonomously advertise services • Supports separate service level agreements with traders • Each SLA can potentially last over small timescale • Flexibility to resell idle resources • Better performance through Wirless Diversity • Technologies (cellular: CMDA, GPRS, WLAN: 802.11b/g) • Networks (Sprint, AT&T, Boingo) • Channels (transmission frequencies) • Can mix-and-match the “best” local links to improve performance

17. Salient features • Incentive-based Collaboration • Traders provide services in return for monetary benefits • Customization and Support for Diverse Applications • Supports on-demand customization • Examples: • Utilize cache only when surfing the web • Obtain location info. for navigation only when driving • Aggregate bandwidth resources for a specific file transfer

18. MoB Architecture

19. MoB architecture Internet Networking infrastructure 3rd party services for accounting and billing,reputation and trust management Mobile devices

20. MoB architecture • Modes of operations • Incentive-based • Service provided in exchange for financial incentive • With no trust assumptions • Both parties use a central reputation system (like Vito)Derive trust from past trade histories • With trust assumptions • Mutual trust between trade partiese.g., due to multiple successful interactions in the past • Altruistic • Perfect trust and no financial incentivese.g., within a friend’s network

21. Vito Design • An eBay like reputation system • Centralized 3rd party service in the wired Internet • Design • Each registered user obtains a timestamped reputation certificate • this certificate records both successful and unsuccessful transaction • During trade, customer and trader examine each other’s reputation certificate. May reject old certificates. • After transaction, they upload feedback scores to Vito • Multiple reputation management systems may coexist

22. Operations in MoB User A Vito User B • User A registers usingits public key, KA+ • Vito issues a reputationcertificate RA • This certificate is signed using Vito’s private key, KVito− • It includes a timestamp TS1 • Contains positive and negative feedback counts for A, ScoreA • Vito does not keep state for A • Equipped with the reputation certificate, A can engage in trades with other users RegisterKA+ RegisterKB+ AcceptRA:[TS1, ScoreA, KA+]KVito− AcceptRB:[TS2, ScoreB, KB+]KVito− A and B independently register with Vito

23. Operations in MoB User A Vito User B • Services are discoveredand advertised usingthe Service LocationProtocol (SLP) • To request a servicein its wireless vicinity Amulticasts a Service Requestto 239.255.255.253:427 • TTL is chosen to be 1, since in MoB service interactions are pairwise SLP Srv ReqRA, [TS3]KA− SLP Srv RespRB, [TS3, TS4, Price]KB− TokenT: [TS4, TS5, A, B, Price]KA− Service interactions A and B interact, no need to access Vito

24. Operations in MoB User A Vito User B • Consider the scenario • A multicasts a ServiceRequest for a 30Kbpsforwarding service • It includes A’s reputation • SLP Service Agent B respondswith a service description (25Kbps)and a price quote • It includes B’s reputation • A sends a Service Acceptance Notification to each of his chosen traders • It includes a timestamp and payment amount • B starts operating as a NAT device for A SLP Srv ReqRA, [TS3]KA− SLP Srv RespRB, [TS3, TS4, Price]KB− TokenT: [TS4, TS5, A, B, Price]KA− Service interactions A and B interact, no need to access Vito

25. Operations in MoB User A Vito User B • Scenario (cont’d) • B presents token T to Vito • Vito charges A • Vito credits B • This is counted as apositive feedback for B from A • B is charged a transaction feefor the gained positive reputation • Once B receives credit it’ll typically report a positive feedback for A • If A was dissatisfied, it’ll explicitly report negative feedback for B EncashT, [TS6, B]KB− Token encashed[TS6]KVito− Feedback[TS7, B, A, Score]KB− Reputation (updated)RA Reputation (updated)RB Nightly reputation and billing updates

26. Design Decisions • Trader (B) uploads its own positive feedback • Positive trader feedback benefits itself in future trades • Thus, beneficiary is responsible for uploading feedback • Trader uploads positive customer (A) feedback • Positive customer feedback contingent upon encashing of the token • The service token indicates the trade price and is signed by A • Vito will check A’s balance and inform B • Based on this response, B rates A • Studies show that expectation of a reciprocal positive rating encourages voluntary feedback

27. Design Decisions • Customer uploads negative feedback for trader • Obviously trader has no incentive to reduce its positive reputation • Trader has no recourse if malicious customer always reports negative feedback • Same shortcoming in eBay • Mitigating assumption: customers may be selfish but not malicious • When they received good service will not rate negatively

28. Design Decisions • Customer pays prior to receiving service • If we had let the customer pay after receiving service • He might default the payment • The trader wouldn’t have a proof of the transaction and no further recourse (recall, the token is the payment) • If customer pays first • If trader encashes the service token, it in fact claims to having provided the service • If trader defaults in provisioning, customer can provide negative feedback

29. Design Decisions • Transaction fee charge • A transaction fee is an incentive for the reputation service provider • Also implies no one can build up reputation for free • Otherwise, construct multiple colluding identities • Perform transactions between these identities • Report positive feedback

30. Evaluation of the Reputation Management Model • For a reputation system to work in practice • There has to be an expectation of future interaction between entities; have to be long-lived • Historical feedback is maintained and made available • Past feedback guides buyer decisions

31. Evaluation of the Reputation Management Model • Challenges to making a reputation system really robust • Sybil attacks: a user with bad reputation acquires a fresh identity • Newcomers are always distrusted • Unless they paid their dues, e.g. registration fee • Alternative, require use of real names or prevent acquisition of multiple pseudonyms • Collusions: a group of users collaborate and rate each other positively • Avoid by using a transaction fee for reputation reporting

32. Evaluation of the Reputation Management Model • Challenges to making a reputation system really robust (cont’d) • Decentralized reputation management • Current centralized solution might not scale • Also may be desirable in many scenarios to decentralize • Some approaches have been proposed in the context of P2P networks • they exploit pre-trusted peers

33. Implementation

34. Implementation • MoB is implemented over Linux • Clients include single and multiple wireless interfaces • Local wireless connectivity (e.g., Bluetooth) • Global wireless connectivity (e.g., 3G) • Installed on each MoB device as a middleware

35. Implementation Accepts connections from MoB applications passing them to the MoB manager Checks local cache manager for the requested object In a cache miss, initiates a connection setup with neighboring MoB device Request/response are correlated using URLs. Updates cache on response At the receiving MoB device, a response handler consults the local cache, or contacts other MoB devices May also retrieve object from the Internet if it has a wide-area access interface, e.g., a 3G-1x/EvDO PC card

36. Implementation Regulates block-based app.-level data striping of large data objects from neighboring MoB devices During download, changes block size, # of parallel TCP connections, and their types (e.g., persistency) to adapt to variable degrees of user churn Also, performs load-balancing Part of the content processing engine. Optionally performs compression, traffic filtering, etc. May downgrade image fidelity over slower links

37. Implementation Neighbor discovery using link-specific mechanisms provided by different wireless interfaces. In 802.11 a specific channel is allocated for neighbor discovery. Periodically, the MoB device goes into a promiscuous mode to discover other devices. In Bluetooth, the device initiates a scan procedure to detect other in-range devices. It can connect to its neighbor using dial-up networking (DUN). Then it can establish an IP connection using point-to-point protocol (PPP) over a serial RFCOMM channel (emulation of a serial port over Bluetooth).

38. Evaluating MoB Applications

39. Experimental Setup • A prototype MoB system was implemented • Experiments with • File-transfer applications • Web browsing • Media streaming • Location determination • Communication • Between customers and traders - Bluetooth, 802.11a/b • Traders • 3G EvDO (2.4Mbps d/l and 153Kbps u/l) • 3G 1xRTT (144Kbps d/l and 64Kbps u/l)

40. File-transfer applications • Data transfer from specific Internet location • FTP-like transfer of a large file • Customer requests a sequence of moderate sized blocks • Close to completion of one block transfer, requests the next • If new traders are available, will simultaneously download blocks through them

41. File-transfer applications • Data transfer from specific Internet location (cont’d) • Customer C uses Bluetooth • Trader T1 uses CDMA 1xRTT • Trader T2 uses CDMA EvDO • At t0 = 0, only T1 is in range of Cso C only downloads from it. • T2 moves in-range of C at t1 = 12 andis detected by C at t2 = 14 • T1 starts to move out-of-range of C around t3 = 45 and stays connected until time 70 sec • Between t2 and t3C downloads from both. The aggregate throughput is 327.2Kbps

42. File-transfer applications • Data location and retrieval • Gnutella and KaZaA-style P2P data search and retrieval • Study impact of different levels of churn on performance • High: each potential trader stays in-range for 10-20 sec • Medium: stays for 40-60 sec • Low: stays 60-120 sec • None: no trader mobility, serves as the base case • In typical coffee-shop scenarios expect low or no churn

43. File-transfer applications • Data location and retrieval (cont’d) • Customer locates nearby trader that has the queried object • Starts block-based download • We assume here it uses only one trader at a time • Searches for alternate trader only when it losses the current • Interaction is through the Bluetooth interface

44. Discussion • Security • MoB provides integrity of reputation certificates • It does not address data security and integrity • A user downloading sensitive data, should probably use Secure Sockets Layer (SSL) to provide end-to-end security • In some scenarios, providing security is not straightforward • In distributed location determination, a malicious trader may provide incorrect location information • This info. can be cross-checked against other traders • If a mismatch is detected, this can lead to negative feedback

45. Discussion • Security • Individual clients may employ different security mechanisms • Based on their prior experience • Based on their faith in behavior of others • They can rely on the reputation system to provide useful historical log • They can choose to accept data from any trader, only those with “reasonable” reputation, or just those they directly trust

46. Discussion • Legal aspects • Many services are traded between only two entities • However, many times a client acts as a reseller • This may raise legal issues • For example, 3G cellphone resells bandwidth to nearby laptop • Many ISPs prohibit reselling bandwidth • This is because they have no financial incentive • This may be solved by providing incentive-sharing techniques between MoB participants • An compensation agreement between the cellphone user and the 3G network operator may be negotiated • May be hard to enforce