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
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
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
Introduction/Overview RTNO • Real-time optimisation problems in networking • routing • queuing • pattern-matching (eg, security) • filtering • Very restricted performance constraints • Multi-platform issues
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!
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 …
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
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? ?
A Typical ACL
A Typical ACL Rules applied in order ‘implicit deny’ at end
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 …
Dependent Rules in ACLs
Dependent Rules in ACLs Passed by Blocked by From: 192.168.16.1 To: 10.0.0.1
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, fkF*: 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.
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 (SakSAi) (DakDAi) (bk Bi) i (fk), in which case the packet will be permitted or denied according to ti.
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) (SakSAiSAj) (DakDAiDAj) (bk Bi Bj) i(fk) j(fk). Eliminating the packet, pk, from this expression, allows a {0, 1}dependency matrix, D = (dij: 1i,jn), to be defined: dij (ti ≠ tj) (SAiSAj) (DAiDAj) (Bi Bj) (ij).
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) (SAiSAj) (DAiDAj) (Bi Bj) (ij). 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) (SAiSAj) (DAiDAj) (Bi Bj) (ij) v (i < v < j), dvj = 0.
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:
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
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)
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
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
(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
(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
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
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
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
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)
Calculating Sd(R) • Look-up tables in ROS or logic circuitry in hardware • c: (router) clock cycles available : : : :
Typical Results
Typical Results
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!
Where to place ACLs?
Where to place ACLs?
Where to place ACLs? Optimal? No – considerable duplication
Where to place ACLs? True optimum can only come from taking a ‘global’ view
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
