haggle architecture and reference implementation

Haggle Architecture and Reference Implementation

Uppsala, September 29-30Erik Nordström, Christian Rohner

Haggle Scenario

• The scenario (you all know this):– People carry information with them– Ad hoc/opportunistic interactions– Heterogeneous connectivity

• Architectural problems:– How to agree on names and addresses?– How to exchange information (protocols, tech.)?– How to prioritize the information to exchange?

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 Haggle INFANT• 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)

Haggle Scenario (contd.)

Interests

Interests

Search for matching content

Search for matching content

4 3 21

12 3 4

Searching in Haggle

• Use searching to resolve mappings between data and receivers

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

•Christian•Tryffel

Relation Graph

• Each Haggle node maintains a relation graph• Vertices are data objects• Edges are relations = two data objects share

an attribute• We define our primitives on the relation graph• Shares similarities with (local) search– E.g., Connections [Soules et. al 2006], Apple

Spotlight, Google Desktop

Filter

Demux = filtering associated with an actor

Data object

Attribute

Induced subgraph

Query – Weighting the graph

There may be many ways to do the weighting!

Resolve = 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

Search Benefits

• Flexible naming and addressing• Late binding resolutions• Late binding demultiplexing• Content dissemination and forwarding– Deciding delegate forwarders– Ordered forwarding

• Resource and congestion control– Limit queries – only get best matching content

Query Time

Weighting

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?