Haggle Architecture Erik Nordstrm Christian Rohner Haggle Project

Haggle Architecture Erik Nordström, Christian Rohner

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

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

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

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

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

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

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?

“Searching” in Early Haggle • INS-inspired namespace – Structured metadata – Hierarchical (name graph/tree) Root • 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 INS Service Accessibility Camera Public Washington Resolution Data-type Building 640 x 480 Picture White house

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 Page. Rank – Connections (Soule et al. 2005)

Relation Graph

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

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

Benefits of a Search Approach • Flexible “naming and addressing” – No e 2 e 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

Demo

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

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

Cut in Relation Graph Ranked result = {v 1, v 2} || {v 2, v 1}

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

Data Object Format

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

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?

Weighting

Query Time