Implementing Declarative Overlays From two talks by Boon

Implementing Declarative Overlays From two talks by: Boon Thau Loo 1 Tyson Condie 1, Joseph M. Hellerstein 1, 2, Petros Maniatis 2, Timothy Roscoe 2, Ion Stoica 1 1 University of California at Berkeley, 2 Intel Research Berkeley 1

Overlays Everywhere… Overlay networks are widely used today: n n Routing and forwarding component of large-scale distributed systems Provide new functionality over existing infrastructure Many examples, variety of requirements: n n n Packet delivery: Multicast, RON Content delivery: CDNs, P 2 P file sharing, DHTs Enterprise systems: MS Exchange Overlay networks are an integral part of many large-scale distributed systems. 2

Problem Non-trivial to design, build and deploy an overlay correctly: n Iterative design process: w Desired properties Distributed algorithms and protocols Simulation Implementation Deployment Repeat… n Each iteration takes significant time and utilizes a variety of expertise 3

The Goal of P 2 Make overlay development more accessible: n Focus on algorithms and protocol designs, not the implementation Tool for rapid prototyping of new overlays: n n n Specify overlay network at a high level Automatically translate specification to protocol Provide execution engine for protocol Aim for “good enough” performance n n Focus on accelerating the iterative design process Can always hand-tune implementation later 4

Outline Overview of P 2 Architecture By Example n n n Data Model Dataflow framework Query Language Chord Additional Benefits n n Overlay Introspection Automatic Optimizations Conclusion 5

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D, is a link from node a to node b” link(a, b) – “there If there is a link from S to D, then S can reach D”. reachable(a, b) – “node a can reach node b” Input: link(source, destination) Output: reachable(source, destination) 6

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D and Z, If there is a link from S to Z, AND Z can reach D, then S can reach D”. Input: link(source, destination) Output: reachable(source, destination) 7

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D, is a link from node a to node b” link(a, b) – “there If there is a link from S to D, then S can reach D”. reachable(a, b) – “node a can reach node b” Input: link(source, destination) Output: reachable(source, destination) 8

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D and Z, If there is a link from S to Z, AND Z can reach D, then S can reach D”. Input: link(source, destination) Output: reachable(source, destination) 9

Towards Network Datalog Specify tuple placement n Value-based partitioning of tables Tuples to be combined are co-located n Rule rewrite ensures body is always single-site All communication is among neighbors n n No multihop routing during basic rule execution Link-restricted rules: Enforced via simple syntactic restrictions 10

Network Datalog Location Specifier “@S” R 1: reachable(@S, D) link(@S, D) R 2: reachable(@S, D) link(@S, Z), reachable(@Z, D) Query: reachable(@a, N) reachable(@M, N) link Input table: Output table: All-Pairs Reachability link @S D @a b @b c @c b @d c @b a @c d a b c d reachable @S D @a b @a c @b @a d @b @S D @b a Query: reachable(@a, N) @c a @d a c @c b @d d @c d b @d 11 c

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D, is a link from node a to node b” link(a, b) – “there If there is a link from S to D, then S can reach D”. reachable(a, b) – “node a can reach node b” Input: link(source, destination) Output: reachable(source, destination) 12

All-Pairs Reachability R 1: reachable(S, D) link(S, D) R 2: reachable(S, D) link(S, Z), reachable(Z, D) “For all nodes S, D and Z, If there is a link from S to Z, AND Z can reach D, then S can reach D”. Input: link(source, destination) Output: reachable(source, destination) 13

Query Execution R 1: path(@S, D, P) link(@S, D), P=(S, D). R 2: path(@S, D, P) link(@S, Z), path(@Z, D, P 2), P=S P 2. Query: path(@a, d, P) link Neighbor table: link D @S D @a b @b c @c b @d c @b a @c d path @S link @S a Forwarding table: link D P @S b c path D P d @S D P @c d [c, d] 14

Chord Model Relational data: relational tables and tuples Two kinds of tables: n Stored, soft state: w E. g. neighbor(Src, Dst), forward(Src, Dst, Nxt. Hop) n Transient streams: w Network messages: message (Rcvr, Dst) w Local timer-based events: periodic (Node. ID, 10) 15

Example: Ring Routing Objects “served” by successor Each node has an address and an identifier Each object has an identifier. Every node knows its successor 16

Ring State Stored tables: n n node(NAddr, N) succ(NAddr, Succ, SAddr) node(IP 58, 58) succ(IP 58, 60, IP 60) node(IP 40, 40) succ(IP 40, 58, IP 58) 17

Example: Ring lookup Find the responsible node for a given key k? n. lookup(k) if k in (n, n. successor) return n. successor. addr else return n. successor. lookup(k) 18

Ring Lookup Events Event streams: n n lookup(Addr, Req, K) response(Addr, K, Owner) n. lookup(k) node(IP 58, 58) succ(IP 58, 60, IP 60) response(IP 37, 59, IP 60) node(IP 40, 40) succ(IP 40, 58, IP 58) n. successor) lookup(IP 58, IP 37, 59) if k in (n, return n. successor. addr else return n. successor. lookup(k) lookup(IP 37 40, IP 37, 59) 19

Query Language: Overlog Datalog rule syntax: <head> <condition 1>, <condition 2>, … , <condition. N>. Overlog rule syntax: <Action> <event>, <condition 1>, … , <condition. N>. 20

Query Language: Overlog rule syntax: <Action> <event>, <condition 1>, … , <condition. N>. Event: RECEIVE lookup(NAddr, Req, K) Condition: lookup(NAddr, Req, K) & node(NAddr, N) & succ(NAddr, Succ, SAddr) & K in (N, Succ] Action: SEND response(Req, K, SAddr) to Req response@Req(Req, K, SAddr) lookup@NAddr(Naddr, Req, K), node@NAddr(NAddr, N), succ@NAddr(NAddr, Succ, SAddr), K in (N, Succ]. 21

P 2 -Chord Routing, including: n Multiple successors n Stabilization n Optimized finger maintenance n Failure recovery 47 Over. Log rules 13 table definitions Other examples: n Narada, flooding, routing protocols 10 pt font 22

Introspection with Queries With Atul Singh (Rice) and Peter Druschel (MPI) Unifying framework for debugging and implementation n Same query language, same platform Execution tracing/logging n n Rule and dataflow level Log entries stored as tuples and queried Correctness invariants, regression tests as queries: n n n “Is the Chord ring well formed? ” (3 rules) “What is the network diameter? ” (5 rules) “Is Chord routing consistent? ” (11 rules) 23

Automatic Optimizations Application of traditional Datalog optimizations to network routing protocols (SIGCOMM 2005) Multi-query sharing: n n n Common “subexpression” elimination Caching and reuse of previously computed results Opportunistically share message propagation across rules lookup Join Select lookup. Addr = node. Addr lookup. Addr = succ. Addr K not in (N, Succ) Join Select lookup. Addr = node. Addr lookup. Addr = succ. Addr K in (N, Succ) Project lookup Project response lookup(SAddr, Req, K) Response(Req, K, SAddr) 24

Automatic Optimizations Cost-based optimizations n lookup Join ordering affects performance Join lookup. Addr = node. Addr succ. Addr = Join lookup. Addr = = node. Addr succ. Addr Select K not in (N, Succ) Select K in (N, Succ) Project lookup Project response lookup(SAddr, R eq, K) Response(Req, K, SAddr) 25

Future Work “Right” language Formal data and query semantics Static analysis n n n Optimizations Termination Correctness 26

Conclusion P 2: Declarative Overlays n Tool for rapid prototyping new overlay networks Declarative Networks n n Research agenda: Specify and construct networks declaratively Declarative Routing : Extensible Routing with Declarative Queries (SIGCOMM 2005) 27