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?