View
294
Download
2
Tags:
Embed Size (px)
Citation preview
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