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

Hossein HojjatJedidiah McClurg Nate Foster

Program synthesis

Network updates

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

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

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!

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

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 ?

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

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

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

LTL and Packet Path Properties

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

Order Update Synthesis: Search φ LTL property topology + configurations

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

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

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.

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

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

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

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

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

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”

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)

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

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

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

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