network state and the QoS requirements of a request, nd a path that maximizes the chances of the ..... appropriate path, in which case the request is rejected.
On Reducing the Processing Cost of On-Demand QoS Path Computation Roch Guerin, Sanjay Kamat George Apostolopoulos IBM T. J. Watson Department of Computer Science Research Center University of Maryland Yorktown Heights, NY 10598 College Park, MD 20742 Satish K. Tripathi Bourns College of Engineering University of California Riverside, CA 92521-0425 Abstract
Quality of Service (QoS) routing algorithms have become the focus of recent research due to their potential for increasing the utilization of an Integrated Services Packet Network (ISPN) serving requests with QoS requirements. While heuristics for determining paths for such requests have been formulated for a variety of QoS models, little attention has been given to the overall processing complexity of the QoS routing protocol. This paper deals with the processing complexity of determining QoS paths in link state based routing architectures. Although on-demand path computation is very attractive due to its simplicity, many believe that its processing cost will be prohibitive in environments with high request rates. In this work, we rst characterize the processing cost of QoS routing algorithms that use the widest-shortest path heuristic. Then we study alternatives to on-demand path computation that can reduce this processing overhead. In addition to the well known solution of path pre-computation, we introduce and study path caching, an incremental modi cation of on-demand path computation. By simulating realistic topologies and trac conditions we investigate the performance of both alternatives. Our results show that caching is an e ective alternative to path pre-computation and that both path caching and pre-computation can achieve signi cant processing cost savings without severely compromising routing performance.
Keywords: Path caching, path pre-computation, link state routing, trunk reservation
1 Introduction Quality of Service (QoS) routing algorithms have become the focus of recent research due to their potential for increasing the utilization of an Integrated Services Packet Network (ISPN) serving requests with QoS requirements. The main body of the QoS routing work so far focuses on the path nding problem: given the QoS metrics, the network state and the QoS requirements of a request, nd a path that maximizes the chances of the request for successful resource reservation and has the minimum negative impact on the network's ability to accept future requests. A variety of heuristics for the unicast version of the above problem under di erent QoS models have been discussed in the literature [4, 7, 8, 9, 10, 11, 12]. Some ([4, 7, 11, 12]), operate under a bandwidth based QoS model where requests express their QoS requirements in terms of desired bandwidth. This model is the basis of the Controlled Load service model proposed by the Int-serv working group of the Internet Engineering Task Force (IETF). Most of the path nding heuristics assume that paths can be calculated on a per request basis, resulting in an on-demand mode of operation. Calculating paths on-demand leads to a simple implementation; in addition, since there is no need for building a QoS speci c routing table, on-demand path computation also has reduced storage requirements. Despite these advantages of on-demand QoS routing, many believe that it may not be practical in environments with high rates of QoS requests because of its high processing overhead. Although this claim is hard to verify due to the limited experience with realistic QoS aware network environments, alternatives to on-demand routing have already been proposed [4, 11, 18, 19] for link state routing environments. These 1
alternatives are based on the path pre-computation principle: paths to destinations are computed asynchronously to the request arrivals and are used to route multiple requests, reducing in this way the per request processing overhead. In the approach of [4], a node periodically pre-computes a single path to each destination. Since the amount of requested bandwidth varies, it is unlikely that a single path will be sucient for routing all requests. To cope with this, requests are grouped into classes of similar bandwidth requirements and a path for each class is pre-computed. In [4] this approach was shown to perform well but no insight into the processing cost reduction achieved from pre-computation was given. The technique proposed by [11] attempts to pre-compute multiple paths per destination by rst discovering the widest of the minimum hop path(s) to the destination and then also maintaining paths that are longer than the minimum hop paths but have larger amounts of available bandwidth. This approach does not require classi cation of requests. Paths are pre-computed periodically using a variation of the Bellman-Ford algorithm. Some results on the processing cost improvement achieved by this pre-computation technique can be found in [21]. The approach of [19] is based on the Dijkstra algorithm. Instead of computing a shortest (cheapest in this case, where the cost of the path is associated with the amount of available bandwidth on the path) path to a single destination, simple extensions to the algorithm allow the computation of paths to all destinations. Appropriately quantized link cost values help in the discovery of multiple equal cost paths to all destinations. These paths are organized in a data structure and paths are \extracted" from this structure when a request is to be routed. At the time of extraction a path can be \validated", i.e., the most recent link state information is used to update the value of available bandwidth on all the links. Paths are pre-computed periodically or when a suitable pre-computed path can not be found. Performance is shown to be similar to on-demand path computation. In all the above schemes, the set of paths to a destination is re-computed from scratch each time the path precomputation is triggered. In addition, heuristics are needed in order to enable discovering more than a single path to each destination and nally, paths to all destinations are pre-computed as a result of the path pre-computation phase. There are nevertheless, certain disadvantages to this pre-computation architecture. Failing to update the set of pre-computed paths between pre-computations may result in more path computations or reduced routing performance. Indeed, if the set of pre-computed paths could be updated (with the addition of a new path for example) potentially more requests could be routed successfully so that the triggering of the next path pre-computation would be delayed in the case where pre-computation is triggered by failure to nd a good precomputed path. If paths are pre-computed periodically, updating the path set can improve routing performance. In addition, using heuristics in order to discover more that a single path to a destination introduces additional complexity to the routing scheme. Finally, pre-computing paths to all destinations may prove inecient both in terms of processing and storage if most of the pre-computed paths are not used. Pre-computing on failure to nd an appropriate pre-computed path may aggravate this ineciency, since routing failures to a single destination will trigger pre-computation of paths to all destinations. Furthermore, if routing is subject to security and policy constraints that may require the computation of multiple sets of paths per destination, multiple sets of paths will have to be pre-computed, each appropriate for one combination of security and policy constraints. In order to cope with the above shortcomings of path pre-computation, we investigate the e ectiveness of a path caching architecture. In this architecture, paths are computed only on-demand and then are stored in a path cache to be reused for future requests. If a request can not be routed using a cached path then an on-demand computation is used to determine a QoS path for it and the new path is added in the path cache, updating in this way its contents. This approach results in improved exibility in maintaining a set of candidate paths for each destination, decouples the maintenance of the path sets of di erent destinations and obviates the need for heuristics for discovering multiple paths per destinations, resulting in a simpler routing algorithm. To the best of our knowledge, the only previous work on path caching appeared in [20]. Although the basic approach is similar, our work is considerably di erent as will become apparent when we present the details of our caching scheme. In addition, a major goal of our work is to compare both the routing performance and the processing cost of path caching to that of a path pre-computation architecture in order to investigate the overall cost e ectiveness of path caching as a method for reducing the processing cost of determining QoS paths. In this paper, we compare the routing performance and the processing cost of on-demand path computation, path pre-computation and cache based routing. From among the path pre-computation proposals, the approach of [11] is chosen as a representative path pre-computation architecture that has received considerable exposure since it has also been proposed to the QoSR and OSPF IETF working groups. In order to perform meaningful processing cost comparisons, we develop a simple model for the processing cost of the routing algorithms that 2
encompasses both the path computation operations, as well as the operations speci c to each routing alternative. The processing cost of individual routing protocol operations is calculated using benchmark experiments and then is used for computing the cost of the routing algorithm in the other experiments. We study the routing performance of path pre-computation and caching and their ability to reduce the processing overhead of ondemand path computation without severe routing performance degradation. We also study the storage overheads associated with each alternative. Before continuing we should note that both path pre-computation and path caching only aim at reducing the amount of calculation performed at the routers. Other aspects of the cost of the routing protocol such as number of routing protocol messages are not considered. Although it may be argued that the cost due to routing message generation and exchange overshadows that of processing, understanding the processing complexity of di erent routing architectures and developing techniques for reducing this complexity is an important rst step in optimizing the routing protocol and can be very useful in route server environments where all path computations are performed in a centralized fashion by a route server. This paper is organized as follows: In Section 2, the algorithms used are discussed and path caching is introduced. In Section 3, issues related to the processing cost of the QoS path nding algorithms used in this work are presented and the methodology for measuring the cost of various algorithm operations is described. Section 4 introduces the simulation environment and in Section 5 the di erent approaches are compared based on the simulation results. In the last Section we summarize our ndings and present issues that we will attempt to resolve in future work.
2 Algorithms for Path Computation We consider only link state routing protocols where paths are calculated at the source and requests are routed using source routing. There is some evidence that this will be the architecture of choice for the standard QoS routing algorithms. Private Network to Network Interface (PNNI) [15], an already standardized QoS routing protocol, is based on this architecture. Moreover, proposals in IETF's QoSR working group are based on the link state architecture and can operate in both source routing and hop-by-hop mode. Given the potential of hop-by-hop routing for forming routing loops, the source routed model seems advantageous although it has some scaling limitations. In a link state routing protocol each node maintains a link state database that contains a description of the network state as known to the node. The link state database is updated from link state reports generated by other nodes. Link state updates are distributed to all nodes using ooding. In contrast to some previous studies, we use a link update generation model proposed in [11] that initiates a new link state update when the available bandwidth in a link changes signi cantly since the last time advertised. A link state update threshold determines the percentage of change necessary for re-advertising the value of the available link bandwidth. If blast is the most recently advertised available bandwidth value and bcur is the current value, an update is originated only if jbcur ? blast j=blast > th, where th is the link state update trigger threshold. Recent simulation studies ([4]) showed that from among the heuristics proposed for routing requests with bandwidth requirements, the shortest path heuristics [4, 11, 12] perform better than the widest path heuristic [7] that prefers widest over shortest paths. The width of the path, also called bottleneck capacity, is de ned as the minimum available bandwidth over all the links in the path. We will use the widest-shortest path heuristic [11] as the basis of the path computing algorithms. On-demand widest-shortest paths are computed as follows: Links that have insucient available bandwidth for the request that is being routed are pruned from the network topology before the path is calculated. Then the minimumhop count paths between the source and the destination are discovered and the widest one is used to route the request. If there are more than one widest-shortest paths one of them must be chosen. In order to achieve some degree of load balancing, the path is chosen at random with a probability that is weighted based on the bandwidth availability of the local interface to the rst hop of the path. That is, if Bi is the available bandwidth in P interface i, the probability of choosing path Pi that will use interface i to reach the rst hop in the path is Bi = Ijmax =1 Bj , where Imax is the highest numbered interface. Note that this method is oblivious of any potential sharing of links between paths and its results can be limited in particular network topologies. For path pre-computation, the approach proposed in [11] uses a modi ed Bellman-Ford algorithm to precompute the widest bottleneck capacity minimum hop path to each destination. In addition, paths that are 3
longer than the minimum hop path (alternate paths) but have larger bottleneck capacity than the shorter paths recorded for this destination are also stored. If there are multiple paths with equal bottleneck capacity all paths are stored. When a request arrives, a path is selected among the pre-computed paths as follows: paths are checked for feasibility in order of increasing length and the shortest feasible one is selected. As in the on-demand case, a path is feasible if its bottleneck capacity (as calculated during the time of path pre-computation) is larger than or equal to the request requirements. If there are multiple feasible paths with the same hop count, a path is selected using the technique discussed above for on-demand path computation. If there are no feasible paths the request is routed over the path with the largest amount of available bandwidth that is available for the destination. For comparison purposes we also use a static path computation algorithm. This operates in exactly the same way as the on-demand algorithm except that the link capacity is used as the value for the available bandwidth, making path selection insensitive to variations of resource availability in the network. If there are multiple minimum hop paths with the same (static) bottleneck capacity, one of the them is selected at random using the same load balancing technique as in the previous two cases, the only di erence is that the link capacity to the rst hop of the path is used instead of the available bandwidth on the interface to the rst hop of the path.
2.1 Path Caching
Path caching attempts to reduce the processing complexity of on-demand path computation without compromising its on-demand nature and its ability to compute paths for individual requests when necessary. Path caching reduces the number of path computations by reusing already discovered paths. Paths to a particular destination are stored in a path cache associated with this destination. Future requests are routed on-demand only if they can not be routed using the contents of the path cache. A di erent path cache is associated with each destination node. The path cache needs to be updated in case of topology changes (i.e. change in link status). This is necessary to avoid storing paths that are not valid anymore (because some of their links have failed) or ignoring new paths (because some links are up again). We assume that cache contents are ushed when the topology changes. The path cache can be implemented in a variety of ways. We chose a simple implementation where a path is represented as a list of node structures. Each node structure is essentially a pointer to the corresponding entry in the link state database (Figure 1). This organization allows for simple traversal of the link state database and easy reconstruction of the path when it is needed for routing a request. Clearly, this cache structure is not optimized for storage. When paths share nodes, these nodes are repeated for each path. A more compact representation would collapse the common nodes into one and use multiple next-hop pointers, one for each of the paths that share the node. We prefer to use the rst approach for its simplicity. The compact representation will make adding, deleting, and updating paths in the cache more complex.
2.1.1 Operation
When a new request arrives, the cache for the destination of the request is searched for a feasible path. Such a path is selected using a cache selection policy. If such a path exists, then it is used to route the request. If there is no feasible path the request is routed on-demand. The on-demand computation may fail to discover an appropriate path, in which case the request is rejected. If a path is found though, it is added in the cache for the destination. If the cache is full, a cache replacement policy determines which cached path will be replaced by the new path. In order to make sure that the cached paths re ect to a reasonable degree the current network state, a cache update policy ensures that cached paths are updated. In the rest of this section we will discuss these cache management policies in detail.
2.1.2 Cache Selection Policy
For each cached path the hop length and the bottleneck bandwidth capacity are maintained in the cache along with the sequence of nodes in the path. The value for the bottleneck capacity does not necessarily re ect the most recent information in the link state database since it is not re-computed each time a link state update is received. Only feasible cached paths are considered for routing requests. A cached path is feasible if its bottleneck capacity is larger than the bandwidth requirements of the request. If the cache does not contain a feasible path, the request can not be routed using the cache contents and will have to be routed on-demand. 4
3
1
3
2
6
1
Path1
Path2
8
Path3
8
3
8
Path Cache for destination 8
1
Link State Records
8
Link State Database
6
3
8
1
2 Source Network Topology
Figure 1: Example path cache organization According to previous studies, in order to minimize the consumption of network resources, the shortest of the feasible paths should be used for routing a request. Choosing a longer path results in using resources on more links and potentially penalizes the ability of the network to accept future requests. Still, depending on the topology of the network, there may exist multiple paths of the same (minimum) hop length. In this case, a tie-breaking mechanism is needed. In the case of path pre-computation, due to the criteria for maintaining paths, equal length paths will always have the same bottleneck capacity. This is not the case when path caching is used since paths of equal hop length and di erent (apparent) bottleneck capacities may be discovered at di erent times and be added into the caches. As a result, we have more exibility in the load balancing mechanisms we can use. In this work we explore three such mechanisms: Round-Robin: For each path a counter of the times the path is used is maintained. When there are multiple feasible paths with the same hop count, the least used of the paths is chosen. This attempts to distribute the load among the multiple paths on a request basis. Note that this may not be necessarily correct since requests have varying bandwidth requirements, and even if the number of requests is evenly distributed among the paths, the requested bandwidth may be not. The usage counter is reset each time the path is added or removed in the cache and when the information about the bottleneck capacity of the path is updated (as we will describe in the next section). Widest path: The path with the largest bottleneck capacity among the feasible equal hop length paths is chosen. This implements a \worse- t" policy, in an attempt to reduce bandwidth fragmentation (see [17] for a discussion of bandwidth fragmentation). Tightest path: The feasible path with the smallest bottleneck bandwidth is chosen. This attempts to leave as much bandwidth available for future larger requests. In all the above cases, in the (rare) occasion that there is also a tie in the amount of available bandwidth, a path 5
is selected among the ones with the same hop length and bottleneck capacity at random. Unlike [19] we do not attempt to validate the cached paths at the time of path selection by accessing the link state database in order to get the most up to date values for the available link capacity; we believe that the cost of accessing the topology database can be quite high in some implementations. Note that the degree that the cache selection policy a ects the performance of the routing algorithm depends on the number of times that a cached path is used for routing a request and also on the number of times that a tie in the hop length is resolved with one of the above three policies. The rst depends on the trac dynamics in the network and on how often the contents of the caches are updated while the second mainly depends on the topology. In a topology with multiple minimum hop paths there will be more ties and the di erences between the above policies will be more pronounced than in a topology where there are few equal hop paths. We chose the topologies used in our experiments so that we can highlight these dependencies.
2.1.3 Cache Replacement Policy
As a result of successful on-demand path computations performed for requests that could not be routed using a cached path, new information needs to be added to the cache. If the path discovered is already in the cache, its bottleneck capacity will be updated. Otherwise, the path will be added in the cache. If the cache is full another path will have to be replaced. The choice of the path to be replaced will depend on the particular cache selection policy, so in each case a path that has low chances of being used later will be replaced. In all cases, the longer path in the cache should preferentially be replaced, since cache selection is geared towards choosing shorter paths. Still, longer paths may be useful if they have large available bandwidth. Thus only paths that are longer than the new path and have smaller bandwidth will be considered for replacement. As soon as one such path is found, the search for a path to be replaced stops. If there are no such paths, a path is selected among the paths with the same hop length as the new path according to the cache selection policy (see pseudocode in Figure 2). If the cache contains only paths shorter that the new path, then a path is selected among all the shorter paths again based on the selection policy. It is easy to see that in all cases at least one path appropriate for replacement will be found. The pseudocode for the algorithm to choose a cached path for replacement is shown in Figure 2.
2.1.4 Cache Update Policy
Clearly, the network conditions (in our case the available bandwidth in each network interface) change continuously, resulting in new feasible paths to destinations that need to be discovered and added to the path cache, and in new values for the bottleneck bandwidth capacity of already cached paths. The contents of the path cache can be updated either by invalidating cached paths or by accessing the link state database and re-computing updated values of the bottleneck bandwidth capacity of the cached paths. When cached paths are invalidated, future requests are forced to be routed on-demand, discovering in this way the new network state. As a result, path invalidation is expected to result in a larger overall number of on-demand path computations. On the other hand, re-computing the bottleneck capacity of cached paths will lead to fewer on-demand computations since the paths are still in the cache and can be used for routing future requests. Still, by only updating cached paths, the discovery of new paths may be delayed resulting in sub-optimal routes. We investigate the performance of the two alternatives using three di erent cache update policies: Periodic Invalidation: All the cached paths for all destinations are periodically invalidated, forcing future requests to be routed on-demand and re-populate the path caches. Periodic Update: All cached paths for all destinations are updated periodically by accessing the link state topology database and re-computing bottleneck bandwidth values. Individual Invalidation: Each cached path has a lifetime associated with it. After the path's lifetime has expired it is invalidated. Note that there is no feedback from the request establishment component to caching. Successful establishment of a request could lead to updating the bottleneck capacity information of the cached path used to route the request, and failure to establish a connection to the removal of the path from the cache. We chose to avoid such feedback to keep the system simple and the di erent components separate. A discussion of the e ectiveness of these techniques in a similar context can be found in [16, 19]. All the above cache update policies require 6
choose a path for replacement to make room for a path with bandwidth b and length l for each path p in the cache if length(p) l and bandwidth(p) b return p if length(p) l and bandwidth(p) b mark p endfor for each path p in the cache with length (p) == l if cache selection policy is round-robin find the path with the largest reference count return p if cache selection policy is widest find the path with the smallest bandwidth(p) return p if cache selection policy is tightest find the path with the largest bandwidth(p) return p endfor for each path p in the cache with length (p) l if cache selection policy is round-robin find the path with the largest reference count return p if cache selection policy is widest find the path with the smallest bandwidth(p) return p if cache selection policy is tightest find the path with the largest bandwidth(p) return p endfor choose randomly one of the marked paths with length (p) l return the selected path
>
Figure 2: Pseudocode for choosing a cached path for replacement performing operations periodically or in the case of individual invalidation setting the lifetime of a cache entry. We will collectively refer to the update period of all the above policies as the cache update period. This term will also include the lifetime of a cache entry when the individual invalidation policy is used and the path precomputation period when paths are pre-computed. When comparing path pre-computation and caching, the cache update period will be set equal to the path pre-computation period. In addition, our work di ers signi cantly from that in [20]. The main di erence is that in [20] only a single path per destination is cached. We allow caching multiple paths per destination achieving more exibility for routing requests using cached paths and attempt to exploit topology characteristics like availability of multiple equal hop paths between sources/destinations. In all our experiments the cache size is limited to only a few paths and the cache replacement policy is now an important component of the caching architecture. In addition, we investigate the e ects of the cache size to the performance of the caching scheme. Finally, cached paths in [20] were invalidated when a suciently large number of link state updates was received for any of the links belonging to the cached path. We believe that the implementation of this policy is non-trivial in terms of processing that has to be performed on receipt of a new link state update since it requires traversing the cache data structures on the receipt of each link state update packet and modify the information stored for the links that are a ected. We chose to investigate di erent, lower cost mechanisms for keeping cached paths up to date.
7
3 Processing Complexity Previous studies of path caching and pre-computation [19, 20] used the amount of on-demand computations that was avoided as a result of using a cached or a pre-computed path as a measure of the processing cost savings achieved by their schemes. We believe that this method is too simplistic, mainly because it fails to model and take into account the cost of the other components that are introduced by the caching or pre-computation scheme, in our case the cost of updating and invalidating caches and selecting cached paths. We develop a more detailed cost model and use it to capture dependencies of the processing cost on the network topology and make a fair comparison of processing cost between our path caching approach and a path pre-computation scheme. In the next sections we will describe how we model the computational cost of the di erent approaches considered in this work.
3.1 Path Computation
In the path pre-computation case, implementation of the widest-shortest path heuristic requires discovering all the feasible minimum hop paths to the destination and selecting the one with the largest bottleneck bandwidth capacity. In order to ensure that no path is ignored, a breadth rst node visiting order must be used. This leads to a Bellman-Ford based implementation for the on-demand path computation. The details of a path nding algorithm based on the Bellman-Ford algorithm can be found in [11]. For on-demand QoS path computation, a QoS path is computed as the widest minimum hop path in the network topology that results after pruning all the infeasible links. Discovering the minimum hop path can be performed with any shortest path nding algorithm. In fact, exactly the same Bellman-Ford based algorithm that is used for pre-computing paths to all destinations can be used in the on-demand path computation case to compute a path to a single destination. Indeed, due to the breadth rst visiting order, paths to the destination are discovered in an increasing hop count order. The modi ed Bellman-Ford algorithm of [11] will maintain the widest of the minimum hop paths, exactly as needed for the widest-shortest path heuristic. As soon as a path to the destination node is discovered, the algorithm will terminate. Since all edges on the graph have cost of 1, the breadth rst vertex visiting order of Bellman-Ford will be the same as the shortest distance rst visiting order of Dijkstra's algorithm. As a result, the complexity of the single destination Bellman-Ford will be the same as Dijkstra's, that is O(N 2 ) if the list of the candidate nodes is organized as an unordered array and O(E + logd N ) if a d?heap is used [3] (N is the number of nodes and E the number of edges in the network). In fact, since the breadth rst visiting order coincides with the shortest distance order, instead of a heap we can use a queue with O(1) complexity for adding a vertex and choosing the next vertex to be expanded. This will lead to a worse case complexity of O(E ) for the single destination path nding problem and O(NE ) for the all destination path nding. In many cases, a limit in the hop length will be used; in these cases, if the hop limit is H , the complexity of the all destination Bellman-Ford becomes O(HE ). The actual running time of a particular execution of the Bellman-Ford based algorithm depends on the number of nodes that had to be visited and expanded. Since using the algorithm to compute a path to a single destination typically requires the expansion of fewer nodes we expect its cost to be less. Still, this will largely depend on the network topology. We will investigate the e ects of the network topology by using di erent, appropriately chosen, topologies. The modi ed Bellman-Ford algorithm builds a QoS routing table that contains all the paths discovered to all destinations in the network. In a real implementation, the QoS routing table will be replaced with a dynamic data structure that will use only as much space as is necessary for storing the discovered paths. As a result, the operations performed by the modi ed Bellman-Ford algorithm can be distinguished into the following categories: Initialization: The data structures maintaining the paths for each destination are initialized. In the path pre-computation case this initialization has to be performed for all the nodes in the network. The cost of initialization depends on the number of nodes in the network. This phase is not needed when the BellmanFord algorithm is used to compute paths to a single destination during on-demand path computation. Path Data Structure Maintenance: This category includes all the path management operations of the modi ed Bellman-Ford algorithm such as adding a newly discovered path to the list of paths to a given destination or deleting/replacing a previously discovered path. The number of such operations is only indirectly related to the number of nodes in the network and depends on the resource availability in the links at the time of the computation. 8
Node Operations: Node operations include accessing the link state record in the link state database and
scanning the links of the node to retrieve the values for the available bandwidth on them. The cost of this operation depends on the implementation of the link state database. Per Iteration Operations: The Bellman-Ford algorithm performs multiple iterations as the search for paths includes nodes that are at increasing hop distance from the source. For each round there is some bookkeeping involved for maintaining the list of nodes that will be expanded in the next iteration. Path Selection: After paths to a destination are pre-computed, one of them is selected to route a particular request.
3.2 Caching Operations
In path caching, apart from the cost of determining the QoS paths, cache management costs must be considered. The following are the main cache management operations: Cache Update: Update the information about all cached paths in the cache (done in the periodic update cache update policy). This involves accessing the link state database and incurs overheads similar to the node operations in path pre-computation. The cost of this operation is O(P L) where P is the number of paths in the cache and L their average length. Caching a Path: When a new path is discovered it must be added in the cache. This operation includes checking if the path is already in the cache, adding the path to the cache and potentially selecting another path for replacement. The cost of the operation depends only on the number of paths in the cache and scales linearly with them if we assume that we sequentially test each cached path for feasibility. Cache Lookup: For each request, the cache is searched for an appropriate path. This operation involves testing cached paths for feasibility and its cost depends on the number of paths cached and scales linearly with them. Path Invalidation: This operation is performed in both the cache invalidation policies. In contrast to the above operations it simply involves setting a ag in the data structure of the cached path and is not particularly expensive. Although there still may be some processing cost associated with invalidating paths, such as for example timer creation and maintenance, we will assume its cost is 0 for the rest of the paper. Cache lookup corresponds to selecting between the pre-computed paths in the path pre-computation approach. Although the implementation of path selection in both cases is slightly di erent, the cost in both cases depends on the number of paths that are available to choose from. If the cached paths are organized in order of increasing length the operation of path selection in both cases will be similar. As a result, we assume that the cost of selecting one of the pre-computed paths and one of the cached paths is the same.
3.3 Measuring the Cost of Routing Algorithm Operations
We derive the cost of the operations described in the two previous sections by pro ling the execution of benchmark experiments using the pixie pro ler available in the Digital Unix platform used for the simulations. The pro ler gives the total real time spent in each function of the simulation. By associating the total time spent for operations of a particular category with the number of such operations we can derive an approximate cost per operation. For path pre-computation the benchmark code performed 10,000 path pre-computations to all destinations, where all nodes took turns as sources of the path computation. For the on-demand case, 10,000 path computations were performed from each source to all other nodes in the network. The path computations were performed in an empty network for requests with 0 bandwidth requirements. The benchmarks were run for the two topologies (isp and mesh) used in the experiments. The topologies are shown in Figure 3. The isp is a typical topology of a large ISP provider [4]. The mesh topology is more compact and we expect the di erences in running time between computing a path to all destinations and a single destination to be small. In addition, in contrast to isp, the mesh topology has a larger number of equal hop multi-paths. The results are summarized in Table 1. The numbers are derived for the architecture we used for the simulations: Alphaserver 2100 4/274 servers with 4 Alpha 21064A CPUs at 275 MHz, 256 Mbytes of real memory, and Digital Unix operating system. The version of the code used is based on a random access implementation of the link state database, achieving in this way very ecient access to the link state information. The reported cost of 9
A
B
B B A B A
A
(a) isp
(b) mesh
Figure 3: Topologies used in the experiments Operation isp mesh Node (Avg/Node) 5 3 Iteration (Avg/Iteration) 2 1.5 Data Structure (Avg/Operation) 4 4 Initialization (Avg/Path Computation) 120 47 Cache Update (Max/Path) 5 Caching a Path (Max/Path Cached) 15 Cache Lookup (Max/Cached Path) 3 Path Selection (Max/Path) 3 Table 1: Cost of the operations performed by the routing algorithms (in sec) cache operations is amortized on a per cached path basis, in this way it is independent on the cache sizes. The cost of initialization is large since part of initialization is spent in releasing the memory of the data structures for the paths used since the last path pre-computation. This cost clearly depends on the size of the network. The cost of all other operations is relatively independent of the size of the network.
3.4 Dependence of the Processing Cost on the Implementation Details
From the operations performed by the di erent algorithms, only accessing the link state database can be seriously a ected by the implementation details. All other operations only access data internal to the routing algorithm and do not need to interact with the link state topology database. The link state database needs to be accessed in order to retrieve information about the number of links associated with a node and resource availability on them. The current practice (as expressed in the guidelines for the implementation of OSPF routing protocol [14]) is to maintain a single link state database entry for each node, containing all the information for its links. As a result, one access to the link state database is required for each node expansion. The exact cost of retrieving a link state advertisement from the database depends on its implementation details. In well known OSPF implementations such as the one in gated [6], the link state database is organized as a list of link state advertisements and hashing is used to speed up retrieval of individual entries while other implementations use a balanced tree structure. Naive implementations perform a database lookup each time information about a link or a node is needed. Alternatively, advertisements already in the database can be linked together according to the connectivity of the network elements they correspond to. This will signi cantly reduce the number of database accesses since the whole network topology can be scanned by following pointers; only a single database lookup operation will be needed in order to access link state information for the source node. 10
In the case of updating the bottleneck capacity of cached paths, the dependence on the implementation of the link state database is not very pronounced. Even if the link state database in not optimized by linking related link state records together, this is essentially performed at the path cache level since cached paths are represented as a list of pointers to the link state records of the corresponding nodes. Using these pointers it is possible to directly access the link state records needed for recalculating the bottleneck capacity of the paths without having to go through the database lookup operation.
4 Simulation Environment and Performance Metrics We have developed a simulator based on the Maryland Routing Simulator (MaRS) [13]. MaRS was extended to perform source routing and the link state update generation mechanism has been modi ed to support triggered updates. A simple resource reservation protocol has been implemented for unicast connections. The trac load is expressed in terms of connection requests. If a request is established there is no actual packet trac over its path. The current load for the network links is determined by the list of reservations that is maintained for each interface by the reservation protocol. E ectively, all connections are assumed to be constant bit rate and to conform to their stated bandwidth requirements. This is clearly a simpli cation but issues like trac policing, shaping, and modeling are orthogonal to the issues we study here. The topologies used in the experiments are shown in Figure 3. The propagation delay in all links is set to 1 millisecond. It is assumed that links never fail. As was shown in [4], for uniform trac all the path nding heuristics perform similarly since the network is uniformly loaded and there are few alternate paths available. In addition, in realistic cases, trac engineering will have resulted in proper dimensioning of link capacities and other network resources for a particular trac pattern. We believe that in such cases QoS routing will not be particularly bene cial, instead its merit will be more apparent when temporary mismatches between trac pattern and network topology will create increased loads on parts of the network. These conditions can occur either as a result of a network failure (link failure) or simply because of changing trac patterns. In order to create the above conditions in our simulations we rst determine the link capacities so that the topology is dimensioned for uniform trac. The resulting link capacities range between 30 and 80 MBits/sec for the isp topology and 100 and 140 MBits/sec for mesh. Then, we create conditions of non-uniform trac by establishing two sets of non-uniform trac nodes. Nodes that belong to one of the sets can request connections only with nodes in the other set and have a mean request arrival rate di erent from the nodes that do not belong to any of the sets. If the destination set contains more than one node, the destination is chosen randomly among the nodes in the destination set with uniformly distributed probability. The nodes belonging to each set for both topologies are shown in Figure 3 marked with A and B correspondingly. In the case of non-uniform trac there are two request arrival rates. The background rate for trac between nodes that do not belong to any of the sets of non-uniform trac nodes and the foreground rate for the nodes in the sets. The background rate is chosen so that background trac levels are large enough to somewhat limit the routing options available to primary trac. Reducing the levels of background trac will reduce the overall blocking ratio. In addition to non-uniform trac we also study the performance of the di erent solutions under uniform trac conditions. For uniform trac all nodes generate requests with the same rate. Uniform trac is less favorable for caching; while path pre-computation performs the same amount of processing independent of the request arrival rates, caching operations depend on the request arrivals. When trac is non-uniform, most requests will arrive at few nodes, potentially allowing caching to be more e ective and achieve in this fashion smaller processing cost than pre-computation. Under uniform trac, the request load is equally distributed to all nodes reducing the above e ect. A basic dimension of the comparison between the di erent routing architectures is their behavior under di erent workloads. To capture the e ects of call duration and requested bandwidth we use two di erent workloads which combine di erent duration and request size. Bandwidth requirements are uniformly distributed between the minimum value of 64 Kbits/sec and 1 or 6 MBits/sec while call duration is exponentially distributed with mean of 3 minutes. The request arrival rates are chosen in such a way so that blocking ratios are kept in the 2%-22% range; the resulting o ered loads are shown in Table 2 for the di erent combinations of topology, trac pattern, and request size. The arrival rates are Poisson distributed. Each node in the network has an individual request arrival process, independent from the ones of the other nodes. The network was simulated until 100,000 connections were requested. The rst 30,000 connection requests were used to warm up the network 11
mesh
isp
Max requested B/W 1 MBits/sec 6 MBits/sec 1 MBits/sec 6 MBits/sec Uniform trac N/A 694 MBits/sec N/A 540 MBits/sec Non-uniform trac 760 MBits/sec 756 MBits/sec 399 MBits/sec 297 MBits/sec Table 2: O ered network load for di erent combinations of trac and topology and are ignored when calculating the routing performance and the processing cost. Unless otherwise stated, all experiments were performed with a link state update generation threshold of 10% in order to achieve good quality link state information. We also report results when the update triggering threshold is 80% to investigate the e ects of inaccurate link state information on our solutions.
4.1 Higher Level Admission Control
It is well known [1, 2] that excessive alternate routing can actually reduce routing performance in conditions of high load, since trac following alternate routes can interfere with minimum hop trac competing for the same links. In order to address this problem, we investigate high level admission control policies similar to trunk reservation. Assuming that explicit routing is used, we propose a trunk reservation approach that may result in rejecting requests routed over alternate paths during the resource reservation phase, even when there are sucient resources to satisfy the request. A local per node check determines if the request is allowed to continue reserving resources over the path depending on both the resources that remain available on the link after the reservation and the relative length of the path, i.e., how much longer it is comparedcapacity to the minimum hop path. When a reservation is attempted through a node, the quantity (bavail ? breq )=bi is calculated for the outgoing i link i, where bavail is the amount of available bandwidth on link i, and bcapacity is the capacity of link i. The i i resource reservation for the request is allowed to continue only if this fraction is larger than a trunk reservation level which depends on the length of the path. If the request fails this test, it is rejected. Computing the trunk reservation level based on the request's requirements and the residual capacity of the link allows us to reject requests only when they really would have resulted in overloading a link. Having di erent trunk reservation levels for increasingly longer paths allows us to penalize longer paths more and control alternate routing better. Clearly, the e ectiveness of this mechanism depends on the trac patterns. Only when load is suciently high will trunk reservation pay o since then there will be primary path requests to use the amount of link capacity that is reserved. Under non-uniform trac, the load intensity of the non-hot spot trac is usually selected to be much lower than that of the hot spot trac. In such an environment, trunk reservation may not improve routing performance. Indeed, in experiments we did, trunk reservation did not a ect the routing performance of on-demand path computation in both the mesh and the isp topology. Under uniform trac though, experiments (not shown here) showed that this mechanism is more e ective and achieves a small increase in the routing performance of the mesh topology which has a larger degree of path sharing. The e ect of trunk reservation in the isp topology is again small. In any case, we believe it is appropriate to carry out our experiments with the above admission control mechanism enabled, since similar mechanisms will have to be in e ect in real networks. For the experiments in this paper, the trunk reservation levels were set to 2% for one hop longer paths, 5% for two, three and four hops longer, and 10% for all longer paths.
4.2 Performance Measures
In most routing studies in circuit switched networks the connection blocking ratio is used as a measure of routing performance. The connection blocking ratio is de ned as the percentage of connection requests rejected out of the total number of requests. As mentioned in [4], this is not necessarily an accurate measure since connections have di erent bandwidth requirements. Thus, we mainly report the bandwidth acceptance ratio, the sum of bandwidths of connection requests accepted over the sum of bandwidths of all the connection requests. To determine the processing cost of the alternative routing architectures, we multiply the number of operations performed in each case by their cost as calculated from the earlier benchmark experiments. This number corresponds to the total time spent in routing protocol processing for a given simulation run. In the gures, 12
we normalize this time by dividing by the simulation duration to derive the percentage of simulated time that was spent in routing protocol processing. For the same trac arrival rates and topology, the total simulation time is the same and processing cost values are comparable, otherwise they need to be normalized by the total simulated time. In all the numbers reported the 95% con dence interval is under .3% in the isp and 1% in the mesh topology for the bandwidth acceptance ratio and under .5% for the processing cost values in both topologies. Con dence intervals were calculated using the Student's t distribution.
5 Performance Comparison First, we determine appropriate values for the path pre-computation period in the particular topologies and workloads used. These values are chosen so that the routing performance of the various alternatives measured using the bandwidth acceptance ratio is better or similar to the performance of static path computation. The values for the update period calculated this way and used in the experiments are 10, 30, 60, 120, 180, 220, and 280 seconds. For the larger values of the update period routing performance can actually be worse than static path computation in some combinations of topology and workload, nevertheless we use them for comparison purposes. A disadvantage of having xed update periods is that it has varying e ects under di erent workloads. For example, for the same network topology, requests belonging to a workload with large bandwidth requirements, must have a slower arrival rate (since we want to keep blocking low) than requests of a workload with smaller bandwidth requirements. For slow arrival rates path pre-computation is performed more often in terms of number of requests between successive path pre-computations. Still, having a xed period will most probably be the simplest alternative in a real network. In addition, even for the simpli ed environment of our experiments, it is not obvious how to choose equivalent pre-computation periods or normalize them for di erent workloads since due to non-uniform trac, di erent nodes have di erent request arrival rates. As an indication, an update period of 5 seconds corresponds to about 5 1 MBits/sec requests and 1.2 6 MBits/sec requests for the mesh topology and 1.3 1 MBits/sec and 0.4 6 MBits/sec requests for the isp topology. The cache size for the path caching experiments was set to four paths. Choosing a small cache size is important since it is desirable to minimize the storage overhead of the path caches. Later we will investigate the e ects of cache size on the performance of the caching policies. We compare the di erent approaches by evaluating their performance/cost tradeo s. We accomplish this by plotting the bandwidth acceptance ratio against the processing cost for the di erent values of the cache update or path pre-computation period. This results in a curve for each di erent alternative. The points of the curve that have larger costs (x-axis coordinate) correspond to smaller periods. For on-demand path computation there is only a single point since its routing performance and cost does not dependent of any period. The processing cost of static computation is negligible but in the graphs we plot a line instead of a single point on the y-axis to make comparisons with the routing performance of static routing easier. In Figure 4, we show the performance of path pre-computation and caching for both topologies for requests up to 1 MBits/sec, for the widest path cache selection policy. In this gure we see that for larger update periods all alternatives can achieve signi cant processing cost savings when compared to on-demand routing. For small update periods all alternatives have routing performance similar to on-demand routing but with cost that can be similar or even exceed the cost of on-demand routing. Indeed, path pre-computation and periodic cache update incur processing cost each time paths are re-computed or the cache is updated. If the update period is suciently small, their cost can exceed that of on-demand path computation. On the other hand, the cache invalidation policies do not involve any processing cost for cache management. As a result, their processing cost can only be smaller than that of on-demand path computation. Path pre-computation and periodic cache update achieve better processing cost savings for similar values of the update period. For large values of the update period the cost of pre-computation and periodic update levels o . This re ects that the processing due to path computation is so small that path selection cost becomes the dominant cost component. On the contrary, the cost of the other two cache policies continues to decrease as the update period increases. This cost decrease is due to the fact that with larger update periods, cached paths are updated less often and tend to be used more, reducing in this way the number of on-demand path computations (this will be better shown in the discussion of Figure 5). Path pre-computation has processing cost similar to that of periodic cache update in the mesh topology. A larger di erence in favor of periodic cache update exists in the isp topology. This is due to the fact that in the larger isp topology the cost of computing a path to 13
0.98
0.97
0.96
0.96 0.95
0.92
BW Acceptance Ratio
BW Acceptance Ratio
0.94
0.9 0.88 Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.86 0.84 0.82
0.94 0.93 0.92
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.91 0.9
0.8
0.89
0.78 0.76
0.88 0
0.2
0.4 0.6 0.8 1 1.2 1.4 Processing Cost (% of total simulation time)
1.6
0
(a) mesh
0.5 1 1.5 2 2.5 Processing Cost (% of total simulation time)
3
(b) isp
Figure 4: Performance comparison, 1 MBits/sec a single destination is much lower than the cost of computing paths to all destinations. This cost di erence is not very pronounced in the mesh topology. Note also that in the mesh topology the routing performance of all alternatives appears to deteriorate quickly and become worse than static routing even for moderately small values of the update period, while this is not the case in the isp topology. This is mainly a result of the fact that in the mesh topology most calls (especially between the source and destination of hot-spot trac) are routed over the equal hop (and in this case also minimum hop) multi-paths. This is in favor of the static routing algorithm that can also use all the available minimum hop multi-paths. In the isp topology, the existence of usable alternate paths results in signi cantly improved routing performance of all alternatives over static routing. Figure 5 shows the cache hit ratios for the caching policies for both 1 MBits/sec and 6 MBits/sec non-uniform trac. The cache hit ratio is de ned as the percentage of the overall requests that was routed using a cached path, independently of whether resource reservation on this path was successful or not. We observe that the periodic update policy has a cache hit ratio close to 100% even for small update periods while the other polices start with a much lower hit ratio and improve as the update period becomes larger. The very high cache hit ratio of the periodic update policy is due to the fact that paths are never invalidated so the cache always contains some paths. In the other two cache policies, quite often the cache becomes empty due to path invalidations and the number of on-demand path computations increases. Larger update periods appear to increase the number of cache hits of the invalidation based policies. This is reasonable since with larger update periods paths are invalidated less often. In addition, the individual invalidation policy generally achieves higher hit ratios. This is again intuitive since the independent invalidation of paths reduces the amount of time that caches are completely empty. The cached path selection policy does not appear to have any e ect on the cache hit ratios. In contrast, the size of the requests a ects the cache hit ratios signi cantly, with smaller requests achieving better ratios. This is intuitive since smaller requests will have more chances of \ tting" in one of the cached paths. This is a strong indication that path caching will be performing better (at least in terms of processing savings) for small requests. The above savings in routing performance, in the form of requests routed using the cache do not come without negative e ects on the routing performance. We expect the number of signaling failures that correspond to path misroutings due to using outdated cached paths to increase with increasing cache update periods. Indeed, this is the case as can be seen in Figure 6. In all cases, the number of signaling failures increases with increasing cache update period. In the isp topology the signaling failures of the smaller requests are signi cantly less; this di erence is less pronounced in the mesh topology. Figure 7 is similar to Figure 4 for requests up to 6 MBits/sec when the widest cached path selection policy is used. The picture is similar with the 1 MBits/sec requests. The periodic update policy again performs comparably to path pre-computation in the mesh topology and outperforms it signi cantly in the isp topology and the invalidation based cache update policies achieve less processing savings that the other alternatives in both topologies. Finally, we show some selected results for uniform trac. Figure 8 shows the behavior of di erent alternatives 14
100 % of requests routed with the cache
% of requests routed with the cache
100
80
60
40
6 MBits/sec Per-Upd 6 MBits/sec Indiv-Inv 6 MBits/sec Per-Inv 1 MBit/sec Per-Upd 1 MBit/sec Indiv-Inv 1 MBit/sec Per-Inv
20
0
80
60
40 6 MBits/sec Per-Upd 6 MBits/sec Indiv-Inv 6 MBits/sec Per-Inv 1 MBit/sec Per-Upd 1 MBit/sec Indiv-Inv 1 MBit/sec Per-Inv
20
0 40000
80000 120000 Update Period (msec)
160000
0
50000
(a) mesh
100000 150000 200000 Update Period (msec)
250000
300000
(b) isp
18
18
16
16
14
14 % of total requests
% of total requests
Figure 5: Cache hit ratios
12 10 8
6 MBits/sec Per-Upd 6 MBits/sec Indiv-Inv 6 MBits/sec Per-Inv 1 MBit/sec Per-Upd 1 MBit/sec Indiv-Inv 1 MBit/sec Per-Inv
6 4
6 MBits/sec Per-Upd 6 MBits/sec Indiv-Inv 6 MBits/sec Per-Inv 1 MBit/sec Per-Upd 1 MBit/sec Indiv-Inv 1 MBit/sec Per-Inv
12 10 8 6 4
2
2
0
0 40000
80000 120000 Update Period (msec)
160000
0
(a) mesh
50000
100000 150000 200000 Update Period (msec)
250000
300000
(b) isp
Figure 6: Signaling failures for 6 MBits/sec uniform trac for both mesh and isp. The above conclusions remain valid even for uniform trac.
5.1 Storage Overheads
Storage is another important cost dimension; in this section we will investigate the storage cost of the alternatives whose routing performance and processing cost was studied in the previous section. Path pre-computation requires more storage than on-demand path computation in order to store the QoS routing table that results from the execution of the modi ed Bellman-Ford algorithm. In the path caching case, the cache entries e ectively form a similar QoS routing table. Without any optimizations and with static allocation of the QoS routing table, path pre-computation will need to store at least N paths since there will be at least one path for each destination. In general there may be multiple paths of di erent or equal hop count further increasing the size of the QoS routing table. Similarly, if path caching is used, up to NCmax paths will have to be stored, if Cmax is the maximum cache size. Assuming a simple cache organization like the one described in Section 2.1, the storage requirements are proportional to the number of paths stored. We can make the same assumption about the way paths are stored in the path pre-computation phase. As a result, we can compare the average storage requirements of the various schemes by comparing the average number of paths maintained in each case. This number depends both on the 15
0.97
0.96
0.96
0.94
0.95 BW Acceptance Ratio
BW Acceptance Ratio
0.98
0.92 0.9 0.88 0.86
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.84 0.82
0.94 0.93 0.92 Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.91 0.9 0.89
0.8 0.78
0.88 0
0.05 0.1 0.15 0.2 0.25 0.3 Processing Cost (% of total simulation time)
0.35
0
(a) mesh
0.05
0.1 0.15 0.2 0.25 0.3 0.35 0.4 Processing Cost (% of total simulation time)
0.45
(b) isp
Figure 7: Performance comparison, 6 MBits/sec 0.98
0.97
0.96
0.94
BW Acceptance Ratio
BW Acceptance Ratio
0.96
0.92 0.9
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.88
0.95
0.94
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.93
0.92
0.86 0.84
0.91 0
0.05 0.1 0.15 0.2 0.25 0.3 0.35 Processing Cost (% of total simulation time)
0.4
0
(a) mesh
0.1 0.2 0.3 0.4 0.5 0.6 Processing Cost (% of total simulation time)
0.7
(b) isp
Figure 8: Performance comparison, 6 MBits/sec, uniform trac network topology and the particular state of the network and it is hard to draw any general conclusions about the relative space requirements of the di erent schemes. In Figure 9, we show the average number of paths maintained by each di erent alternative in the two topologies used, for uniform trac of up to 6 MBits/sec. The number of paths is sampled each time a request is attempted to be routed and the average is computed over all the nodes in the network, giving an estimate of the average overall space that is devoted for the QoS routing table. Using uniform trac allows for a more realistic estimate since all network nodes have a similar request load and we avoid pathological situations where nodes have very small caches due to very low request load. For the mesh topology in Figure 9(a) the periodic cache update policy has the largest average number of available paths as expected. Path pre-computation has signi cantly less available paths. This is due to the fact that the mesh topology has many equal hop multi-paths, and due to the widest selection criterion, only the widest one will be maintained by path pre-computation. The di erence between the periodic update policy and path pre-computation is smaller in the isp topology. The cache invalidation policies have the least number of available paths in both topologies; periodically invalidating cached paths results in larger periods of time where the cache is empty. Cached path availability is relatively independent of the cache update period for all policies. Only for the periodic invalidation policy the number of available paths increases when the cache update period becomes larger. This is reasonable since a large update period results in less often cache invalidations. Furthermore, the type of 16
2.4
1.9
2.2
1.8 1.7
1.8
Number of Paths
Number of Paths
2 Widest Per-Upd Widest Indiv-Inv Widest Per-Inv Pre-Comp
1.6 1.4 1.2
1.6 1.5 1.4
Widest Per-Upd Widest Indiv-Inv Widest Per-Inv Pre-Comp
1.3 1.2
1
1.1
0.8
1 0
40000
80000 120000 Update Period (msec)
160000
0
(a) mesh
50000
100000 150000 200000 Update Period (msec)
250000
300000
(b) isp
Figure 9: Average number of paths maintained cache selection policy does not a ect path availability, which is why only results for the widest cache selection policy are shown in Figure 9. Overall, we observe that path caching using the periodic update policy tends to maintain more paths than path pre-computation, translating in increased storage requirements. Still, this increase is not very signi cant, and in addition, the average storage requirements are quite lower than the maximum cache capacity (4 paths). Due to path invalidations, the invalidation based cache policies always have less cached paths. Periodic invalidation in particular results on the average in only one path cached.
5.2 E ects of Cache Selection Policy
In Figure 10, we show the e ects of the cache selection policy for both topologies for requests up to 1 MBits/sec. We observe that the the type of cache selection policy is important only for the periodic update cache policy and does not make any di erence in the routing performance of the invalidation based update policies. This is a result of the the high cache occupancy of the periodic update policy. Since in this policy paths are never invalidated, we expect caches to hold a larger number of paths and at the same time have a larger number of ties on the path length, especially for the mesh topology. On the other hand, in the invalidation policies, paths are removed from the caches and have to be rediscovered again resulting in lower number of cached paths as discussed in subsection 5.1. This is why for the invalidation based cache policies the type of cache selection policy does not have any signi cant e ect on routing performance; for these policies we show results for only the widest cache selection policy. For the periodic cache update policy, the widest path cache selection policy results in better routing performance for smaller update period values for both topologies. The tightest path policy always results in the worse routing performance. Overall, we observe that only the widest cached path selection policy achieves good performance when the periodic update cache update policy is used. Choosing the tightest path will soon result in over owing the chosen path since the reduction of the path's available bandwidth will be discovered later, when the cache is updated again. The round-robin cache selection policy ignores completely the available bandwidth capacity and fails to achieve good performance when caches are updated often. Only choosing the widest cached path combines protection against the infrequent updating of the cached paths with good routing performance for smaller update periods. The situation is similar for uniform trac. In Figure 11, we show the routing performance of the periodic cache update policy compared to the performance of path pre-computation for increasing values of the update period. For the mesh topology (Figure 11(a)) we observe that while the widest path cache selection policy behaves similarly to path pre-computation, the round-robin path cache selection policy has much improved performance for larger values of the update period, although still it is not much better than static routing. This is an illustration of the e ects of the decreasing quality of information used for routing (as a result of larger update periods). While path pre-computation and widest cache selection policy are sensitive to inaccuracy of path information, choosing the least used path is insensitive to the update period since it does not rely of the value of bottleneck bandwidth to pick a path. This 17
0.98
0.96
0.96
0.95 0.94
0.92
BW Acceptance Ratio
BW Acceptance Ratio
0.94
0.9 0.88 Pre-Comp RR Per-Upd Widest Per-Upd Tightest Per-Upd Widest Per-Inv Widest Indiv-Inv Static
0.86 0.84 0.82 0.8
0.93 0.92 0.91
Pre-Comp RR Per-Upd Widest Per-Upd Tightest Per-Upd Widest Per-Inv Widest Indiv-Inv Static
0.9 0.89
0.78 0.76
0.88 0
0.2
0.4 0.6 0.8 1 1.2 1.4 Processing Cost (% of total simulation time)
1.6
0
(a) mesh
0.5 1 1.5 2 2.5 Processing Cost (% of total simulation time)
3
(b) isp
Figure 10: E ects of cache selection policy, 1 MBits/sec 0.98
0.96
0.96
Pre-Comp Widest Per-Upd RR Per-Upd Tightest Per-Upd Static
0.92
0.95 0.94 BW Acceptance Ratio
BW Acceptance Ratio
0.94
0.9 0.88 0.86 0.84 0.82
Pre-Comp Widest Per-Upd RR Per-Upd Tightest Per-Upd Static
0.93 0.92 0.91 0.9
0.8 0.89
0.78 0.76
0.88 0
40000
80000 120000 Update Period (msec)
160000
0
(a) mesh
50000
100000 150000 200000 Update Period (msec)
250000
300000
(b) isp
Figure 11: Routing performance, 1 MBits/sec results in low performance for smaller update periods, but better performance when the update period becomes large. These e ects are exacerbated in the mesh topology since most of the requests are routed through equal hop length multi-paths and the e ects of the cached path selection policy are very visible. For the isp topology, the results shown in Figure 11(b) indicate that this phenomenon is not present. Since in isp there are fewer equal hop multi-paths, cached paths are chosen mainly based on their hop length and not their bottleneck capacity and all policies behave similarly.
5.3 E ects of Cache Size
In Figure 12, we show how the cache size a ects the routing performance of the di erent cache based alternatives. In part (a) of the gure we show data for the mesh topology and in (b) for isp. Requests are up to 1 MBits/sec and the link state update threshold was set to 10%. The update period was set to 5 seconds. The invalidation based policies do not show any important dependence on the cache size, mainly since the cache occupancy is low most of the times. Nevertheless, there are some interesting variations in the behavior of the periodic cache update policy. In the mesh topology, when the widest cached path selection is used, performance increases with increasing cache size. This is reasonable since this topology has multiple equal hop paths that should be in cache to achieve good performance. The more paths exist in the cache, the more information is available about the 18
0.96
0.96
0.95 0.94
0.94
BW Acceptance Ratio
BW Acceptance Ratio
0.98
0.92 0.9
RR Per-Upd Widest Per-Upd Tightest Per-Upd Widest Indiv-Inv Widest Per-Inv
0.88
0.93 0.92
RR Per-Upd Widest Per-Upd Tightest Per-Upd Widest Indiv-Inv Widest Per-Inv
0.91 0.9
0.86
0.89
0.84
0.88 1
2
3
4 Cache Size
5
6
7
1
(a) mesh
2
3
4 Cache Size
5
6
7
(b) isp Figure 12: E ects of cache size
network each time cached paths are updated and the load balancing performed by choosing the widest of them performs better. This is an indication that in some types of topologies, caching multiple paths per destination is advantageous to a single path cache architecture similar to [20]. The performance of a round robin selection of cached paths does not really depend on the cache size. Due to the high degree of link sharing between the minimum hop multi-paths, even rotating between few multi-paths can achieve the same link load as rotating between multiple paths. Selecting the tightest cached path performs badly, con rming that this policy is not very e ective. In the isp case there will be less equal hop multi-paths in the caches due to the topology. As a result, the variations in the routing performance due to the di erent cache selection policy are much less pronounced. For the periodic cache update policy, routing performance of the widest cached path selection policy is independent of the cache size and the tightest cached path selection policy performs badly again. The routing performance of the round-robin cached path selection policy is slightly decreasing with a cache that is larger than 1 path. that this selection policy does not perform well. Again, for the invalidation based cache update policies the type of cached path selection policy does not a ect their performance. As a result, in Figure 12, for the invalidation based policies we show only the curve for the widest cached path selection policy. In separate experiments we veri ed that the processing cost of the various caching policies does not show any signi cant dependence on the cache size. It appears that, overall, cache management costs are only a small fraction of the total processing cost of the routing algorithm.
5.4 E ects of Accuracy of Link State Information
We also performed a series of experiments with a link state triggering threshold of 80%. This large threshold results in signi cantly less updates (85% reduction in isp and 70% in mesh) and forces the di erent algorithms presented so far to operate with inaccurate information about available bandwidth on network links. As can be seen in Figure 13 the relative performance of the various alternatives considered is unchanged.
6 Conclusions and Future Work From our experiments it turns out that: Path caching is a viable method for reducing the processing cost of on-demand QoS path computation, at least when the widest-shortest path selection policy is used. The periodic cache update policy coupled with the widest cached path selection policy achieves the best processing cost routing performance trade-o , in many cases signi cantly better than path pre-computation. Tightest cached path selection policy performs bad in all cases considered in this work. 19
0.98
0.955 0.95
0.96 0.94
BW Acceptance Ratio
BW Acceptance Ratio
0.945
0.92 0.9
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.88
0.94
Pre-Comp Per-Upd Indiv-Inv Per-Inv On-Demand Static
0.935 0.93 0.925 0.92 0.915
0.86 0.91 0.84
0.905 0
0.05 0.1 0.15 0.2 0.25 0.3 0.35 Processing Cost (% of total simulation time)
0.4
0
(a) mesh
0.1 0.2 0.3 0.4 0.5 0.6 Processing Cost (% of total simulation time)
0.7
(b) isp
Figure 13: Performance comparison, 6 MBits/sec, uniform trac, 80% threshold
Invalidation based cache update policies achieve signi cant processing cost savings but in general less than
path pre-computation and periodic cache update. Topology can play an important role in both the processing cost and the routing performance of the di erent caching policies. In particular, the amount of equal hop multi-paths and the density and diameter of the topology can determine the relative costs of single-destination and all-destination path computations and the routing performance of the di erent cached path selection policies. Small cache sizes are sucient for achieving good routing performance and processing savings. There is always a dependency on the network topology. In some cases, i.e. in the mesh topology, the cache should be large enough to hold multiple minimum length equal hop paths. Storage requirements of path caching are comparable to those of path pre-computation. The periodic update cache policy tends to maintain more paths than pre-computation while the opposite holds for the invalidation based policies. The above conclusions are still valid when link state information is inaccurate due to a large value of the link state update trigger threshold.
6.1 Future Work
As mentioned earlier, the amount of link state update trac is also a signi cant component of the cost of the routing algorithm, potentially larger than the processing cost. This work is the rst step towards a server based implementation of the routing protocol where all route computations are performed by a single node. This architecture allows for link state update protocols that are more ecient than ooding resulting in a routing protocol implementation that is ecient in both processing cost and message overhead. Based on the results of this work, we plan to investigate the feasibility of centralized path computation for a variety of trac workloads. Part of this work will be a more realistic routing algorithm cost study which takes into account the cost of generation and processing of link state updates.
20
References [1] R. S. Krupp, Stabilization of Alternate Routing Networks, in IEEE International Communication Conference, Philadelphia, PA, 1982 [2] R.J. Gibbens, F. P. Kelly, and P. B. Key, Dynamic Alternate Routing - Modeling and Behaviour, in Teletra c Science for New Cost-E ective Systems, Networks and Services, ITC-12, Elsevier Science Publishers, 1989 [3] R. E. Tarjan, Data Structures and Network Algorithms, Society for Industrial and Applied Mathematics, 1983 [4] Q. Ma and P. Steenkiste, On Path Selection for Trac with Bandwidth Guarantees, Proceedings of IEEE International Conference on Network Protocols, Atlanta, Georgia, October 1997. [5] B. V. Cherkassky, A. V. Goldberg, and T. Radzik. Shortest Paths Algorithms: Theory and Experimental Evaluation. In Proceedings of the 5th Annual ACM SIAM Symposium on Discrete Algorithms, pages 516{ 525, Arlington, VA, January 1994 [6] The Gate Daemon Project, http://www.gated.org [7] Z. Wang, and J. Crowcroft, Quality of Service Routing for Supporting Multimedia Applications, IEEE Journal Selected Areas in Communications, 14(7):1228-1234, 1996 [8] W. C. Lee, M. G. Hluchyj, and P. A. Humblet, Routing Subject to Quality of Service Constraints in Integrated Communication Networks, IEEE Networks, pages 46-55, July/August 1995 [9] R. Widyonon, The Design and Evaluation of Routing Algorithms for real-time Channels, Technical Report TR-94-024, University of California at Berkeley, June 1994 [10] V. P. Kompella, J. C. Pasquale, and G. C. Polyzos, Two Distributed Algorithms for the Constrained Steiner Tree Problem, In Proceedings of 2nd International Conference on Computer Communication and Networking, pages 343-349, 1993 [11] R. Guerin, D. Williams, and A. Orda, QoS Routing Mechanisms and OSPF Extensions, in proceedings of GLOBECOM 1997 [12] Q. Ma, P. Steenkiste, and H. Zhang, Routing High-Bandwidth Trac in Max-Min Fair Share Networks, in ACM SIGCOMM'96, 206-217, 1996 [13] C. Alaettinoglu, A. U. Shankar, K. Dussa-Zieger, and I. Matta. Design and Implementation of MaRS: A Routing Testbed, Journal of Internetworking Research and Experience, 5(1):17-41, 1994 [14] J. Moy, OSPF Version 2, Internet Request for Comments, RFC 2178 [15] Private Network to Network Interface Speci cation, Version 1.0, af-pnni-0055.000, ATM Forum, March 1996 [16] L. Breslau, Adaptive Source Routing of Real Time Trac in Integrated Service Networks, Ph.D. Thesis, University of Southern California, December 1995 [17] S. Gupta, Performance Modeling and Management of High-Speed Networks, Ph.D. Thesis, University of Pennsylvania, 1993 [18] J.-Y. Le Boudec and T. Przygienda, A Route Precomputation Algorithm for Integrated Services Networks, Journal of Network and Systems Management, vol. 3, no. 4, pages 427-449, 1995 [19] A. Shaikh, J. Rexford and K. Shin, Ecient Precomputation of Quality-of-Service Routes, to appear in Proc. Workshop on Network and Operating Systems Support for Digital Audio and Video, July 1998. [20] M. Peyravian and A. D. Kshemkalyani, Network Path Caching: Issues, Algorithms and a Simulation Study, Computer Communications, vol. 20, pages 605-614, 1997 [21] G. Apostolopoulos and S. K. Tripathi, On the E ectiveness of Path Pre-computation in Reducing the Processing Cost of On-demand QoS Path Computation, to appear in Proceedings of IEEE Symposium on Computer and Communication, Athens, Greece, June 1998
21
