A distributed cache architecture with snooping for QoS routing in large networks

Computer Networks 44 (2004) 189–209 www.elsevier.com/locate/comnet

A distributed cache architecture with snooping for QoS routing in large networks M. Rezvan a b

a,* ,

K. Pawlikowski a, H. Sirisena

b

Department of Computer Science, University of Canterbury, Private Bag 4800, Christchurch 1, New Zealand Department of Electrical and Electronic Engineering, University of Canterbury, Christchurch 1, New Zealand Received 20 June 2002; accepted 26 February 2003 Responsible Editor: E. Knightly

Abstract To meet the diverse quality-of-service (QoS) requirements of emerging multimedia applications, communication networks should provide end-to-end QoS guarantees. QoS routing is the first step towards this goal. The route computing overhead caused by on-demand calculation of QoS routes, especially in large networks with heavy traffic, is a concern and can cause scalability problems. This paper addresses this problem by introducing a novel distributed cache architecture. The distributed nature of the proposed cache architecture facilitates its deployment in large networks. To maximize the performance of the distributed cache architecture, cache snooping has been proposed to alleviate the side effects of network states fluctuations on the cached route so that the overall routing performance is significantly improved. Assuming a bandwidth-based QoS model, in performance evaluation of the proposed distributed cache architecture, we use a broad range of realistic network topologies, network traffic conditions, routing protocols, and aggregation techniques to evaluate different aspects of the proposed cache architecture under different conditions. The results confirm that the route caching is quite effective in reduction of route computing overhead. In addition, our results suggest that the cache snooping can significantly increase the overall routing performance, especially in the presence of highly inaccurate network state information.
2003 Elsevier B.V. All rights reserved. Keywords: Quality-of-service; Routing; Distributed cache; Cache snooping

1. Introduction To meet the diverse quality-of-service (QoS) requirements of emerging multimedia applications, communication networks should provide end-toend QoS guarantees. QoS routing is the first step

*

Corresponding author. E-mail address: [email protected] (M. Rezvan).

towards this goal. It seeks to find routes that satisfy a set of QoS constraints while achieving overall network efficiency [16]. Therefore, unlike current routing protocols, QoS routing protocols rely on dynamic network state information for computing QoS routes [1,2,6,9,12]. Frequent route computing and network state updates, especially in large networks, can cause computing and traffic overhead, respectively. Therefore, scalability to large networks has been identified as one of the

1389-1286/$ - see front matter
2003 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2003.02.001

190

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

key issues in designing a QoS routing protocol [10]. It is desirable to minimize these overheads without sacrificing the overall routing performance. In this paper, we address the route computing overhead. In QoS-capable networks, routes are computed upon arrival of calls. The main advantage of this on-demand approach is its simplicity. However, in large networks with high arrival rates, this approach can cause significant computing load. The pre-computing technique has been proposed and shown to be an effective solution to reduce route computing load [7,14]. The principle is to compute routes as a background process and use them when a call arrives, therefore reducing the computing load upon each arrival. In this paper, we focus on route caching that has been recently proposed as a solution to reduce the route computing load by reusing already computed routes [1,2,7,15]. In route caching, a newly computed route is stored in a cache for possible use by future calls. Upon arrival of a call, the cache is searched for a route that can satisfy the requested QoS parameters. If no such route is found in the cache, then a new route has to be computed. Because cache size is limited, cache replacement policies should be used when the cache is full. In addition, when several feasible routes are found in the cache, efficient route selection policies are required to maximize network resource efficiency. While caching is a promising approach to reduce route computing load, we believe that recent proposals have taken very simplistic approaches and several fundamental issues have received no attention. Firstly, the hierarchical architecture of very large networks has not been taken into account. Large networks are potentially partitioned into several domains. A realistic caching scheme should offer an end-to-end solution across multiple domains in a large network. Secondly, for scalability reasons, topology aggregation is identified as an essential technique in large networks with multiple domains [4,10,11]. In a large network, an end-to-end route potentially crosses several domains. Considering that each domain represents only an aggregated view of its internal topology and state information, the important question is: how can such an end-to-end route be cached effi-

ciently? Finally, cached routes are subject to changes in the network conditions and should be regularly updated. The simple update techniques that try to periodically re-compute all cached routes can cause considerable computing load. In this paper, we propose a novel distributed cache architecture to reduce the route computing load, while addressing the above-mentioned issues. Our distributed cache architecture has several advantages as follows: • It can scale to very large networks since it has a distributed nature. It has been designed to be easily deployable in networks with multiple domains. • A cache content management/replacement technique called cache flushing has been developed. It suits the distributed nature of our cache architecture. The traditional cache replacement techniques take action when the cache is full and a new entry has to be added. In contrast, the cache flushing works in the background and always maintains some free space in the cache elements of the proposed distributed cache architecture (we accurately define the meaning of the cache element in Section 2). • Once a route is cached, our distributed cache architecture does not rely on network state updates and operates independently. Therefore, our cache architecture does not suffer from inaccuracy of the network state information caused by topology aggregation, delays in the distribution of the network states, or network state update interval. Instead, our architecture directly monitors only those parts of the network that are more likely to be used. In this way, it intelligently adapts to the changes in the network states. This is done by a novel technique called cache snooping, which has been developed to alleviate the effects of network state fluctuations on the cached routes with minimum overhead. • Cache snooping increases the routing tolerance to inaccurate network state information. This improves the overall routing performance, especially in the presence of highly inaccurate network state information. • Another technique that is designed to increase the performance of the distributed cache archi-

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

tecture is route borrowing. As we detail in Section 5, route borrowing lets a long end-to-end cached route to be partially reused from its non-terminal points. This significantly increases the likelihood of reusing the cached route which leads to major reduction in route computing load. • We have considered simplicity as a key design issue for distributed cache architecture and its associated techniques. Therefore, the distributed cache architecture relies on simple but efficient algorithms and techniques so that the added complexity to the network is minimized. In this paper, we assume that network links and nodes are fault-free and function perfectly. This let us to focus on exploring different aspects of the distributed cache architecture and its operation. It is also worth mentioning that the distributed nature of the proposed cache architecture is an essential pre-requisite for developing the cache snooping. As we detail throughout the paper, it becomes clear that without the distributed cache architecture in place, the cache snooping cannot be developed. The remainder of this paper is organized as follows. Section 2 overviews the distributed cache architecture. Section 3 details the cache flushing technique and its associated parameters and policies. Section 4 details the cache snooping and its associated parameters and policies. Section 5 details the route borrowing. Section 6 outlines the simulation assumptions. Section 7 outlines and analyses the simulation results. Section 8 concludes the paper.

2. Distributed cache architecture The fundamental component of the distributed cache architecture is its core architecture. The core architecture does not include the cache snooping. As we detail in this section, the core architecture consists of the cache elements deployed across the networks, basic cache operations that includes saving and reusing the cached routes, and the cache flushing. Before detailing the distributed cache architecture, we briefly discuss our network and routing models. For clarity, in the rest of the

191

paper, the term ‘‘core distributed cache architecture’’ is used instead of ‘‘core architecture’’. 2.1. Network model As mentioned, the proposed distributed cache architecture is designed to scale to very large networks. We have considered a large network that is partitioned into several domains. Each domain is connected to the rest of the network through its border nodes. Domains are subject to topology aggregation, a commonly used technique to reduce the overhead traffic caused by network state updates [4]. Therefore, nodes inside a domain have detailed view of the topology and network state information of the domain, while the rest of the network has only an aggregated view of the domain. The network state and topology information is periodically updated by the switches in the network. As mentioned in Section 1, we have assumed a fault-free network model, where network links and nodes always function properly. We explore the effects of network failure on the performance of the proposed distributed cache architecture at a different stage. 2.2. Routing model We have assumed a source-based link state routing model similar to the ATM PNNI standard [3,16]. Calls arrive at the border nodes of network domains. QoS routes are computed and setup between two border nodes. All routes are bidirectional. In link state routing, network state information is periodically distributed in the network, so that each border node maintains a link state database (LSDB) containing topology and network state information. In source routing, a route is computed at the node where the call has arrived. If the route has to cross several domains, only a skeleton route is computed for those domains. When the route setup request enters a domain at a border node, the border node constructs the detailed structure of the route for that domain. Finally, we assume a bandwidth-based QoS model, so that calls request for bandwidth as their QoS parameter. This simple, yet realistic, model can represent a broad range of applications, while

192

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

helps us to focus on other aspects of the cache architecture. Route identifier

2.3. Core distributed cache architecture

Route 1

Fig. 1 shows how the core distributed cache architecture is deployed in a large network. As shown, every border node in a domain maintains a cache element. These cache elements are connected together by means of pointers (network addresses) and form the basis of the distributed cache architecture. Each cached route is stored across several cache elements in a distributed fashion and in the form of several segments. By segment, we mean the part of a route that is laid between two adjacent border nodes. Routes enter the border nodes in the form of an ingress segment and leave the border nodes in the form of an egress segment. When a route crosses a border node, the cache element at the border node stores information about both ingress and egress segments. For example, in Fig. 1, assume that upon arrival of a call at the border node A, a route has been successfully computed between the border nodes A and C. This route also passes through the border node B and is stored across the cache elements at the border nodes A, B, and C as follows. The cache element at the border node A stores the A–B segment, the cache element at the border node B stores the A–B and

C A

B

Inter-Domain Link Switch inside the domain

Domain

A cache element

Border node

Fig. 1. Deployment of the core distributed cache architecture across a network with multiple domains.

Route 2

Route state

Address list of border nodes Ingress segment topology information Egress segment topology information Route bottleneck bandwidth Time stamp

Reuse counter

Route N

Fig. 2. The internal structure of a cache element at a border node.

the B–C segments, and the cache element at the border node C stores the B–C segment. Note that the cache elements at two ends of a route store only one segment. Fig. 2 shows the internal structure of the cache element at a border node, identifying the following fields: • Route identifier. This is a number assigned to a route when it is cached. The combination of this number and the address of the source node helps to identify different segments of a route that are stored across different cache elements. Note that although the route identifier is assigned locally in the border node, where the route has been computed, the combination of route identifier and address of the border node form a unique value across the network. • Route state. A cached route can be in one of several states. For example, it can be in use by a call, be available for arriving calls, or be stale. Different cache operations set this field appropriately for correct operation of the cache architecture. • Address list of border nodes. This is a list containing addresses of all border nodes that a route has crossed. This list is used to traverse a route. It contains the addresses of source, destination, and all intermediate border nodes that a route has crossed. This list is arranged as a bi-directional linked list.

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

• Route bottleneck bandwidth. The QoS parameter used in our architecture. This is the minimum available bandwidth in an end-to-end cached route. • Topology information of ingress and egress segments. For each route, each cache stores topology information of up to two segments connected to it. The topology information is used by operations such as route selection or cache snooping. Therefore, once a route is cached, it can be used without relying on topology information stored in LSDB. The importance and novelty of the segment-by-segment caching approach is detailed in Sections 2.4 and 2.5. Here, it is worth clarifying two issues regarding the route segments:
It is essential to store topology information of both ingress and egress segments of the cached routes because cached routes can be reused from both ends. Therefore, navigation through segments may be required in both directions.
Each segment (either ingress or egress) belongs only to a specific cached route. Segments are not shared between different cached routes. In other words, each cached route is saved in the form of multiple interconnected segments. • Time stamp. This field keeps the time when the route was computed and stored in the cache for the first time. As we discuss later, it is used by a variety of time-based policies. • Re-use counter. This is a counter that is increased by one each time the cached route is re-used successfully. As a general rule, in our cache architecture, whenever an entry of the cache element at a border node has to be accessed, regardless from the type of operation (e.g., storing a segment, snooping, or flushing), the corresponding cache element is locked. After operation is finished, the cache element will be unlocked. This is to avoid multiple operations to simultaneously access a given cache element. In addition, there is a FIFO buffer associated with the cache element at every border node. This buffer is used to save the control messages sent by other cache elements dur-

193

ing different operations such as flushing and snooping.

2.4. Route caching procedure Considering our routing and network model, the process of caching a new route proceeds in parallel with the route setup procedure. Upon arrival of a call at a border node, if there is no feasible route found in the cache element of the border node, a route has to be computed ondemand. In accordance with the source-based link state routing model, based on the topology and network state information stored in its LSDB, and the selected routing algorithm, the source node computes a primary route skeleton that crosses one or more domains. From this point, caching the new route and setting it up across the network proceed simultaneously. As the route setup message crosses the border nodes of the domains, upon successful setup, each segment is stored by the cache element at the corresponding border nodes at its two ends. As route caching proceeds, the route state is set to ‘‘in-use’’ in all corresponding cache elements. This is to avoid the route to be used by another call, while it is being setup in the network. This process continues until the last segment of the route is successfully cached and the route setup message reaches the destination border node. At this stage the setup message is sent back to the source indicating a successful call setup. As this message comes back across the network, the address list of border nodes will be stored across all corresponding segments in the cache elements and the route state is set to ‘‘in-use’’ in all cache elements across the route. If the route setup procedure fails at any stage, a failure message is sent back to the source node. As this message comes back to the source node, all the corresponding segments in the cache elements across the route will be labeled as ‘‘stale’’. Note that the caching process always assumes that the cache elements at the border nodes have free space. This is because we have designed a novel cache content management/replacement technique called cache flushing that works as a background task. We detail this technique in Section 3.

194

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

2.5. Using the cached routes When a new call arrives at a border node, based on the requested bandwidth and the destination address, the cache at the border node is searched for a feasible route. If no feasible route is found in the cache, a route has to be computed. If only one feasible route is found in the cache, the route setup will be started as follows. Starting from the cache element at the source border node, where the route is found, the first segment of the route is extracted from the cache and is setup in the network. If the segment is setup successfully, the corresponding entry in the cache element is labeled as ‘‘in-use’’ and route setup proceeds to the next border node. As setup proceeds across border nodes, the address list and the route identifier fields are used to keep track and find the route information and the next border node. This process continues until the last segment of the route is setup. If at any stage the route setup fails, all corresponding cache entries will be labeled as ‘‘stale’’ and an on-demand route computing will be started. If more than one feasible route is found in the cache, one of them should be selected to go through setup process. In such situation, we use one of the following route selection policies: • Most Recently Computed (MRC). This policy aims to minimize the probability of selecting an obsolete cached route by choosing the youngest route. The principle is that the younger route has been subject to less fluctuation in the network states. • Least Frequently Used (LFU). This policy attempts to choose the least popular route, therefore increasing the availability of more popular routes for future calls. • Widest. This policy chooses the widest one among all feasible routes. Its goal is to balance the network load. It also attempts to reduce bandwidth fragmentation. • Tightest. This policy attempts to choose the best fit. It leaves wider routes for future calls with possibly higher bandwidth requirement. After a route is selected based on the adopted cache selection policy, it goes through the setup

process. When a call is finished, the allocated bandwidth across the network links will be released and all segments of the route in corresponding cache elements will be labeled as ‘‘available’’. To keep the distributed cache architecture and its management simple, we have assumed that only one call can use a cached route at one time.

3. Cache flushing As the cache size is limited, a replacement mechanism is essential for the distributed cache architecture. The replacement mechanism is required when the cache is full and a new route needs to be stored in the cache, so that the new route replaces an already cached route. The straight ondemand approach is to perform the replacement when a new route needs to be cached and the cache is full. We believe that this on-demand approach is not very suitable for our distributed cache architecture, where there is a cache element at each border node. This is because different border nodes are subject to different traffic conditions. Consequently, a cache element at a particular border node may have free space, while at the same time, another cache element at another border node is full. Therefore, we have developed a novel technique called cache flushing that works for each border node as a background task. The principle of cache flushing is to flush one or more routes out, whenever the cache element at a border node becomes full. Therefore, flushing occurs at different cache elements independently. However, each time flushing is initiated in a cache element, other cache elements across the network will also be affected. This is because of the transmission of flushing messages between cache elements. Whenever the cache element at a border node becomes full, the flushing procedure starts and proceeds as follows: 1. The cache element is locked. As mentioned in Section 2.3, whenever an entry of a cache element at a border node has to be accessed, regardless from the type of operation, the corresponding cache element is locked. After

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

operation is finished, the cache element will be unlocked. This is to avoid multiple operations to simultaneously access the cache element. 2. Based on a flushing policy, Nflush routes are selected to be flushed out (i.e., to be labeled as stale). Nflush , called the flushing size, is a flushing parameter that indicates the number of routes that should be flushed out during cache flushing. 3. For each flushed route, a message is sent to the cache elements of neighbor border nodes that hold other segments of the route. Upon receiving the flushing message, the cache elements at neighbor border nodes flush out the corresponding segments of the route. This process continues until all segments of the route are flushed out. 4. The cache element is unlocked. Two important factors in cache flushing are flushing policy and Nflush . We have considered the following flushing policies: • Least Recently Computed (LRC). This policy attempts to flush the oldest routes. An older route is more likely to be obsolete because it has been subject to more fluctuations in the network states. • Least Frequently Used (LFU). This policy attempts to flush those routes that are less likely to be used by future calls. A larger Nflush causes less frequent flushing, but more overhead traffic during each flushing. The overhead traffic is caused by transmission of flushing messages between cache elements at different border nodes. On the other hand, a smaller Nflush causes more frequent flushing, but less overhead traffic during each flushing. Adopting a very large Nflush causes a large number of cached routes to be flushed during each flushing. This may decrease the overall performance of the routing. On the other hand, adopting a very small Nflush may cause too frequent flushing and can cause instability in the cached routes. This, especially in large networks with higher propagation delays, may decrease the performance of the cache due to selecting the flushed routes whose corresponding

195

flushing messages are not yet received by all cache elements.

4. Cache snooping Changes in the network states can cause cached routes to become obsolete (i.e., unable to offer their associated bottleneck bandwidth). Selecting obsolete routes from the cache, adversely affect the routing performance. In addition, because the core distributed cache architecture stores routes in the form of interconnected segments, an end-to-end route becomes obsolete when even one of its segments is obsolete. More importantly, we have designed the distributed cache architecture to operate without relying on network state and topology information stored in LSDB at border nodes. The reason for such approach is to completely decouple the distributed cache architecture from the inaccuracy of information stored in the LSBD of the border nodes. To address these problems, we have developed a novel technique called cache snooping. The principle of cache snooping is to periodically snoop (i.e., check up) those cached routes that are more likely to be used, and keep them as up-to-date as possible, with minimum overhead. Note that snooping is not performed for segments that are being used by a call. This is because when a cached route is being used by a call, it has been set up in the network successfully. This indicates that the route is not obsolete. Assume Isnoop represents the snooping interval. Every Isnoop seconds, each cache element performs snooping only for its egress segments as follows: 1. The cache element is locked. 2. Based on a snooping policy, up to Nsnoop egress segments are selected. Nsnoop defines a limit on the number of segments that are selected for snooping. For each selected egress segment, the topology information is extracted from the cache element, and a snooping packet is sent across the segment in the network. 3. Upon receiving the snooping packet, each network switch enters the available bandwidth on its corresponding link in the packet and forwards

196

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

the snooping packet to the next switch. This continues until the snooping packet reaches the end of the segment (i.e., another border node) and is sent back. 4. At the border node, where the snooping has been initiated, the smallest bandwidth value of the segment is extracted from the snooping packet. If the smallest bandwidth value is larger than or equal to the route bottleneck bandwidth, the snooping has been successful for this segment. Otherwise snooping fails because the route cannot satisfy its associated bottleneck bandwidth. If snooping fails, the route is deleted from the cache architecture. This is done by sending messages to the cache elements that store other segments of the route. 5. The cache element is unlocked. To efficiently incorporate the cache snooping in the core distributed cache architecture, the snooping interval (Isnoop ), snooping policies, snooping size (Nsnoop ), and snooping strategies are factors that should be carefully evaluated. Isnoop presents a trade-off between snooping overhead and the accuracy of cached routes. The cache snooping can cause computing and traffic overhead. The computing overhead is caused by operations like accessing and searching the cache. The overhead traffic is caused by transmission of snooping packets and messages. A very large Isnoop causes less overhead but it cannot increase the accuracy of cached routes efficiently. On the other hand, a very short Isnoop may cause considerable snooping overhead but it can efficiently increase the accuracy of the cached routes. As mentioned, the goal of cache snooping is to increase the accuracy of the cached routes with minimum overhead. On the other hand, there is little benefit in snooping the cached routes that are not likely to be used by arriving calls. Therefore, a snooping policy is required to select only the cached routes that are more likely to be used. We have incorporated the following policies: • Most Frequently Used (MFU). This policy assumes that a route that is used more frequently in the past is more likely to be used again.

• Most Recently Used (MRU). This policy assumes that a route that is used more recently is more likely to be used again. • Widest. This policy assumes that a wider route can satisfy a broader range of requests. Therefore it is more likely to be used in the future. Nsnoop defines a limit on the number of segments that should be snooped in the cache of a border node. Based on the adopted snooping policy, up to Nsnoop segments are selected, each time snooping is initiated in a cache. Therefore, if the total number of ‘‘available’’ segments in a cache is more than or equal to Nsnoop , then Nsnoop segments will be selected. If the total number of ‘‘available’’ segments in a cache is less than Nsnoop , then all of them will be selected. A very large Nsnoop can cause significant snooping overhead, especially when a cache contains a large number of segments. On the other hand, a very small Nsnoop is not likely to increase the accuracy of cached routes efficiently. This can lead to a poor overall routing performance. Cache snooping attempts to reduce the likelihood of selecting the obsolete routes by deleting them from the cache. It causes little computing overhead but may cause some overhead traffic due to transmission of messages between cache elements of the border nodes. However, in the long term, it increases the on-demand route computing overhead. In Section 7, we evaluate the effects of the above mentioned factors on the performance of the distributed cache architecture, under a variety of conditions.

5. Route borrowing Until now, we have assumed that the cached routes are selected by arriving calls in an end-toend fashion. In other words, upon the arrival of a call at a border node, the cache element at that border node is searched only for routes that are started or ended in that border node. Although simple to implement, this approach eliminates the partial usage of end-to-end cached routes. This is clearly depicted in Fig. 3. As can be seen, the arriving call at the border node B requests a QoS

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

S3

S5

A

B S1

197

D

S2

S6

E

S4

C

F

Internal structure of the cache at the border node B at the tim e T, when a call arrives at the border node B and request a route to F:

ID Bandwidth 101 12 234 10 132 11 198 3

State “In-use” “Available” “Available” “Available”

Ingress segment A-s1-s2-B A-s1-s2-B C-s2-s3-B A-s1-s2-s3-B

E gress segment B-D B-D B-D B-D

Address list A-B -D-E A-B-D-F C-B-D A-B-D-E

The corresponding end-to-end routes for the above route IDs are as follows: 101 : A-s1-s3-B-D -s5-s6-E 234 : A-s1-s2-B-D -s5-s6-F 132 : C-s2-s3-B-D 198 : A-s1-s2-s3-B-D -s5-s4-s6-E

At the tim e T , when there are four cached routes in the netwo rk, a call arrives at the border node B, an d requests a route to bord er node F with 8 m egabits/second capacity. •

The cache at the border node B is searched and such a route is not found.

•

An on-demand route computing procedure is initiated at border node B.

•

This happens despite the fact that route 234 is available and can satisfy the requested bandwidth. It is not selected because it can be re-used only at its terminal border nodes (A and E). This decreases the cache utilization and causes unnecessary on-demand route computing load.

•

Route borrow ing allows partial usage of end-to-end cached routes.

Fig. 3. A simple scenario describing route borrowing.

route with 8 Mbits/s bottleneck bandwidth to border node F. At the same time, we see that there is a cached route between border nodes A and F that crosses border node B, satisfies the requested bandwidth by the call, and is in the ‘‘available’’ state. The arriving call, however, does not use this cached route because the route is originally computed between border nodes A and F. Consequently, a separate route has to be computed between border nodes B and F. This end-to-end approach, especially in large networks with potentially long routes, reduces the cache usage and leads to more on-demand route computing. To alleviate this, we propose a technique called route

borrowing. Route borrowing allows a call to partially borrow an end-to-end cached route instead of computing a new one, and the whole route is labeled as ‘‘in-use’’ so that it cannot be used by another call at the same time. Route borrowing is a very simple but effective way to increase the cache utilization.

6. Simulation environment The performance evaluation of our proposed distributed cache architecture is based on stochastic discrete-event simulation. The simulation

198

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

one. In all our simulation experiments, these intradomain topologies are synthesized on the domains of the MCI topology. Therefore the internal topology of each domain in the MCI topology is either type-1 or type-2. The propagation delay for intra-domain and inter-domain links is 1 and 4 ms, respectively. Although topology aggregation is not the focus of this paper, we have incorporated it into our simulation model to make our simulation scenarios as realistic as possible. In this paper, however, we have used only two well-known aggregation mechanisms: full-mesh and symmetric star. In the full-mesh method, the aggregated topology can be represented by a matrix with one entry per pair of border nodes. Thus, a domain with N border nodes has a matrix of size N 2 . The symmetric star method is based on the assumption that the distances are the same between any pair of border nodes. The cost metric for border-to-border distance is the same cost metric used in routing algorithms in the simulation. In our simulation experiments, we will consider different network configurations in terms of size, type of topology, and the aggregation method. Each of them will be classified Network(d; t; aggr), where d defines the number of domains in the MCI topology, t defines the type of intra-domain topology, and aggr defines the aggregation method. For example, Network(19, type-1, full-mesh) represents a network configuration as follows:

programs were written in C++, linked to AKAROA2, a controller of stochastic simulation [8], and run on a network of UNIX workstations. AKAROA2 transparently transforms an ordinary sequential simulation program into one for parallel execution on a network of UNIX workstations. It automatically stops the simulation when the steady-state estimates of performance measures obtain the required relative precision. In this section, we detail different aspects of our simulation environment and assumptions. All results presented in this paper have been obtained with at least 5% precision at the 95% confidence level. 6.1. Network topologies In accordance with our network model, we have selected different network topologies at interdomain and intra-domain levels. For inter-domain topology, we have adopted MCI Internet backbone, which is a real continent-wide topology used in other studies [1,2,13]. Fig. 4 shows this topology. Each node in this topology is assumed to be a domain. The internal topology and state information of these domains are subject to topology aggregation. We have considered two different intra-domain topologies, which are referred to as type-1 and type-2 topologies. Fig. 5a and b shows these topologies. The type-1 topology resembles a multicampus corporate network with several campus networks connected together with high bandwidth links. The type-2 topology is a randomly generated

• An inter-domain topology consisting of 19 domains is used, as in the complete MCI back-

18

5 7

16 17

1

15

6

3

14

8 2

11

4 OC-3 OC-12 Network Domain

13 9 10

12

Fig. 4. Inter-domain topology (MCI backbone).

19

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

199

T3 OC-3 Switch

(a)

(b)

Fig. 5. Intra-domain topologies: (a) type-1 topology––average nodal degree: 3.12; (b) type-2 topology––average nodal degree: 5.2.

bone. This is the case for all results presented in this paper. • The internal topology of each domain is a type1 (i.e., multi-campus) network. • Full-mesh aggregation method is used in each domain. 6.2. Network traffic We have incorporated the following comprehensive traffic model into our simulation environment: • Call arrival process. We assume that calls arrive according to a Poisson process. In our experiments the assumed mean arrival rate is between 10 and 100 calls/s. Each call is associated with its border nodes, i.e. a pair of nodes playing the role of its source and destination. These border nodes are selected from a uniform distribution. • Call holding time. The exponential distributions of holding times of calls have been assumed, with different mean call holding times. While the exponential distribution has been studied for voice traffic [5], to the best of our knowledge, the holding time distribution for video traffic is not clearly understood. For simplicity, we assume that both voice and video calls have exponentially distributed holding times, with the same mean call holding times. • Requested bandwidth. The diversity of the requested bandwidth is an important issue that should be taken into account when designing a large QoS capable network. This is because different applications such as Internet telephony

and real time video need different amounts of bandwidth. Thus we have considered the following broad range of applications: A. From 16 to 64 Kbits/s. This interval represents such applications as Internet telephony and videophones with different resolutions. In simulation experiments, the voice calls select a bandwidth from this interval according to a uniform distribution. B. From 1 to 5 Mbits/s. This interval represents applications such as streaming video, video conferencing and compressed video streams generated by coding schemes such as MPEG-2 with different resolutions. In simulation experiments, the video calls select a bandwidth from this interval according to a uniform distribution. • Traffic mixture. In the communication networks with heterogeneous traffic, the ratio between different types of traffic is an important factor. In accordance with our selected model for the requested bandwidth, assuming that kVoice (from 16 to 64 Kbits/s) and kVideo (from 1 to 5 Mbits/s) represent the share of voice and video calls respectively, and h is the mixing coefficient, the total traffic load, k, can be represented as follows: k ¼ hkVoice þ ð1  hÞkVideo ;

0 6 h 6 1:

6.3. Routing algorithms Different routing algorithms can behave quite differently under different network topologies and traffic conditions. We have incorporated three

200

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

different routing algorithms in our simulation environment as follows: • Widest–shortest path. This algorithm first selects all feasible routes with minimum hop counts then selects the one with maximum available bandwidth. This algorithm emphasizes on balancing the network load by selecting the least loaded (widest) route. • Shortest–widest path. This algorithm first selects all routes with maximum available bandwidth then selects the one with smallest hop count. This algorithm emphasizes on minimizing the resource consumption by selecting the route with minimum hop count. • Competitive call routing. Following [17], this algorithm applies an exponential cost metric of links, which for link L is defined as CL ¼ lðrL =bL Þ1 , where rL and bL are the occupied and total bandwidth of link L, respectively, and l is a cost parameter. Note that CL assumes the maximum value equal 1, if whole bandwidth of a link is used, and then exponentially decreases to 1=l if rL ¼ 0. The cost of a route is defined as sum of the link costs. It selects the minimum cost route provided it is feasible, which means its cost is less than a threshold. Selecting appropriate values of l and b is not a trivial task, see [17]. Following the recommendations given in [9], we have set l ¼ 1000, and b ¼ 1. 6.4. Performance measures We have considered the following performance measures: • Cache utilization ratio. The primary purpose of route caching is reusing a computed route to reduce the route computing load. This performance measure indicates how well the cached routes are being reused by arriving calls. We define it as follows: Cache utilization ratio ¼ Number of calls for which at least one feasible cached route is found =Total number of calls:

• Cache hit ratio. The accuracy of cache contents is a very important factor that can dramatically affect performance of the cache. This is because changes in the network states can cause cached routes to become stale and unable to satisfy their associated QoS parameter (bandwidth). This, even assuming a high cache utilization ratio, can degrade the routing performance. Therefore, to measure the accuracy of cache contents, we formulate cache hit ratio as follows: Cache hit ratio ¼ Number of calls that have been successfully established using a cached route =Total numbers of calls for which at least one feasible cached route is found: • Reduction in route computing load. This is the production of the cache hit ratio and the cache utilization ratio. This measure shows how much reduction in route computing load is achieved by the proposed distributed cache architecture. For example, a 0.4 for this measure means the 40% of the arrivals are routed via cache without on-demand computing. The reduction of the route computing load is defined as follows: Reduction of route computing load ¼ Cache utilization ratio  Cache hit ratio OR Reduction of route computing load ¼ Number of calls that have been successfully established using a cached route =Total number of calls: • Bandwidth blocking ratio. If all calls request the same amount of bandwidth, a lower call blocking ratio implies more QoS calls accepted into the network. However, when calls can request different amounts of bandwidth, a low call blocking ratio does not necessarily mean high efficiency. We need to make sure that the proposed distributed cache architecture does not increase the bandwidth blocking ratio. It is defined as follows:

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

Bandwidth blocking ratio ¼

Total amount of rejected bandwidth : Total amount of requested bandwidth

As outlined throughout this paper, due to the distributed nature of the proposed cache architecture, different cache operations such as snooping and flushing may cause exchange of control messages between the cache elements. Transmission of these messages may cause some overhead traffic. Here, we have not attempted to quantify and measure this overhead traffic for several reasons. First, we have designed the distributed cache architecture to minimize the requirement for exchanging control messages. Second, these control messages do not carry much information and therefore are very small. Third, the exact format and length of such messages are technology-specific (e.g., ATM or TCP). For example, different protocols may put extra header and/or use such techniques as compression. Such factors influence the actual bandwidth consumed by control messages.

7. Performance evaluation results We outline and discuss our simulation results as follows. In Section 7.1, we study the core distributed cache architecture. In Section 7.2, we study the impact of cache snooping in reducing the route computing load. We also investigate the influence of different snooping parameters and policies and try to find optimal working range for them. In Section 7.3, we outline how cache snooping increases the tolerance of routing. In Section 7.4, we show how route borrowing can significantly increase the overall performance of the distributed cache architecture. 7.1. Core distributed cache architecture Our investigations reveal that the size of the cache elements play an influential role in the performance of the distributed cache architecture. A

201

small cache size always leads to a relatively low cache utilization ratio. On the other hand, we continuously observe a limit for the cache size, after which, the cache utilization does not increase significantly. Although this limit changes under different conditions, we observe it falls somewhere between 70 and 100. We have selected a cache size of 100 for the rest of our studies. This means that each cache element at the border nodes can have up to 100 entries. This will let us get the best out of the cache utilization ratio, while minimizing the memory consumption at the border nodes. As an example, Fig. 6 displays one of our experiments on the effects of the size of the cache elements. If the size of the inter-domain network is constant, we observe that having larger cache elements initially results in a higher cache utilization ratio up to a certain point, after which increasing the size of the cache elements has less effect on the cache utilization ratio. This is followed by a final settlement or a very small growth in the cache utilization ratio. This is because increasing the size of the cache elements initially provides the opportunity for caching a larger number of successfully computed routes so that arriving calls are more likely to find a feasible route in the distributed cache architecture. We also observe that considering the same intra-domain topology, in a smaller network, the cache utilization ratio increases faster and settles with a smaller size for cache elements. However, the overall cache utilization ratio is larger than that achieved in a bigger network. This is because in a smaller network, new arrivals can choose their source and destination from a smaller sample space. This increases the likelihood of reusing the cached routes. In Fig. 7, we study the general effectiveness of the proposed distributed cache architecture in reducing the route computing load. Note that route borrowing has not been incorporated yet. Under the voice-dominated traffic, the route computing load has been reduced to between 26.7% and 10.9%, depending on the arrival rate and the adopted route selection policy. Assuming the same conditions, under video-dominated traffic, the route computing load has been reduced to between 18% and 2.4%. One sees that the distributed cache architecture is less effective at higher loads (i.e., at

202

M. Rezvan et al. / Computer Networks 44 (2004) 189–209 0.55

Cache utilization ratio

0.45

0.35

Network (19,type-2,full-mesh) Network (19,type-2,star) Network (15,type-2,full-mesh) Network (15,type-2,star) Network (10,type-2,full-mesh) Network (10,type-2,star) Network (5,type-2,full-mesh) Network (5,type-2,star)

0.25

0.15

0.05 10

20

30

40

50

60

70

80

90

100

110

120

Size of the cache elements Fig. 6. Effect of size of the cache elements on the cache utilization ratio.

MRC, 20%voice, 80%video MRC, 80%voice, 20%video LFU, 20%voice, 80%video LFU, 80%voice, 20%video Widest, 20%voice, 80%video Widest, 80%voice, 20%video Tightest, 20%voice, 80%video Tightest, 80%voice, 20%video

Reduction in route computing load

0.26

0.21

0.16

0.11

0.06

0.01 10

20

30

40

50

60

70

80

90

100

Arrival rate Fig. 7. Reduction in the route computing load (without route borrowing) for different route selection policies and different traffic mixtures. Network(10, type-2, full-mesh), LRC flushing policy, flushing size ¼ 2.

higher arrival rates or under the video-dominated traffic). This is because at higher loads, the network state is more variable so that the cached routes become obsolete faster and cache hit ratio decreases. In Section 7.2, we will show that the cache snooping improves the performance of the

distributed cache architecture at higher loads. In addition, in Section 7.4, we show that route borrowing significantly improves the performance of the distributed cache architecture. Fig. 7 also indicates that the MRC selection policy constantly offers the best performance. This is because MRC

(a)

0.57

Reduction in route computing load

Cache hit ratio&Cache utilization ratio

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

0.47 Cache hit ratio, Shortest-widest Cache hit ratio, Widest-shortest Cache hit ratio, Competitive Cache utilization, Shortest-widest Cache utilization, Widest-shortest Cache utilization, Competitive

0.37

0.27 10

20

30

40

50

60

70

80

90

Arrival rate

(b)

Shortest-widest Widest-shortest Competitive

0.25

0.15

0.05 10

100

203

20

30

40

50

60

70

80

90

100

Arrival rate

Fig. 8. Effects of routing algorithms on the performance of the distributed cache architecture.

policy attempts to select the youngest (i.e., most recently computed) cached routes. The diagrams in Fig. 8a and b show the effect of the adopted routing algorithm in the network on the performance of the distributed cache architecture. We observe that the choice of routing algorithm does not affect the cache utilization ratio, while only slightly affects the cache hit ratio. This is because the cache utilization ratio is mainly affected by the number and variety of the cached routes. On the other hand, there seems to be a relationship between the adopted routing algorithm and the cache hit ratio. The shortest–widest routing algorithm achieves the best hit ratio, especially at lower arrival rates. This routing algorithm attempts to minimize the resource consumption by selecting the routes with a minimum hop count. A shorter route is less likely to become obsolete by changes in the network state. Fig. 8b shows that the choice of routing algorithm has only minimum overall effect on the performance of the distributed cache architecture. This is an advantage because the distributed cache architecture can be incorporated in different networking technologies that may use different routing algorithms. Fig. 9a presents the influence of the flushing policies and the flushing size (NFlush ) on the performance of the distributed cache architecture. We observe that under both voice and video-dominated traffic, the LRC flushing policy offers the best performance. From Fig. 9a, one also sees that

under video-dominated traffic, the choice of flushing policy has a more significant impact on the performance of the distributed cache architecture. The reason is under video-dominated traffic, the choice of flushing policy can greatly affect the cache hit ratio because of the higher network state fluctuations. In this case, the LRC policy leads to a higher cache hit ratio, especially at larger flushing sizes. The higher cache hit ratio means a better performance for the distributed cache architecture. Finally we observe that the performance of the distributed cache architecture gradually decreases, when we increase the flushing size. This is because a large flushing size leads to deletion of many routes (some of them can be useful ones) each time a flushing occurs in a cache element. This reduces the cache utilization ratio, which is shown in the form of lower overall performance. This indicates that a large flushing size is not a good idea. Fig. 9b presents the influence of cache flushing on the network bandwidth blocking ratio. One sees that the bandwidth blocking ratio increases by increasing the flushing size. This backs our previous conclusion from Fig. 9a. Here, we can conclude that a small flushing size should be used for cache flushing to avoid an excessive bandwidth blocking ratio. Finally, we observe that the LRC flushing policy is quite sensitive to the flushing size, especially when the network state update interval is longer. This is because a longer network state update interval reduces the accuracy of the

204

M. Rezvan et al. / Computer Networks 44 (2004) 189–209 0.45 LRC, 80% voice, 20% video LRC, 20% voice, 80% video LFU, 80% voice, 20% video LFU, 20% voice, 80% video

0.25 0.2

bandwidth blocking ratio

Reduction in route computing load

0.3

0.15 0.1 0.05

0.41 0.37 0.33 0.29 0.25 0.21 0.17 0.13 0.09 0.05 0.01

0 2

4

6

8

(a)

10 12 N Flush

14

16

18

LRC, update interval=30 seconds LRC, update interval=180 seconds LFU, update interval=30 seconds LFU, update interval=180 seconds

20

2

4

6

8

(b)

10 12 N Flush

14

16

18

20

Fig. 9. Effects of the cache flushing policies on the performance of the distributed cache architecture. MRC route selection policy, Network(19, type-2, full-mesh).

network state information so that fewer routes can be successfully computed and cached. We suggest a flushing size of 2, coupled with LRC policy can offer the best performance for the cache flushing with minimum impact on the bandwidth blocking ratio. 7.2. Influence of cache snooping on route computing load In Section 7.1, we showed that the core distributed cache architecture is quite effective in reducing the route computing load. However, as

shown in Fig. 7, highly variable network state at higher loads decreases the cache hit ratio (cached routes or segments become rapidly obsolete) which causes the core distributed cache architecture to perform poorly. Fig. 10a and b demonstrates how the cache snooping improves the performance of the core distributed cache architecture. In Fig. 10a, one sees that the cache snooping significantly increases the cache hit ratio. As it shows, the core distributed cache architecture achieves a cache hit ratio of between 40% and 30% depending on the call arrival rate. Assuming the same conditions and widest snooping policy, by incorporating the

1

Cache hit ratio

0.8

Reduction in route computing load

Network(10,type-2,full-mesh), No snooping Network(10,type-2,full-mesh), MFU Network(10,type-2,full-mesh), MRU Network(10,type-2,full-mesh), Widest

0.9

0.7 0.6 0.5 0.4 0.3

(a)

0.31 0.26 0.21 0.16 0.11 0.06 0.01

10

20

30

40

50

60

Arrival rate

70

80

90

100

(b)

Network(10,type-2,full-mesh),No snooping Network(10,type-2,full-mesh),MFU Network(10,type-2,full-mesh),MRU Network(10,type-2,full-mesh),Widest

0.36

10

20

30

40

50

60

70

80

90

100

Arrival rate

Fig. 10. Impact of cache snooping on the performance of the distributed cache architecture. Snooping interval ¼ 30 s, snooping size ¼ 6, 80% video, MRC selection policy, LRC flushing policy, flushing size ¼ 2, Network(10, type-2, full-mesh).

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

cache snooping in the core distributed cache architecture, cache hit ratio between varies between 75% and 56%. The increased cache hit ratio means that the distributed cache architecture can reduce the route computing load more effectively. This is shown in Fig. 10b. In this experiment, the widest snooping policy performs best because majority of the cached routes belong to video calls with high bandwidth requirements. We have not shown the cache utilization ratio because it is not affected by the cache snooping. The key to efficiently integrate the cache snooping into the distributed cache architecture is to define the optimal working range for different snooping parameters. Fig. 11 shows the influence of snooping interval on the cache hit ratio. In Fig. 11, we have assumed an arrival rate of 80 calls/s so that the network state is highly variable. The general observation is that under all snooping policies and traffic mixtures, a long snooping interval decreases the cache hit ratio. Under videodominated traffic, the cache hit ratio is more sensitive to the snooping interval, because network states change more rapidly due to the allocating and releasing of larger amounts of bandwidth across the network links for video calls. In general, a snooping interval of 30 s maximizes the cache hit ratio.

Fig. 12 presents the influence of snooping size on the cache hit ratio. One sees that under all conditions and for all snooping policies, by increasing the snooping size, initially the cache hit ratio increases sharply up to a certain point, after which it increases only trivially. A larger snooping size means that more segments are selected for snooping. Initially, a very small snooping size (e.g., 2) cannot effectively increase the accuracy of the caches at the border nodes because many segments that are likely to be used in the future are simply ignored during cache snooping. Therefore, as shown in Fig. 12, with a very small snooping size, the choice of snooping policy does not have a significant impact on the cache hit ratio. Increasing the snooping size to larger values causes the ignored segments to be included in the snooping procedure. This leads to a sharp increase in the cache hit ratio. In this situation, the choice of snooping policy is expected to show a more significant difference in the obtained cache hit ratio. This phenomenon is shown in Fig. 12. After this stage, increasing the snooping size has only a minimal effect on the cache hit ratio. This is because the segments are sorted, based on the adopted snooping policy, in a descending fashion so that a large snooping size selects many segments of little importance.

0.8

0.5

0.4

0.75 0.65 0.55 0.45

0.3

0.2 30

0.85

Cache hit ratio

Cache hit ratio

0.6

MFU, 80 calls/second MRU, 80 calls/second Widest, 80 calls/second MFU, 20 calls/second MRU, 20 calls/second Widest, 20 calls/second

0.95

MFU, 80% voice, 20% video MRU, 80% voice, 20% video Widest, 80% voice, 20% video MFU, 20% voice, 80% video MRU, 20% voice, 80% video Widest, 20% voice, 80% video

0.7

205

0.35

60

90

120 150

180 210

240

270 300

Snooping Interval (seconds)

Fig. 11. Impact of snooping interval on the cache hit ratio. Network(19, type-2, full-mesh).

2

4

6

8

10

12

14

16

18

20

Snooping size

Fig. 12. Impact of snooping size on the cache hit ratio. Network(19, type-2, full-mesh).

206

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

7.3. Influence of cache snooping on routing tolerance

1. The distributed cache architecture stores the detailed topology and network state information for each cached route in the form of several inter-connected segments so that the distributed cache architecture is completely de-coupled from the LSDB at the border nodes. In this way, once a feasible route is found in the cache, the corresponding route setup procedure can proceed without relying on the network state and the topology information stored in the LSDB of the border nodes. Therefore, the distributed cache architecture does not suffer from inaccurate network state information caused by long state update intervals. Furthermore, the novel segment-by-segment approach in storing an end-to-end route in the cache means that the cached routes do not suffer from the inaccuracy caused by topology aggregation. 2. Cache snooping alleviates the effects of the changes in the network states so that the accuracy of the cached routes is significantly increased. Cache snooping is performed in a distributed fashion by the caches at the border nodes using local segment information so that it does not rely on information stored in the LSDB of the border nodes. In other words, the distributed cache architecture is completely decoupled from topology and network state information stored in the LSBD of the border nodes. Fig. 13 shows how cache snooping helps increase the tolerance of routing in the presence of inaccurate network state information. It is important because a lower blocking ratio means that more calls can simultaneously exist in the network. For example, in the absence of the distributed cache architecture, a state update interval of 300 s leads to a bandwidth blocking ratio of about 16%. At the same time, under a cache snooping interval of 30 s, coupled with the widest snooping policy, a state update interval of 300 s leads to a bandwidth blocking ratio of about 6%. It is obvious that using the right snooping interval and snooping policy,

No caching MFU, snooping interval=90seconds MRU, snooping interval=90seconds Widest, snooping interval=90seconds MFU, snooping interval=30seconds MRU, snooping interval=30seconds Widest, snooping interval=30seconds

0.19

Bandwidth blocking ratio

The distributed cache architecture can increase the tolerance of the routing for two reasons:

0.21

0.17 0.15 0.13 0.11 0.09 0.07 0.05 030. 30

60

90

120

150

180

210

240

270

300

State update interval (seconds)

Fig. 13. Impact of cache snooping on the bandwidth blocking ratio. Network(19, type-2, full-mesh), 80% video.

cache snooping increases the tolerance of the routing in the presence of inaccurate network state information (i.e., a long state update interval). 7.4. Influence of route borrowing on route computing load In Fig. 14a, we explore the impact of route borrowing on the cache utilization ratio under different traffic mixtures. One sees that under videodominated traffic, route borrowing significantly improves the cache utilization ratio. For example, in this particular experiment, without route borrowing and under video-dominated traffic, the cache utilization varies between 44.9% and 16.8%, depending on the call arrival rate. Under the route borrowing, the cache utilization ratio varies between 74.3% and 58.8%. Similar improvement in cache utilization can be seen under the voicedominated traffic. Note that route borrowing does not affect the cache hit ratio. This is because cache hit ratio reflects the accuracy of the cached routes rather than how well they are used by arriving calls. As shown in Fig. 14b, the increase in the cache utilization ratio helps the distributed cache architecture to reduce the route computing load much more effectively. We observe that when route borrowing is used, under the voice-dominated traffic, the route computing load is reduced between 67% and 56%. Similarly, under the videodominated traffic, the route computing load is

M. Rezvan et al. / Computer Networks 44 (2004) 189–209 1 0.9

Cache utilisation ratio

0.8

Reduction in route computing load

80% voice, No Borrowing 80% voice, Borrowing 80% video, No Borrowing 80% video, Borrowing

0.7 0.6 0.5 0.4 0.3 0.2 0.1 10

(a)

20

30

40

50

60

70

80

90

100

Arrival rate (calls/second)

(b)

0.1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 0.55 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 10

207

80% voice, No Borrowing 80% voice, Borrowing 80% video, No Borrowing 80% video, Borrowing

20

30

40

50

60

70

80

90

100

Arrival rate (calls/second)

Fig. 14. Reduction in the route computing load, under route borrowing. Network(10, type-2, full-mesh), LRC flushing policy, flushing size ¼ 2.

reduced between 47% and 36%. One sees that the route borrowing significantly improves the performance of the distributed cache architecture. These results, coupled with inherent simplicity of route borrowing, prove the merits of route borrowing.

8. Conclusions In this paper, we have introduced a distributed cache architecture to reduce the route computing load caused by the execution of the QoS routing algorithms, assuming bandwidth-based QoS requirements. Considering the distributed nature of cache architecture, to minimize the added complexity to the network, simplicity is a key design issue in our approach. Therefore, we have designed and incorporated simple yet efficient algorithms and techniques. The distributed cache architecture is easily scaled to large hierarchical networks. The cached routes are stored in the form of multiple interconnected segments across several cache elements. Cache snooping was proposed as a distributed technique to alleviate the effects of rapid changes in the network states so that the route computing load is reduced more efficiently. In addition, cache snooping helps to increase the

tolerance of QoS routing in the presence of inaccurate network state information caused by long network state update intervals. This means that the proposed distributed cache architecture can also reduce the overhead traffic caused by the frequent distribution of the network state information, while achieving a good performance. Also route borrowing was introduced as a simple but effective technique to improve the performance of the distributed cache architecture. While cache snooping improves the cache hit ratio, route borrowing significantly increases the cache utilization ratio. We considered realistic network topologies, routing algorithms, traffic models, and topology aggregation techniques to show that our solution is deployed in real life large networks. Our findings can be summarized as follows: 1. The distributed cache architecture is quite effective in reducing the route computing load. For example, in a network with 10 domains and under voice-dominated traffic, assuming route borrowing is used, we showed that the distributed cache architecture reduces the route computing load between 67% and 56%, depending on the arrival rate. 2. The size of the cache elements affects the performance of the architecture. Our studies

208

3.

4.

5.

6.

7.

8.

M. Rezvan et al. / Computer Networks 44 (2004) 189–209

suggested that between 70 and 100 entries per cache element offer good performance. The route selection policy also influences the performance, with the MRC route selection policy being the best. The choice of topology aggregation and routing algorithms have only a minimal impact on the performance of the core distributed cache architecture. This indicates that the distributed cache architecture can be incorporated in different networking technologies and standards that may use different routing algorithms. The cache flushing affects both the cache hit ratio and the cache utilization ratio. A small flushing size of about 2, coupled with the LRC flushing policy maximizes the performance of the core distributed cache architecture. Cache snooping effectively contributes to reducing the on-demand route computing load. We showed that cache snooping significantly increases the cache hit ratio. The performance of the different snooping policies depends on the traffic mixture. Under voice-dominated traffic, the MRC snooping policy performs best, while under video-dominated traffic the widest snooping policy is the best. A reasonably short snooping interval is desirable. Studies suggest that a snooping interval of about 30 s is adequate. Neither a very small nor a very large snooping size is adequate. Investigations suggest a snooping size of 6. Cache snooping also increases the tolerance of the routing in the presence of inaccurate network state information caused by long network state update intervals. This is reflected by the lower bandwidth blocking ratio achieved by cache snooping. Route borrowing is a very promising technique to increase the performance of the distributed cache architecture. We showed that it can significantly increase the cache utilization ratio.

We currently work on several novel techniques that can be coupled to the core distributed cache architecture to increase its performance. In this paper, we considered a source-based routing model similar to that used in ATM standards. The Internet and IP-based networks have adopted hop-

by-hop routing. In addition, the popularity of the Internet makes it a potential medium for QoS applications and therefore QoS routing. The integration of our distributed cache architecture into IP-based networks needs further research and investigation. Finally, in this paper, we assumed a fault-free network. In reality, network links and routers can face a variety of faults (e.g., link failure). This can affect the proper operation of the proposed distributed cache architecture and needs further investigation.

References [1] G. Apostolopoulos, S. Tripathi, On reducing the cost of on-demand QoS path computation, in: Proceedings of International Conference on Network Protocols, October 1998. [2] G. Apostolopoulos, R. Guerin, S. Kamat, S. Tripathi, Quality of service based routing: a performance perspective, in: Proceedings of ACM SIGCOMMÕ98, September 1998. [3] ATM Forum, Private Network–Network Interface specification version 1.0, Technical Report af-pnni-0055.000, ATM Forum, March 1996. [4] B. Awerbuck, Y. Du, B. Khan, Y. Shavitt, Routing through networks with hierarchical topology aggregation, Journal of High Speed Networks 7 (17) (1998) 57–73. [5] V.A. Bolotin, Modeling call holding time distributions for CCS network design and performance analysis, IEEE Journal of Selected Areas in Communications 12 (3) (1994) 433–438. [6] E. Crawley, R. Nair, B. Opalan, H. Sandick, A framework for QoS-based routing in the Internet, IETF Internet Draft, July 1997. [7] I. Cidon, T. Hsiao, A. Khamisy, A. Parekh, R. Rom, M. Sidi, OPENET: an open and efficient control platform for ATM networks, in: Proceedings of INFOCOMÕ98, San Francisco, CA, March 1998, p. 824. [8] G.C. Ewing, K. Pawlikowski, D. Mcnickle, Akaroa2: exploiting network computing by distributed stochastic simulation, in: Proceedings of the European Simulation Multi Conference, ESMÕ99, Poland, Warsaw, 1999, pp. 175–181. [9] R. Guerin, A. Orda, QoS-based routing in networks with inaccurate information; theory and algorithms, in: Proceedings of INFOCOMÕ97, 1997. [10] F. Hao, E.W. Zegura, On scalable QoS routing: performance evaluation of topology aggregation, in: Proceedings of INFOCOMMÕ2000, 2000. [11] W.C. Lee, Topology aggregation for hierarchical routing in ATM networks, ACM Computer Communication Review 25 (2) (1995) 82–92.

M. Rezvan et al. / Computer Networks 44 (2004) 189–209 [12] H. Lorenz, A. Orda, QoS routing in networks with uncertain parameters, in: Proceedings of INFOCOMMÕ98, 1998. [13] Q. Ma, P. Steenkiste, On path selection for traffic with bandwidth guarantees, in: Proceedings of International Conference on Network Protocols, Atlanta, GA, October 1997. [14] Orda, A. Sprintson, QoS routing: the precomputing perspective, in: Proceedings of INFOCOMÕ2000, 2000. [15] M. Peyravian, A.D. Kshemkalyani, Network path caching: issues, algorithms and a simulation study, Computer Communications 20 (1997) 605–614. [16] A. Shaikh, J. Rexford, K.G. Shin, Evaluating the impact of stale link state on quality-of-service routing, IEEE/ACM Transactions on Networking 2 (9) (2001) 162–176. [17] L. Zhang, M. Andrews, S. Bhatt, K. Krishnan, A performance comparison of competitive on-line routing and state-dependent routing, in: Proceedings of GLOBECOMÕ97, 1997, pp. 1813–1819. M. Rezvan is a Lecturer (Assistant Professor) in the School of Computer Science and Engineering, the University of New South Wales, Sydney, Australia. He received his Ph.D. in Computer Science from University of Canterbury in New Zealand. He also has several years of industrial experience in software development.

209

K. Pawlikowski is an Associate Professor in Computer Science at the University of Canterbury, Christchurch, New Zealand. He received his Ph.D. in Computer Engineering from the Technical University of Gdansk, Poland. He is the author of over 110 research papers and four books, given over 100 invited lectures and talks at over 70 universities and research institutes in Asia, Australia, Europe, and North America. His research interests include stochastic simulation, performance modeling of telecommunication networks, traffic modeling, and distributed processing. He has served as a research fellow of Humboldt Foundation (Germany) in 1983 and 1999.

H. Sirisena is an Associate Professor in the School of Electrical and Electronics Engineering at the University of Canterbury, Christchurch, New Zealand. He received his Ph.D. from the Cambridge University, Cambridge, England. He has held many visiting positions in Universities in Australia, Asia, and North America. His research interests include communication networks and protocols, soft computing, and control systems.