More on protocol implementation Version walks Timers and their problems

How to choose search structure Insert pattern –Random enough or pseudo-sequential Lifetime –Ratio of lookups/insert+deletes Lookup pattern Lookup type –Exact? –Prefix?

Example RSVP –Key for the session tree is (ingress_ip, egress_ip, lsp_id) –After I setup the LSPs they stay up for long time Few deletes, mostly inserts All inserts at the beginning few later Most probably all inserts are uniformly distributed over the key space –During operation I will have to look up all LSPs Lookup pattern is uniformly distributed No need to think about optimizations like splay trees –Which tree would perform better in these conditions? I could use an unbalanced tree but it is risky Hashing could be used by it will be tricky to get a good hash function –Ingress_ip, egress_ip are few 100s of addresses –Lsp_id is correlated with ingress_ip

Version Walks Walking all the tree may be an overkill if only few elements changed Assign a version to each node –Each time it changes increase it by one –Copy this version to all the nodes predecessors all the way to the root of the tree Each node’s version is the max version among all its children Now, when walking specify a min version –If I reach a node that has smaller version no need to visit its children Can save a lot of walk time –Depending on the shape of the tree, the locality of changes etc etc Versioning has a small cost –For each version change I will have to visit all the path from the root of the tree to the node that changed

Timers Timer has associated with it its firing time I need –Create/delete/modify timer –Find the next timer to fire Scalability means all should be fast –Quagga has a list of timers ordered according to their expiration, create/modify will be very slow – O(n) –Need a structure that has fast insert and delete and O(1) for fiding the next timer to fire Plain binary trees, O(logn) for insert and O(logn) for find next Priority heaps O(logn) for insert and O(logn) for find next Calendar queues around O(1) for insert and find next –Same problem for event driven simulators Lots of work has been done there

Calendar Queue A set of lists or buckets Each bucket corresponds to some period of time and holds all the timers that will fire in that period. Timers in the same bucket are in a sorted list I walk the buckets in a round robin fashion O(1) to find the next timer to fire Challenges – Determine the bucket size so I keep only few timers per bucket Dynamically adjust the bucket size Will cost me to move timers around –Skewed timer distributions will cause a very small bucket duration and many empty buckets –If the number of active timers is very variable (from few 10s to few 10,000s and back) then I will spend too much time readjusting the bucket sizes

Timers are Tricky Timers can get synchronized –Usually need jitter –A good timer library should provide these Timer slip –Timer fires after it should have –Happens if I do not schedule things properly Timer clustering –Many timers will fire at the same time Too low granularity of bad scheduling –Have to process them in a controlled way Queue of expired timers and process few at a time Clock drift –Hardware clocks are usually drifting Running slower or faster, can be up to 2 min per year A good timer library or gettime function be aware of that –Or use ntp to sync with an accurate source

How do timers synchronize Triggered updates –When something change in the network all routers reset their timers E.g. link fails and LSP path changes, all PATH and RESV refreshed can get synchronized They will remain in sync Update collision Update processing time is relatively large Routers first finish processing all updates they receive and then they set their timer –If two routers receive each other’s updates they will get in sync and will remain in sync –Slowly more routers get in sync

Solutions Do not reset timers when there is a triggered update –But if routers start synchronized they can not get desynchronized Jitter in the timers –Add a random component to the expiration time –Analysis has shown that this jitter must be around half the period –This is where the refresh formula for RSVP comes from

Timer design Create/delete patterns are important again –Consider RSVP. Need to: Refresh PATH Refresh RESV Check for timeout in PATH Check for timeout in RESV One timer is enough for all of these, each time it fires compute what is the next thing to do and –One timer for LSP, so number of active timers does not change too much This is good for calendar queues (and heaps) –RSVP timers Typical values: refresh every 10 seconds, timeout after loosing 3 refreshes, I.e. 45 seconds. So max value for the timer is 45 seconds Can use this to optimize the calendar queue

Too many timers? Even with a single timer per LSP I may have 100,000 timers –Too much memory –Very large tree or too many buckets in a calendar queue May be possible to have fewer timers –If I can live with little bit of inaccuracy –For N timers that are going to fire close use a single timer –When this timer fires process all N timers

Timers and state refresh RSVP is a soft state protocol, state must be refreshed –Frequent refresh: faster detection of changes –Frequent refresh: more bandwidth used for refreshes 100,000 LSPs, 120 bytes per update –Update each second = 96 Mbit/sec –For a 1 Gig link, to keep updates to less than 1% of link capacity I must send 1 update each 10 seconds

Fixed and dynamic timers Fixed timers –More state – more bandwidth for refreshes Scalable or dynamic timers –Tie state refresh to link capacity –Do not use more than x % of link capacity for refreshes –More state – less frequent refreshes –The receiver estimates the sender’s refresh rate to determine when to time out state –Send messages for new state first, updates with less priority