P2P Applications and MobileMAN Jon Crowcroft, Ziran Sun, (UCAM) Elgan Huang&Wenjun Hu (UCAM) Marcel...
-
Upload
esther-west -
Category
Documents
-
view
214 -
download
0
Transcript of P2P Applications and MobileMAN Jon Crowcroft, Ziran Sun, (UCAM) Elgan Huang&Wenjun Hu (UCAM) Marcel...
P2P Applications and MobileMAN
Jon Crowcroft, Ziran Sun, (UCAM)
Elgan Huang&Wenjun Hu (UCAM)
Marcel Dischinger&Jan Hoeft (Karlsruhe)
2
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 based on Dischinger Wb
3
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:
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
5
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)
6
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!
7
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
8
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
9
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
10
Some Haggle Applications
• Asynchronous messaging
• Automatic address book or calendar updates
• File sharing
• Commercial transactions
• Tracking or finding users
11
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
12
Illustration: Ad-hoc messaging1. Forwarding within communities
13
Illustration: Ad-hoc messaging2. Taking advantage of mobility
14
AP
AP
Illustration: Ad-hoc messaging3. Use the Internet if (and only if) its
sensible
15
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
16
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
17
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
18
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 content-query 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”
19
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)
20
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
21
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…?
22
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
23
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
24
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
25
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?