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”

Opportunistic

Pocket-switched

Community

“Search the neighborhood”

Searching and Forwarding

Interests

Interests

Search for matching content

Search for matching content

4 3 21

12 3 4

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

?

www.cnn.com

news.bbc.co.uk

www.foxnews.com

Host-centric vs. Data-centric

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)

• 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

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)

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

•Uppsala•Cambridge•Haggle

•Cambridge•Haggle

•Music•Haggle

•Haggle

•Food•Haggle•Music•CoRe

•Food•Stockholm

•Beer•Music•CoRe

•Computer•Beer•Film

•Film•Beer•Computer

2

1

11

2

12

1

3

1

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

Demo

Filter – Local Demultiplex

Demux = filtering associated with an actor

Data object

Attribute

Induced subgraph

Query – Weighting the graph

There may be many ways to do the weighting!

Cut in Relation Graph

Ranked result = {v1,v2} || {v2,v1}

Exchanging Data ObjectsResolve

data/content Resolve node

•Since content and nodes are both data objects, these two operations are (more ore 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