AHOP Problem and QoS Route Pre-computation

Adam Sachitano

IAL

Citations

1. Computing shortest paths for any number of hops, Orda and Guerin, IEEE/ACM Transactions on Networking (TON) Volume 10 , Issue 5 (October 2002) p. 613 - 620

2. Precomputation schemes for QoS routing, Orda and Sprintson, IEEE/ACM Transactions on Networking (TON) Volume 11 , Issue 4 (August 2003) p. 578 – 591

Computing shortest paths for any number of hops

• Known as the AHOP problem (all hops optimal path)

• Involves identifying the minimum weight path or paths for all hop counts

• Fundamental issue in QoS routing– Guarantees may include: cost, delay, bandwidth, etc.

– “Determining the cheapest path available that meets a desired level of service”

AHOP focus

• Computational complexity of solving AHOP for prevalent cost functions

• Two solutions are presented with best known complexity

• Speculation on future work leading to precomputation schemes

AHOP

• Generalization from several routing algorithms used to guarantee a certain SLA on connectivity or performance

• Traffic must be routed along paths which can meet such guarantees at a minimal cost to the network

• The most general case of this problem is known to be NP-complete

AHOP special cases

• The general case is not the most interesting in routing

• More interesting (specific) cases related to QoS routing are solvable with tractable solutions– Minimum number of hops is a realistic and

practical measure of network cost– Min-hop paths easily computed using well-

known algorithms (i.e., Bellman-Ford)

Specific AHOP complexity

• Bottleneck metrics– Weight of a bottlenecked path is the maximum

(or minimum) value of its link weights

• Additive metrics– Weight is the sum of the weights of the links

that comprise the path

Bottleneck Metrics

• Common example: Bandwidth– The maximum bandwidth of a particular path

between points A and B cannot be greater than the minimum bandwidth of the links composing the path

Additive Metrics

• Common example: End-to-end delay– The total delay of a particular path between

points A and B is not less than the sum of the delays of the links composing that path

AHOP vs. shortest-path

• For the shortest-path problem, the same solution can be used for additive and bottleneck metrics.

• For the AHOP problem, the solutions and complexities of those solutions for additive and bottleneck metrics differ

AHOP short story

• Lower-bound for additive metrics is Ω(N3)– AHOP for additive metrics is a problem which contains

the Restricted Shortest Path problem, which is known to be NP-hard

• Average case for bottleneck metrics is O(N3/log(N))

• Pseudocode and analyses of algorithms corresponding to these results is presented in [1]

Conclusions

• Authors establish worst-case complexities for AHOP in general

• Authors show that special cases of AHOP are more pertinent to QoS and show better worst-case complexities for these

• Authors presented algorithms which solve the special cases in the presented run times

Benefits and Caveats

• Important in QoS: Solving AHOP computes, for each hop count n, the best service guarantees feasible between a source node and all other destinations on the network

• However, even if the solutions are tractable, performing them repeatedly (i.e., for repeated requests) will be computationally expensive

Future work Segue into Precomputation

• Computing AHOP for all possible sources as well• Formulate the possibility for a “route server”

which would be a network element that performs these AHOP computations for all sources/destinations (offloading this burden from core routers)

• Such a network element would require an efficient scheme of precomputation

Justification of Precomputation

• Providing for the growth in data traffic and network capabilities requires new ways of managing networks

• This is currently infeasible due to constraints on computing power of existing core network elements

Precomputation

• Precomputation-based methods have been proposed as a means to:– facilitate scalability– improve response time– reduce computation load on network elements

Precomputation on core elements

• Computing AHOP on-line and on-demand during periods of high load will only increase the burden on core network elements

• Solution: Use periods of low processor load to perform QoS routing-related computations (such as solving AHOP) in advance as background processes

• Subsequent requests which have a solution due to this advanced preparation could be served and routed instantly

Precomputation on core elements

• On networks of typical hierarchical topology, precomputation can lead to improvements in network overhead by reducing amortized computation costs at core network elements

Precomputation Mechanics

• Precomputation is achieved by a two-step precomputation scheme:– Advanced preparation: precomputation of paths

for varying event parameters (scope determined by feasibility)

– Event arrival: events are dispatched according to a precomputed route meeting the event’s QoS needs

A priori preparation

• A core router could compute AHOP for all known destinations for a variety of possible event parameters– Complete routes could be stored if time and space are

available

– Partial computations which would support faster route resolution could be stored

• Core routers would have to be pre-configured as to which route metrics to consider in this step

Event Arrival

• Assuming that some method of storing complete routes resulting from the a priori phase is available, event arrivals will be handled by ‘looking up’ an acceptable route OR

• Assuming that only partial computations are carried out in the a priori phase, additional computations would have to be carried out here

Delay example

• Suppose a router is configured to consider delay-based SLAs on a network

• Router spends periods of low load precomputing AHOP routes from itself to known destinations for a certain (controllable) range of possible delay constraints

• Incoming events are reconciled with precomputed delay ranges, an acceptable route is selected, and the event is dispatched

Scalability Benefits:

• Traditional vehicles for facilitating scalability:– Reducing network element load– Limiting the amount of link state information

• Precomputation provides for both of these, resulting in lower total overhead across the network

Fault Tolerance Benefits:

• Failures of network elements must be handled by rerouting traffic around the failure

• This can be handled more quickly if alternative routes have been precomputed

Benefits to bursty traffic / load balancing:

• Periods of bursty traffic can be handled with lower amortized overhead

• A packet’s time in a router’s queue would be reduced due to lower overhead in dispatching previous requests

• If a number of routes for a given SLA have been computed, then events requesting that SLA can be evenly dispatched among the different acceptable precomputed paths

Current uses of precomputation comparison

• IP static routing tables

• QoS has higher overhead than standard IP routing

• QoS complexity and demanding SLAs make QoS computation more desirable

Problem: Precomputation in hierarchical networks

• In networks composed of subdomains, knowledge about the internal structure of a subdomain may be restricted

• A scheme for topology aggregation is briefly presented

Topology aggregation

• A network composed of subnetworks is analyzed according to links in and out of the subnetworks.

• Unrestricted information about the subnetwork is “published” by border routers on these links

• This information is used by outside routers in precomputation schemes

• Such a scheme provides for more scalable QoS routing

Complexity

• For bottleneck metrics, the IBF method presented in the AHOP paper is used

• Though a lower-bound was shown in the AHOP paper for additive metrics, the problem in general is NP-hard (it contains RSP)

• Instead of the method presented in AHOP, a polynomial-time method which gives an eta-approximation of an optimal solution is presented and analyzed

• Given the methods presented in the paper, overall load is reduced by precomputation [2]

Future work

• A more in-depth investigation into when precomputation should be applied

• Methods to perform precomputation sporadically and recompute only when the network changes drastically.

• “Route server” network elements– For each routing subdomain, install a network element

tasked solely with precomputation and handling of route requests from core routers in its peer group