MoB: A Mobile Bazaar for Wide-area Wireless Services Presented by Nir Peer University of Maryland Rajiv Chakravorty Sulabh Agarwal Suman Banerjee U. of

MoB: A Mobile Bazaar for Wide-area MoB: A Mobile Bazaar for Wide-area Wireless ServicesWireless Services

Presented by Nir PeerUniversity of Maryland

Rajiv ChakravortySulabh AgarwalSuman Banerjee

U. of Wisconsin-Madison

Ian Pratt

U. of Cambridge

2

IntroductionIntroduction

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


Leads to poor performance of networked applications on mobile devices

4


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 competitionFine-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 competitionFine-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 MoBServices in MoB

Goal of MoB: enable incentive-induced service collaboration between independent mobile devices.

Example: bandwidth aggregation service

customer traders

8


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


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


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


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 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


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 ReputationPricing 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 environmentsApplicable 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 featuresSalient 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 featuresSalient 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

MoB ArchitectureMoB Architecture

19

MoB architectureMoB architecture

3rd party services for accounting and billing,reputation and trust management

Internet

Mobile devices

Networking infrastructure

20

MoB architectureMoB 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 parties

e.g., due to multiple successful interactions in the past Altruistic

Perfect trust and no financial incentivese.g., within a friend’s network

21

Vito DesignVito 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

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

Operations in MoBOperations in MoBUser A Vito User B

Register KA+

AcceptRA:[TS1, ScoreA, KA

+]KVito−

Register KB+

AcceptRB:[TS2, ScoreB, KB

+]KVito−

A and B independently register with Vito

23

Operations in MoBOperations in MoB

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

User A Vito User B

SLP Srv Req RA, [TS3]KA−

SLP Srv RespRB, [TS3, TS4, Price]KB

−

A and B interact, no need to access Vito

TokenT: [TS4, TS5, A, B, Price]KA

−

Service interactions

24


Consider the scenario A multicasts a Service

Request 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

User A Vito User B

SLP Srv Req RA, [TS3]KA−

SLP Srv RespRB, [TS3, TS4, Price]KB

−

A and B interact, no need to access Vito

TokenT: [TS4, TS5, A, B, Price]KA

−

Service interactions

25


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 fee

for 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

User A Vito User B

Nightly reputation and billing updates

Encash T, [TS6, B]KB−

Token encashed[TS6]KVito

−

Feedback[TS7, B, A, Score]KB

−

Reputation (updated)RA

Reputation (updated)RB

26

Design DecisionsDesign 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


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


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


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 Evaluation of the Reputation Management ModelManagement 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


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


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

ImplementationImplementation

34

ImplementationImplementation

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

ImplementationImplementationAccepts 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

ImplementationImplementationRegulates 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

ImplementationImplementationNeighbor 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).

Evaluating MoB ApplicationsEvaluating MoB Applications

39

Experimental SetupExperimental 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 applicationsFile-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


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 C

so C only downloads from it. T2 moves in-range of C at t1 = 12 and

is 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 t3 C downloads from both. The aggregate throughput is

327.2Kbps

42


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


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

DiscussionDiscussion

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


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


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

Documents

MoB: A Mobile Bazaar for Wide-area Wireless Services Presented by Nir Peer University of Maryland Rajiv Chakravorty Sulabh Agarwal Suman Banerjee U. of