optimising internet access control lists vic grout, and stuart cunningham centre for applied...

Optimising InternetAccess Control Lists

Vic Grout, and Stuart Cunningham

Centre for Applied Internet Research (CAIR)University of WalesNEWI Plas Coch Campus, Mold RoadWrexham, LL11 2AW, UKwww.cair-uk.org

[email protected]@cair-uk.org

NEWI North East Wales Institute of Higher Education - Centre for Applied Internet Research

Department of Computer Science and Engineering, University of Nevada, Reno15th November 2006

Access Control Lists (ACLs)

“Packet filters”



Interfaces: in and out (permit/deny)



Interfaces: in and out (permit/deny) Also selecting packets for traffic policies



Interfaces: in and out (permit/deny) Also selecting packets for traffic policies Across an internet



Interfaces: in and out (permit/deny) Also selecting packets for traffic policies Across an internet Can add considerable packet latency


ACL Uses and Applications

Blocking and passing traffic security/privacy/protection commercial restrictions/preferences

Selecting packets for traffic policies Network Address Translation (NAT) traffic shaping bandwidth allocation/provisioning/reservation routing/switching VPNs/tunnelling logging etc.

Packet Lookups

There are different forms of (subtly different) packet lookup scenarios Packet classification

• e.g., routing tables• find the longest prefix matching a packet

Packet matching• e.g., ACLs• find the first rule matching a packet

Some, but not all, approaches work, sometimes partially, for both

This talk concentrates on packet matching in ACLs

Anatomy of an ACL access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any


Sequence of ‘permit’and ‘deny’ rules



Each rules tries to matchsome feature of the packet

being processed




being processed

Rules processedsequentially …




being processed


… until a rule matchesthe packet (stop) …




being processed


… until a rule matchesthe packet (stop) …

… or the last ruleis reached

ACL Optimisation How can the matching of packets against an ACL be

optimised? It depends on ACL implementation

Where are ACLs stored? Where does optimisation take place

Are ACLs implemented in hardware? software? a combination?

Are ACLs searched linearly? in parallel (TCAMs) or using trees/tries? using cache?

Hardware Implementations

Using TCAMs Ternary Content Addressable Memory

A TCAM takes a rule and outputs the lowest indexed rule that matches the

packet i.e. the first rule in the ACL stored in the TCAM

TCAM

Packet

RuleACL

CAMs and TCAMs

CAM (Content Addressable Memory) A kind of ‘RAM in reverse’ Accepts data and returns the address (say) Binary match on 1s and 0s Used in switch MAC address tables for example

TCAM (Ternary CAM) Allows 1, 0 or ? ? – wildcard to match either 1 or 0 Used (in slightly different ways) for

• routing tables• ACLs

TCAM Example

Packet: ip 10.0.0.3 192.168.0.211100 0000101000000000000000000000001111000000101010000000000000010101

deny ip 10.0.0.0 0.0.0.255 any

1 1010 1101010101010101010110011000101 01110111???????????????????????0 0001 1101111100 :1 1100 00001010???????????????????????? ???????????????????????????????? :1 1010 10110111111001110101010101010101 0101?????????1111010110?????????0 ???? 1111???????????????????????????? 0000011101010110101?????????????1 ???? ???????????????????????????????? ????????????????????????????????

1 1100 00001010???????????????????????? ????????????????????????????????

Rule

ACL

TCAM

CAM/TCAM Implementation

Hardware version of an associative array Semiconductor

complex circuitry• expensive• power dissipation/cooling

Emulated trees/hashing/pipelining slower

Not just a question of searching TCAMs How are they maintained?

• eg, how is a new rule inserted?

Only really viable for top-end routers

Optimisation in Software

(Implementation can still be in hardware) Control in software

Binary Search Trees (BSTs) Tries

• ‘prefix trees’ Reordering (optimising) linear list

All have advantages/disadvantages. Generally: the faster to search, the harder to maintain

• processing overhead how about responding to changing traffic patterns?

• ‘stable’/’unstable’ traffic

‘Algorithmics’

Tries

Re’trie’val An improvement over BSTs

0 1

0 10 1

10

0 0 0 1 1

1 1 1 1

0 1 0 1 1

0 1 1 1 0 1

0000

11111

0000100 0000101 … … … 1101111

rules stored as keys on branches, not nodes

Tries vs. Trees

Advantages of tries Faster (O(rulelength) vs. O(log numberofrules)) Fast array indexing Smaller for large numbers of short rules Balancing not necessary

Disadvantages of tries Can only order on given structure Larger for small numbers of large rules More complex to maintain

Cisco Turbo ACLs (2003/2004)

Reordering (Optimising) a Linear List

What if hardware implementation or tries are impractical? eg, lower range routers

Can we optimise directly on the ACL? eg, change the rule order in the (linear) list

Possible objections algorithms too complex to be implemented? algorithms take longer to run than savings gained? linear optimisation only worthwhile for large lists?

• which we don’t get on small routers some rules can’t be reordered …

Rule Order access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any

It takes time to processeach packet againstthe rules in a list …

Rule Order access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any


… and there may be a better list,with the rules in a different order,

that can be processed faster

Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any


However, some rules aredependent and cannot

be reordered

… and there may be a better list,with the rules in a different order,

that can be processed faster


However, some rules aredependent and cannot

be reordered

The same packet couldmatch both these rules


This order woulddeny the packet …

Rule Dependencies access-list 173 permit icmp any any access-list 173 permit tcp any any established access-list 173 deny ip RANGE MASK any access-list 173 deny ip 10.77.23.0 0.255.255.255 any access-list 173 deny ip 172.16.2.0 0.15.255.255 any access-list 173 deny ip 192.168.1.0 0.0.255.255 any access-list 173 deny ip 169.254.1.0 0.0.255.255 any access-list 173 permit tcp any host MAILSERVER eq smtp access-list 173 deny ip 192.168.2.0 0.0.0.255 any access-list 173 permit tcp any host NAMESERVER eq domain access-list 173 permit udp any host NAMESERVER eq domain access-list 173 permit udp any eq 53 host NAMESERVER gt 1024 access-list 173 permit tcp host MANAGER host SUN eq telnet access-list 173 permit tcp host MANAGER host SERIAL0 eq telnet access-list 173 permit tcp host MANAGER host ETHERNET0 eq telnet access-list 173 permit udp host MANAGER host SERIAL0 eq snmp access-list 173 permit tcp any host FTPSERVER eq ftp access-list 173 permit tcp any eq ftp-data host FTPSERVER access-list 173 permit tcp any eq ftp-data any gt 1024 access-list 173 permit tcp any host WWWSERVER eq www access-list 173 permit tcp any host SWWWSERVER eq 443 access-list 173 permit udp EXT-NTPSERVER any eq 123 access-list 173 permit udp any range 6970 7170 any access-list 173 deny ip any any

… but this orderwould permit it

Linear ACL Latency

(Simplified notation) n rules in list L Hit-rate hi(L)

• probability that packets match rule i in list L Latency i(L)

• time taken to process rule i in list L Cumulative latency i(L)

• time taken to process list up to and including i in list L

Expected latency E(L)• average time to process List L

i

jii LL

1

)()(

)()()(1

LLhLEn

iii

Linear ACL Optimisation Problem

Expected latency E(L) average time to process List L

Dependency Matrix D = (dij)

Problem: Minimise E(L) subject to D NP-complete (Grout et al., JoH, 2005)

)()()(1

LLhLEn

iii

:0

:1ijd

Rules i and j are dependent

otherwise

ACL Optimisation - Background

2000: Hari et al. analysis to resolve rule conflicts

2001: Stocia model for packet classification

2002: Cisco ACL optimizer and hits optimizer

2003/2004: Bukhatwa & Patel various optimisation techniques for simplified problems

2003/2004: Cisco ACL Manager

2004: Al-Shaer & Hamed complete model for avoiding conflict

ACL Optimisation - Background

2000: Hari et al. analysis to resolve rule conflicts

2001: Stocia model for packet classification

2002: Cisco ACL optimizer and hits optimizer

2003/2004: Bukhatwa & Patel various optimisation techniques for simplified problems

2003/2004: Cisco ACL Manager

2004: Al-Shaer & Hamed complete model for avoiding conflict

OFF-LINE

ON-LINE

Online ACL Optimisation

2005: IEEE/IFIP IM (& Jnl. Heuristics): Grout et al. complete model of optimisation problem shown to be NP-complete simple (inefficient) heuristics

2005: INC: Grout et al. improved (efficient) heuristics analysis incomplete

2006: Computer Communications: Grout et al. complete analysis different ACL and traffic types

2006: WWW/Internet: Grout et al. fine-tuning of parameters

Exact ACL Optimisation

Exhaustive Search Dynamic Programming Linear Programming Branch and Bound

All ideally suited to static optimisation may struggle to deal with changing traffic

characteristics

Exhaustive Search

Generate each permutation of the rules in turn Check whether dependencies (D) satisfied Evaluate E(L) Record successive minima

Computationally infeasible Time complexity, O(n!) Space complexity, O(n)

Dynamic Programming

‘Sequence to Minimise Expected Latency’ (SMEL) Variation of Held & Karp (1962) TSP algorithm

Initial ACL: Z = {r1, r2, …, rn} (with rn fixed)

For Y = {r1, r2, …, rn-1} and r Y, let |SMEL|(Y, r) be the minimum

expected latency of the sublist Y {rn}

Then

SMEL can then be calculated as min r |SMEL|(Z, r) + (r(Z))

Only useful as a benchmark for (very small) problem instances Time complexity, O(2n) Space complexity, O(2n)

LP and B & B

3: Linear Programming (LP) Formulation of SMEL as LP non-trivial but possible not appropriate for embedded implementation some value in small-scale testing

4: Branch and Bound (B&B) eg, Applegate & Cook (2003/2004) TSP often involve human intervention not appropriate for embedded implementation some value in comparison for small numbers of larger

problem instance

Approximations and Heuristics

k-opt simple rule swaps

Lin and Kernighan (1973) nested rule swaps

Constrained Sort (Grout et al., 2005) a form of ‘immediate promotion’

-opt (Grout et al., 2006) local swap operation

May manage dynamic optimisation better more responsive to changing traffic characteristics

2-opt

L := IZ;

repeat

max := 0;

for i := 1 to n-2 do

for j := i+1 to n-1 do

if dij = 0 then

begin

:= E(L,T) – E(L<ij>,T); if > max then

begin

max := ; i* := i;

j* := j

end

end;

if max > 0 then

swap(ri*(L), rj*(L))

until

max = 0

3-opt

L := IZ;

repeat

max := 0;

for i := 1 to n-3 do

for j := i+1 to n-2 do

for k := j+1 to n-1 do

if (dij = 0) and (djk = 0) and (dik = 0) then

begin

:= E(L,T) – E(L<ijk>,T); if > max then

begin

max := ; i* := i;

j* := j;

k* := k

end

end;

if max > 0 then

permute(ri*(L), rj*(L), rk*(L))

until

max = 0

LK-opt

Various forms, eg …

L := IZ;

repeat

repeat

single_smel_2-opt

until

max = 0;

single_smel_3-opt

until

max = 0

Constrained Sort (C-Sort)

L := IZ;

repeat

:= 0; for i := 1 to n-2 do

if di i+1 = 0 then

if E(L,T) – E(L<i i+1>,T) > 0 then

begin

:= 1; swap(ri(L), ri+1(L))

end

until

= 0

Comparing Heuristics

2-opt Fairly fast and reasonably accurate

3-opt Slower but more accurate

LK-opt Slowest but most accurate

C-Sort Fastest but not particularly accurate

All must be reapplied at intervals as traffic characteristics change … which leads us to some further analysis of the

problem – and, in particular, hit-rates

A Deeper Analysis

None of 2-opt, 3-opt, LK-opt or C-sort are fast enough to justify their use in real time unless only applied infrequently which negates their effectiveness The main problem is having to recalculate the expected

latency for each permutation

Where do hit-rates come from? They are counted as packets arrive They must all start equal

• when the list is configured/reconfigured• zero?• or normalised probabilities?

A Deeper Analysis

In fact, in comparing rule order for a list L, the significance of rule hit-rates is only relative. It is not necessary for them to be normalised (i.e. summing to 1) probabilities. This implies that the hit-rate of a newly hit rule, i, can increase without changing the hit-rates of the other rules.

Following an increase in a rule i’s hit-rate, the only possible change in rule order (to reduce E(L)) is to promote i up the list. The most likely candidate with which to exchange it is rule i-1, immediately above it.

A Deeper Analysis

The potential saving in expected latency in swapping rules i-1 and i is given by

a simple, local calculation.

Considering rule promotions continuously in this manner is entirely responsive to dynamically changing traffic patterns. This suggests the following …

iiii

iiiiiiiiii

n

ikkkiiii

i

kkk

n

ikkkiiii

i

kkk

hh

hhhh

hhhhhhhh

11

11111

111

2

1111

2

1

)()(

Simple ACL Optimisation (-opt)

Three-part heuristic:

Step 1: Initialisation (following manual ACL configuration)

for i := 1 to n do

hi := 1 \ hit rates equal at start

Step 2: Promotion (on a packet matching rule i)

hi := 2hi \ exponentially increase matched hit-rate

if di-1 i=0 and hiλi-1 > hi-1λi then

Swap(i-1, i) \ promote if E(L) reduced

Step 3: Reduction (periodically to prevent overflow)

for i := 1 to n do

hi := hi / max j hj

Calculating Effectiveness

Cost of optimisation against value Value

: percentage decrease in expected latency• simulation/testing

Cost

B: size (bits) of registers

100

4 n

B

n212

ACL Optimisation Effectiveness

ACL characteristics: DI (dependency index) probability of two rules being dependent

Traffic self-similarity: S (self-similarity index) Probability that a packet matches the same rule as the

previous packet Minimum number of rules (n*) for -opt to work:

DI = 0.00 0.25 0.50 0.75 1.00

S = 0.00 19 21 23 33

0.25 16 19 21 29

0.50 13 15 19 26

0.75 9 10 13 21

1.00 8 9 12 17

Refining the Dependency Index

In reality, DI can never be as large as 1 Dependencies can only exist between opposite types

permit/deny x permits, y denys n = x + y

P: Permit D: Deny X – No dependencies ? – Possible dependencies

RULE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 & TYPE P P D D D D D D P P P P P P P P P P P P P P P D

1 P 2 P 3 D 4 D 5 D 6 D 7 D 8 D 9 P

10 P 11 P 12 P 13 P 14 P 15 P 16 P 17 P 18 P 19 P 20 P 21 P 22 P 23 P 24 D

Figure 2. Rule Dependencies.

X – No ? - Possibledependencies dependencies

? – Possibledependencies

X – No ?dependencies

X

X ?

?

X

?

X – No dependencies ?

X ? – Possible dependencies

X

Refining the Dependency Index So number of dependencies bounded by n2 – x2 – y2

and DI bounded by

So 0 ≤ DI ≤ 0.5

However, in -opt, swaps are not considered between non-contiguous blocks

2

222

n

yxn

0

0.1

0.2

0.3

0.4

0.5

0.6

1 3 5 7 9 11 13 15 17 19 21 23 25

Upper bound for DI

x: Number of Permits

x + y = n n = 24

n2 – x2 – y2

n2

Re-refining the Dependency Index Suppose L has bx blocks of permits Xj and by blocks of

denys Yk

Number of invalid swaps is then … and the fragmented dependency index, FDI, bounded by

So 0 ≤ FDI < 1

yx

b

kk

b

jj YXyxn

11

yx

b

kk

b

jj YXn

1

2

1

22

yxb

kk

b

jj YXn

n 1

2

1

222

1

0

0.2

0.4

0.6

0.8

1

1.2

1 3 5 7 9 11 13 15 17 19 21 231 2 3 4 6 8 12 24

Upper bound for FDI

yxb

kk

b

jj YXn

n 1

2

1

222

||||1

bx + by

|Xj| = |Yk| = n / (bx + by) 1 j bx and 1 k by

ACL Case Studies

ACL n x y bx by Xj Yk DI * FDI*

A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74

B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81

C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65

D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87

E 19 7 12 1 2 7 6, 6 0.47 0.66

F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73

G 111 29 82 1 2 29, 80, 2 0.39 0.41

H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60

I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70

J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83

K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76

* upper bound

ACL Case Studies


A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74

B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81

C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65

D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87

E 19 7 12 1 2 7 6, 6 0.47 0.66

F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73

G 111 29 82 1 2 29, 80, 2 0.39 0.41

H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60

I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70

J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83

K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76

* upper boundA,E: SOHO environments B,C,D: College/UniversityF,G,H: Company networks I,J,K: Standard templates

ACL Case Studies


A 16 10 6 2 3 6, 4 2, 3, 1 0.47 0.74

B 53 20 33 4 4 10, 7, 2, 1 14, 12, 5, 2 0.47 0.81

C 55 10 45 2 3 5, 5 27, 17, 1 0.30 0.65

D 144 27 117 6 7 4, 7, 6, 6, 3, 1 18, 32, 12, 6, 25, 21, 3 0.30 0.87

E 19 7 12 1 2 7 6, 6 0.47 0.66

F 93 22 71 3 4 13, 8, 1 41, 17, 12, 1 0.36 0.73

G 111 29 82 1 2 29, 80, 2 0.39 0.41

H 62 4 58 2 3 2, 2 22, 32, 4 0.12 0.60

I 172 54 118 2 3 31, 23 77,40,1 0.43 0.70

J 68 19 49 4 5 1, 1, 15, 2 16, 8, 12, 10, 3 0.40 0.83

K 63 22 41 2 3 18, 14 18, 13, 10 0.45 0.76

* upper bound

Comparing Dependency Bounds

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

A B C D E F G H I J K

Upper bound for FDI

Upper bound for DI

Comparing Dependency Bounds

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

A B C D E F G H I J K

Upper bound for FDI

Upper bound for DI

FDI is generally amore pessimistic(i.e. allowing fewerswaps) bound thanDI. They can beclose in exceptionalcases.

Effectiveness of Simple Optimisation

ACL S = 0.00 0.25 0.50 0.75 1.00

A DI* / FDI* 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0

B 1 / 0 1 / 0 1 / 1 1 / 1 1 / 1

C 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

D 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

E 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1

F 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0

G 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

H 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

I 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

J 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1

K 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

0: -opt notworthwhile

1: -optworthwhile

Effectiveness of Simple Optimisation

ACL S = 0.00 0.25 0.50 0.75 1.00

A DI* / FDI* 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0

B 1 / 0 1 / 0 1 / 1 1 / 1 1 / 1

C 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

D 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

E 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1

F 0 / 0 0 / 0 0 / 0 0 / 0 0 / 0

G 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

H 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

I 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

J 1 / 0 1 / 1 1 / 1 1 / 1 1 / 1

K 1 / 1 1 / 1 1 / 1 1 / 1 1 / 1

0: -opt notworthwhile

1: -optworthwhile

Instances inwhich DI orFDI makes adifference.

Conclusions

ACL Optimisation in hardware is very fast but also very expensive TCAMS

• only on top-end models Tries

• not quite as expensive• but not as fast• a compromise

Conclusions

ACL optimisation in software may have some potential in restricted environments conventional static methods

• too complex• not reactive to changing traffic

simpler process may be the solution• very fast• reacts to changing traffic• is worthwhile to implement

• savings in latency outweigh time to implement

Thank you …

… Any Questions?

NEWI North East Wales Institute of Higher Education - Centre for Applied Internet Research

Vic Grout, and Stuart Cunningham

Centre for Applied Internet Research (CAIR)University of WalesNEWI Plas Coch Campus, Mold RoadWrexham, LL11 2AW, UKwww.cair-uk.org

[email protected]@cair-uk.org

Department of Computer Science and Engineering, University of Nevada, Reno15th November 2006

optimising internet access control lists vic grout, and stuart cunningham centre for applied...

Documents