Dynamic routing Qo S routing Load sensitive routing

Dynamic routing – Qo. S routing • Load sensitive routing • Qo. S routing

Load sensitive routing • In what we have seen in this class so far costs are static – Administrator configures them • Why not try to adapt to the conditions of the network? – Use less loaded links – Use links with less delay – Use links that have less loss • Two problems: – Need to know the condition of the links – Can have positive feedback • Oscillations

In the very early days • In ARPANET, from 1969 – Delay SPF: compute shortest paths based on the delay on a link • Use the queue length to estimate it – Delay values where exchanged each time they changed significantly • But (usually under heavy load): – – – A link that has low delay may become too attractive Traffic will start using it Delay will increase, will become less attractive Traffic will stop using it and so on… Oscillation • Oscillations cause too many advertisements, too much CPU load on routers, and low utilization of some of the links

Improvements • The “revised” Internet Metric – Metric advertised should be relative to other links and not just the queue length • If average link cost is 10 advertise 20 when link is overloaded • 20 is almost like two links • Some traffic will start using paths that are 1 hop longer – Have a lot of damping in the advertisements of metrics – Result in more gradual changes in traffic and link utilization • There will still be oscillations – Smaller magnitude – Better overall network utilization under heavy load

But only a single metric • SPF can have only a single cost value per link – SPF can not compute paths that minimize two metrics – Unless I do a linear combination of all into a single value • Example – EIGRP from Cisco allows to advertise dynamic information and select paths using it – Combines multiple performance metrics into a single per-link value • Load sensitive routing is mostly abandoned today – Oscillations are very undesirable

To. S routing • What we have today is Type of Service (To. S) routing – Even than is not really used • IP packets have 4 bits of To. S in their header – Some combinations have pre-assigned meaning • 0100 = max throughput • 1000 = min delay • Etc… • In principle routers compute different routes for each of these bits – Links may have different costs for each To. S value – OSPF can advertise different link costs for each To. S

Oscillations revisited • Oscillations happen because traffic can shift around • What happens if I could “pin” traffic on a certain path? – Using source route, MSPL LSP, or some other explicit routing technology? – No more oscillations • Now I need to find good paths for traffic – From source S to destination D – Satisfying one or more Qo. S constraints – This is “Qo. S Routing”

Quality of Service (Qo. S) • Quantitative metrics that express how well my traffic is treated • Most common – Delay (end-end or per link) • Queuing delay • Propagation delay (hop length related) – Loss – Jitter (delay variation) – Available bandwidth • A Qo. S guarantee tells me that one of the above metrics will have a bounded value

How to achieve Qo. S • Need to schedule resources in each router/link – Link transmission slots • To ensure available bandwidth – Queue lengths and entries • To ensure that a packet will not be delayed by queuing too much – Buffers • To ensure low loss rates • Huge body of work on resource scheduling for Qo. S

Reservations • Assume I found a path that satisfies the requirements • To ensure I get the requested service I will need to reserve resources on the path – Reserve the 100 Mbit/sec bandwidth – Reserve queue entries and link scheduling resources to limit my latency, loss and jitter • After reservation, less resources are available to other traffic – Admission control – New traffic may be rejected if there are not enough resources available

Signaling • Combine path pinning and resource reservation in a single signaling step • Not unlike setting up an LSP with RSVP-TE • Two pass – Forward pass: • send the request • perform admission control • Initial reservation – Reverse pass: • Fine tune reservations

Qo. S routing • Find a path to destination D with end-end delay=20 msec, loss rate < 1% and available bandwidth 200 Mbit/sec • How to find the path? – Need to have an algorithm to compute a path that satisfies all these constrains – Need to have up to date information about what happens in all links and nodes in the network

Metric types • Additive metrics: – The metric for the path is the sum of the metric for the links of the path – Delay, jitter • Multiplicative metrics: – The metric for the path is the product of the metrics for the links of the path – Loss rate • Bottleneck metrics: – The metric for the path is the largest (or smaller) of the metrics for the links of the path – available bandwidth

Constrained path computation • How to find a path that optimizes multiple metrics? – E. g a min delay and min loss path? • How to find bounded paths? – E. g. a path that has delay < 50 msec and available bandwidth > 100 Mbit/sec • Well I can not [Wang, Crowcroft 1996] – More than 1 additive and/or multiplicative metrics is NP-complete • 1 additive + 1 multiplicative, 2 additive, 2 multiplicative: all NP-complete • 1 additive, 1 multiplicative: OK

All is not lost • Available bandwidth allows some flexibility – Find paths that have at least B bottleneck bandwidth and satisfy 1 more condition is possible • Prune all links that have less than B available bandwidth • And then compute the best path for the second metric – E. g delay and bandwidth, bandwidth and loss, bandwidth and jitter are all possible

Example • Delay and bandwidth: path with bandwidth 100 Mbit/sec and delay < 10 msec – Prune all the links with less than 100 Mbit/sec available bandwidth – Run SPF to find the least delay path to destination – If least delay > 10 msec no path exists – If delay <= 10 msec found my path

Pre-computing Qo. S routes • I may have a lot of incoming requests for Qo. S routes – Computation of routes may become an issue – Pre-compute routes • But for pre-computed routes I do not know the Qo. S requirements of the requests – Compute a range of paths for all possible requests • More storage • E. g. compute paths with 10, 1000 Mbit/sec available capacity and 10, 20, 40 msec delay • When a request comes, fit it in the appropriate path – Compute the “widest” paths for different hop lengths and use the shortest one where the request can fit in • “shortest-widest” path

A “good” routing algorithm? • What is the optimization goal? – To fit as much traffic as possible in the network • Increases utilization of resources • Increases revenue – A request is blocked when it can not find a path with the Qo. S it needs – Reduce the blocking • Number of requests blocked – Requests have different bandwidth requirements • Sum of bandwidth of the blocked requests • Routing algorithm A is better than B if: – for a given set of requests A can achieve less blocking that B

Hard to evaluate • Needs simulation • Traffic models are not known – What kind of Qo. S traffic will want – How big/small are the bandwidth requests • Relative to the link sizes • Topology has a very large effect • Traffic patterns too – Hot-spot vs. uniform load – Overall load in the network • No standards exist for Qo. S routing performance evaluation

Why Qo. S routing works • Conventional routing uses only the shortest path(s) (maybe more than one) – Resources on other links are underutilized • Qo. S routing can switch traffic to longer (alternate) paths when the shortest paths fill up – Better network resource utilization – Less blocking • Only if there are unloaded alternate paths – If network is heavily loaded and all paths are full Qo. S routing can not do much

Problem • Qo. S routing works on-line – Given a set of requests I find a route and establish it one by one – The path I find for a route will affect the availability of paths for future requests – Picking a bad route now may result in blocking many future requests – EXAMPLE • How can I ever optimize for requests that do not know yet – Have to rely on heuristics

Optimization heuristics • Longer or shorter paths? – Shorter paths use less resources in the network – Avoid completely very long paths • Best or worse fit? – If I fit request too tightly on a link I cause bandwidth fragmentation • May cause blocking later on • Trunk reservation – Traffic on alternate paths may starve traffic that could use the shortest paths – Reserve some amount of resources on the shortest paths

Amount of update traffic • When conditions change on a link send an update • In an IGP updates are flooded – If conditions on a link change very frequently there will be a lot of updates – A lot of bandwidth and CPU will be lost • Must limit the rate of updates – But then link state information will not be accurate anymore • “stale” state • Fundamental trade-off – Accuracy of routing vs. cost of updates – How can I get good routings even if state information is stale?

Limiting the update rate • Update threshold – Generate an update when link information changes more than t% since last advertisement • E. g available bandwidth changes more than 10% – More accurate when available bandwidth is small • This is good we need more accuracy then • Clamp down timer – Do not send more than x updates per second

More limiting • Divide the link bandwidth in regions – Equal sizes – Exponential sizes • When available bandwidth moves to a different region since last advertisement send a new one – Can advertise the region and not the exact value of available bandwidth • Many links will have same available bandwidth • More availability of equal bandwidth paths to choose from

Routing with stale values • Randomized routing – Do not believe the information we have – Add some randomness in the path selection decisions