Dynamic routing – QoS routing

• Load sensitive routing • QoS 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

ToS routing

• What we have today is Type of Service (ToS) routing– Even than is not really used

• IP packets have 4 bits of ToS 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 ToS value– OSPF can advertise different link costs for each ToS

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 QoS constraints – This is “QoS Routing”

Quality of Service (QoS)

• 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 QoS guarantee tells me that one of the above metrics will have a bounded value

How to achieve QoS

• 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 QoS

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

QoS 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 QoS routes

• I may have a lot of incoming requests for QoS routes– Computation of routes may become an issue – Pre-compute routes

• But for pre-computed routes I do not know the QoS requirements of the requests – Compute a range of paths for all possible requests

• More storage • E.g. compute paths with 10, 100, 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 QoS 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 QoS 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 QoS routing performance evaluation

Why QoS routing works

• Conventional routing uses only the shortest path(s) (maybe more than one)– Resources on other links are underutilized

• QoS 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 QoS routing can not do much

Problem

• QoS 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