Transcript P2P Application and MobileMAN

P2P Applications and
MobileMAN
Jon Crowcroft, Ziran Sun, (UCAM)
Elgan Huang&Wenjun Hu (UCAM)
Marcel Dischinger&Jan Hoeft
(Karlsruhe)
Application & Cross Layer outlook for review 2
• First step will build on experience with bamboo
(java p2p middleware - tutorial) and multicast
 Multicast is reverse path of forward p2p route - if p2p
route is hash of node location from wifi layer, should
work well! (by Dischinger).
 problem for OLSR/HSLS using reverse path
 Distance (coord triangle) service (Hoeft)
• Possible use of fuzzy logic controllers
 to avoid interference between nested control laws
acting on NeST data (worked in past) - e.g.
 MAC->HSLS/OLSR cong indication -> TCP->App
• Could also look at synch/many-to-many Fileshare 2
Economics & Mobility outlook for review 2
• Have simulation results for taxi
 Using realistic mobility model
• But: for Different routing layer (not HSLS)
 takes advantage of restricted waypoint and
knowledge of velocity distribution of taxis and
intersections (road topology and traffic matrix)
• No integration of incentive or cross layer
yet in simulation…
• Future: move to more radical cross layer:
3
Ad-Hoc google Haggle
Opportunistic networking in a disconnected age.
Currently internal Cambridge project only
Christophe Diot, Gianluca Iannaconne,
Marc Liberatore, James Scott, Eben Upton
Intel Research Cambridge
Jon Crowcroft, Ziran Sun, Wenjun Hu
Cambridge University
Collaborating institutions and
Pis for possible EU proj.
•
•
•
•
Intel Research, UK (Christophe Diot)
Cambridge University, UK (Jon Crowcroft)
EPFL, Switzerland (Jean-Yves LeBoudec)
University of Uppsala, Sweden (Per
Gunningberg)
• University of Massachusetts, USA (Brian
Levine)
5
The world is not connected!
• Users move between heterogeneous connectivity
islands
• End-to-end is not always possible
 One or both ends or middle may be disconnected
• Device should make network decisions
 Shall I send by Bluetooth, WiFi, GPRS, email later:)?
• => No IP route => No TCP => New Stack
 Not MobileMAN!
6
Challenges with periodic and
local connectivity
•
•
•
•
•
Distributed subject-based naming
Nodes need to locate themselves
Neighbours discovery
Security, trust and reputation
Exploit massive aggregate bandwidth
 Identify devices with local connectivity
 Make use of MBs of local storage
7
Haggle goals
•
•
•
•
Ad Hoc google
Cross platform
Cross network technologies
Provide a useful set of services in the
absence of a fixed infrastructure and e2e
connectivity




opportunistic connection
“smart” message forwarding
distributed naming
authentication and trust information
8
Haggle goals (cont.)
• Exploit features of the problem space
 node mobility for message delivery
 Build communities
 distributed, intuitive authentication
• Integration with legacy systems
 email delivery
 web requests
9
Some Haggle Applications
•
•
•
•
•
Asynchronous messaging
Automatic address book or calendar updates
File sharing
Commercial transactions
Tracking or finding users
10
Haggle Assumptions
• Users carry devices with connectivity
 Bluetooth, 802.11, Ethernet, cradle, etc.
• Storage is not a problem
 storage density doubling every year
• Battery is more of a problem
 heuristics to determine how scarce battery is
 scale Haggle operations appropriately
 allow user control
11
Illustration: Ad-hoc messaging
1. Forwarding within communities
12
Illustration: Ad-hoc messaging
2. Taking advantage of mobility
13
Illustration: Ad-hoc messaging
3. Use the Internet if (and only if) its
sensible
AP
AP
14
Haggle is VERY ad-hoc
•
•
•
•
Ad-hoc life is often disconnected
Dynamic communities, dynamic trust
Mobility and opportunistic networking
Heterogeneous network types with different
bandwidth/cost/coverage/naming
• Internet is a technology of the past
15
Principle components of
Haggle
• Communities instead of ASs
• “Small world” forwarding
 the Internet is a networking technology
 among others
• Localization for networking and for apps
• Trust and security built-in
• Attention: paid to user acceptance, usability,
and privacy
16
Community networks
• Recently, many applications have relied on
communities sharing a common interest/goal:
 Overlay networks, VPNs, etc.
 File sharing P2P networks
 Ad-hoc networks
• Communities may be transient (concert attendees)
or long-lived (interest groups)
• Users may be in multiple communities at any
time, and change communities over time
• Issues with naming, trustability, security, incentive
to cooperate
17
Small world forwarding
• Bootstrap State information are flooded
 tau-persistent multicast (tau dynamic)
 Used to populate initial “forwarding” tables, No routes,
no routing, yes congestion control
 Find the next hop that has the highest probability to
deliver based on google-style “relevant” to contentquery
 Dual control algorithm for resource management
• Application forwarding based on neighbourhood
status and history+interest
 by including in proactive crawl/index
 Avoid flooding -I.e. interest directed OLSR
 Data aging - but very large “forwarding” “cache”
18
Localization
• Node localization is important
 Neighbourhood discovery/community creation
 Location-aware applications
 Trust and security
• Various options
 Relative to other nodes
 Absolute (e.g. GPS)
 Based on some external service (c.f. PlaceLab use of
base stations)
19
Trust and Security
• Human in the loop for bootstrapping trust
 User 1 + PDA 1 <-> PDA 2 + User 2
 User recognize each other and auth PDAs
simultaneously - PDAs use localization and biometric
to check each other and their humans
• Trust is partially transitive (c.f. PGP)
 Encryption and signing can then provide secure,
authenticated transmissions
 Reputation systems may be used to provide incentives
to play nice
• How do we preserve privacy? Community based
20
Usability and User
Involvement
• Usability will require informing the user
about network state issues – but how?
 Spinning globe, signal strength bars, greyed-out
names, instant messaging presence indications
• When is user involvement required?
 Most decisions must be made by devices
 Some decisions may have to be left to user
• What incentive to cooperate? Kazaa…?
21
Research Plan
• Proof-of-concept demo
 runs on Bluetooth capable Java mobile phones
 address book + other small file synchronization
• Implement base Haggle modules
 link layer interface, neighbor discovery,
message forwarding, local store, monitoring
 Asynchronous messaging, people localization
• Build other simple applications
22
Research Plan (Cont.)
• Small-scale deployment
 measure usage patterns, bug test prototype
• Model large deployment in simulation
 examine system performance under simple models, find
bottlenecks
 iterate with less forgiving models
• Improve performance
 e.g., forward on the basis of likelihood of meeting,
trust, community membership
23
Research Plan (Cont.)
• Implement additional modules
 Community, trust, localization, legacy system
interaction, filesystem interaction
• Implement additional applications
 file sharing, web queries, e-mail, ims
• Deploy at large meeting (e.g. 500 users at
INFOCOM), measure usage patterns
24
Suggestions & Questions
• If you had haggle, you would have these slides
• If you had haggle, you could contribute new application
patterns and code to us now
• We would trust that it came from you, and you that our
slides or code were from us
• You could pass it on to colleagues and collaborators
without even knowing it, safely!
• You could even throw away your USB dongle (note
painful latency, and poor security even with biometric e.g.
usb fingerprint)
• Wouldn’t Haggle be useful?
25