MoB: A Mobile Bazaar for Widearea Wireless Services

1
MoB A Mobile Bazaar for Wide-area Wireless
Services

• Presented by Nir Peer
• University of Maryland

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

• Goal of MoB enable incentive-induced service
  collaboration between independent mobile devices.
• Example bandwidth aggregation service

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 (contd)
• 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 (contd)
• 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 Microsofts 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, ATT, 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 friends 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
  others 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 Vitos 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

Register KA
Register KB
AcceptRATS1, ScoreA, KAKVito-
AcceptRBTS2, ScoreB, KBKVito-
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.253427
• TTL is chosen to be 1, since in MoB service
  interactions are pairwise

SLP Srv Req RA, TS3KA-
SLP Srv RespRB, TS3, TS4, PriceKB-
TokenT TS4, TS5, A, B, PriceKA-
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 As reputation
• SLP Service Agent B respondswith a service
  description (25Kbps)and a price quote
• It includes Bs 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 Req RA, TS3KA-
SLP Srv RespRB, TS3, TS4, PriceKB-
TokenT TS4, TS5, A, B, PriceKA-
Service interactions
A and B interact, no need to access Vito
25
Operations in MoB
User A
Vito
User B

• Scenario (contd)
• 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 itll typically report a
  positive feedback for A
• If A was dissatisfied, itll explicitly report
  negative feedback for B

Encash T, TS6, BKB-
Token encashedTS6KVito-
FeedbackTS7, B, A, ScoreKB-
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 As 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 wouldnt 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 (contd)
• 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
  (contd)
• 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 t3 C 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 (contd)
• 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