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.
4
IntroductionIntroduction
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
Services in MoBServices 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 MoBServices 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 MoBServices 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 MoBServices 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 MoBServices 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 MoBServices 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 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
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
Operations in MoBOperations in MoB
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
Operations in MoBOperations in MoB
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
Design DecisionsDesign 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 DecisionsDesign 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 DecisionsDesign 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 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
Evaluation of the Reputation Evaluation of the Reputation Management ModelManagement 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 Evaluation of the Reputation Management ModelManagement 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
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).
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
File-transfer applicationsFile-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 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
File-transfer applicationsFile-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 applicationsFile-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
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
DiscussionDiscussion
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
DiscussionDiscussion
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