1. 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

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

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

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

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

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

7. 7 All-Pairs Reachability R2: reachable(S,D)  link(S,Z), reachable(Z,D) R1: reachable(S,D)  link(S,D) Input: link(source, destination) Output: reachable(source, destination) “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”.

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

9. 9 All-Pairs Reachability R2: reachable(S,D)  link(S,Z), reachable(Z,D) R1: reachable(S,D)  link(S,D) Input: link(source, destination) Output: reachable(source, destination) “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”.

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

11. 11 All-Pairs Reachability R1: reachable(@S,D)  link(@S,D) R2: reachable(@S,D)  link(@S,Z), reachable(@Z,D) Network Datalog Query: reachable(@M,N) @SD @ab c d reachable Output table: Input table: Query: reachable(@a,N) @SD @cb d link @SD @bc a link @SD @ab link @SD @dc link bdc a @SD @ba c d reachable @SD @ca b d reachable @SD @da b c reachable Location Specifier “@S” Query: reachable(@a,N)

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

13. 13 All-Pairs Reachability R2: reachable(S,D)  link(S,Z), reachable(Z,D) R1: reachable(S,D)  link(S,D) Input: link(source, destination) Output: reachable(source, destination) “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”.

14. 14 R1: path(@S,D,P)  link(@S,D), P=(S,D). R2: path(@S,D,P)  link(@S,Z), path(@Z,D,P 2 ), P=S  P 2. @SDP DP @cd[c,d] Query Execution @SDP DP Query: path(@a,d,P) Neighbor table: @SD @cb d link @SD @bc a link @SD @ab link @SD @dc link bdca path Forwarding table:

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

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

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

18. 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)

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

20. Query Language: Overlog Datalog rule syntax: ,, …,. Overlog rule syntax: ,, …,.

21. Query Language: Overlog 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]. Overlog rule syntax: ,, …,.

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

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

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

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

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

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