Haggle Architecture

1. Haggle Architecture Erik Nordström, Christian Rohner

2. Haggle Project • 4 Year EU project • 8 partners: Uppsala, Cambridge, Thomson, CNR, Eurecom, SUPSI, EPFL, LG (former Intel) • Uppsala: • Testbed (Virtual-APE) • Architecture design and implementation • People • Erik, Christian, Daniel, Fredrik

3. Haggle – “Ad hoc Google” Community “Search the neighborhood” Opportunistic Pocket-switched

4. Searching and Forwarding Search for matching content Search for matching content 1 Interests 2 3 4 Interests 4 3 2 1

5. Haggle Architecture Invariants • Data-centric • Application-layer framing (“data objects”) • Dissemination instead of conversation • Late binding • Asynchronous

6. Architecture Issues • Resolving “destinations” • Who and what is out there? • Interfacing • Physical • Language / Protocol • Content and priority • Forwarding ?

7. Host-centric vs. Data-centric news.bbc.co.uk www.cnn.com www.foxnews.com news.google.com

8. A Search-based Network Architecture • Make searching a first class networking primitive • What does searching imply? • Unstructured (meta)data • Query - Keywords/interests • Ranked results • How can searching help us in a Haggle-style networking context?

9. “Searching” in Early Haggle INS • INS-inspired namespace • Structured metadata • Hierarchical (name graph/tree) • Used to map from higher level name to lower level protocol/interface • Static, and pre-defined mappings • No searching – just lookup / tree traversal • How map data to user? • Implies destination oriented communication

10. Searching on the Desktop and the Web • Consistent namespaces • Semantic filesystem (Gifford et al. 1991) • File attributes along file names • User explicitly adds metadata • Metadata extraction and indexing • Content-based search • Probabilistic models map metadata (term freq., language models) to search terms • Context enhanced search using graph models • Google’s PageRank • Connections (Soule et al. 2005)

11. Relation Graph

12. Haggle Relation Graph • Each Haggle node maintains a relation graph • Vertices are data objects • Edges are relations = two data objects share an attribute • Primitives on the relation graph = network operations • Shares similarities with (local) search • E.g., Connections [Soules et. al 2006], Apple Spotlight, Google Desktop

13. Relation Graph • Computer • Beer • Film • Music • Haggle • Food • Haggle • Music • CoRe • Film • Beer • Computer • Uppsala • Cambridge • Haggle 2 3 1 1 1 2 2 1 1 • Beer • Music • CoRe • Cambridge • Haggle 1 • Food • Stockholm • Haggle

17. Benefits of a Search Approach • Flexible “naming and addressing” • No e2e end-point identifiers • Late binding resolutions • Late binding demultiplexing • Content dissemination and forwarding • Ordered forwarding • Delegate forwarding and interest-based forwarding • Resource and congestion control • Limit queries – only get best matching content

18. Demo

19. Filter – Local Demultiplex Data object Induced subgraph Attribute Demux = filtering associated with an actor

20. Query – Weighting the graph There may be many ways to do the weighting!

21. Cut in Relation Graph Ranked result = {v1,v2} || {v2,v1}

22. Exchanging Data Objects Resolve data/content Resolve node • Since content and nodes are both data objects, these two operations are (more ore less) the same

23. Data Object Format

24. Searching in Haggle • Use searching to resolve mappings between data and receivers • Analogy: Top 5 hits on Google • Content ranked (priority) • Results change with the content carried

25. Conclusions • Search primitives are useful abstractions for DTN-style networking • Novel naming and addressing • Ranking useful for dissemination • Resource/congestion control • Ordered forwarding (priorities) • Better understanding of scaling needed • Query time • Effect on battery life?

27. Weighting

28. Query Time