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, 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  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, , 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 messaging 1. Forwarding within communities

13 Illustration: Ad-hoc messaging 2. Taking advantage of mobility

14 AP Illustration: Ad-hoc messaging 3. 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, , 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?