Optimisation and Model checking applied to multipath routing

1. Optimisation and Model checking applied to multipath routing Nigel Walker, Ben Strulo, BT laboratories; Peng Wu, UCL; Alessio Lomuscio, Imperial.

2. Outline • Optimisation theory as model of network control • Design framework • Another type of formal model • Decomposition + Graphical syntax • Leads to interaction, algorithms and protocols • Multipath routing • As an example • Model checking experience • Reflections

3. Node hierarchy Inner core Outer core Metro NGN core topology (simplified)

4. Node hierarchy Inner core Outer core Metro Multipath routing Preconfigure a number of paths between source–destination pairs over which traffic can be distributed.

5. Purported advantages • Exploit network capacity region • Diverse paths find spare capacity when it is available • Admission control can be done at the edge by selecting (not creating) a path. • Complex routing need be done only when paths are set up. • Robust to traffic matrix uncertainties • Resilience • Load can be rapidly shifted between paths • Requiring only local decisions made at the source

6. X3 X1 X5 X4 X2 Demands, paths, links (over a simpler topology!). UAB(XAB) UAC(XAC) XAC = X3 + X4 + X5 XAB = X1 + X2 xc = X2 + X5 xe = X4 + X5 xa xb A C xc xd xe xf B

7. X3 X1 X5 X4 X2 Optimisation formulation. max UAB(XAB) + UAC(XAC) XAC = X3 + X4 + X5 XAB = X1 + X2 xc = X2 + X5 xe = X4 + X5 xa xb A C xc xd xe xf B

8. X3 X1 X5 X4 X2 Optimisation formulation. max U(X) X = H X such that xc = X2 + X5 xe = X4 + X5 xa xb A C xc xd xe xf B

9. Optimisation formulation. max U(X) X = H X such that X ≥ 0 xc = X2 + X5 xe = X4 + X5 xa xb A C xc xd xe xf B

10. Optimisation formulation. max U(X) X = H X such that X ≥ 0 x = A X xa xb A C xc xd xe xf B

11. Optimisation formulation. max U(X) X = H X such that X ≥ 0 x = A X k ≥ x

12. Optimisation formulation. The (global) objective or utility function max U(X) X = H X such that X ≥ 0 The (shared) constraints x = A X k ≥ x

13. Deriving the Lagrangian function U(X) - Y ( X – H X ) + ỹ ( x - A X ) + y ( k – x ) objective constraints Introduce a Lagrange multiplier (dual variable, Y) for each constraint to give the Lagrangian Function k ≥ x U(X) X = H X x = A X Maximise Lagrangian with respect to primal variables Minimise Lagrangian with respect to dual variables A saddle point

14. Primal variables Dual variables Terms from Lagrangian Component Graph construction. UAB(XAB) UAB(XAB) + … XAB - YAB ( XAB – X1 – X2 ) + … X ≥ 0 -YABXAB YAB +YAB X1 +YAB X2 X1 X2

15. Component Graph for Multipath Routing. +U(X) Utility function X AB AC -YX Y Path selection +YHX X 2 5 4 1 3 -YX Network interface Y +YX̃ X̃ -ỹAX̃ ỹ Flow aggregation c f d a e b +ỹx x -yx y Capacity constraint +yk

16. Determine least cost over available paths Select least cost path Congestion price accumulated alongeach path. Aggregate flow from allpaths using each link Set congestion price y of each link Decomposition, message passing, feedback loop. Set admitted flow X, given least path price Y,X=argmax[ U(X) – YX ] Flow launched into networkpropagates tolinks on selected path Distributed congestion priceamongst paths using each link

17. Stability and convergence:standard recipe • Variables adjusted slowly • while propagating their values over the graph. • Modelled as differential equations. • several different versions (primal, dual, ...) • Concave-convex assumption leads to convergence proof • via Lyapunov function • Assumes negligible propagation delay These are rather limiting assumptions. Would like to investigate discrete changes to flow levels. i.e. transitions. What about model checking?

18. Hopes for model checking • Move away from differential equation dynamics to discrete transitions and state space • Sources move traffic between paths in discrete chunks • Links are either congested or not. Sudden link failures • Tool to answer more detailed questions about dynamics • Does it stabilise? How long does it take to reconfigure? • What is the maximum amount of traffic that we might loose following a failure • How does link delay affect reconfiguration time or stability? • Expose unanticipated behaviour • Design framework • complementing optimisation

19. Fears for model checking • State explosion • State explosion • State explosion • But can any tricks within the repertoire of model checking or, possibly, tricks inspired by optimisation mitigate against this? • Becoming familiar with the logical formalism (CTL etc.) • But that’s not really a fundamental problem! It was actually an attraction.

20. Our experiments and experiences summarised • Built several different models • variations on agent behaviour and connectivity • Tried several different environments: • NuSMV, SPIN, UPPAAL and Verics • Discrete versions of the source flow and link price variables, and of the dynamics. • with an attempt, not wholly convincing, to maintain some formal similarity between the transition rules and well-known differential equations for this problem • State explosion was indeed a problem right from the start. • This restricted us to a very simple network topology. • Struggled over interpretation of interleaving semantics.

21. Simple topology B A D C E F Three flows, each has choice of two paths. Three link, each used by two paths. Each path uses on one link. Links have capacity constraints.

22. Component Graph for Multipath Routing. AB CD EF 1 3 5 2 4 6 flows prices, congestion, capacity signalling of flows and prices is subject to propagation delay a b c

23. Component Graph for Multipath Routing. 1 2 a c Those pesky dining philosophers again???

24. Interpretation of non-determinismTwo aspects:- • Degeneracy in the solution for each agents individual actions (easy) • e.g. choice between two paths if both have equal cost • Interleaving semantics (harder) • we could understand different choice in the abstract model • sources synchronous, sources asynchronous, etc... • but struggled to relate these to temporal behaviour of the underlying ‘real’ system. • the dynamics of the model are very weakly specified. • this should be useful for modelling uncertainty or obliviousness to propagation delay (all possibilities are represented)

25. What is the model actually modelling?Example interleaving assumption. • Each source agent acts asynchronously. • Changes are propagated through resources (links) before any other source agent acts. • How is this ‘faithful’ to the underlying ‘real’ system? • if sources act infrequently compared to the propagation delay across the networks • no hidden ‘on the fly’ state. The state space is well captured as the product space of all the agents. • But this limitation is not so completely different from the limitation of modelling the dynamics using differential equations! • infrequent updates c.f. slow updates.

26. How to get a better grip on time evolutionModelling on-the-fly state? • As a ‘shift register’ between agents • rather like modelling explicit buffers • Or by timing the arrival of a signal • UPPAAL and timed model checking. • This explodes the state space • but can the explosion be offset by greater determinism? • probably depends partly on how the model checkers work. • We were not greatly successful in this direction. Unfinished business here!

27. Stepping back • The types of systems we are investigating are feedback systems (with complex topology). • In such systems we are typically interested in asking questions about stability, convergence time, robustness, etc. • Doing any of the following might destabilise the system • increase step size • increase action frequency • increase propagation delay (round trip time) • So these quantities are linked • and this should be reflected somehow in the model building.

28. Stepping even further back • Optimisation v.s. logic • can specify a global objective as a Lagrangian function depending on lots of system variables. • could also specify a global objective as a logical formula depending on lots of system variables. • But optimisation has a notion of convexity • property that is independent of system size • guarantees convergence, independent of topology • forms the boundary of complexity. Non-convex problems are combinatorially difficult. e.g constraint satisfaction problems. • What equivalent to convexity is there in logic? • currently exploring A/G framework, linking in with component graphs

29. Conclusions • Don’t forget optimisation (+ game theory + control ...) as formal framework. • Component graph representation opens up window onto many other interesting subjects • Still believe model checking should be able to illuminate issues not visible through optimisation, but • formalism has some issues • state space explosion, temporal details. • practitioner has some issues • interpretation in this setting

30. Questions

31. Optimisation decomposition • Optimisation has a long pedigree of applications to networking (planning, routing, traffic engineering, flow control). • Global view of network objective. (c.f. game theory) • A global problem can be solved by breaking it down into interacting sub-problems. • Many algorithms (and protocols in a distributed setting) can be derived this way • e.g. Shortest path formulated as minimum cost flow gives Bellman Ford algorithm. • This provides an elegant framework for reasoning about (some simple types) of distributed processes.

32. Logical + discrete models • But optimisation methods seem quite different in style to models of interacting systems frequently favoured by computer science (process calculus, model checking, petri-nets) where logic plays a more prominent role in specification. • Our investigation sought to place model checking alongside optimisation in analysing a multipath routing problem of interest to BT (and others).

33. Component Graph • Graphical syntax for Lagrangian function • Formally similar to • Factor Graphs • Constraint graphs • but we have primal and dual variables • Tool for visualisation of • structure of Lagrangian • sparseness of components • decomposition • Algorithm (distributed) is modelled as message passing over this graph. Strongly related to • message passing algorithms in coding • marginalisation and belief propagation • constraint propagation in constraint satisfaction algorithms

34. Stepping back – 2tentative position statement • The standard model checking recipe is quite precise about agent steps, but utterly vague (deliberately so) about their corresponding time steps. • All possible time evolutions are projected onto one transition system. • This projection is forgetful of the important structural properties underlying the behaviour or constraints we are interested in • How to identify interesting traces and recover interesting stability constraints etc. • I seem to be arguing for timed model checking, but is this enough?