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
