A Rearrangeable Algorithm for the Construction of Delay ... - CiteSeerX

A Rearrangeable Algorithm for the Construction of Delay-Constrained Dynamic Multicast Trees Sriram Raghavan Dept. of Computer Science Stanford University, Stanford, CA 94305 USA ([email protected]) G. Manimaran Dept. of Electrical and Computer Engineering Iowa State University, Ames, IA 50011 USA ([email protected]) C. Siva Ram Murthy Dept. of Computer Science and Engineering, Indian Institute of Technology, Madras 600 036, INDIA ([email protected])

Abstract

With the proliferation of multimedia group applications, the construction of multicast trees satisfying Quality of Service (QoS) requirements is becoming a problem of prime importance. Many of the multicast applications (such as video broadcasts and teleconferencing) require the network to support dynamic multicast sessions wherein the membership of the multicast group changes with time. In this paper, we propose and evaluate an algorithm called CRCDM (Controlled Rearrangement for Constrained Dynamic Multicasting) for on-line update of multicast trees to adjust to changes in group membership. The CRCDM algorithm is based on a concept called Quality Factor (QF) that represents the usefulness of a portion of the multicast tree to the overall multicast session. When the usefulness of a particular region of the tree drops below a threshold, a rearrangement technique is used to suitably modify the tree. Our algorithm aims to satisfy the delay-constraints of all current group members, at the same time minimizing the cost of the constructed tree. We compare the performance of our algorithm, by simulation, with that of an o-line Steiner heuristic; with ARIES [2], a recently published algorithm for on-line update of unconstrained trees; and with the algorithm proposed in [10] for on-line update of delay-constrained trees. The simulation results indicate that our algorithm provides excellent cost-competitiveness that is better than that provided by the algorithm described in [10], minimizes changes in the multicast tree after each update, and performs favorably even when compared with the unconstrained ARIES heuristic.

Keywords: Multicast routing, On-line Steiner problem, Dynamic multicast groups, Rearrangement

algorithm, QoS, Group communication

 This work was done when the authors were at the Dept. of Computer Science and Engineering, Indian Institute of Technology, Madras, India.

1

1 Introduction With the growth of interest in exible multicast communication networks supporting a wide class of applications, the importance of routing techniques for multicast connections is being emphasized. Multicast can be loosely de ned as the ability to logically connect a subset of nodes in the network. A summary of the multicast routing problem is given in [29] and [26]. A multicast group is a collection of nodes that are the destinations of the same sequence of messages. These messages may originate at one or more source nodes. Based on the nature of group membership, multicast groups are classi ed into two categories :

 Static Groups : those in which membership remains unchanged throughout the group's lifetime.  Dynamic Groups : those in which nodes can leave and/or join the group dynamically. It has been established that determining an optimal multicast tree for a static multicast group can be modeled as the NP-complete Steiner problem in networks [11] and [29]. Consequently, a number of good, inexpensive heuristics for the Steiner problem have been proposed and reviewed extensively [3], [25], [17], [29], [11], [22]. There have also been attempts to create multicast trees without resorting to the Steiner-tree based model. Some important alternative approaches include DVMRP [7], PIM [6], and core-based trees [1]. These approaches are suitable for datagram environments such as the Internet in which the routes taken by multicast packets may vary and where minimization of algorithm overhead takes precedence over minimization of tree cost. However, Steiner tree heuristic approaches apply to virtual-circuit environments such as ATM networks, in which low multicast tree cost1 is of more interest. An additional dimension to the multicast routing problem is the need to construct trees that will satisfy the Quality of Service (QoS) requirements of modern networked multimedia applications. One of the most common QoS constraints is an upper bound on the delay between the transmission and receipt of a message. The problem of constructing delay-constrained low-cost multicast trees for routing to static multicast groups has been addressed in [15], [16], and [20]. In this paper, we address the problem of modifying such a delay-constrained multicast tree when new nodes enter or existing members leave the multicast group (i.e., the problem of constructing delay-constrained multicast trees for routing to dynamic multicast groups). The rest of this paper is organized as follows. In Section 2, we describe some of the existing approaches to the on-line multicast problem. The formal problem speci cation and the proposed CRCDM algorithm are described in Section 3. In the same section, we also indicate how to modify the algorithm to accommodate individual delay constraints for each multicast group member. Section 4 presents and discusses the simulation results. Finally, Section 5 concludes the paper highlighting the advantages of our algorithm.

2 Background The problem of updating a multicast tree to accommodate addition or deletion of nodes to the multicast group is known as the on-line multicast problem in networks. The graph-theoretic version of this problem, known as the on-line Steiner problem in networks is NP-complete [9] and has been addressed in [28] and [12]. In the extreme case, the on-line multicast problem can be solved as a sequence of static multicast problems, by rebuilding the tree at each stage using a static Steiner heuristic. However, 1

cost of a tree is the sum of it's edge costs.

2

this approach is too expensive and is unsuitable for ongoing real-time multicast sessions which cannot tolerate the disturbances caused by excessive changes in the multicast tree after each addition or deletion. Much of the previous work on the on-line multicast problem has addressed only the issue of costminimization. (In section 2.1, we review some of the solutions that come under this category) However, as mentioned in the previous section, delay-constraint is a very common and important QoS constraint for a large number of multimedia applications. Therefore, a version of the on-line multicast problem that factors in delay-constraint will nd wide application in a number of contexts. We refer to this delay-constrained version of the problem as the constrained on-line multicast (COLM) problem. To the best of our knowledge, the rst, and till now, only work that has simultaneously addressed the twin issues of dynamic group membership and delay-constraint satisfaction is the algorithm proposed in [10]. In section 2.2, we review this algorithm and highlight some of it's shortcomings. We also indicate how our algorithm overcomes these drawbacks to provide multicast trees with lower average costs.

2.1 Existing Approaches-Unconstrained Case

The on-line multicast problem was rst presented by Waxman [26] and has since been addressed in [12], [28], [14], and [2]. Waxman, in the rst paper, divides on-line heuristics into two categories : those that allow recon guration (or rearrangement) of the tree and those which do not. In the latter case, as new nodes are added to or removed from a group, rearrangement of existing routes is not allowed, i.e., addition of edges during node removal or deletion of edges during node addition is not allowed. Waxman and Imase in [12] have investigated bounds for both kinds of heuristics. Considering only addition of members, they have shown that the lower bound for the cost competitiveness (de ned as the ratio of cost of a multicast tree to that of an optimal tree for the same set of members) of any non-rearrangeable heuristic is 1 + 21 blog2 (n ? 1)c where n is the number of members added to the group up to that point. Waxman and Imase have also shown that no such nite bound exists if deletions are also considered. A rearrangeable heuristic, on the other hand, can have a nite bound for cost competitiveness taking into consideration both addition and deletion of nodes.

2.1.1 GREEDY Algorithm This simple non-rearrangeable heuristic was proposed by Waxman in [26] with an aim to minimize the perturbation to the existing tree. To add a node u to an exiting multicast group, a closest node v already in the connection is chosen and u is attached to v via the least cost path. For a delete request, if the node being removed is a leaf node, then the branch of the tree supporting only that node is pruned. For the case of non-leaf nodes, no action is taken.

2.1.2 Edge-Bounded Algorithm (EBA)

This rearrangeable heuristic [12] works by enforcing an upper bound on the distance between nodes in the tree after each update operation. EBA works on the basis of distance graphs2 . EBA is also A distance graph is a complete graph on the same set of nodes as the original graph with cost of edge (i; j ) equal to the cost of the shortest path between i and j in the original graph. 2

3

parameterized by a value  which decides the bound that the algorithm is trying to enforce. It is shown in [12] that the cost of the tree produced by EBA is at most 4 times that of an optimal Steiner tree for the same group.

2.1.3 GSDM Algorithm The Geographic Spread Dynamic Multicast (GSDM) algorithm proposed in [14] is a rearrangeable heuristic that is based on the notion of the geographic spread of a tree. Deletions are handled as in GREEDY. For addition of members, GSDM identi es three key nodes in the existing tree as follows : Let A be the node which is to be added to the multicast group. Let B be the current multicast group member that is closest to A. Let C and D be the two nearest nodes to A which are neighbors on either side of B in the current tree. Then, the three key nodes involved in the attachment of A are B , C , and D. GSDM compares the cost of four possible types of connections involving A, B , C , and D. The type of connection that minimizes the cost (if there is a tie, it is resolved in favor of the type that results in greater geographic spread) is then chosen.

2.1.4 ARIES Heuristic The recently proposed ARIES heuristic [2] aims to combine the computational simplicity of GREEDY with the better competitiveness possible using a rearrangeable heuristic. ARIES works by monitoring the accumulated damage to the multicast tree within local regions of the tree as members are added to or deleted from the group. When the damage to a region of the tree exceeds a threshold, then a simple rearrangement heuristic is used to recreate the tree.

2.1.5 Virtual Trunk Dynamic Multicast (VTDM) Algorithm

The non-rearrangeable VTDM algorithm proposed in [18] is based on the following principle : \In the dynamic multicast routing problem, if a static multicast algorithm is applied to re-construct the tree for each request, some nodes and links may be frequently used. If a dynamic multicast routing algorithm can use these nodes and links, then it could conceivably construct low-cost trees matching the cost-performance of the static multicast algorithm". In order to identify such nodes and links, the authors de ne the notion of a Virtual Trunk(VT), which is a tree of the underlying network. The nodes of the VT are determined using a weight function3 that associates a positive real number with each node. The VT, for a given connection, is constructed by applying the KMB algorithm [17] to a selected set of nodes. It is then used as a template for modifying the tree in response to changes in group membership. New nodes are attached to the multicast tree by determining the least-cost path connecting the node to the Virtual Trunk. Node deletions are handled as in GREEDY.

2.2 Existing Approaches-Constrained Case

In this section, we will rst brie y describe the algorithm proposed in [10] and later, compare the approach taken in [10] with our approach. 3 The weight of a node is de ned to be the number of shortest paths (between any two nodes of the network) passing through that node.

4

2.2.1 Lagrangian-Relaxation Based Algorithm

The algorithm proposed in [10] (hereafter referred to as LRA4 ) handles deletion by merely pruning unnecessary branches from the tree (as in GREEDY). The problem of adding a new node to a multicast tree is reduced, through a suitable modi cation, to the problem of determining a delay-constrained minimum cost path between the new node and the source. This modi ed problem is then solved using a heuristic that is based on the Lagrangian-relaxation method frequently used to solve NP-hard problems.

2.2.2 Comparison Between the Two Approaches

The fundamental problem with the LRA algorithm is that no substantial action is taken to handle deletion of nodes from the multicast group, if the deleted node is a non-leaf node. The authors justify this decision based on the fact that this helps to avoid disturbance to the existing connection. (In fact, all the simulation results presented in [10] were generated without using any node deletion requests.) However, this simplistic approach to node deletion can seriously degrade the quality of the tree, since certain portions of the tree could become irrelevant due to successive deletions in the same region. By removing these unwanted portions of the tree, it will become possible to substantially reduce the cost of the tree. On the other hand, if each deletion triggers an aggressive response from the algorithm resulting in large modi cations to the existing tree, the performance of the connection will be very poor. Hence, there is a tradeo between minimizing cost and reducing the modi cations to the tree. The LRA algorithm does not provide any mechanism for exploiting or balancing this tradeo. We further explore this issue in section 3.2 and describe how our algorithm facilitates this tradeo through the notion of a Quality Factor. Through simulation, we will show, in section 4, that when both node addition and node deletion requests are considered, our algorithm achieves much better cost performance than LRA and adapts much better to tight delay-constraints.

3 Proposed CRCDM Algorithm

In this section, we will rst formally state the COLM problem and then proceed to describe our solution.

3.1 Problem Formulation Network Model

The network is modeled as a simple, undirected, connected graph G = (V; E ), where V is the set of nodes and E is the set of edges. An edge e 2 E connecting nodes u and v will be denoted by (u; v). Each edge e has two non-negative metrics associated with it : a cost C (e) and a delay D(e). A path P = (v0 ; v1 ; v2 ;


; vn ) in the network, has two associated characteristics : Cost C (P ) = Delay D(P ) = 4

X C (v ; v

n?1

i=0 n?1

Lagrangian-Relaxation Algorithm.

5

i i+1 )

X D(v ; v i=0

i i+1 )

Similarly, a tree T = (VT ; ET ) which is a subgraph of G has an associated cost de ned as

C (T ) =

X C (e)

e2ET

Given a tree T and two nodes v1 and v2 belonging to this tree, we will let PT (v1 ; v2 ) denote the path between v1 and v2 in this tree. Then, the delay and cost of this path are respectively denoted as DT (v1 ; v2 ) and CT (v1 ; v2 ). Successive updates to a multicast group are modeled as a request vector R = fr1 ; r2 ;


; rn g consisting of a sequence of n requests. Each request ri is either of the form (v; add) (indicating the addition of v to the multicast group) or of the form (v; remove) (indicating removal of v from the existing group), for some v 2 V . Si denotes the set of nodes that belong to the multicast group after satisfying requests r1; r2 ;


; ri . Problem Specification

In this paper, we consider two versions of the COLM problem. The rst version, referred to as COLMUC, is the uniformly constrained on-line multicast problem where the delay-constraint of all members of the multicast group is identical. The second version, referred to as COLM-IC, is the individually constrained on-line multicast problem where each member of the multicast group has it's own delayconstraint relative to the source. This model applies to multicasting of multimedia information (such as video or audio broadcasts) where each receiver could subscribe to and receive a dierent quality of service. An instance of the individually constrained on-line multicast problem (COLM-IC) on the above network can be modeled as a 3-tuple (s; R;
), where :

 s is the source node, relative to which all delay-constraints are measured  R = fr1 ; r2 ;


; rng is the request vector consisting of a sequence of n updates 
: Sni=1 Si ! R+ is a function that maps each multicast group member to it's delay constraint The objective of the COLM-IC problem is to determine a sequence of multicast trees T1 ; T2 ;


; Tn such that for each Ti , 1  i  n, the following are true :  Ti spans the set s [ Si  DTi (s; v) <
(v), for each v 2 Si  Cost C (Ti) is the minimum among all possible trees satisfying the above two conditions The uniformly constrained on-line multicast problem (COLM-UC) can be speci ed as a special case of the above formulation, where the delay-constraint of all the group members is the same. In this case,
can be thought of as a positive real number (rather than a function) representing this common delay constraint.

6

3.2 Algorithm Description

As mentioned previously, any algorithm for on-line update of multicast trees must take into account two important and possibly contradicting goals. The rst goal is to ensure that the cost of the multicast tree after each update is as small as possible. This could require repeated recon guration of the tree after each update operation so as to remove unwanted high-cost edges from the tree. On the other hand, real-time multicast sessions cannot tolerate frequent large changes to the multicast tree as packets are constantly in ight within the tree. Therefore, a balance needs to be struck between cost-reduction and minimization of the number of changes to the tree. To achieve this balance, Bauer and Varma [2] have suggested the technique of allowing the quality of a tree to degrade up to a xed threshold. Any further degradation results in a rearrangement of a portion of the tree using a simple static Steiner heuristic. In our CRCDM algorithm, we adopt this idea of accumulating the damage to a tree and triggering a rearrangement based on a threshold. However, since our algorithm has to deal with a constrained multicast tree, we employ a rearrangement technique that takes the delay-constraints of the multicast group members into account. The ARIES algorithm in [2] accomplishes rearrangement by breaking up the tree into a number of fragments and then combining them using the K-SPH heuristic [3]. This heuristic treats all fragments identically and works on the lines of Prims' algorithm for minimum spanning trees. However, delay being a source-centric metric, any rearrangement algorithm for delay-constrained trees needs to treat the fragment containing the source node in a distinct fashion. Therefore a heuristic such as K-SPH cannot be directly employed. Quality Factor: In our algorithm, we use a dierent technique for determining the point at which a rearrangement needs to be triggered. In ARIES, the damage to any region of the tree is measured simply by the number of newly added or recently deleted nodes in that region. When this number exceeds a speci ed threshold, rearrangement is triggered. However, this measure does not take into account the \contribution" of a region to the rest of the tree. By contribution of a region, we mean the number of multicast group members which are connected to the source through this region. We believe that even if a region of tree has degraded to a certain extent (using ARIES's measure), as long as it is serving a large number of multicast members, it should not be disturbed, i.e., rearrangement must be initiated only when a region of the tree that is only serving a small number of multicast members contributes considerably to the cost of the tree. We therefore propose a technique for triggering rearrangement based on monitoring the usefulness of a region, rather than the damage, and triggering a rearrangement when the usefulness falls below a threshold. This intuitive concept of usefulness will be formalized in the next subsection when we mathematically de ne the Quality Factor of a region. Note that for applications which absolutely cannot tolerate any change in an existing multicast tree, our algorithm can be reduced to a non-rearrangeable algorithm by setting the usefulness threshold to be 0. We assume the presence of a unicast algorithm for constructing a delay-constrained least cost paths between a pair of nodes. Ecient algorithms for this purpose have been proposed in [19] and [23]5 . Note that the Lagrangian-relaxation heuristic employed in LRA, also addresses the same problem and can therefore be used in conjunction with our algorithm. In the following sections, we will discuss in detail the steps to be performed during each update operation on the multicast group. We will rst present some de nitions and notations to be used in the description of the algorithm, then separately deal with node addition and node removal, and nally discuss the rearrangement technique. For ease of presentation, we will describe the CRCDM algorithm for an instance of COLM-UC. Section 3.2.5 describes how to modify our algorithm to handle COLM-IC. Since the problem of constructing delay-constrained least-cost paths is NP-complete, these approaches are essentially based on heuristics. 5

7

Legend : Group Member x

x x

Source Node

x x

Marked Node M-Region

Source Fragment

Figure 1: M-Regions and Fragments

3.2.1 De nitions and Notations We will use the following notations and de nitions to aid in the description of our algorithm.

sd denotes the low-cost path between s and d determined by a unicast routing strategy for a delay-constraint
.

UR( , ,
):

degT (x)

:

denotes the degree of a node x in tree T .

Member node :

group.

refers to a node in the multicast tree that is currently a member of the multicast

as part of the execution of our algorithm, certain nodes in the multicast tree (mainly former member nodes that have since been deleted from the tree) will be \marked". These nodes will be called M-Nodes (Marked Nodes).

M-Node :

Any node in a multicast tree that is neither an M-Node nor a Member node is called an Interconnection node (I-node) or a relay node. I-Node :

M-Region : With every M-Node x in a multicast tree T , we associate an M-Region R(x) de ned as follows : R(x) is the maximal connected subtree of T including x and containing only M-Nodes or I-Nodes as its interior nodes. By de nition, any leaf-node of an M-Region must either be a member

8

node or the source node. Note that two dierent M-nodes might be associated with the same M-region. A fragment of a multicast tree T is a connected subtree of T in which every leaf node is either a member node or the source node. In the extreme cases, a fragment could be just the source node, a single member node, or the entire multicast tree.

Fragment :

Fragment Leader :

de ne

Let f be a fragment containing a set S of member nodes. For some node x in f ,

delayslack(x) = miny2S f
? Df (x; y)g

The idea behind this function is that if the fragment is attached to the rest of the tree through node x, then the maximum allowable delay (so as not to violate the delay constraints of any member node of f ) between the source node and x is delayslack(x). A node l in fragment f is called the leader of f (denoted as l = leader(f )) if

delayslack(l)  delayslack(x) 8x 2 f

Ties for the leader are resolved in favor of the node with smaller node address. For ease of presentation, delayslack(leader(f )) will be denoted as delayslack(f ).

descT (R)

: For an M-Region R in a multicast tree T rooted at a source node s, descT (R) denotes the set of member nodes that are descendants of R, i.e., those member nodes whose path to the source includes a portion of the interior of the M-Region.

The Quality Factor of an M-Region R in a multicast tree T is de ned as: T (R)j QFT (R) = Numberjdesc of M-Nodes in R The QF of an M-Region is a measure of it's usefulness to the multicast tree (the larger the QF, the better is the usefulness of that M-Region). As the number of M-Nodes in that region increases, it's usefulness decreases (as this means that a large number of member nodes which were in that region have since been deleted from the group). This is balanced by the numerator which is a measure of the number of member nodes that are being supported by this region of the tree. The larger this number, the greater is the utility of this region. Quality Factor

QFT (R)

:

3.2.2 Node Addition

In this section, we will describe the steps to be taken in order to accommodate addition of nodes to a multicast group. Studies on the unconstrained version of the on-line multicast problem in [8] and [27] have revealed that when nodes are added to a multicast group, good performance can be obtained by simply connecting the new member to the existing tree through a minimum cost path. Extending this to the delay-constrained version, we explore the possibility of connecting new nodes to an existing tree through delay-constrained minimum cost paths. Since this problem is NP-hard, enumeration of all feasible paths connecting the node and the tree will be enormously expensive. We therefore assign a priority to each node in the existing tree and select a certain number of nodes with the highest priority. We then construct delay-constrained low-cost paths between these selected nodes and the new node. 9

Finally, a selection function is applied to select the best among these constructed paths. The details are as follows. Consider a multicast tree T spanning a source node s and a set W of multicast group members. At any time during the lifetime of the multicast group, the source node s maintains a priority list of all nodes (member nodes, M-Nodes, I-Nodes, or source node) currently in the multicast tree. The nodes in the list are stored in increasing order of their delay from the source. In other words, if v1 and v2 are any two nodes in T , then v1 will be placed before v2 in the priority list if DT (s; v1 ) < DT (s; v2 ). The intuitive idea behind this ordering is that nodes with lesser delay to the source have a greater residual delay6 available and therefore have a better chance of constructing low-cost paths to new member nodes. Hence they must be given a higher priority. Consider a request r = (x; add) on the above multicast tree T . The following steps are taken to service this request : 1. The rst 7 nodes in the priority list (if there are less than  nodes in the tree, then all nodes) are selected. For each such selected node v, the unicast path UR(v; x;
? DT (s; v)) is determined using any delay-constrained minimum cost routing strategy ([19], [23], or Lagrangian-relaxation [10]). 2. If the unicast path in the above step connecting a selected node v and node x rst intersects T at some node w, then this path is ignored and instead the path UR(w; x;
? DT (s; w)) is chosen. If the latter path once again intersects the tree, a similar action is taken. This procedure is employed repeatedly as required, ensuring that the nal path connecting some node u in T to node x intersects T only at u. 3. As a result of the above two steps, we will have a collection of up to  paths, connecting various nodes in the tree with node x, any one of which can be used to attach x to T without violating the delay-constraint of node x8 . 4. For some path P in the above collection connecting node v to node x, we de ne a selection function SF (P ) as follows :

SF (P ) =
? D (Cs;(Pv)) ? D(P ) T The denominator of the selection function denotes the residual delay of x in the resultant tree if P was chosen as the attachment path. If preference is given to paths with lower SF values, the

selection function can be used to simultaneously minimize the cost of the path and maximize the residual delay of x. 5. The path with the least SF value is chosen to attach x to the tree. Tree T augmented with this selected path constitutes the updated tree T 0 corresponding to the multicast group W [ x. 6. If the point of attachment (say u) of this selected path is an M-Node, then u is unmarked (becomes an I-Node). If u was the only M-Node in the M-Region R(u) then that M-Region no more exists. This is the maximum delay of any path that can be attached to the tree at this node without violating the delay constraint for the other end of the path. 7  is a parameter for this algorithm which may be tuned as needed. 8 Note that if the unicast routing strategy is unable to construct a path that satis es the delay-constraint between one or more of the selected nodes and x, then less than  paths are possible. 6

10

3.2.3 Node Removal

In this section, we will discuss the actions to be taken when a multicast group member leaves the group. Consider a request r = (x; remove) on a multicast tree T spanning a source s and a multicast group W (x 2 W ). The steps to be taken to service this request depend on the degree of node x in T . The following two cases are identi ed :

 If x is a leaf node, then the portion of the tree servicing only x is removed from the tree. This portion is de ned as follows : In the path PT (x; s), let u be the node closest to x such that either u 2 W or degT (u) > 2. Then the portion of the path PT (x; s) between x and u is removed from the tree. If u 6= s and u 2= W then u is marked, i.e., u becomes an M-Node. If u is already not part of an M-Region, then a new M-Region containing u gets created.  If degT (x)  2, then x is marked, i.e., x becomes an M-Node. This could either result in the creation of a new M-Region or in the merging of two or more existing M-Region's into a bigger M-Region.

In either case, the Quality Factors of all the M-Regions are updated. If the Quality Factor of some M-Region of the tree goes below a threshold value  (which is a parameter for the algorithm), the rearrangement algorithm described below is employed.

3.2.4 Rearrangement Algorithm As discussed above, the rearrangement algorithm is initiated after servicing a delete request, if the Quality Factor of some M-Region in the multicast tree drops below threshold . The most important consideration in any rearrangement algorithm for a constrained multicast tree is the need to ensure that no delay-constraints are violated as a result of the rearrangement. To achieve this, we propose the following rearrangement algorithm. Consider a multicast tree T spanning a source node s and a multicast group W , immediately after some delete request has been serviced. Let R be an M-Region of the multicast tree such that QFT (R) < . All nodes in the interior of region R are, by de nition, M-Nodes or I-Nodes. Therefore they are not essential to the multicast tree. The rst step in the rearrangement algorithm is to remove all nodes and edges in the interior of R from T . This results in splitting T into a number of fragments (as de ned in section 3.2.1). One of the fragments will contain the source node and will hereafter be referred to as the source fragment (refer Figure 1). The rearrangement algorithm works by iteratively attaching each of the non-source fragments to the source fragment so as to create a connected multicast tree. Consider a stage in the rearrangement algorithm where there are m non-source fragments f1 ; f2 ;


; fm and a source fragment f . The following steps constitute one iteration of the rearrangement algorithm : 1. Let delayslack(fk ) = min1im fdelayslack(fi )g. 2. Determine the path P = UR(s; leader(fk ); delayslack(fk )). As in step 2 of the node addition algorithm in section 3.2.2, if P rst intersects the source fragment f at some node w, then P is ignored and the path UR(w; leader(fk ); delayslack(fk ) ? Df (s; w)) is considered. If the latter path once again intersects f , the action is repeated. This process is repeatedly employed until a path Pk , that does not intersect with f other than at it's initial node, is obtained. 3. Let path Pk connect a node v1 in the source fragment f with some node v2 in fragment fk . Note that path Pk , though intended with leader(fk ) as the destination, might actually intersect fk at 11

fragment f k

Legend : Group Member

Source fragment f

Pk

v2

x

Source Node Path to attach next fragment to source fragment

x v1

New source fragment f’

Figure 2: Step 3 of Rearrangement Algorithm - Case 1 some node other than the leader node. Hence v2 may or may not be leader(fk ). Two cases arise depending on the nature of Pk : Case 1 : If Pk does not intersect any of the other fragments (fi , 1  i  m, i 6= k), then fragment fk is attached to the source fragment f through this path to create a new source fragment f 0 (refer Figure 2). Note that because of the de nition of Pk and that of delayslack(fk ), the delay constraint of all member nodes in the fragment fk will be satis ed. For the next iteration of the rearrangement algorithm there will be m ? 1 non-source fragments (fi , 1  i  m, i 6= k) and the source fragment f 0 . Case 2 : If Pk intersects some other fragments before terminating in node v2 , let fl be the rst fragment that Pk intersects. Then, fragment fl is attached to f using the portion of Pk connecting these two fragments. This results in the formation of a new source fragment f 00 (refer Figure 3). Note that because of the choice of fk and the de nition of delayslack, the delay constraint of all member nodes in fl is satis ed. For the next iteration of the rearrangement algorithm there will be m ? 1 non-source fragments (fi , 1  i  m, i 6= l) and the source fragment f 00 .

If the removal of a region R from T results in the creation of k fragments, then the rearrangement algorithm will require k ? 1 iterations (since the number of non-source fragments decreases by 1 for every iteration). At the end of k ? 1 iterations, only one fragment will remain, which will be the rearranged multicast tree. As mentioned above, the delay constraints of all the member nodes in the fragment being attached are satis ed in every iteration. Consequently, the resultant multicast tree after rearrangement satis es the delay constraints of all current multicast group members. 12

fragment f l v1 Source fragment

Legend :

x

Group Member Pk

Source Node

f

x v2

fragment fk

New source fragment f’’

fragment fk

Figure 3: Step 3 of Rearrangement Algorithm - Case 2 Note that, the rearrangement algorithm may not always be able to construct a valid multicast tree connecting all the member nodes, because it uses a heuristic based unicast routing algorithm for connecting non-source fragments to the source fragment. In the case of failing to connect all the fragments satisfying the delay requirements, the old tree (i.e., the tree before rearrangement) is left intact.

3.2.5 Modi cations to Accommodate COLM-IC The description of the CRCDM algorithm in the previous three sections has assumed a uniform delayconstraint
for all the multicast group members. In this section, we will indicate how to modify the algorithm to accommodate COLM-IC which allows individual delay-constraints for each member node. In this case, we will let
(x) denote the delay-constraint of some member node x. Since the steps described in section 3.2.3 for handling the deletion of multicast group members consist merely of marking nodes or pruning unnecessary branches, they are independent of the delayconstraints. Hence no modi cation to these steps is needed to accommodate COLM-IC. Modifications During Node Addition : To handle individual delay-constraints, the following modi cations to the steps described in section 3.2.2 are needed :

 In steps 1 and 2 of section 3.2.2, the delay constraint
has to be replaced by the term
(x) representing the delay-constraint of the newly arriving member node x. Hence, any path between a node v in the existing multicast tree T and the new member x will use a delay-constraint of
(x) ? DT (s; v). 13

 The selection function de ned in step 4 of section 3.2.2 is modi ed to : SF 0(P ) = C (P )  (DT (s; v) + D(P )) where v is the node at which path P attaches to multicast tree T . The second term in this selection function is the delay between the source node and node x in the resultant tree if path P is chosen for attachment. The idea here is to choose a path with a low SF 0 value so that both the cost of the path and the resultant delay between s and x are minimized. The originally de ned (P ) selection function SF (P ) =
?DT C(s;v )?D(P ) needs to be modi ed, in the case of COLM-IC, since it assumes a constant value for
. : To accommodate individual delay constraints, the only change to the rearrangement algorithm is the rede nition of the delayslack function (refer section 3.2.1) as follows : Let f be a fragment containing a set S of member nodes. For some node x in f , de ne Modifications to Rearrangement Algorithm

delayslack(x) = miny2S f
(y) ? Df (x; y)g The de nition of the fragment leader as the one with the minimum delayslack value and all the steps

in the rearrangement algorithm apply without change to COLM-IC provided the de nition given above is used.

4 Experimental Results In this section, we present the results of the simulation experiments that were conducted to analyze the performance of the CRCDM algorithm. We compare our algorithm with three other algorithms :

 To measure the cost competitiveness of our algorithm with respect to a pseudo-optimal algorithm, we have used the delay-constrained static Steiner heuristic DCMTCD , proposed by Kompella et al in [16].  To study the eect of loose delay-constraints on our algorithm, we have chosen to compare our algorithm with the unconstrained on-line heuristic ARIES discussed previously in section 2.1.4.  Finally, we compare our algorithm with the LRA algorithm (discussed in section 2.2.1) that also addresses the COLM problem.

We will rst de ne the performance metrics, then describe the simulation model, and nally present and discuss the results.

4.1 Performance Metrics

To analyze the performance of our algorithm, we used the following metrics : Cost Competitiveness (CC): This metric is a measure of how well a given algorithm performs (as regards cost of tree) in relation to the optimal algorithm. Since the on-line multicast problem is NPcomplete, it will be impractical to use the optimal algorithm as a basis for comparison. Hence, we use the DCMTCD heuristic (which constructs delay-constrained trees for static groups [16]) as our 14

benchmark. For our simulation purpose, we de ne cost competitiveness as follows : Let there be a sequence of n requests (addition or deletion) on a given multicast group in a network. Let Ti , i = 1 to n, be the sequence of trees constructed by our algorithm. Viewing the same problem as a set of n static Steiner problems, we apply the DCMTCD heuristic and construct a sequence of n trees, Ti0 , i = 1 to n. Then, for this instance of the problem, the cost competitiveness of our algorithm is given by the expression P

CC =

n C (Ti0) i=1 C (Ti )

n

where C (T ) is the cost of tree T . A low CC value for an on-line algorithm indicates that it is able to construct trees whose cost is not much larger than the cost of a tree constructed by an optimal algorithm. Average Tree Change (ATC) : As mentioned previously in section 3.2, it is important for on-line multicast algorithms to ensure that the multicast tree is not changed excessively to accommodate each update request. As a metric to measure this requirement, we de ne ATC as follows: For a sequence of n update requests, let an algorithm produce the sequence of trees Ti , i = 1 to n. Then ATC for this instance of the problem is given by the expression

ATC =

Pn?1 j (E(Ti) ? E(Ti+1)) [ (E(Ti+1) ? E(Ti)) j i=1

n?1 where E (T ) denotes the set of edges in tree T and j S j denotes the cardinality of a set S . A low value

of ATC indicates that an algorithm is able to accommodate changes in the group without excessively modifying the tree. Average CPU Time : This metric measures the average computational requirements for the various update algorithms. For our simulation purposes, average CPU time is de ned as the time taken by a serial implementation of the algorithm to solve one problem instance on a 133 MHz Pentium machine running the Linux operating system. For our simulation studies, all the algorithms were implemented using the same set of graph manipulation functions thus ensuring a level playing eld.

4.2 Simulation Model

To conduct the simulation studies, we have chosen to use randomly generated networks. This ensures that the simulation results are independent of the characteristics of any particular network topology. Using randomly generated network topologies also provided the necessary exibility to tune various network parameters such as average degree, number of nodes, and number of edges, and to study the eect of these parameters on the performance of the algorithms. The technique used for random network generation is described in detail in section 4.2.1. To generate node addition and node deletion requests to multicast groups, we have used a probabilistic model that allows control of the relative frequencies of add and delete requests. This technique is described in detail in section 4.2.2. Throughout our simulation, each request was generated and presented to the algorithm only after the previous request had been completely serviced. As described in section 3.2, our algorithm uses an underlying unicast routing strategy for constructing low-cost delay-constrained paths between pairs of nodes. For the purpose of simulation, we have used the Residual Delay Maximizing (RDM) unicast routing heuristic proposed in [19].

15

4.2.1 Random Graph Generation

In generating random graphs, we have adopted the method used in [26], where vertices are placed randomly in a rectangular coordinate grid by generating uniformly distributed values for their x and y coordinates. The graphs' connectivity is ensured by rst constructing a random spanning tree. This tree is generated by iteratively considering a random edge between nodes and accepting those edges that connect distinct components. The remaining edges of the graph are chosen by examining each possible edge (u,v) and generating a random number 0  r < 1. If r is the less than a probability function P (u; v) based on the edge distance between u and v, then the edge is included in the graph. The distance for each edge is the Euclidean distance (denoted as d(u; v)) between the nodes that form the end-points of the edge. We used the probability function ?d(u;v)

P (u; v) = e n where  and are tunable parameters and n is the number of nodes in the graph. Increasing  increases the number of connections between far o nodes and increasing increases the degree of each node. 2

4.2.2 Request Generation To generate addition or deletion requests for our simulation, we have used the probabilistic model employed in [26] and [2]. In a network of size N , let k represent the number of member nodes in the multicast tree. Then, the probability of an add-request is given by the expression : Prob(add) = (N ? (kN) +?(1k)? )k where is a constant in the range (0; 1]. The value of determines the equilibrium point at which the probability of an add or delete request is equally likely. When = Nk , the above expression takes a value of 0.5. The probability that a request will be a delete-request is given by Prob(del) = 1 ? Prob(add).

4.2.3 Simulation Parameters Our simulation studies were conducted on a set of 150 random networks, generated as described in section 4.2.1, using a coordinate grid extending from (0; 0) to (400; 400). Values of  = 0:1 and = 0.2 were used to generate 200-node networks with average degree ranging between 3 and 4. All the generated graphs were sparse, containing only around 8% of the total number of possible edges. Sparse graphs with low average degrees are more representative of real networks and pose a tougher problem, in general, to Steiner heuristics. The average group size was maintained at 60, which is representative of a sparsely distributed real-world multicast group [2]. Edge costs were uniformly distributed in the range [1; 10] whereas edge delays were made proportional to their Euclidean distance in the coordinate grid. Each random network was used to generate 100 instances of the dynamic multicast routing problem. Each problem instance received a total of 100 update requests (node addition or node deletion requests). These requests were generated based on the probabilistic model described in section 4.2.2 using a value 60 . As a result, each problem instance received approximately the same number of of = 0:3 = 200 addition and deletion requests. The various instances of the problem were generated as follows :

 The source node for a given problem instance was selected by randomly generating an integer in the range [0; 199]. The node whose number matched this random number was chosen to be the source node. 16

 For addition of a node to the multicast group, any non-member node in the network was chosen

with equal probability to become the new member node.  To choose the member node for a deletion request, the following procedure was adopted : The age of all current member nodes was determined (the age of a member is de ned as the number of node addition or node deletion requests that have elapsed since the member joined the tree). The interval [0; 1] was partitioned into subintervals and one member node was associated with each subinterval. The sizes of the subintervals were chosen to be proportional to the age of the member that they represented. A random number r in the range [0; 1] was then generated and the member node chosen for deletion was the one whose range contained r. Such a procedure makes the deletion of an older member more likely than that of a new member.

Our algorithm is parameterized by the two values  (denoted as RHO in the graphs) and  (denoted as KAPPA in the graphs).  represents a tradeo between the update time during addition requests and the average cost of the resultant tree. When a larger value of  is used, more ways of attaching a new node to an existing multicast tree are considered before the best among them is selected (based on the selection function de ned in section 3.2.2. This results in an increase in update time for add requests but improves the probability of choosing a better low-cost attachment path. The other parameter , controls the frequency with which rearrangements are triggered. A smaller value of  allows portions of the tree to degrade substantially before triggering a rearrangement, whereas a larger value of  will trigger rearrangements more frequently. In all the graphs below, we plot the performance of our algorithm for various values of these parameters. For example, the legend RHO-5 for a plot implies that for all the points in that plot, our algorithm was run with  = 5. A similar notation is employed for . The ARIES heuristic is parameterized by a single parameter which represents it's threshold value for triggering rearrangements. A larger threshold value implies less frequent rearrangements. We have chosen to use a value of 6 for this parameter (denoted as ARIES-6 in the plots) as this value exhibited the best performance in the simulation studies described in [2]. Table 1 summarizes the values of the various parameters that were employed in our simulation study. The value listed for a particular parameter in the table denotes it's default value which is the value used when that parameter is not being varied.

Parameter

Source node Node to be added Member to be deleted Delay constraint

 

ARIES's parameter Network size

Default Value / Generation Method

Randomly generated Any non-member node equally likely Older member proportionately more likely 50 5 10 6 200

Table 1: Simulation Parameters

17

4.3 Discussion of Results

In this section, we will present some of the important results of our simulation study and discuss the reasons for the observed results. 100 Cumulative Percentage of Cases

Cumulative Percentage of Cases

100 RHO-3 RHO-4 RHO-5 RHO-6

80

60

40

20

0

RHO-3 RHO-4 RHO-5 RHO-6

80

60

40

20

0 1 1.02 1.04 1.06 1.08 1.1 1.12 1.14 1.16 1.18 1.2 Cost Competitiveness

3

4

5 6 7 Average Tree Change

Figure 4a: Eect of  on CC

Figure 4b: Eect of  on ATC

8

100

Cost Competitiveness (average)

Cumulative Percentage of Cases

1.3

80 60

RHO-3 RHO-4 RHO-5 RHO-6

40 20 0

RHO-3 RHO-4 RHO-5 RHO-6

1.28 1.26 1.24 1.22 1.2 1.18 1.16 1.14 1.12 1.1

0

0.1

0.2 0.3 0.4 0.5 CPU Time (seconds)

0.6

0.7

60

Figure 4c: Eect of  on Average CPU Time

80 100 120 140 160 180 200 Network Size (Number of nodes)

Figure 5a: Eect of Network Size on CC

18

0.5

7

Average Tree Change

6.5

Average CPU Time

RHO-3 RHO-4 RHO-5 RHO-6

6 5.5 5

0.3 0.25 0.2 0.15 0.1

4.5

0.05 0

4 60

60

80 100 120 140 160 180 200 Network Size (Number of nodes)

1.35

7 RHO-3 RHO-4 RHO-5 RHO-6

6.8 Average Tree Change

1.3

80 100 120 140 160 180 200 Network Size (Number of nodes)

Figure 5c: Eect of Network Size on Average CPU Time

Figure 5b: Eect of Network Size on ATC

Cost Competitiveness (average)

0.45 RHO-3 RHO-4 0.4 RHO-5 0.35 RHO-6

1.25

1.2

1.15

6.6

RHO-3 RHO-4 RHO-5 RHO-6

6.4 6.2 6 5.8 5.6

1.1 10 20 30 40 50 60 Multicast Group Size (as percent of network size)

10 20 30 40 50 60 Multicast Group Size (as percent of network size)

Figure 6a: Eect of Group Size on CC

Figure 6b: Eect of Group Size on ATC

19

1.3

KAPPA-14 KAPPA-12 80 KAPPA-10 KAPPA-8

Cost Competitiveness (average)

Cumulative Percentage of Cases

100

60

40

20

0 1.04

1.08 1.12 1.16 Cost Competitiveness

1.2

1.2 1.15 1.1 1.05

1.24

40

Figure 7: Eect of  on CC

45 50 55 60 65 70 75 80 Delay Constraint (uniformly constrained)

Figure 8: Eect of Delay Constraint on CC

1.4

100 RHO-3 RHO-4 RHO-5

Cumulative Percentage of Cases

Cost Competitiveness (average)

1.25

1 1

1.35

RHO-3 RHO-4 RHO-5

1.3 1.25 1.2 1.15 1.1

80

ARIES-6 Delay=80 Delay=70 Delay=60 Delay=50

60

40

20

0 10 20 30 40 50 60 Delay Constraint Range (individually constrained)

1 1.02 1.04 1.06 1.08 1.1 1.12 1.14 1.16 1.18 1.2 Cost Competitiveness

Figure 9: Eect of Delay Constraint Range on CC

Figure 10: Comparison with ARIES

20

1.35 Cost Competitiveness (average)

Cumulative Percentage of Cases

100 RHO-5-RDM RHO-5-LAG 80 RHO-3-RDM RHO-3-LAG LRA 60

40

20

RHO-3 RHO-4 RHO-5 LRA

1.3 1.25 1.2 1.15 1.1 1.05 1

0

40

1 1.02 1.04 1.06 1.08 1.1 1.12 1.14 1.16 1.18 1.2 Cost Competitiveness

45 50 55 60 65 70 75 80 Delay Constraint (uniformly constrained)

Figure 12: Cost-Comparison with LRA under Dierent Delay-constraints

Figure 11: Cost-Comparison with LRA

Cumulative Percentage of Cases

100 RHO-3 RHO-4 RHO-2 RHO-0 LRA

90 80 70 60 50 40 30 20 3

4

5 6 7 Average Tree Change

8

Figure 13: ATC-Comparison with LRA

The simulation results reveal the following interesting features : Figures 4a, 4b, and 4c illustrate the eect of parameter , on the performance of our algorithm. All graphs were generated based on random 200-node networks using 100 problem instances on each network. Figure 4a presents the cumulative distribution for the costcompetitiveness of our algorithm at varying values of . It shows that larger values of  provide better cost-competitiveness (the curves for larger  occupy the more favorable upper portion of the graph). In

1.

Effect of



(RHO) :

21

fact, for  = 5, our algorithm produced trees with CC values less than 1.2 for almost 95% of the cases. This is to be expected, since a larger  requires M-Regions to possess better Quality Factors. Hence rearrangements are more frequent and this reduces the average tree cost. On the other hand, at lower  values, quality factors are allowed to degrade more without triggering a rearrangement. This reduces the average disruption to the multicast trees and is re ected by a drop in the value of the ATC metric (as observed in Figure 4b). Figure 4c illustrates the eect of  on the average CPU time taken by our algorithm. As  increases, rearrangements are triggered more frequently thus resulting in an increase in CPU time. The time taken for the node deletion and node addition algorithms will in general be much smaller than the time required to execute the rearrangement algorithm. Hence, the frequency of rearrangements (which in turn depends on ) will have a substantial eect on the average CPU time of our algorithm. Effect of Network Size : Figures 5a, 5b, and 5c illustrate the eect of network size on the CC and ATC metrics. 150 random networks of each size (60, 70,


, 200) were generated and each network was subjected to 100 problem instances. Each point in the graph therefore represents the average CC/ATC/CPU-time value of all these problem instances. Figure 5a shows that the cost competitiveness of our algorithm remains low (ranging between 1.15 and 1.24) for the entire range of network sizes. The higher CC values at larger network sizes is a consequence of the sub-optimality of the unicast routing heuristic RDM [19] (employed as part of our algorithm). This sub-optimality tends to have a greater eect for larger networks as the rearrangement algorithm (and hence the unicast routing strategy) needs to work with a larger number of bigger fragments. The higher CC values at small network sizes is also consistent with our expectation, since, adding or deleting members in a small graph may signi cantly aect graph cost and consequently the ratio between a heuristic tree's cost and that of the baseline tree. Figure 5b shows that the ATC metric also increases with network size for all values of . This trend merely re ects the fact that as network size increases, multicast group members are separated by longer paths. Hence more edges are needed to attach new members to existing multicast trees. This is especially true for the sparse multicast groups considered in our simulation studies. Figure 5c plots the variation of average CPU time with network size for various values of . The CPU time of our algorithm will depend on the time taken by the unicast routing strategy (in this case, the RDM heuristic [19]) to construct delay-constrained paths. Like other constrained unicast routing strategies, the RDM heuristic, being search-based, takes a longer time to execute on larger networks. This explains the trend observed in Figure 5c.

2.

Figures 6a and 6b illustrate the eect of multicast group size on the performance of our algorithm. Multicast group sizes were varied from 10% to 60% of network size. For each group size, the parameter was chosen as described in section 4.2.2 so as to make add and delete requests equally probable. This ensured that the average group size was maintained relatively constant despite the update requests. Figure 6a shows that our algorithm performs better for sparse multicast groups with the CC value increasing consistently with group size. Figure 6b shows that the ATC metric is relatively independent of the multicast group size. These results are consistent with our expectations, since multicast tree characteristics such as node degree, member proximity, and concentration are more likely to aect the ATC metric than group size.

3.

Effect of Group Size :

Figure 7 illustrates the eect of  on the cost-competitiveness of our algorithm. As  increases, the number of nodes selected in step 1 of section 3.2.2 increases. Hence a larger number of unicast paths are constructed before the best one is selected. This marginally improves the cost-competitiveness of our algorithm as shown in Figure 7. However, this trend does not hold beyond

4.

Effect of



:

22

a point (the curves for  = 12 and  = 14 are quite close to each other). Also, the change in CC due to variations in  are not as signi cant as that due to change in . Consequently,  is the parameter that most critically controls the performance of our algorithm with respect to all three metrics. Effect of delay-constraint (COLM-UC): Figure 8 illustrates the eect of delay-constraint on the performance of our algorithm. This eect is studied separately for the case of COLM-UC (in Figure 8) and COLM-IC (in Figure 9). Figure 8 shows that the cost competitiveness of our algorithm improves as delay-constraints become looser. This is a natural consequence of the fact that a similar variation with delay constraints is also exhibited by the unicast routing heuristic RDM [19] which we used for simulating our algorithm. In general, tighter delay-constraint would require the algorithm to sacri ce cost-minimization to a certain extent, in order to meet the tougher constraints.

5.

Effect of delay-constraint range (COLM-IC): Figure 9 plots the variation of average costcompetitiveness with the range of delay-constraints (in the case of COLM-IC). For example, a delayconstraint range of 30 implies that the delay-constraints of the group members were chosen uniformly from the range [50-15,50+15] (in each case, 50 was always the midpoint of the range). Figure 9 shows that as the range widens, the competitiveness of the algorithm drops. This is to be expected, since, widely varying delay constraints will adversely aect the rearrangement algorithm as follows : If two multicast members, one with a tight constraint and another with a loose constraint are part of the same fragment, then the delayslack value of the fragment is essentially aected by the tightly constrained group member. The other multicast member therefore gets unnecessarily aected. Since such a grouping of members does not aect a static Steiner heuristic, the CC values goes up.

6.

Figure 10 compares the performance of our algorithm with the recently proposed unconstrained on-line Steiner heuristic ARIES [2]. The gure plots the cumulative distribution of competitiveness at various values of delay-constraints. All the plots were generated on the same set of problem instances except that the delay-constraints were varied from 50 to 80. The performance of our algorithm consistently improves as constraints are loosened. Its performance at a delay-constraint of 80 is almost as good as that of the unconstrained ARIES. This illustrates that the algorithm is able to make good use of loose constraints to further minimize the tree cost. 7.

Comparison with ARIES :

Figure 11 plots the cumulative distribution of the CC values of both the LRA algorithm and our algorithm. Plot RHO-3-RDM refers to our algorithm run with  = 3 and using the unicast RDM heuristic [19]. Plot RHO-3-LAG refers to our algorithm run with  = 3 and using the same Lagrangian heuristic that LRA uses. Similar meanings are attributable to RHO-5-RDM and RHO-5-LAG. The plot illustrates that the cost-performance of our algorithm is much better than that of LRA when both node additions and node deletions are considered. This clearly demonstrates our claim, that periodic rearrangement to remove useless portions of the tree, could signi cantly improve the cost performance of a dynamic multicast algorithm. The fact that both the RHO-3 curves and both the RHO-5 curves are quite close implies that the results were not in uenced by the nature of the unicast algorithm employed.

8.

Comparison with LRA :

Comparison with LRA under different delay-constraints : Figure 12 plots the average cost-competitiveness of both the algorithms under dierent delay-constraints. The gure shows that the improved performance of our algorithm becomes more obvious under tight delay-constraints. We attribute this to an additional bene t of the rearrangement algorithm, wherein, besides removing unwanted portions of the tree, the algorithm also serves to reduce the average source-destination delay

9.

23

in the rearranged tree.9 As a result, post-rearrangement node additions are much easier to achieve, as delay-constraint requirements become less stringent. This eect becomes more prominent under tight delay constraints, as observed in the gure. 10. ATC - Comparison with LRA : Figure 13 plots the cumulative distribution of the ATC metric for both the algorithms. As expected, the non-rearrangeable LRA algorithm provides better performance when compared with the RHO-3 and RHO-4 plots. However, for  = 2, the performance of our algorithm is almost as good as that of LRA, whereas for  = 0 (no rearrangement), our algorithm even performs slightly better than the LRA algorithm. Clearly, if the application is sensitive to excessive rearrangements,  can be chosen so as to reduce ATC to acceptable levels.

5 Conclusions In this paper, we proposed a new algorithm called CRCDM for on-line update of delay-constrained multicast trees with an aim to minimize the cost of the constructed trees. Such an algorithm can be used to maintain constrained trees for routing to dynamic multicast groups. We also illustrated how to extend the algorithm to manage individual delay-constraints for each member of the multicast group. We presented simulation results that compared the performance of our algorithm with that of the pseudo-optimal static Steiner heuristic DCMTCD [16]. We also compared the performance of our algorithm with ARIES [2], an on-line Steiner algorithm for maintaining unconstrained trees, and with LRA [10], a recently proposed algorithm for maintaining delay-constrained trees. The simulation results revealed the following features of our CRCDM algorithm :

 The CRCDM algorithm performs extremely well (in terms of cost) in comparison with the baseline     

solutions provided by the static Steiner heuristic. Throughout our simulation, the average cost of the trees produced by CRCDM was at most 1.3 times the average cost of the trees produced by DCMTCD . The algorithm also scales well to cases when average delay-constraint requirements are loose, as illustrated by it's performance in relation to an unconstrained on-line heuristic such as ARIES. When both node additions and node deletions are considered, CRCDM provides better cost performance than the LRA algorithm [10]. This performance improvement also becomes larger and more signi cant when the delay constraints are made tighter. Since CRCDM works by allowing the trees to degrade before applying selective rearrangement, successive trees produced by the algorithm were often quite close. Hence, disruptions were minimized. The algorithm is very exible and general, in that, it can be used in conjunction with any unicast routing algorithm that produces delay-constrained low cost paths. The CRCDM algorithm also enjoys the advantage of being parameterized by two tunable parameters  and .  represents a tradeo between update time during add-requests and average tree cost.  provides a mechanism to control the frequency with which rearrangements are triggered.

In a number of random samples, we observed that member nodes that were previously attached to the source through long paths, after rearrangement, were connected through much shorter paths. 9

24

 Finally, our algorithm can also accommodate highly sensitive applications that require no disruption to an existing connection. This is achieved by setting  = 0 thereby ensuring that no rearrangements are triggered.

We presented and simulated our algorithm under the assumption that successive update requests to the tree were widely separated in time thereby allowing all rearrangements to be completed before the next request. When this assumption is violated, i.e., when multiple simultaneous requests need to be handled, any distributed implementation of our algorithm has to be designed to avoid race conditions. Designing such a distributed version of our algorithm is an area for future investigation.

References [1] T. Ballardie, P. Francis, and J. Crowcroft, \Core-based trees (CBT): An architecture for scalable inter-domain multicast routing," Computer Commun. Rev., vol. 23, no. 4, pp. 85-95, 1993. [2] F. Bauer and A. Varma, \ARIES : A Rearrangeable Inexpensive Edge-Based On-Line Steiner Algorithm," IEEE JSAC., vol. 15, no. 3, pp. 382-397, Apr. 1997. [3] F. Bauer and A. Verma, \Distributed algorithms for multicast path setup in data networks," IEEE/ACM Trans. on Networking, vol. 4, no. 2, pp. 181-191, Apr. 1996. [4] C. H. Chow, \On multicast path nding algorithms," Proc. IEEE INFOCOM '91, pp. 1274-1283, 1991. [5] C. Diot, W. Dabbous, and J. Crowcroft, \Multipoint communications : A survey of protocols, functions and mechanisms," IEEE JSAC., vol. 15, no. 3, April 1997. [6] S. Deering et al., \The PIM architecture for wide-area multicast routing," IEEE/ACM Trans. Networking, vol. 4, no. 2, pp. 153-162, 1996. [7] S. Deering and D. Cheriton, \Multicast routing in datagram internetworks and extended LANs," ACM Trans. Comp. Sys., vol. 8, no. 2, pp. 85-110, 1990. [8] M. Doar and I. Leslie, \How bad is naive multicast routing," Proc. IEEE INFOCOM, pp. 82-89, 1993. [9] M. R. Garey and D. S. Johnson, Computers and Intractability : A guide to the theory of NPcompleteness, W.H.Freeman, 1979. [10] S. Hong, H. Lee, and B. H. Park, \An ecient multicast routing algorithm for delay-sensitive applications with dynamic membership," Proc. of IEEE INFOCOM, pp. 1433-1440, 1998. [11] F. Hwang and D. Richards, \Steiner tree problems," Networks, vol. 22, pp. 55-89, 1992. [12] M. Imase and B. Waxman, \Dynamic Steiner tree problems," SIAM J. Disc. Math,, vol. 4, no. 3, pp. 369-384, Aug. 1991. [13] B. K. Kadaba and J. M. Jae, \Routing to multiple destinations in computer networks," IEEE Trans. on Commun., vol. 31, no. 3, pp. 343-351, March 1983. 25

[14] J. Kadirire and G. Knight, \Comparison of dynamic multicast routing algorithms for wide-area packet switched (Asynchronous Transfer Mode) networks," Proc. of IEEE INFOCOM, pp. 212219, Apr. 1995. [15] V. Kompella, J. C. Pasquale, and G. C. Polyzos, \Multicast routing for multimedia communication," IEEE/ACM Trans. on Networking, vol. 1, no. 3, pp. 286-292, June 1993. [16] V. Kompella, J. C. Pasquale, and G. C. Polyzos, \Two distributed algorithms for the constrained Steiner tree problem," Proc. Comput. Commun. Networking, San Diego, CA, June 1993. [17] L. Kou, G. Markowsky, and L. Berman, \A fast algorithm for Steiner trees," Acta Informatica, vol. 15, pp. 141-145, 1981. [18] H.Lin and S.Lai, \VTDM - A dynamic multicast routing algorithm," Proc. IEEE INFOCOM, pp. 1426-1432, 1998. [19] Raghavan Sriram, G. Manimaran, and C. Siva Ram Murthy, \Preferred-link based delayconstrained least cost routing in wide area networks," Computer Communications, vol. 21, no. 18, pp. 1655-1669, Nov. 1998. [20] Raghavan Sriram, G. Manimaran, and C. Siva Ram Murthy, \Algorithms for delay-constrained low-cost multicast tree construction," Computer Communications, vol. 21, no. 18, pp. 1693-1706, Nov. 1998. [21] Raghavan Sriram, G. Manimaran, and C. Siva Ram Murthy, \A rearrangeable algorithm for the construction of delay-constrained dynamic multicast trees," Proc. of IEEE INFOCOM, pp. 10731080, 1999. [22] S. Ramanathan, \Multicast tree generation in networks with asymmetric links," IEEE/ACM Trans. on Networking, vol. 4, no. 4, pp. 558-568, August 1996. [23] H. F. Salama, Douglas S. Reeves, and Yannis Viniotis, \A distributed algorithm for delayconstrained unicast routing," Proc. IEEE INFOCOM, pp. 84-91, 1997. [24] A. Shaikh and K. Shin, \Destination driven routing for low-cost multicast," IEEE JSAC., vol. 15, no. 3, pp. 373-381, April 1997. [25] H. Takashami and A. Matsuyama, \An approximate solution for the Steiner problem in graphs," Int. J. Math. Educ. in Sci. and Technol., vol. 14, no. 1, pp. 15-23, 1983. [26] B. Waxman, \Routing of multipoint connections," IEEE JSAC., vol. 6, no. 9, pp. 1617-1622, Dec. 1988. [27] B. Waxman, \Performance evaluation of multipoint routing algorithm," Proc.IEEE INFOCOM, pp. 980-986, 1993. [28] J. Westbrook and D. Yan, \Greedy algorithms for the on-line Steiner tree and generalized Steiner problems," 3rd Workshop on Algorithms and data structures, WADS '93, pp. 621-633, Aug. 1993. [29] P. Winter, \Steiner problem in networks: A survey," Networks, vol. 17, no. 2, pp. 129-167, 1987.

26

Appendix : Pseudo-code for our Algorithm To aid in the description of our algorithm, we will use the following notations besides the ones used in sections 3.1 and 3.2.1 :

T

plist( ) :

T

This denotes the priority list of nodes in tree T , created as described in section 3.2.2.

members( ) :

V (T )

This denotes the current set of multicast member nodes in the tree T .

This denotes the vertex set of a tree T .

:

plist,k)

getnth(

plist.

:

This function returns the element with the kth highest priority in the priority list

unicast(s,d,
,B ) : This function attempts to setup a path P between between source s and destination d satisfying a delay-constraint
. If none of the internal nodes in this path are in the node set B , this function returns the ordered pair (P , true). Otherwise, this function returns (u, false), where u is the node in P closest to s such that u 2 B .

T P Let P be a path beginning at node x and let T be a multicast tree such that x is the only node common to P and T . Then, this function attaches P to T at the attachment node x.

attach( , ) :

T P deleting P .

detach( , ) :

P ab

Where P and T are as described in the previous item, this function prunes T by

subpath( , , ) :

This denotes the portion of the path P between nodes a and b.

P B ) : Given a path P beginning at node x and a set of nodes B , let u be the rst node in P such that u 2 B . Then, pre x(P , B ) returns subpath(P , x, u).

prefix( ,

The formal description of our algorithm consists of individual pseudo-code for node removal, node addition, and rearrangement.

27

Node Addition Algorithm sT x

Add( , , ,
)

/* add node x to multicast tree T ; source node s; delay constraint
*/ begin for = 1 to do begin let i = getnth(plist(T),i) let ( i , i ) = unicast( i, ,
( ) T( , end while ( ) do i such that i = begin for = 1 to do if i = then let ( i , i ) = unicast( end let SF( m ) = Min SF( i ) : 1 attach( , m) update Quality Factors end

i



u X Y

u x

9Y

i

Y

X Y

f

X T X

D s ui ), V (T ))

false

 false

Y

x

X

Xi, x,
(x)

 i  g

Node Deletion Algorithm sT x

Delete( , , )

/* delete node x from tree T ; source node s */ begin if let let

degT (x) = 1 then begin P = PT (s; x) u be node in P nearest to x such u 2 members(T ) or degT (u) > 2 if (u 2 = members(T )) then mark u detach(T , subpath(P , u, x))

end else mark update Quality Factors if ( M-Region such that end

that

x

9

R

QFT (R) < )

28

R

Rearrange( )

-

DT (s, Xi ), V (T ))

Rearrangement Algorithm

sT R /* M-Region R; tree T ; source node s */

Rearrange( , , )

begin remove all internal nodes and edges of from let this create a set of non-source fragments and a source fragment while ( 1) do begin let ( k ) = Min ( i) : 1 let i = let i = while ( i = ) do ( i , i ) = unicast( i, ( k ),

R

jSj 

f

T S = ff1 ; f2 ;


; fm g

delayslack f fdelayslack f  i  mg Y false X s Y false X Y X leader f delayslack(fk ), V (f )) S jS j let P = prefix(Xi, i=1 V (fi )) let P terminate in the fragment fl attach(f , P ) S = S - ffl g

end end

29