Performance Evaluation and Comparison of Tree and ... - CiteSeerX

Performance Evaluation and Comparison of Tree and Ring Application-Layer Multicast Overlay Networks Ahmed Sobeih†,‡ , Jun Wang‡ and William Yurcik‡ † Department of Computer Science, University of Illinois at Urbana-Champaign, Urbana, IL 61801, USA ‡ National Center for Supercomputing Applications (NCSA), Champaign, IL 61820, USA E-mail: [email protected], {wangj,byurcik}@ncsa.uiuc.edu Abstract Application-layer multicast (ALM) protocols differ in, among other aspects, the topology of the underlying overlay network (e.g., tree, mesh or ring). Therefore, comparing the performance of ALM overlay networks is an important step towards assessing the inherent advantages and/or limitations of each overlay network topology. In particular, ring-based ALM overlay networks have the advantages of (a) providing a constant node degree; i.e., the number of neighbors each group member has on the overlay network is constant and independent of the size of the multicast group and (b) enabling the implementation of secure, reliable and totally-ordered message delivery through the use of a ring with a token that contains ordering and flow control information. Motivated thus, we present in this paper a simulation-based performance evaluation and comparison between two ALM overlay networks. The first connects the multicast group members in a ring overlay network while the second connects them in a tree. Simulation results, which have been conducted in J-Sim, have shown that although a ring overlay network incurs a higher path stretch and a higher link stress than a tree overlay network, it provides a constant and lower node degree and a higher data delivery ratio despite the failure/leaving of a single multicast group member than those provided by a tree overlay network.

1

Introduction

IP multicast [11, 12] is a network layer multicast mechanism for disseminating data from a source to all the multicast group members. Instead of sending a separate copy of the data to each individual group member, the source simply sends a single copy to all the members. An underlying multicast routing protocol determines, with respect to certain optimization objective(s), a multicast tree connecting the group members. Data generated by the source(s) flow through the multicast tree, traversing each tree edge exactly once and being replicated at each branching node. When group members join or leave a multicast group, the multicast tree is dynamically reconfigured. Although conceptually simple and elegant, IP multicast has not yet been widely adopted more than 10 years of its initial invention. This is due to concerns related to deployment (e.g., the

need of router support for multicast and hence the violation of the end-to-end argument in system design [23]), scalability (e.g., the need to maintain per-group state information at each router), and network management (e.g., the need for support of higher layer functionality, such as security and error control). Application-layer multicast (ALM) [9], also called end-system multicast (ESM), has been proposed as an alternative for multicast. The major difference between IP multicast and ALM is that in the former, packets are replicated at routers whereas in the latter, packets are replicated at end-hosts. Specifically, in ALM, members in a multicast group communicate via an overlay network. Each edge in the overlay network corresponds to a direct unicast path between two multicast group members. All the data packets are sent as unicast packets and forwarded from one member to another on the overlay network. As a result, ALM does not require additional router support for multicast (e.g., support for additional functions or maintenance of per-group state information at core/edge routers). This enables rapid and seamless deployment of multicast applications. Due to the ease of deployment, several ALM protocols have already been proposed [3, 4, 5, 6, 7, 13, 14, 17, 21, 22, 18, 29, 31, 32]. Each of the ALM protocols is targeted to optimize certain performance objective(s) (e.g., better bandwidth usage, routing delay comparable to that incurred in IP multicast, scalability) by building a specific ALM overlay network topology (e.g., tree, mesh or ring). However, the price that ALM has to pay is the performance penalty (in terms of packet delay, bandwidth usage, resilience to change of the overlay topology) because a packet may be replicated and forwarded on the same link more than once, and end-hosts may join/leave the multicast tree more dynamically than routers do. Therefore, comparing the performance of ALM overlay networks is an important step towards assessing the cost incurred by each overlay network topology. In this paper, we use J-Sim [1], an open-source network simulation and emulation environment, to conduct a simulation-based performance evaluation and comparison between two generic ALM overlay network topologies; the first is ring-based while the second is tree-based1 . 1 We choose J-Sim because its autonomous component architecture (ACA) provides composability, extensibility and the loose coupling feature between individual components [27]. All of these features enable new components to be included in J-Sim in a plug-and-play fashion.

The reason why we are interested in evaluating a ring-based ALM overlay network is threefold: (1) the node degree on a ring is O(1); i.e., the number of neighbors each multicast group member has on the overlay network is constant and independent of the size of the multicast group; this may significantly reduce the complexity in, for example, the key distribution mechanism; (2) secure, reliable and totally-ordered message delivery can be efficiently achieved through the use of a ring with a token that contains ordering and flow control information [19] and (3) a ring overlay network topology is inherently reliable to single node failures. On the other hand, the major problem of a ring-based topology is the potentially large routing delay a packet may incur especially for large multicast groups. However, it should be noted that as mentioned in [20], although the routing delay in a ring-based topology may be longer than a tree-based topology, the total delay can be smaller. This is because a ring reduces the buffering delay inside a node. For example, in several modern distributed file systems (e.g., GFS [16]), data are pushed linearly along a chain, rather than a tree, of nodes (called chunkservers in GFS) so that a node’s full outbound bandwidth is fully utilized to transfer the data as fast as possible rather than divided among multiple receivers. The rest of the paper is organized as follows. In Section 2, we discuss related work. In Section 3, we explain our methodology in evaluating and comparing the two ALM overlay network topologies. Following that, we present the experimental results in Section 4. Finally, we conclude the paper and highlight research avenues for future work in Section 5.

2

Related Work

In this section, we provide a taxonomy for ALM protocols. An extensive survey of ALM protocols can be found in [2]. The ALM protocols that have been proposed in the literature can be classified into two categories: centralized protocols and distributed protocols. An example of a centralized ALM protocol is ALMI [21], in which members of a multicast group periodically measure an application-specific performance metric (e.g., send ping messages to measure round trip time) between themselves and report these measurements to a centralized controller, which then computes a minimum spanning tree based on these measurements and sends the resulting tree information to all the group members. Distributed ALM protocols, on the other hand, do not depend on a centralized entity that has global knowledge of the multicast group members and the distances between each pair of them. They can be divided further into two subcategories: tree-first and mesh-first. In a tree-first ALM protocol (e.g., YOID [14], Overcast [17], AOM [29], HMTP [31]), a tree overlay topology for data delivery is built directly when members join. YOID dynamically configures the group members in a group-shared tree for the efficient distribution of the multicast data packets. Overcast provides scalable and reliable single-source multicast using a distributed tree-building protocol to create a source-specific tree rooted at the source. AOM builds a tree overlay topology in a distributed manner that uses both the end-to-end delay and the

round-trip time between members to construct the tree. In contrast, HMTP uses the round-trip time between members as the only metric. On the other hand, a mesh-first ALM protocol (e.g., Narada [9, 8], NICE [3], LARK [18], Gossamer [7]) first builds a mesh overlay topology and then, on top of that mesh, constructs a tree for data delivery. Narada builds, and incrementally improves the quality of, a mesh connecting the multicast group members and runs a distance vector routing protocol on top of the mesh in order to build source-specific reverse shortest path trees for data delivery. NICE arranges the multicast group members in a hierarchical overlay topology, in which all the group members are present in the lowest layer. Members in each layer are partitioned into a set of clusters. Each cluster in each layer has a cluster leader that joins another cluster in the higher layer; the highest layer in the hierarchy has a single member. In order to support cluster maintenance, each member of a cluster periodically exchanges heartbeat messages to each of its cluster peers (i.e., in each cluster in each layer, the control topology is a clique). On top of the hierarchical overlay topology, a source-specific tree is defined for delivering data packets generating from a source. Specifically, in each cluster in each layer, the data topology is a star. LARK also organizes members into cliques; however, the overlay network structure is restricted to only one level. In addition, members also peer with randomly selected members belonging to other distinct cliques. The data delivery path in LARK is also built in the form of a source-specific tree on the clustered overlay topology. Gossamer was suggested in [7] as a component of the Scattercast architecture for Internet broadcast distribution. ScatterCast proXies (SCXs), which are strategically placed network agents that are central to the operation of Scattercast, use Gossamer to first build an overlay mesh and then run a variant of a distancevector routing protocol to effectively build source-rooted reverse shortest path data distribution trees. A ring-based ALM overlay network topology fits into the mesh-first category of ALM protocols. Chord [25, 26] and VRing [24] are examples of overlay networks that use a ring to provide group communication. In this paper, we do not compare two specific ALM protocols. Instead, we compare two generic ALM overlay network topologies; namely, a ring and a tree. We choose to compare generic topologies instead of specific protocols because we are not interested in evaluating the mechanism by which the overlay network is constructed; this has already been done in previous work (e.g., [24, 3, 18]). We are rather interested in evaluating and comparing the performance of the two network topologies after they have been constructed.

3

Methodology

In this section, we will first give a formal problem definition, followed by two heuristic algorithms that construct tree-based and ring-based ALM structures respectively. We will then present the data sending and delivery mechanisms.

3.1

Formal problem definition

For presentation convenience, we give a brief description of the network model, based on which we will give the formal problem definition. A network is presented as a graph G = (V, E), where V is the set of nodes and E is the set of links. A link from node x to node y is represented as (x, y). The capacity of link (x, y) is denoted by c(x, y). We assume that links are bidirectional with the same capacity in each direction; i.e., c(x, y) = c(y, x). A weight is associated with each link, denoted by w(x, y) for link (x, y). The weight of a link can be hop count, delay, or other costs. In this paper, we focus on hop count; i.e., w(x, y) = 1 for every link (x, y) ∈ E. Since we are investigating multicast systems, there is a subset of the nodes that form the multicast group, called the member nodes. The set of member nodes is denoted by Vm , and the number of member nodes is then denoted by |Vm |. A path p from v1 to vn is denoted as p(v1 , vn ) (pv1 ,vn for short) and p(v1 , vn ) = hv1 , v2 , · · · , vn−1 , vn i. If v1 and vn are the same node, p(v1 , vn ) forms a ring. The weight of a path or a ring is the summation of all link weights on the path or the ring. Based on the network model above, we now give formal definitions of the problems that we will look into. Problem 1 – ALM Optimal Tree Problem Given a network G = (V, E) and member nodes set Vm ⊆ V , find the optimal tree that covers all of the member nodes in Vm . The tree is optimal in terms of the summation of all the link weights in the tree. Problem 2 – ALM Optimal Ring Problem Given a network G = (V, E) and member nodes set Vm ⊆ V , find the optimal ring that connects all of the member nodes in Vm . Likewise, the ring is optimal if it has the smallest summation of all the link weights on the ring. Notice that both problems are NP-hard. Problem 1 is basically a Steiner tree problem [15] and Problem 2 is a variant of the Traveling Salesman problem2 . In the next section, we will present two heuristic algorithms to address these two problems.

3.2

Approximation algorithm for constructing an optimal tree-based ALM structure

The heuristic algorithm, which we used to obtain an approximate solution to the ALM optimal tree problem, consists of the following three major steps. Step 1: Form a virtual mesh among all member nodes. For each pair of member nodes x ∈ Vm and y ∈ Vm , Dijkstra’s algorithm is used to find the shortest path px,y between x and y. Then we install a virtual link in the virtual mesh and assign the weight 2 To

see the NP-hardness of Problem 2, we first simplify the original problem by constructing a virtual full (i.e., completely-connected) mesh consisting of only all the member nodes. The weight of the virtual link between each pair of member nodes is equal to the weight of the shortest path between the corresponding two nodes in the original topology. To search for an optimal ring on top of this virtual mesh, which is a Traveling Salesman problem, is NP-hard [10].

of the path px,y to the virtual link. Note that the virtual mesh is a full (i.e., completely-connected) mesh. Step 2: Find the minimum spanning tree (MST) in the virtual mesh. We use the Prim algorithm to form the MST [10], which is an exact algorithm in polynomial time. Step 3: Restore the original paths and finalize the approximate solution. Since the MST found in Step 2 is in the virtual mesh, we need to replace each virtual link in the MST by its original path (recall that every virtual link in the mesh represents the shortest path between the two corresponding nodes). For example, if the virtual link (x, y) is in the MST, then in order to form the final approximate solution, we need to replace it by the shortest path between x and y, px,y , found in Step 1. It is easy to verify that the entire heuristic algorithm takes polynomial time to terminate.

3.3

Approximation algorithm for constructing an optimal ring-based ALM structure

Our approximation algorithm for constructing the optimal ring-based ALM structure is a simple greedy algorithm. It consists of the following three major steps. Step 1: Same as Step 1 in the algorithm presented in Section 3.2. Step 2: Find the approximate optimal ring in the virtual mesh by using greedy local search. We first randomly pick up a node in the full mesh, say x, and mark it as visited. Then, among all its neighboring nodes, we pick up the nearest unvisited neighbor, say y, and mark it as visited. By “nearest” we mean the corresponding virtual link (x, y) is the shortest in terms of the link weight among all of the unvisited neighboring nodes of x. Next, we start from y and find its nearest unvisited neighbor in the same way, and so on, until we have covered all of the nodes in the virtual mesh; i.e., a ring is found that covers all of the nodes in the mesh. Note that such a ring is guaranteed to be found because we are searching for the ring on top of a full mesh. Step 3: Restore the original paths and finalize the approximate solution. Likewise, we need to replace each virtual link on the ring found in Step 2 by its original path. Similarly, it is easy to verify that this heuristic algorithm also takes polynomial time to terminate.

3.4

Data sending and delivery mechanisms

In this section, we explain the data sending and delivery mechanisms that are adopted on both the ring-based ALM overlay network and the tree-based ALM overlay network, which we will call Ring and Tree respectively. Each multicast data packet has a sequence number SeqNo field such that the tuple < GroupID, OrigSrc, SeqNo > is unique, where GroupID is the multicast group ID and OrigSrc is the ID of the original source. The tuple < GroupID, OrigSrc, SeqNo > is ensured to be unique by having each group member maintain a separate counter (initialized to 0) for each multicast group, in which it is a member. When a group member s intends to multicast a data packet to group g and the current value of its counter

for that group is c, it sends a multicast data packet with the tuple < g, s, c > to all its neighbors and then increments the counter (i.e., c ← c + 1). In Ring, sending each data packet to all the neighbors implies that data packets are sent on both the clockwise and the counter-clockwise directions of the ring. A node m that is a member in group g, receiving a data packet < g, s, q >, handles the incoming data packet only if it is not the original source (i.e., m 6= s) and it has not received the data packet before (i.e., the data packet is not a duplicate). Detecting duplicate packets can be achieved by having each group member m maintain the highest sequence number, HighestSeqNumReceived, received from each source s. HighestSeqNumReceived is initialized to -1. A data packet is considered a duplicate if HighestSeqNumReceived ≥ q, where q is the value of the sequence number, SeqNo, field of the data packet. If the data packet is not considered a duplicate, node m forwards it to all its neighbors except the neighbor from which it came and sets HighestSeqNumReceived to q.

4

Experimental Results

In this section, we evaluate the performance of Ring and compare it with the performance of Tree. In general, ALM overlay networks can be evaluated using the following performance evaluation criteria [18]: 1. Path Stretch between a pair of members is defined as the ratio of the end-to-end delay (measured in terms of either latency or number of physical hops) along a path connecting the two members on the overlay network to that along the direct unicast path. In a single-source multicast group, the average path stretch is calsr culated as ∑r∈R |R| where sr is the path stretch between the source and a receiver r and |R| is the number of receivers in the group. By definition, IP unicast has an average path stretch of unity. The closer the average path stretch of a protocol to unity, the better. 2. Link Stress, where the stress of link l is defined as the number of identical copies of a multicast data packet that are forwarded over the physical link l. The average link stress is calcutl lated as ∑l∈L |L| where tl is the stress of link l and |L| is the number of physical links used for data forwarding in the topology. By definition, IP multicast has an average link stress of unity. The closer the average link stress of a protocol to unity, the better. 3. Node Degree is defined as the number of neighbors each group member has on the overlay network. The average node ∑ m dn degree is calculated as n∈V where dn is the degree of group |Vm | member n and |Vm | is the number of multicast group members. It is desirable for a node to have a small number of neighbors because a large node degree usually causes potential performance bottleneck due to large buffering delays in a node. 4. Data Delivery Percentage is defined as the percentage of the remaining multicast group members that continued to receive data packets despite the failure (or leaving) of one multicast group member. We performed our simulation-based comparative study in JSim on a transit-stub topology of 250 nodes generated using the GT-ITM topology generator [30]. Members of the multicast

group are randomly selected. The overlay size, |Vm |, (i.e., the number of multicast group members) varies from 20 to 160. All the members join the multicast group at simulation time 300 seconds. After the ALM overlay network is constructed, an end-host is chosen uniformly at random to be the data source generating data packets. In these simulations, we do not consider data packet loss and/or excessive queuing delay due to congestion. To provide a fair comparison between Ring and Tree, we use the same unicast routing protocol, the same network topology and the same multicast group members. Each simulation result is an average of 10 simulation runs, each of which is run with a different network topology and and a different set (but the same number) of multicast group members. Figures 1-2 respectively show the average and maximum path stretch (measured in number of physical hops) of Ring and Tree versus the overlay size. As shown in Figures 1-2, Tree has a lower average and a lower maximum path stretch than Ring for all values of |Vm |. This is because each member in Ring forwards a multicast data packet at most once; in contrast, a member in Tree may forward a multicast data packet more than once depending on how many neighbors it has on the data delivery tree. This reduces the distance (measured in terms of the number of physical hops that have to be traversed) from a source to the receivers in Tree at the price of extra forwarding at the multicast group members. Figures 3-4 respectively illustrate the average and maximum link stress of Ring, Tree and multiple unicast versus the overlay size. As shown in Figure 3, the average link stress in Tree is slightly less than that in Ring. Although the non-leaf member nodes in Tree may forward the multicast data packets more than once, the leaf member nodes do not forward any data packets. This reduces the average link stress. On the other hand, as shown in Figure 4, the maximum link stress in Tree is slightly larger than that in Ring. Tree has a larger maximum node degree (as will be shown later) and this leads to increasing the maximum number of identical copies of a multicast data packet sent on a physical link (i.e., increasing the maximum link stress). The link stress incurred by multiple unicast is significantly higher (especially for large multicast groups) than that incurred by Ring or Tree. This is due to the fact that the source has to unicast a copy of each multicast data packet to each receiver causing an increase in both the average and maximum link stress. The better performance of Tree with respect to the average/maximum path stretch and average link stress, however, do not come for free. As shown in Figure 5, although the average node degree in Ring is almost equal to that in Tree, the maximum node degree in Ring is O(1) (i.e., independent of the overlay size), while the maximum node degree in Tree increases with the increase in the overlay size. Figure 6 shows a cumulative distribution of node degree in Tree for three selected overlay sizes (40, 100 and 160 members). As shown in Figure 6, 17.5 %, 21 % and 24.4 % of the multicast group members have a node degree that is strictly greater than two (which is the maximum node degree in Ring) for the 40-member, 100-member and 160-member cases respectively. In addition to having a constant node degree and a lower maxi-

100

10

5

0

20

40

60

80

60 40 20 0

100 120 140 160 180

20

40

60

80

20 15 10 5

20

40

60 80 100 120 140 160 180 Overlay Size (hosts)

Figure 4. Maximum link stress of Ring, Tree and multiple unicast versus the overlay size.

4 3 2

0

100 120 140 160 180

Tree (average) Ring (averge & maximum) Tree (maximum)

25 Node Degree

Maximum Link Stress

30

150

0

5

1 20

0

20

40

60 80 100 120 140 160 180 Overlay Size (hosts)

Figure 5. Node degree of Ring and Tree versus the overlay size.

mum node degree than Tree, Ring also provides perfect data delivery if a single multicast group member fails (or leaves the multicast group). As shown in Figure 7, Ring provides a 100 % data delivery percentage (i.e., all the remaining multicast group members continue to receive data packets) despite the failure/leaving of a single multicast group member. This is because Ring provides two paths over the overlay network from each member to another; one path is clockwise and the other path is counter-clockwise. If one of the two paths is disrupted due to the failure/leaving of a member, the other path is used; i.e., the ring is inherently reliable to single node failures. On the other hand, the data delivery percentage in Tree is consistently below 100 %. This is because Tree does not inherently provide a backup path to each group member in the way that Ring does. In fact, if a non-leaf member node in Tree fails or leaves the multicast group, its children on the tree will not continue to receive data packets causing a reduction in the data delivery percentage as demonstrated in Figure 7.

5

40

60

80

100 120 140 160 180

Overlay Size (hosts)

Figure 2. Maximum path stretch (measured in number of physical hops) of Ring and Tree versus the overlay size.

Tree Ring Unicast

50

6

Overlay Size (hosts)

Figure 1. Average path stretch (measured in number of physical hops) of Ring and Tree versus the overlay size.

100

Tree Ring Unicast

7

80

Overlay Size (hosts)

200

8

Figure 3. Average link stress of Ring, Tree and multiple unicast versus the overlay size.

Number of Multicast Group Members

15

Tree Ring Average Link Stress

Tree Ring Maximum Path Stretch

Average Path Stretch

20

40 members 100 members 160 members

200 150 100 50 0

0

5

10 15 Node Degree

20

Figure 6. Cumulative distribution of node degree in Tree.

Conclusions and Future Work

In this paper, we presented a simulation-based comparative study that evaluates and compares the performance of tree and ring application-layer multicast (ALM) overlay networks. Simulation results, which have been conducted in J-Sim, have shown that although a ring overlay network incurs a higher path stretch and a higher link stress than a tree overlay network, it provides a constant and lower node degree and a higher data delivery ratio despite the failure/leaving of a single multicast group member than those provided by a tree overlay network. Based on the results presented in this paper, we conclude that, in scenarios similar to those presented in this paper, using a ring overlay network is not suitable for delay-sensitive applications because the path stretch that is incurred can be up to an order of magnitude larger than that incurred by a tree overlay network. On the other hand, a ring overlay network is suitable for applications in which it is

Data Delivery Percentage

100 95 90 85 80 75

Tree Ring 20

40

60 80 100 120 140 160 180 Overlay Size (hosts)

Figure 7. Data delivery percentage of Ring and Tree versus the overlay size.

desirable to have a constant and low node degree and to guarantee perfect data delivery despite single node failures. For future work, we intend to build group communication applications that make use of ring-based ALM overlay networks so that we can study how they perform in real-life. This will also enable us to consider the effect of both the routing delay and the buffering delay on ring-based ALM overlay networks and compare this combined effect with other tree-based ALM overlay networks. Another avenue for future research is studying to what extent the constant node degree in ring-based ALM overlay networks helps in the scalability of security protocols.

References [1] J-Sim. http://www.j-sim.org/. [2] C. Abad, W. Yurcik, and R. Campbell. A survey and comparison of end-system overlay multicast solutions suitable for network centric warfare. In Proc. of SPIE’04. [3] S. Banerjee, B. Bhattacharjee, and C. Kommareddy. Scalable application layer multicast. In Proc. of ACM SIGCOMM’02. [4] K. Birman, M. Hayden, O. Ozkasap, Z. Xiao, M. Budiu, and Y. Minsky. Bimodal multicast. ACM Trans. on Computer Systems, 17(2):41–88, May 1999. [5] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, A. Rowstron, and A. Singh. Splitstream: High-bandwidth multicast in cooperative environments. In Proc. of ACM SOSP’03. [6] M. Castro, P. Druschel, A.-M. Kermarrec, and A. Rowstron. SCRIBE: A large-scale and decentralized application-level multicast infrastructure. IEEE Journal on Selected Areas in Communications, 20(8):1489–1499, October 2002. [7] Y. Chawathe. Scattercast: An Architecture for Internet Broadcast Distribution as an Infrastructure Service. PhD thesis, University of California, Berkeley, 2000. [8] Y.-H. Chu, S. G. Rao, S. Seshan, and H. Zhang. Enabling conferencing applications on the Internet using an overlay multicast architecture. In Proc. of ACM SIGCOMM’01. [9] Y.-H. Chu, S. G. Rao, and H. Zhang. A case for end system multicast. In Proc. of ACM SIGMETRICS’00. [10] T. Corman, C. Leiserson, and R. Rivest. Introduction to Algorithms. MIT Press, Cambridge, MA, 1990. [11] S. Deering. Host extensions for IP Multicasting. RFC 1112, August 1989.

[12] S. Deering and D. Cheriton. Multicast routing in datagram internetworks and extended LANs. ACM Trans. on Computer Systems, 8(2):85–110, May 1990. [13] P. Eugster, S. Handurukande, R. Guerraoui, A.-M. Kermarrec, and P. Kouznetsov. Lightweight probabilistic broadcast. In Proc. of IEEE DSN’01. [14] P. Francis. Yoid: Extending the multicast Internet architecture. white paper http://www.aciri.org/yoid/, 1999. [15] M. Garey and D. Johnson. Computers and Intractability: A Guide to the Theory of NP-Completeness. W.H. Freeman, San Francisco, CA, 1979. [16] S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google file system. In Proc. of ACM SOSP’03. [17] J. Jannotti, D. Gifford, K. Johnson, M. Kaashoek, and J. O’Toole. Overcast: Reliable multicasting with an overlay network. In Proc. of OSDI’00. [18] S. Kandula, J.-K. Lee, and J. C. Hou. LARK: A light-weight, resilient application-level multicast protocol. In Proc. of IEEE CCW’03. [19] K. P. Kihlstrom, L. E. Moser, and P. M. Melliar-Smith. The SecureRing group communication system. ACM Transactions on Information and System Security, 4(4):371–406, November 2001. [20] Y. Ofek and B. Yener. Reliable concurrent multicast from bursty sources. IEEE Journal on Selected Areas in Communications, 15(3):434–444, April 1997. [21] D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel. ALMI: An application level multicast infrastructure. In Proc. of USITS’01. [22] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker. A scalable content-addressable network. In Proc. of ACM SIGCOMM’01. [23] J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-end arguments in system design. ACM Trans. on Computer Systems, 2(4):277–288, November 1984. [24] A. Sobeih, W. Yurcik, and J. C. Hou. VRing: A case for building application-layer multicast rings (rather than trees). In Proc. of IEEE/ACM MASCOTS’04 (to appear). [25] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A scalable peer-to-peer lookup service for Internet applications. In Proc. of ACM SIGCOMM’01. [26] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H. Balakrishnan. Chord: A scalable peer-to-peer lookup protocol for Internet applications. IEEE/ACM Trans. on Networking, 11(1):17–32, February 2003. [27] H.-Y. Tyan. Design, Realization and Evaluation of a Componentbased Compositional Software Architecture for Network Simulation. PhD thesis, Department of Electrical Engineering, The Ohio State University, 2002. [28] H.-Y. Tyan and J. C. Hou. JavaSim: A component-based compositional network simulation environment. In Proc. of Western Simulation Multiconference, CNDS’01. [29] S. Wu and S. Banerjee. Improving the performance of overlay multicast with dynamic adaptation. In Proc. of IEEE CCNC’04. [30] E. W. Zegura, K. L. Calvert, and S. Bhattacharjee. How to model an internetwork. In Proc. of IEEE INFOCOM’96. [31] B. Zhang, S. Jamin, and L. Zhang. Host multicast: A framework for delivering multicast to end users. In Proc. of IEEE INFOCOM’02. [32] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. Katz, and J. Kubiatowicz. Bayeux: An architecture for scalable and fault-tolerant widearea data dissemination. In Proc. of ACM NOSSDAV’01.