Real-Time Network Optimisation

1. Real-TimeNetwork Optimisation Vic Grout Centre for Applied Internet Research (CAIR) University of Wales NEWI Plas Coch Campus, Mold Road Wrexham, LL11 2AW, UK v.grout@newi.ac.uk http://www.newi.ac.uk/Computing/Research NEWINorth East Wales Institute of Higher Education - Centre for Applied Internet Research

2. Introduction/Overview • Real-time optimisation problems in networking • routing • queuing • pattern-matching (eg, security) • filtering • Very restricted performance constraints • Multi-platform issues Frame Relay LAN ATM LAN LAN

3. Introduction/Overview • Real-time optimisation problems in networking • routing • queuing • pattern-matching (eg, security) • filtering • Very restricted performance constraints • Multi-platform issues Traffic (packets) in Traffic (packets) out Router Interfaces … various processing (optimisation) problems within router      

4. Introduction/Overview RTNO • Real-time optimisation problems in networking • routing • queuing • pattern-matching (eg, security) • filtering • Very restricted performance constraints • Multi-platform issues      

5. Requirements of RTNO Software • Low space-complexity • coded into router operating system (ROS) • (or) embedded in hardware • Minimal time-complexity • need to be re-run frequently • must not add to inherent latency of processing traffic • Cross-platform interoperability • simple implementation • configurable to time/space resources/need • (in development) to allow comparison • Cheap ‘n’ cheerful!

6. RTNO Software Design Principles • Fast approximations/heuristics • modification of existing algorithms • development of new techniques • Configurable by parameters – trade-off: • (time/space) complexity • accuracy • For example, search processes truncated in: • time • scope • resolution • degree/depth • Illustrated by example …

7. Example: Packet Filters (ACLs) • Filters applied on routers to implement policies • security • traffic shaping/queuing • Access Control Lists (ACLs) • lists of (permit/deny) rules • (each) packet compared with rules in order • permit/deny packet according to first match 

8. Example: Packet Filters (ACLs) • Filters applied on routers to implement policies • security • traffic shaping/queuing • Access Control Lists (ACLs) • lists of (permit/deny) rules • (each) packet compared with rules in order • permit/deny packet according to first match Pass or block this packet?  ?

9. A Typical ACL

10. A Typical ACL Rules applied in order ‘implicit deny’ at end 

11. ACL Optimisation • The time taken to process a packet against an ACL will depend upon which rule matches the packet • hit rate • the probability that a packet will match a given rule • latency • the time taken to process a rule • cumulative latency • the time taken to process rules up to a given rule • expected latency • of the list as a whole • The objective is to minimise the time taken to process each packet. To do this, we want rules with high hit-rates towards the top of the list but those with high latencies towards the bottom. Clearly, these objectives may conflict/compete. And there is another problem …

12. Dependent Rules in ACLs

13. Dependent Rules in ACLs Passed by Blocked by From: 192.168.16.1 To: 10.0.0.1 

14. Formulisation of ACL RTNO Problem: Packets and Flows Define A* to be the set of all addresses available within a given system, define B* to be the set of all protocols recognised by the system and define F* = {0, 1}m to be the set of mflag vectors ({0, 1} m-tuples acting on B* ) valid for the system. For completeness, X* represents the set of payloads. A packet, pk = (Sak, Dak, bk, fk, Xk), is defined by its constituents: Sak A*: the source address, Dak A*: the destination address, bk B*: the protocol, fkF*: the flags vector, and Xk X*: the payload. A traffic flow, T = [p1, p2, ..., pq], is a sequence of q packets. For sufficiently large q, this may be regarded as a distribution of packets and we simply refer to the traffic, T.

15. Formulisation of ACL RTNO Problem: Rules and Policies A rule, ri = (ti, SAi, DAi, Bi, i), consists of: a type, ti (permit, deny}, SAi A*: the source range, DAi A*: the destination range, Bi B*: the protocol range, and a flags predicate, i: F*  {true, false}. Only ti is a required component. If any other components are absent then SAi = A*, DAi = A*, Bi = B* or i true by default. A policy, Z = [r1, r2, ..., rn] is an (ordered) sequence of n rules to achieve some purpose. The last rule denies all traffic, ie, tn = deny, SAn = A*, DAn = A*, Bn = B* and n true. A packet, pk, matches a rule, ri (for which we write pk ri), if its addresses and protocols are within the range of the rule and if its flags vector satisfies the rule’s flags predicate. That is, pk ri (SakSAi)  (DakDAi)  (bk Bi) i (fk), in which case the packet will be permitted or denied according to ti.

16. Formulisation of ACL RTNO Problem: Dependencies A dependency exists between two rules, riand rj, if they are of opposite type and it is possible that there exists a packet, pk, that matches both rules ((pk ri)  (pk rj)), that is ri and rjare dependent if  pksuch that (ti ≠ tj)  (SakSAiSAj)  (DakDAiDAj)  (bk Bi Bj) i(fk) j(fk). Eliminating the packet, pk, from this expression, allows a {0, 1}dependency matrix, D = (dij: 1i,jn), to be defined: dij (ti ≠ tj)  (SAiSAj)  (DAiDAj)  (Bi Bj)  (ij).

17. Formulisation of ACL RTNO Problem: Redundancies A rule, rj, in a policy, Z, is redundant (written ri rj) if there exists a rule, ri (i < j), in Z, such that all packets matching rj will be matched by ri. ri rj(ti = tj) (SAiSAj)  (DAiDAj)  (Bi Bj)  (ij). A redundant rule may be removed from the policy without changing its purpose. A rule, ri, in a policy, Z, is potentially redundant if there exists a rule, rj (i < j), in Z, such that all packets matching ri will be matched by rj. A redundant rule may be removed from the policy without changing its purpose provided that no other rules between ri and rj are dependent upon rj, that is, ri rj(ti = tj) (SAiSAj)  (DAiDAj)  (Bi Bj)  (ij) v (i < v < j), dvj = 0.

18. Formulisation of ACL RTNO Problem: Lists An access list, or simply list, L, implements a policy, Z = [r1, r2, ..., rn], if it is a permutation of the rules of Z such that the order of dependencies is preserved. Let ri(L) be the rule at position i in L. A special case of a list implementing a policy, Z, is the identity list, IZ = [r1, r2, ..., rn], for which ri(IZ) = ri i (1 i n). Let m be the number of dependencies:

19. Formulisation of ACL RTNO Problem: Latencies and Hit Rates The latency, ( ri), of a rule ri is the time taken to (independently) process ri. The cumulative latency, ( ri(L)), ofri in a list L, is the time taken to process ri and all rules preceding it in L. The hit-rate, h(ri(L),T), of rule riin a list L, is the probability that a packet from a traffic flow T will match ri in L. The expected latency, E(L,T), of a list L, in traffic T, is then given by

20. Formulisation of ACL RTNO Problem: Objective and Complexity • For a given policy Z applied to traffic T, Find the list Lmin, • implementing Z, such that E(Lmin , T) = min L E(L , T) • subject to the dependency constraints ri(L) < rj(L)  dij = 1  1  i < j  n • Solution space (n-1)! (unconstrained). NP-complete, by polynomial translation to • [SS4] Sequencing to Minimize Weighted Completion Time • [SS7] Sequencing to Minimize Maximum Cumulative Cost (Garey and Johnson, 1979)

21. Truncated Local-Search Optimisation • Truncated in time • conceptually simple but requires timers • lack of control (for comparison) • no (cross-platform) flexibility • Truncated Scope/Resolution/Degree(Depth) time degree/depth search/solution sequence scope Search space Solution space resolution

22. k-Opt Search • Swap/permute k rules in ACL • mark savings/maximise improvement • Particularly suited to RTNO • Simple (minimal) ROS code • Effective hardware implementation (‘wires’) • Fixed k-opt • 2-opt, 3-opt, 4-opt (?), etc. • Variable k-opt • eg, Lin-Kernighan • Combine using variable parameters • scope (k), resolution, degree

23. (Example) 3-Opt Resolution i i+1, j j+1, k k+1 3(i,1,1)-OPT i i+1, j j+1 k k+1 3(i,1,3)-OPT i i+1 j j+1 k k+1 3(i,2,2)-OPT

24. (Example) 3-Opt Resolution i i+1, j j+1, k k+1 X X X 3(i,1,1)-OPT i i+1, j j+1 k k+1 X X X 3(i,1,3)-OPT i i+1 j j+1 k k+1 X X X 3(i,2,2)-OPT

25. Scope and Resolution R = 0 R = 1 R = 2 R = 3 R = 4 … S = 2 2(i,j) 2(i,j) 2(i,j) S = 3 3(i,j,k) 3(i,j,k) 3(i,j,k) 3(i,j,k) S = 4 4(i,j,k,l) 4(i,j,k,l) 4(i,j,k,l) 4(i,j,k,l) 4(i,j,k,l) : : : : : : i: best path recorded through search i: all paths recorded through search

26. Scope and Resolution R = 0 R = 1 R = 2 R = 3 R = 4 … S = 2 2(0) 2(1) 2(2) S = 3 3(0) 3(1) 3(2) 3(3) S = 4 4(0) 4(1) 4(2) 4(3) 4(4) : : : : : : S: Scope R: Resolution

27. Search Degree S(R) S(R) S(R) S(R) S(R)S(R) S(R) S(R) S(R) … S(R) S(R) S(R) S(R) S(R)S(R) … … S(R) S(R) S(R) … S(R) S(R)S(R) d d d: depth (degree) of search Projected solution

28. Sd(R) Search • Use standard tree-search algorithm with parameters: n  S  R  1 d  1 • Select S, R & d to suit platform • can be calculated in real-time (dynamically) • For example (extreme), to ensure optimality, n1(1), n-12(2), etc. (all exponential) Scope DegreeResolution Sd(R)

29. Calculating Sd(R) • Look-up tables in ROS or logic circuitry in hardware • c: (router) clock cycles available : : : :

30. Typical Results

31. Typical Results

32. Other ‘Issues’ and Conclusions • How to detect dependencies? • How to calculate hit rates? • How to detect equivalence? • When to optimise? • Where to place ACLs? • RTNO is worthwhile • ‘Keeping it simple’ is a complicated business! • ‘Cheap ‘n’ cheerful works well!

33. Where to place ACLs?

34. Where to place ACLs?

35. Where to place ACLs? Optimal? No – considerable duplication

36. Where to place ACLs? True optimum can only come from taking a ‘global’ view

37. Any questions? Thank you Vic Grout Centre for Applied Internet Research (CAIR) University of Wales NEWI Plas Coch Campus, Mold Road Wrexham, LL11 2AW, UK v.grout@newi.ac.uk http://www.newi.ac.uk/Computing/Research NEWINorth East Wales Institute of Higher Education - Centre for Applied Internet Research