Using Access Probabilities In Address Lookups

1. Using Access Probabilities In Address Lookups Jim Washburn & Katerina Argyraki EE384Y Class Project

2. Access probabilities are not uniform • Lookup table contains set of keys Ki • Access probabilities Pi • Access times Ai • Avg access time • Ei = i {AiPi}

3. Where is accounting info stored? • Per key • Per nexthop

4. Lookup table operations • add(key) • delete(key) • search(key) • compile( ) • When to compile? • What happens to searches while compiling ? • How long to maintain accounting info?

5. Approach to the problem • Amortize the optimization • Incrementally optimize at search time • Perform optimization step with low probability per access • keeps cost low!

6. Base structure: BST on intervals • Can do prefix matches or exact matches • Allows many different tree configurations for the same set of keys • can be dynamically reconfigurable • Permits localized incremental operations • affect just two nodes

7. BST rotation operation z z right y x left x y C A A B B C Only nodes x and y are written

8. Self-adjusting heuristics • single rotation on every access • too conservative? • move-to-rooton every access • too aggressive? • move-up on every access • “middle ground” solution • but how many nodes?

9. Low-cost heuristics • single rotation with low probabilityp • decrease the amount of writes • move-to-root with probability proportional to node depth • favor nodes that are deep down the tree • move-up with counters • per node counter keeps # of hits • a node is never moved above another node with higher counter

10. BST as Markov Chain • Tree can be in any of its possible configurations, with probabilities given by the stationary distribution. …

11. Markov calculations (1) Done with 60 randomly selected access distributions, for a 3 node tree Probability of optimization step set to 0.1

12. Markov Calculations(2)

13. Simulation results (1) • Scenario 1: 99% hit on 7 rules • .5, .25, .12, .6, .3, .1 • Average performance (the good news):

14. Simulation results (2) • Scenario 1: 99% hit on 7 rules • .5, .25, .12, .6, .3, .1 • Worst-case performance (the bad news):

15. Simulation results (3) • Scenario 2: 60% hit on 12 rules • .13, .09, .06, .05, .04, .03, .02, .01, .01, .01 • Average performance:

16. Simulation results (4) • Scenario 2: 60% hit on 12 rules • .13, .09, .06, .05, .04, .03, .02, .01, .01, .01 • Worst-case performance:

17. Simulation results (5) • Scenario 3: uniform distribution • The worst-case for our heuristics! • Average performance:

18. Simulation results (6) • Scenario 3: uniform distribution • The worst-case for our heuristics! • Worst-case performance:

19. Bounding the tree depth • Check before moving a node • If move will increase depth beyond max, don’t do it • How to check? • Keep extra info per node e.g., node depth • Must not introduce extra accesses for maintenance! • Impossible with single rotation or move up 

20. MTRR with bounded worst-case • Augmented BST • Each node knows • the depth of its longest branch on the left • the depth of its longest branch on the right • Rotating a node up, requires updating all its ancestors up to the root • With move-to-root we do that anyway 

21. Simulation results (1) • Scenario 1: 99% hit on 7 rules • .5, .25, ,12, .6, .3, .1 • Average performance:

22. Simulation results (2) • Scenario 1: 99% hit on 7 rules • .5, .25, ,12, .6, .3, .1 • Worst-case performance:

23. Conclusions • We can optimize without having to maintain per-key accounting state, or periodically recompiling the entire data structure. • Average access time results comparable to compiled results, which are close to lower bound which is determined by entropy. • Worst case results not as good, need more heuristics to bound the tree depth