1. Program Synthesis for Network Updates Pavol Černý CU Boulder Dagstuhl, February 2015

2. Hossein HojjatJedidiah McClurg Nate Foster

3. Program synthesis

4. Network updates

5. Network Update T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 H1 H2 H3 H4 Spec: consistency – either red or blue

6. Technique: Two-Phase Updates Space: in general, two-phase updates require double the amount of memory on switches Time: updating a TCAM can take on the order of 10s of seconds for several hundred rules Semantics: in many applications, full consistency is not needed

7. Order Updates T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 H1H1 H2H2 H3H3 H4H4 Approach: update switches in a specified order that eventually reaches the target configuration Problem: can create behaviors that were not possible in either configuration, which easily leads to violations of important invariants Example: updating A1 first, then C2 breaks H1-H3 connectivity!

8. Order Update Example T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 No order update preserves full consistency! H1 H2 H3 H4 If we want only H1-H3 connectivity: Order A2-A4-T1-C1 works

9. Order Update Example T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 H1 H2 H3 H4 Property: at all times, maintain H1-H3 connectivity and either traverse A2 or A3 A2-A4-C1 (not good) A2-A4-T1-C1 ?

10. Waits T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 H1 H2 H3 H4 Approach: to avoid violating invariants, pause between each switch update, and wait until in-flight packets have exited the network Performance: because transmission delay of a switch is in μs, but TCAM updates take 10s of seconds, effect of waits is negligible

11. Outline (synthesis for network updates) 1.Synthesis for network updates 2. Main ideas Counterexample-driven search Incremental model checking

12. Synthesis of Updates Input: initial network configuration final network configuration set of path properties (in LTL) Output: sequence of switch updates such that the path properties hold for every packet that traverses the network while updates are performed

13. LTL and Packet Path Properties

14. Outline (synthesis for network updates) 1.Synthesis for network updates 2. Main ideas Counterexample-driven search Incremental model checking

15. Order Update Synthesis: Search φ LTL property topology + configurations

16. Algorithm  High-level structure: Depth-first search with Incremental model checking (for LTL) featuring Counterexample-based pruning Early Search Termination Wait removal

17. Counterexamples Use of counterexamples. If a configuration is found to be wrong, we get a counterexample. Counterexample: (sequence of pairs (node;bool); bool indicates whether node has been updated) (A1,true) (C2,false) Use the counterexample to avoid model checking calls. T1 A1 A2 T2 C1 T3 A3 A4 T4 C2 H1H1 H2H2 H3H3 H4H4

18. No forwarding loops Critical Observation: Correct network configurations do not produce forwarding loops. Therefore: We obtain loop-free Kripke structures. The observation greatly simplifies (incremental) model checking.

19. Model checking for LTL on loop-free structures One sentence summary: The idea is the same as in LTL-to-Büchi construction, but on loop-free structures it is possible to check all constraints locally (no need for the Büchi condition).

20. Model checking for LTL on loop-free structures Labeling sink nodes

21. Model checking for LTL on loop-free structures Labeling internal nodes

22. Incremental model checking LTL a a b F a b a a b F b b Update Example: We are updating the state K. The label at state K has changed. The label at its parent has not changed. We can stop propagating the update. K K

23. Algorithm High-level structure: depth-first search with counterexamples  Two restrictions i.Every node updated at most once. Simple sequence of updates. ii.Wait between every two updates. Careful sequence of updates. a)Enables checking configurations in isolation. b)Requires loop-freedom. (At each step, we check that the node we updated is not a part of a loop.)  Wait removal heuristic Two switches A and B; update sequence A followed by B. If in the initial configuration, packets processed by A cannot reach B, then no wait needed

24. Algorithm Procedure DFSforOrder(NetPol, cs) Input: current network policy NetPol; last updated switch cs Output: ok if a correct update sequence exists; the sequence L 1: if NetPol = NetPolF then return (true, [NetPol]) 2: if (NetPol models V) or (NetPol models W) return (false,[]) 3: V  (V or NetPol) 4: if (cs != bot) then 5: (ok,cex)  hasNewLoops(NetPol,cs) 6: if (not ok) { W  W or analyzeCex(cex); return (false,[]) } 7: (ok, cex)  ModelCheck(NetPol,F) 8: if (not ok) { W  W or analyzeCex(cex); return (false,[]) } 9: for all (NetPolN,cs) in NextPolicies(NetPol) do 10: (ok,L)  DFSforOrder(NetPolN,cs) 11: if ok then return (true,NetPol::wait::L) Procedure OrderUpdates(NetPolI, NetPolG, F) Input: init policy NetPolI; target policy NetPolG; LTL spec F Output: simple and careful sequence of updates, if it exists 1: if hasLoops(NetPolI) or hasLoops(NetPolG) then return “No” 2: W  false //wrong configurations 3: V  false //visited configurations 4: (ok,L)  DFSforOrder(NetPolI,bot) 5: if ok then return L else return “No”

25. Algorithm Procedure DFSforOrder(NetPol, cs) Input: current network policy NetPol; last updated switch cs Output: ok if a correct update sequence exists; the sequence L 1: if NetPol = NetPolF then return (true, [NetPol]) 2: if (NetPol models V) or (NetPol models W) return (false,[]) 3: V  (V or NetPol) 4: if (cs != bot) then 5: (ok,cex)  hasNewLoops(NetPol,cs) 6: if (not ok) { W  W or analyzeCex(cex); return (false,[]) } 7: (ok, cex)  ModelCheck(NetPol,cs,F) 8: if (not ok) { W  W or analyzeCex(cex); return (false,[]) } 9: for all (NetPolN,cs) in NextPolicies(NetPol) do 10: (ok,L)  DFSforOrder(NetPolN,cs) 11: if ok then return (true,NetPol::wait::L)

26. Related Work Consistent updates Network verification Header Space Analysis NetPlumber … Network update synthesis (via ordering updates) zUpdate Dionysos (SIGCOMM 2014, Jin, Liu, Gandhi, Kandula, Mahajan, Zhang, Rexford, Wattenhofer )  computes ordering updates based on a dependency tree  would be cool: dependency trees for a general class of properties Godfrey et al. NSDI 2015 Schmid et al. HotNets 2014

27. References  Andrew Noyes, Todd Warszawski, Pavol Cerny, Nate Foster Toward Synthesis of Network Updates, SYNT 2013  Jedidiah McClurg, Hossein Hojjat, Pavol Cerny, Nate Foster Efficient Synthesis of Network Updates, PLDI 2015

28. Summary Main ideas: I. Easier to specify than to implement  good problem for program synthesis II. Incremental model checking (for LTL) Future work:  Fast updates (eliminating wait commands)  Failure recovery, robustness  Bandwidth constraints  Heuristic: re-using model checking labeling in search

29. Program Synthesis for Network Updates Pavol Černý CU Boulder Dagstuhl, February 2015