Building Low Delay Application Layer Multicast Trees

Transcription

1 Building Low Delay Application Layer Multicast Trees Su-Wei, Tan Gill Waters Computing Laboratory, University of Kent Abstract Application Layer Multicast (ALM) enables rapid deployment of multicast applications which have been hindered by sparse deployment of network layer multicast infrastructure. In ALM, application hosts organise themselves into an overlay topology on top of the underlying unicast network solutions. Application data is multicast over the overlay network. This paper investigates the problem of building a low delay overlay tree in a distributed manner. We study and propose an enhancement to an existing protocol called Tree Building Control Protocol (TBCP). We also propose a new strategy to maintain and improve the tree quality in a changing network environment. Our simulation results indicate that the enhancement and the new tree refinement technique outperform the previous proposals. Index Terms application layer multicast, distributed tree building protocol. D I. INTRODUCTION ue to the need for efficient techniques for group communications, multicasting has received much research attention since its initial proposal [1]. Early multicast proposals have focused on network layer based solutions in which multicast packet replication and forwarding mechanisms are all implemented in network routers. Indeed, network layer solutions make the most efficient use of network resources, such as bandwidth. Unfortunately, global deployment of IP multicasting has been hindered for a number of practical reasons [2]. Consequently, various alternative proposals, such as simple multicast [3], source specific multicast [4] and application layer multicast (ALM) [5, 6, 7] have been suggested. Out of these proposals, ALM has been in the limelight in recent years. This is because it utilises the existing Internet unicast protocols, which facilitates instant deployment without modifying the existing network infrastructure. In the ALM architecture, packet replication and forwarding are handled at the end hosts. ALM uses an overlay on top of the physical network for communication between members. Each overlay link is essentially a unicast tunnel rather than a point-to-point link. Consequently, a multicast member is able to reach all other participants as long as it has their addresses. A naïve overlay solution is to use a star topology rooted at the data source as the delivery tree. Despite its simplicity, this solution results in traffic concentration at links close to the sender. Consequently, it does not scale for a large user population. A practical ALM solution should use only a subset of the full mesh links to form the overlay. Therefore, the multicast efficiency of an ALM solution is largely determined by the overlay topology chosen. Building a tree in the application layer is fundamentally different from building one in the network layer. In the network layer, the tree computation is done at routers which are equipped with network topology information. As the packet replication and forwarding are done at the router level, a packet can be delivered to every destination without unnecessary duplication in the network. On the other hand, an application layer host has either no or limited access to the routing information. This results in unnecessary packet duplication and prolonged latency. The first challenge in constructing an efficient data delivery tree is thus: how to uncover the underlying network metrics efficiently. The following question is then: how can we use the obtained information to build a good tree. A good tree is of course, subject to the optimisation objective we wish to achieve. In this paper, we focus on building low delay overlay trees which are suitable for single source delay-sensitive content distribution applications. Examples of such applications are live webcast and media streaming from a well-known server. We conduct a detailed study on an existing protocol called Tree Building Control Protocol (TBCP) [8] as a basis for building low delay trees. We propose an enhancement to TBCP to improve the performance of the protocol. We also propose a new strategy to maintain and improve the tree quality in a changing network environment. In next section, we discuss several issues involved in building low delay overlay trees. In Section III, we review and analyse TBCP. In Section IV, we describe a new tree improvement strategy. We present some simulation results in Section V. In Section VI, we briefly discuss some related work and finally, Section VII concludes the paper. II. BUILDING LOW DELAY OVERLAY TREES In ALM, a star topology rooted at the data sender provides the best delay performance. However, as each connection is a unicast tunnel that may traverse multiple physical links, identical packets can traverse the same link more than once. The number of duplicated packets that traverse a single link is defined as the link stress [5]. In addition, the fanout of the overlay or the number of receivers that can be served simultaneously is constrained by the interface bandwidth of the sender. The problems of finding the minimum diameter, i.e. low delay tree with fanout constraint have been proven to be 1

2 NP-hard in [9] and [10]. In both works, the authors focused on a centralised computation model where the membership information and distances among the members are readily available. Unfortunately, unlike routers, application layer hosts have little or no routing information. To infer the underlying network metrics (e.g. delay, bandwidth), end-to-end measurement techniques have to be used. Typically, these techniques require probe packets to be sent between two end hosts for some time interval. It is impractical for each host to perform measurements to all other participants. Consequently, a practical solution has to work with limited topology information in a distributed manner. We consider the problem in a dynamic environment, i.e. the membership information and join sequence are initially unknown. Each multicast member executes an instance of a tree building protocol to construct the distribution tree. The tree is defined by a set of parent-child relationships among the members. Each member, except the root, joins the multicast session by becoming a child of an on-tree member. To join an existing session, a new member first contacts a well-known Rendezvous Point (RP) to obtain a list of existing members. The new member then begins its joining process by sending query message to one or some of the on-tree members. The information about the RP itself may be announced to potential participants through some out-of-band mechanisms such as web publishing or electronic mail. To build a low delay tree, the objective of a newcomer is to choose a parent that provides the smallest latency from the root without violating the degree constraint. Figure 1 illustrates a decision problem faced by a distributed protocol. In the figure, r is the root node while N is the newcomer. If r has a maximum fanout that is more than two, it is clear that N can be accepted as the child of r. However, if the maximum fanout of r is just two, there are a number of possible configurations even in this simple example (see Figure 1 (b), (c) and (d)). While the solution shown in (d) is the best possible configuration for root delay optimisation, it will increase the sub-tree delay to y. Figure 1 (b) and (c) depicts the well-known triangle problem [12] involving node r, N, and x or y respectively. Initially, all newcomers treat the root node as the potential parent and begin their joining process from it. During the joining process, a newcomer performs distance measurements to the potential parent and its children. The measured results are then sent to the potential parent. On receiving such information, the potential parent consults a set of potential local configurations and calculates a score value for each configuration. The local configurations used effectively test all possible arrangement within the local region (see Figure 2). The potential parent rearranges the local region by issuing either a Welcome or Go message to the node involves in the rearrangement. The Welcome message is used to inform the receiving node that it is accepted as a child of the potential parent. On the other hand, the Go message indicates that the receiving node is redirected to a new potential parent. On receiving a Go message, a node executes the above joining procedures from the potential parent given in the message. TBCP uses a configurable score function to evaluate the goodness of a configuration. Therefore, the final shape of the resultant tree depends on the function and the metrics involved. If the score function is suitably chosen, TBCP can overcome the triangle problem in the local region. In [8], the score function of a configuration c is defined as, score c) = max D( p, ) (1) ( m ( C{ N}) m where D(i,j) is defined as the distance between node i and j along the tree, p is the current potential parent, C is the set of p s children and N is the newcomer. Based on the score function, the configuration with the smallest score value is chosen. It is an attempt to minimise the maximum overlay distance in the set of local configurations, and thus, hopefully will achieve global optimisation. Figure 2: TBCP Local Configurations Figure 1 III. TREE BUILDING CONTROL PROTOCOL (TCBP) A. Protocol Description TBCP [8] is a generic tree building protocol designed to reduce the convergence time by building a good tree as early as possible. The main concept is to rearrange the tree members confined within a local region according to a set of configurations and a score function. B. Analysis of TBCP Score Function The set of local configurations used effectively test all possible arrangement within the local region. In this section, we provide an analysis and propose an enhancement to the protocol for delay optimisation. The score function in [8] tries to minimise the maximum overlay distance within the local region. In this score function, if the distance of one of the overlay links within the configuration dominates other links, many configurations will give the same score value. Figure 3 illustrates the scenario where link between node p and c 1 is the dominant link. There are several possible ways to break the tie. We have chosen the configuration cost (see equation 2), as the tiebreaker. 2

3 The configuration cost for configuration c, C(c) is given by e C ( c) = d( e) (2) E i where E i is the set of overlay links in configuration i, d(e) is the delay value of overlay link e. From our experiments, we have observed that this choice always outperforms the version where the tie break is arbitrary. Another possible choice is to break tie in a lexicographical order. To explain this, we first assume that the overlay distances of a configuration are sorted in a non-increasing order into a vector V(d). Therefore, the first component of the vector represents the score value of the configuration. For two configurations with equal score value, we compare their subsequent V(d) components and choose the one that gives the first smaller value. While this or other choices may perform better than our selection, we argue below that a greedy score function as in Equation 1 is not suitable for delay optimisation. C. Proposed Score Function We propose a new score function for TBCP. Our score function is aimed to minimise the triangle cost within the local region. Referring to the set of configurations shown in Figure 2, only one change is done in each configuration. Our score function only evaluates the changed segment within a configuration. To explain the score function, we use Figure 5. In the figure, p is the potential parent node, x and y are nodes involved in the change. Our score function for a configuration c is given as, d( p, x) + d( x, y) score( c) = (3) d( p, y) The score function gives the ratio between the distance from p to y via x and the distance between p and y. We choose the configuration that gives the smallest score value. Effectively, we are trying to minimise the triangle cost created by the change. Figure 3: Dominant Link (p, c 1 ) in Local Configuration The following discussion is based on the example given in Figure 4. Figure 4 (a) (d) illustrates a sequence of tree construction stages using equation 1 as the score function. The example assumes that each node has a maximum fanout of three and p is the root of the tree. In panel (a), node N1 is the newcomer that wishes to join the tree. We assume that the distance of d(p,a) and d(p,b) are same and are the maximum in the local configurations. We then further assume that the distance d(p,n1) + d(n1,c) is smaller than d(p,c) + d(c,n1). Therefore, the resultant configuration will be as in panel (b). Now, another newcomer, N2 tries to join the tree. As the local configurations only consider the arrangements involving p, N2 and p s children (i.e. N1, A, B), the best local configuration is as shown in panel (d). The example above shows a major problem of the greedy score function. In the protocol, the set of configurations used only involves the local region around the newcomer, the current potential parent and its children. A greedy score function such as equation 1 that attempts to provide the best local configuration, will often result in inefficient resource usage. The problem gets worse when the member population increases. Consequently, the resultant tree is not able to achieve the target objective. A better solution for the example would be the configuration shown in panel (e). Figure 4: Sequence of Tree Construction Process Figure 5: Changed Segment {p, x, y} in Local Configuration IV. NEW TREE IMPROVEMENT STRATEGY In this section, we describe a new tree improvement strategy. In a practical operating environment, group membership and underlying network conditions change over time. Consequently, a tree refinement is needed to maintain and improve the quality of the delivery tree in dynamic scenario. Our tree refinement strategy is inspired by the use of local transformations to improve overall tree performance [11,12]. 3

4 In [11], the authors proposed a family of tree refinement algorithms called switch-trees. In the algorithms, each node independently switches parent to reduce the tree cost or tree latency. The switching targets are confined within a predefined hop counts from the node wishes to perform the switching. HostCast [12] is another such protocol designed for delay sensitive applications. In addition to switching parent, HostCast provides a swapping operation between a child and its parent to alleviate the triangle problem. Similarly to the above protocols, in our proposed strategy each node performs measurements to a set of target nodes confined within a local region. Unlike previous proposals, we consider a centralised computation model within the local region. The idea is to have all the measurements collected be sent to a leading node in the local region. Based on the collected information, the node forms a distance mesh of the local region and computes the optimal configuration for the region. The results are sent to the nodes in the form of parentchild relationship. The centralised computation allows the use of more sophisticated optimisation algorithms to compute an optimal tree. While the centralised computation model has a scalability problem, it is not an issue here as only a subset of participants is involved. In addition, it avoids the looping problem that can occur when the transformation decision is made independently [11]. Figure 6 illustrates the scope of a local region. In the figure, r is the root of a sub-tree and is the only ALM node at level 0. A node at level 2, say x, measures the distance between itself and all the black nodes. As a result, node x knows its distance to each of its siblings and all level 1 and 0 nodes. In our protocol, when a node measures the distance between itself with another node, say y, the measured result will be made known to y. With this, level 2 nodes also have the information for some of the level 3 and 4 nodes. If the maximum fanout of any node is k, the measurement overhead is at most 2k. The measured results are sent to r along the overlay tree. Based on the collected results, r constructs a distance mesh as shown in Figure 7. In the figure, each line represents the availability of the distance information. Using the local distance topology, the root computes the best configuration and sends the results as pairs of parent-child relationship to the nodes. Currently, we use the centralised greedy algorithm proposed for minimum diameter, degreebounded spanning tree problem presented in [9]. The original algorithm is aimed to minimise the tree diameter, i.e. the minimum of the maximum distance between any two nodes in the tree. As we consider single-sender applications, we modify the objective function in the algorithm to minimise the root diameter. The inputs to the greedy centralised algorithm are the distance information and the degree constraint of each node. The output is a degree constraint delay minimised tree. We denote δ(v) as the smallest root distance of node v. Initially, this value is set to the directly distance from each of the nodes to the root. The algorithm constructs a tree, T in an incremental manner starting from the root node. At each step, a new node u with the smallest δ(u) is added to the existing component T. Then, for each node v not in the component, we update its parent to an on-tree node q which, without violating the degree constraint, gives v the smallest δ(v). The algorithm takes O(n 2 ) to update the parent for each v that is not in T, where n is the number of nodes. The algorithm terminates when all nodes are included in T. The total running time of the algorithm is O(n 3 ). Figure 6: Measurement Scope for Node x A. Simulation Setup Figure 7: Local Region Distance Mesh V. PERFORMANCE EVALUATION We developed a simple discrete event simulator for the evaluations. The simulator assumes a shortest path routing for any two nodes in the network. The simulator models the propagation delay of links but not queuing delay and packet losses. We used both Waxman and Transit-stub network models [13,14] to generate topologies used in the evaluations. The topologies used consist of 600 routers. The multicast members are randomly chosen and attached to the routers. The number of members ranges from 50 to 300. Each member has a maximum fanout of 6. The refinement period is set to 30 seconds. Our results were collected from ten independent runs of each simulation scenario. We compare our proposed solution with the existing TBCP score function. In addition, we use the switch-two-hop protocol in [11] to evaluate the efficiency of our tree improvement strategy. As the original switch-two-hop algorithm in [11] does not consider the triangle problem discussed in Section II, our implementation of the protocol allows a node to swap position with its parent to alleviate the problem. The measurement overhead of switch-two-hop protocol is O(k 2 ) where k is the maximum fanout value. B. Performance Metrics We use the following performance metrics to evaluate the proposed solution. 4

5 Stress Stress is defined as the number of duplicated copies of identical packet over a single link. The delay performance is evaluated in terms two relative delay penalty measurements proposed in [15]: o RMP Maximum overlay delay over the maximum unicast delay, and o RAP Average overlay delay over the average unicast delay C. Results and Discussion This section presents the results of our simulation experiments. We refer to the version of TBCP with original score function and our proposed function as TBCPoriginal and TBCP-new respectively. We first investigate the performance of our new score function in comparison with the original version. In the experiments, members do not perform tree improvement. Figure 8 depicts the performance in term of RMP. From the figure, we can see that our new score function provide better RMP values across the group size. The performance advantage increases with the group size. While not shown here, the version that offers an arbitrary tie-break performs the worst. Figure 9 shows that our proposed solution achieves a better stress performance. after the overlay tree stabilized. Figure 10 and 11 show the RMP and RAP performance respectively. In general, the results show that the tree refinement technique can further improve the delay performance. In addition, our local region centralized refinement technique performs better than the distributed version. In application layer routing, the gain in latency performance is often compromised by the increase of link stress. Figure 12 indicates that our proposed solution maintains comparable stress performance while providing lower latency. Although we do not show the time taken to stabilise here, our centralised approach can achieve faster convergence speed than the distributed version, as expected. In most simulations, we observed that the tree stabilizes after 2 or 3 runs of the tree improvement algorithm by each member. Figure 10: RMP Performance w Tree Refinement Figure 8: RMP Performance w/o Tree Refinement Figure 11: RAP Performance w Tree Refinement Figure 9: Link Stress Performance w/o Tree Refinement In our next experiment, we activate the tree refinement procedures for all nodes. Since we are interested in the steady state performance of the protocols, the results were collected Figure 12: Link Stress Performance w Tree Refinement 5

6 VI. RELATED WORK Building efficient distribution trees in the context of ALM has received increasing attention recently. Basically, tree building protocols can be classified into centralised and distributed approaches. In centralised approach, a dedicated server is used to perform the overall tree computation. As this approach requires each member to perform end-to-end measurement to all or most members, it does not scale. ALMI [16] and Host- Based Multicast (HMB) [17] are such protocols. In contrast to the above proposals, our proposal uses centralised computation only for a sub-set of nodes. In addition, the computation is distributed among the members. Consequently, it is able to serve a larger group size. Distributed protocols can be further grouped into mesh-first and tree-first protocols. Mesh-first protocols take a two steps approach to construct the distribution tree. Initially, a mesh is formed among the members. The distribution tree is then derived from the mesh. As a mesh contains loops, protocols falling in this category need a way to disseminate the topology information and to construct the delivery tree. Narada [5], one of the initial ALM proposals is a mesh-based protocol. It uses a distance vector like routing protocol and the well-known reverse path forwarding mechanism to multicast data. Another class of mesh-based protocols is built on top of the infrastructure creates using Distributed Hash Table (DHT) techniques. These include Scribe [18], multicast-can [19], Bayeux [20] and Chord [21]. In tree-first protocols, the distribution tree is built directly. Yoid [22] is one of them. It consists of a set of protocols forming a new architecture for general content distribution. Besides the delivery tree, Yoid maintains a mesh structure as a mean of failure recovery. Yoid uses switch parent technique to avoid routing pathology rather than achieve optimisation. HMTP [6] is another tree-first protocol designed to build low cost overlay tree. TBCP, switch-trees and HostCast also belong to tree-first approach. NICE [7] and ZigZag [23] use a distributed clustering strategy to build the distribution tree and could be classified under this category. VII. CONCLUSION In this paper, we give two contributions. First, we proposed a new score function for TBCP for building low delay overlay trees. The new score function attempts to minimise the triangle cost within a local region. Secondly, we design a new tree improvement strategy. In the strategy, nodes independently perform distance measurement to some nodes within a local region. The root node at the local region collects the distance information and uses a centralised algorithm to rearrange the nodes. While the solution uses centralised computation model, it involves only a subset of participants. Furthermore, no transient loops will be created. We show by simulations that the proposed enhancement to TBCP and the refinement strategy perform better than previously proposed solutions. To obtain more confidence in our results, we are currently evaluating the proposal for larger network topologies and group sizes. An immediate extension of this work is to study the efficiency of the centralised local region reconfiguration with other optimisation algorithms and objective functions. In addition, we intend to study the case where participants may leave at will or fail during the course of a session. REFERENCES [1] S. Deering and D. R. Cheriton. Multicast Routing in Datagram Inter- Networks and Extended LANs. ACM Transactions on Computer Systems, 8(2): , May [2] C. Diot, B. N. Levine, B. Lyles, H. Kassem and D. Balensiefen. Deployment Issues for the IP Multicast Service and Architecture. IEEE Network, Jan [3] R. Perlman, C. Lee, T. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, J. Thoo and M. Green. Simple Multicast: A Design for Simple, Low-overhead Multicast. Internet Draft, IETF, March [4] H. Holbrook and B. Cain. Source-specific Multicast for IP. Internet Draft, IETF, November [5] Y. H. Chu, S. G. Rao and H. Zhang. A Case for End System Multicast. In Proc. of ACM SIGMETRICS, June [6] B. Zhang, S. Jamin and L. Zhang. Host Multicast: A Framework for Delivering Multicast To End Users. In Proc. of IEEE Infocom [7] S. Banerjee, B. Bhattacharjee and C. Kommareddy. Scalable Application Layer Multicast. In Proc. of ACM SIGCOM, August [8] L. Mathy, R. Canonico and D. Hutchison. An Overlay Tree Building Control Protocol. In Proc. of Networked Group Communication, [9] S. Y. Shi and J. S. Turner. Multicast Routing and Bandwidth Dimensioning in Overlay Networks. IEEE JSAC, Volume 20, Number 8, October 2002 [10] N. M. Malouch, Z. Liu, D. Rubenstein and S. Sahu. Graph Theoretic Approach to Bounding Delay in Proxy-assisted, End-system Multicast. In Proc. of IWQoS [11] D. A. Helder and S. Jamin. End-host Multicast Communication Using Switch-Trees Protocols. In Proc. of the Workshop on Global and Peer to Peer Computing on Large Scale Distributed System (GP2PC), May [12] Z. Li and P. Mohapatra. HostCast: A New Overlay Multicast Protocol. In Proc. of IEEE ICC, [13] E. W. Zegura, K. L. Calvert and S. Bhattacharjee. How to Model an Internetwork. In Proc. of IEEE Infocom, March [14] Available at: [15] M. Castro, M. B. Jones, A. M. Kermarre, A. Rowstron, M. Theimer, H. Wang and A. Wolman. An Evaluation of Scalable Application-lavel Multicast Built Using Peer-to-peer Overlays. In Proc. of IEEE Infocom, [16] D. Pendarakis, S. Shi, D. Verma and M. Waldvogel. ALMI: An Application Level Multicast Infrastructure. In Proc. of 3 rd USENIX Symposium on Internet Technologies and Systems, March [17] V. Roca and A. El-Sayed. A host-based Multicast (HBM) Solution for Group Comunications. In Proc. of 1 st IEEE Int l. Conf. Networking, Colmar, France, July [18] A. Rowstron, A. M. Kermarre and A. Rowstron. Scribe: A Large-scale and Decentralised Application-level Multicast Infrastructure. IEEE JSAC vol. 20, no. 8, Oct [19] S. Ratnasamy, M. Handley, R. Karp and S. Shenker. Application-level Multicast Using Content-addressable Networks. In Proc. of Networked Group Communication, Nov [20] S. Zhuang, B. Zhao, A. Joseph, R. Katz and J. Kubiatowicz. Bayeux: An Architecture for Scalable and Fault-tolerant Wide-area Data Dissemination. In Proc. of NOSSDAV. June [21] I. Stoica, R. Morris, D. Karger, F. Kaashoek and H. Balakrishnan. Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications. In Proc. of ACM SIGCOMM, San Diego, California, August, [22] P. Francis. Yoid: Extending the Internet Multicast Architecture. Available at: [23] Duc A. Tran, Kien A. Hua and Tai T. Do. ZIGZAG: An Efficient Peerto-Peer Scheme for Media Streaming. In Proc. of IEEE Infocom, March