Program Synthesisfor 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

H1

H2

H3

H4

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-C1works

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 UpdatesInput:

• 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

• ReachabilityEvery path that starts in reaches

“”

• Waypointing“a packet does not exit the network without passing through w”

“” “”

• Service chaining“all packets go first through and then through

before exiting the network ”

“”

LTL and Packet Path Properties

𝑠𝑖 𝑑𝑖

𝑔𝑤

𝑔𝑤2𝑤1

Outline (synthesis for network updates)

1. Synthesis for network updates

2. Main ideas• Counterexample-driven search• Incremental model checking

Order Update Synthesis: Search

φLTL

propertytopology +

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

H1

H2

H3

H4

No forwarding loopsCritical 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 LTLon loop-free structuresOne 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).

Labeling by maximally consistent sets of subformulas (and their negations)

Formula

Maximally consistent set (example)

A node is labeled by a set iff there exists a path starting at such that for all formulas , we have that .

Model checking for LTLon loop-free structures

Labeling sink nodes

Observation: there is only one path starting at a sink node.

A sink node is labeled by iff

holds at iff … iff iff

Important for the overall algorithm: Eventualities (given by Until) realized at sink nodes “at the latest”

Therefore, all checks are local.

Model checking for LTLon loop-free structures

Labeling internal nodes

An internal node is labeled by iff … iff there is a child of labeled by and … iff either or there is a child of labeled by and and

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.

KK

AlgorithmHigh-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 heuristicTwo 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 csOutput: 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) do10: (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 FOutput: 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”

AlgorithmProcedure DFSforOrder(NetPol, cs)Input: current network policy NetPol; last updated switch csOutput: 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) do10: (ok,L) DFSforOrder(NetPolN,cs)11: if ok then return (true,NetPol::wait::L)

Related WorkConsistent 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

SummaryMain 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 Synthesisfor Network Updates

Pavol ČernýCU Boulder

Dagstuhl, February 2015