Implementing Declarative Overlays

1. Implementing Declarative Overlays B. T. Loo, T. Condie, J. M. Hellerstein, P. Maniatis, T. Roscoe, I. Stoica Presentation by Hakon Verespej

2. What the hell is an overlay anyways? An abstraction on top of the network layer to provide some service. Common uses include routing, forwarding, etc. (i.e. they provide new functionality on top of existing infrastructure) Examples: Multicast, P2P file sharing, …

3. What the hell is an overlay anyways?

4. That’s nice. So what? Building communication infrastructure is solidifying as a requirement in software development. Remember that message systems of this nature are not limited to those that operate over the Internet.

5. Okay, so what are we looking at here? Traditionally, implementing overlays tends to be time-consuming and difficult (i.e. buggy). We want to improve upon these issues.

6. Okay, so what are we looking at here? There are a couple of approaches Protocol-centric Structure-centric We will use a combination

7. Goals Ease the overlay development process. Create a useful tool for rapid prototyping. “Good enough” performance. Lofty? Not particularly. Reasonable? Yes.

8. Overview of a P2 Overlay Node

9. Sweet! Show me more! To specify structure, a declarative query language called OverLog is provided. Benefits include: Scoping Typing Encapsulation and Reuse

10. Let’s get dirty Let’s look at an example. Narada Mesh Overlay multicast system Consists of 2 layers Group membership (mesh) Delivery trees built on top of the mesh

11. Let’s get dirty Narada mesh overview: Each node keeps a set of all neighbors and a set of all members Nodes send keep-alive messages. Neighbors exchange knowledge. A node declares a neighbor dead if it doesn’t receive a keep-alive from it. Random probes measure latencies and are used to modify the neighbor list.

12. Let’s get dirty The tables: materialize(neighbor, 120, infinity, keys(2)). materialize(member, 120, infinity, keys(2)). materialize(sequence, infinity, 1, keys(2)).

13. Let’s get dirty Maintenance: R1 refreshEvent(X) :- periodic(X, E, 3). R2 refreshSeq(X, NewSeq) :- refreshEvent(X), sequence(X, Seq), NewSeq := Seq + 1. R3 sequence(X, NewS) :- refreshSeq(X, NewS).

14. Let’s get dirty R4 member@Y(Y, A, ASeqX, TimeY, ALiveX) :- refreshSeq@X(X, S), member@X(X, A, ASeqX, _, AliveX), neighbor@X(X, Y), not member@Y(Y, A, _, _, _), TimeY := f_now@Y(). R5 member@Y(Y, A, ASeqX, TimeY, ALiveX) :- refreshSeq@X(X, S), member@X(X, A, ASeqX, _, ALiveX), neighbor@X(X, Y), member@Y(Y, A, ASeqY, _, _), ASeqY < ASeqX, TimeY := f_now@Y(). R6 member@Y(Y, X, S, TimeY, true) :- refreshSeq@X(X, S), neighbor@X(X, Y), TimeY := f_now@Y().

15. Let’s get dirty P2 implicitly determines table structure. neighbor(MyAddress, NeighborAddress) member(MyAddress, MemberAddress, MemberSequence, MemberInsertionTime, MemberLive)

16. Let’s get dirty Joining the mesh: N1 neighbor@Y(Y, X) :- refreshSeq@X(X, S), neighbor@X(X, Y).

17. Let’s get dirty Neighbor relationships: L1 neighborProbe@X(X) :- periodic@X(X, E, 1). L2 deadNeighbor@X(X, Y) :- neighborProbe@X(X), neighbor@X(X, Y), member@X(X, Y, _, YT, _), f_now() - YT > 20. L3 delete neighbor@X(X, Y) :- deadNeighbor@X(X, Y). L4 member@X(X, Neighbor, DeadSeq, T, false) :- deadNeighbor@X(X, Neighbor), member@X(X, Neighbor, S, _, _), DeadSeq := S + 1, T:= f_now().

18. Let’s get dirty Latency measurements: P0 pingEvent@X(X, Y, E, max<R>) :- periodic@X(X, E, 2), member@X(X, Y, _, _, _), R := f_rand(). P1 ping@Y(Y, X, E, T) :- pingEvent@X(X, Y, E, _), T := f_now@X(). P2 pong@X(X, Y, E, T) :- ping@Y(Y, X, E, T). P3 latency@X(X, Y, T) :- pong@X(X, Y, E, T1), T := f_now@X() - T1.

19. Let’s get dirty Utility Measurement: U1 ugain@X(X, Z, sum<UGain>) :- latency@X(X, Z, T), not neighbor@X(X, Z), route@Z(Z, Y, _, C), UNew := T + C, route@X(X, Y, _, UCurr), UNew < UCurr, UGain := (UCurr - UNew) / UCurr. U2 neighbor@X(X, Z) :- ugain@X(X, Z, UGain), UGain > addThresh.

20. Ooh! I feel so dirty… Any questions so far?

21. Ooh! I feel so dirty… P2 only required 3 materializations and 16 rules. Traditional implementations take hundreds of lines of code. The P2 specification can be directly compiled and executed on a set of P2 nodes.

22. P2 Implementation Let’s not bore ourselves with implementation details. Refer to the paper if desired. At a high level, the P2 system includes: OverLog parser A planner A set of dataflow element implementations Run-time plan executor

23. P2 Implementation

24. P2 Implementation A few notable points: The authors implemented PEL , an expression language for manipulating values and tuples. Handlers run to completion. Planner is not easily extensible at present.

25. Let’s see what P2 can really do! We’ll look at Chord, a P2P lookup system. Refer to your handout. ¿ Do we have time ? ¿ Is everyone interested ?

26. Let’s see what P2 can really do!

27. Cool! But… does it work? Static state tests No churn Uniform lookup work load

28. Cool! But… does it work? Hop count averages are as expected. Low BW usage. Lookup latency is on the same order as that published for MIT’s C++ implementation.

29. Cool! But… does it work? Dynamic state tests 400-node network. Varying degrees of churn. Same lookup workload.

30. Cool! But… does it work? Maintenance traffic is still low. Performs well with low churn, but takes a beating under high churn. For comparison, the MIT implemetation has 99.9% consistency for 47-minute sessions and lookup latency of less than 5 seconds under high churn.

31. Conclusion The approach looks promising. Overlays can be specified extremely concisely. OverLog may impose a difficult learning curve and the syntax tends to be viewed as an “acquired taste”. The Chord spec is not quite declarative, but this is not by fault of OverLog.

32. Woohoo! It’s the weekend!