DualCast: Protocol Design of Multiple Shared Trees Based Application Layer Multicast

Transcription

1 th IEEE International Conference on Parallel and Distributed Systems DualCast: Protocol Design of Multiple Shared Trees Based Application Layer Multicast SHAN Baosong, LIANG Yuan, ZHOU Mi and LOU Yihua State Key Lab. of Software Development Environment School of Computer Science and Engineering Beihang University, Beijing , China Abstract This paper introduces a new approach to build application layer multicast overlay Multiple Shared Trees. Multiple shared trees approach makes tradeoffs between traditional source-based trees and single-shared tree, and between transmission efficiency and protocol overheads. Based on this, we propose two protocols to build ALM overlay among end users and media-forwarding-gateways respectively. The latter references the design thought of Aggregated Multicast to share the multicast trees among groups. 1 Introduction As the multimedia applications are more and more common on the Internet, and the IP Multicast[1] is poorly deployed due to many technical and non-technical reasons[2], application layer multicast[3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13] has been a hotspot of recent research works. Many application layer multicast protocols are designed to replace the IP multicast and improve the transmission efficiency of multimedia data. According to the multicast trees types, the protocols are mainly divided into two types: source-based trees and single-shared tree. Protocols of the former type will construct a tree for each media source (i.e. sender), while those of the latter type will only construct one single tree within a multicast group s scope and all the senders share the tree to forward data. Narada[3] is a typical source-based trees protocol. It provides very efficient data transmission service as long as the group scope is relatively small. As the group size increases, the control overheads of Narada systems will increase very rapidly. Yoid[4] employs singleshared tree to transmit data, so it can support fairly large group. Yet because all the members are in one single tree and each node cannot have too many outbound degrees, the depth of the tree will be relatively high, which causes high latency. For the real-time interactive multimedia applications (such as video conferencing and remote educating), low latency and middle to large scaled groups are both required to be supported. So why not make a tradeoff between efficiency and scalability? Tan has proposed an approach[14] using multiple shared trees, yet there is no detailed design of many principle problems like the numbers of roots, the placement of roots, data transmission algorithms, etc. This paper proposes a new method to transmit data which employs multiple shared trees. That is, the number of (application layer) multicast trees is more than one and far less than the total number of sources. Based on it, we propose two protocols, Group Cast and Global Cast, which use multiple shared trees within a group s scope and in the global scope respectively. For the first protocol, multicast trees serve only the members of a session or a group. For the second protocol, any tree can serve members in more than one groups, for example, members in several different conferences, just like the aggregated multicast[15]. Further, we emerge the two protocols in the ADMIRE[16] system, to provide two types of service for video conferences. The former is to serve the peer to peer conferences for end users. The latter is to construct an application layer multicast overlay network of media-forwarding-gateways to provide more reliable service. The rest of this paper is organized as follows. In Section 2 we introduce the principles of multiple shared trees, which is our working basis, and an overview of the solution. Section 3 and section 4 describe the Group Cast and Global Cast in detail. Section 5 presents the evaluation results. Section 6 talks about the implementation and application plan of the protocols. Section 7 presents the conclusion and future work /08 $ IEEE DOI /ICPADS

2 2 Principles of Multiple Shared Trees Traditional protocols of IP multicast and application layer multicast employ either source based trees or single shared tree to transmit data among all the members. Suppose we have a group with n members and ns source members (senders). Source-based trees protocols will construct and maintain ns trees while single-shared tree s protocols will only construct one single tree. In application layer multicast, the outbound degree of each member cannot be very large due to the limited bandwidth and processing ability of end user terminals. So if n and ns are both very large, there will be very high overheads for sourcebased trees protocols and very high latency for singleshared tree s protocols. For example we have a conference group of 100 members, and 10 of them are media senders. The maximum outbound degree of each tree node is limited to 2. If we use source based trees, we need to establish 10 trees and maintain all the connecting information of each node in each tree. For every member, it should have a route table of 99 entries. For single shared tree, if we use non-directional delivery tree, the average delay will be relatively high, and the maximum delay will be high if we employ bi-directional delivery tree. In this example, the maximum delay can be as high as 14 if we use bi-directional tree. Then we could conclude that in ALM, source-based trees protocols are suitable for small group communications and single-shared tree s protocols are suitable for noninteractive applications, such as video on demand (VOD) service. In order to deal with the cases that group size and the number of senders are both very large, we propose a different design named multiple shared trees. The principle idea of multiple shared trees, is to make a tradeoff between source based trees and single shared tree. We will construct m trees and m is larger than 1 and far smaller than ns. Because the overheads increase rapidly with tree number, the relatively small tree number will make sure the overheads are not too high. And we can also control the interactive trees depth to make sure the latency is not too high either. 2.1 Each Node in One Tree or Each Node in All Trees? There are two ways to use multiple shared trees to forward data across the trees. One is that each node joins only one tree, and all the trees roots build an all-connecting mesh to forward data across different trees. The other is that each node joins all the trees, and each node will select a specific tree to forward data. The design of each node in one tree is somehow a variation of single shared tree, except that the roots of all the Figure 1. Ratio of Average Delay Figure 2. Ratio of Maximum Delay trees can connect with each other and thus build an allconnecting mesh. The protocol cost of it will be similar to single-shared-tree but it is very difficult to control the average and maximum delay. If each node joins all the trees, and protocol cost is m times as the design of each node in one tree where m is the number of trees. Since each node is in all the trees, the sender need send data to only one tree which it is nearest to the root. We have carried out some experiments to compare the two designs. Figure 1 and 2 show the ratios of average delay and maximum delay of three application layer multicast protocols HTMP[17], Yoid[4] and MST using each node in one tree. The results show that each node in one tree cannot achieve better delay than single-shared-tree. And because the number of the tree is far less than the number of senders, which means the protocol cost of it can be well controlled, we finally choose to let each node join all the trees. 2.2 How Many Trees Should Be Constructed? We have mentioned that the number of the trees should be far less than the number of senders in order to control the protocol overheads. How is the number of the trees determined? Suppose the trees are to serve members in a video conference, all the members are at least RTCP[18] data senders 866

3 Figure 3. l-tree and s-trees Figure 4. New Source S4 Joins and some of the members are audio RTP senders or video RTP senders. RTCP data is not sensitive to delay while RTP data s delay should be controlled to ensure the interactive effect. All the non-rtp-source members construct a delivery tree called listener tree (l-tree). And all the RTP source members construct a few delivery trees called source trees (s-trees). Note that every source member should join all the s-trees, and normally, the position and role of the same member in different s-trees are different. The following figure shows the l-tree and s-trees. Next we will explain how should these s-trees be constructed. First we set two threshold values: the maximum number of s-trees (nt max ), and the maximum fan-out degree of nodes on s-tree (d max ). As long as the number of s-trees (nt) does not exceed nt max, each new source node can construct a new s-tree rooted on itself, and currently, only the root node is a source node, call the other nodes are called listener nodes). After nt reaches the value of nt max, any new source node has to join one of the existing s-trees as a source node (not root now). The new node should join on one s-tree as a source node and be at the as higher level as possible, and join the other s-trees as a listener node. Note that on s-tree, new joined source node can replace the position of any listener node, pushing it to some lower level, while source nodes positions cannot be replaced. For example, the first non-root source node can take the place of any second-level listener node on some s-tree, and then joins the other s-trees as a listener node (usually as a leaf node). The following figure shows how a new source joins after nt reaches nt max. The roots of s-trees should forward data from tree to the root of l-tree. Also the root of l-tree forwards data from l- tree to the roots of all the s-trees. A RTP source node only sends data to the s-tree on which it is marked as a source node. 2.3 Which Nodes Should Be Roots? As the number of source nodes increases, the s-trees may need to be optimized. In video conferences, audio data is normally forwarded to all participants while video data is only forwarded to those who subscribe the data, which is called forward on demand. We use n s to count the subscribers of a source node, a source node would record the n s values of itself and all its children. When there exist a child whose n s is larger than its parent and the difference exceeds a preset threshold, the parent will exchange positions with the child who has the most subscribers of its brother nodes. By this kind of promotions, the most popular source nodes will become higher and higher on the s-trees, till becoming roots. The threshold value is to avoid instability of s-trees. Based on the idea of multiple shared trees, we propose two protocols Group Cast and Global Cast, which would be introduced in the next 2 chapters. 3 Group Cast: Multiple Shared Trees within agroup In video conferences, a group corresponds to a meeting room. Members within a group communicate with each other while non-members will not receive any data of this meeting. Group cast builds multiple shared trees to serve only members within the scope of a specific meeting. 3.1 Trees Construction A new RTP listener member will get a potential parents list of l-tree from the rendezvous point. Then it will perform some quick tests to sort the list and tries to join as a new child of the node on the list one by one till the join succeeds. A new RTP source member will get a potential position list of the s-tree from the rendezvous point, on which the member will become source node. The list may consist only the member itself, which indicates that the member should construct a new s-tree rooted at itself and then the other source members will join this tree later. Otherwise, the member should communicate with the nodes of the list one by one till succeeding to take some node s place and tries to add the node being replaced as a child. Also the 867

4 Figure 6. Node Promotion Optimization Figure 5. How Node L4 Leaves l-tree rendezvous point will return lists of potential parents of the other s-trees, on which the member will be listener nodes, and then the member joins the s-trees one by one. A RTP source node may become a listener node, and vice versa. Under such conditions, the node should leave the old tree and joins the new tree. The node needs to promote one of its child who has the deepest subtree to replace its position. And the role-changed node joins the l-tree or s-trees as the above explains. The following figure shows how a node leaves the original tree. 3.2 Route Tables Nodes on the l-tree maintain routing information of parent and children, and data is forwarded bi-directional along the tree. Nodes on the s-trees maintain routing entries of parent and children of each s-tree, and should mark if it is a source node or a listener node on a specific tree. Also the number of the video subscribers of a source node and that of its each child source node are recorded. For nodes on l-tree: self-generated source data is sent to all the neighbors (including parent and children). incoming data is forwarded to all the neighbors except for the one from which the data comes. For nodes on s-trees: self-generated source data is sent to all the neighbors of the tree on which the node is marked as a source node. incoming data is forwarded to all the neighbors of the same tree except for the one from which the data comes. 3.3 Trees Optimization Members on s-trees are interacting users, that means they are probably talking with each other and even watching each other s video during talking. While the members on l-tree are currently listening and watching others without sending their audio or video data. So the most important thing is to optimize the s-trees to make the interactive delay as small as possible. When the number of interacting members does not exceed nt max, the protocol is working like Narada, although the routing algorithms are not the same. The Problem is how to deal when many members are talking with each other at the same time. The principle thinking is to make the popular source nodes move to the upper levels of s-trees, which could achieve smaller average delay. The optimization operation is shown in the following figure. Source nodes on the s-trees record the number of its subscribers and report the number to its parent. The parent will exchange the positions with its most popular child, when the child has more subscribers than the parent and the difference reaches a certain extent (threshold value). On the other hand, the rendezvous point will count the source nodes on each s-tree, and have the new source node join as a source the s-tree with the least source nodes. 4 Global Cast: Multiple Shared Trees across Groups Using multiple shared trees (MST) within a group, we construct the application layer multicast overlay among end users. While in some cases, the conferencing service need to be more responsible, so we will organize the mediaforwarding-gateways (we will short its name as MFG ) to form an ALM overlay and the end user acquire multimedia data from the nearest MFG. Yet ALM overlay among MFGs is different from that among end users, because it will serve many groups (conferences). If the trees still serve only one group, the control overhead will increase rapidly as the number of groups grows. So we reference the design of aggregated multicast, and make the MST to serve all the groups. MFG performs join action when the first end user requests service from it, and performs leave action when the last end user leaves. Further, Border Media Gateway[19] is engaged on links of s-trees between the nodes who belong to different internet service providers and the default route path between 868

5 Table 1. Protocol Evaluation Results of Yoid, Narada and MST Protocol Maximum Routing Entries Yoid d max +1 Narada n src + n lis 1 MST nt max (d max +1) Protocol Maximum Number of Trees Yoid 1 Narada n src MST nt max +1 Table 2. Protocol Evaluation Results of Yoid, Narada and MST Protocol Max. Interactive Path Length Yoid 2 log dmax Narada log dmax MST log dmax (n src ) Protocol Max. Path Length (Cont.) Yoid 2 log dmax Narada log dmax MST log dmax (n src ) + log dmax (n lis ) them is weak. BMGs replace the weak or bad links between autonomous systems, especially the ones belonging to different Internet Service Providers. In some cases, this could improve the transmission efficiency as much as 80-90%. 5 Evaluation Results Our algorithms of multiple shared trees take the forward on demand into account and are designed specially for interactive multimedia data applications, so the interactive delay is the most important parameter we care about. Also the protocol cost is very important for the scalability of the implementations and applications. Assume we have a group of 100 members and at most 10 members are interactive members at the same time. We set the maximum number of s-trees is 5, and the maximum fan-out degree is 3. The maximum data delivery path in s- trees is 3 and maximum routing entries of each source node is 20. In l-tree, the maximum data path is 8 and the maximum number of routing entries of each node is 4. As for Narada, the maximum data delivery path is 4 and the number of routing entries of each node is 99. As for Yoid, the maximum data delivery path is 8 and the number of routing entries of each node is 4. Generally, the protocol evaluation results of Yoid, Narada and MST are shown in the two tables. d max stands for the maximum of fan-out degree. n src stands for the number of RTP source nodes and n lis stands for the number of non-rtp-source nodes. nt max stands for the maximum number of s-trees, a constraint value in MST. From the tables we can conclude that when the number of total members is very large, the protocol overheads of Narada are very high. And because neither Narada nor Yoid treats source nodes and listener nodes differently, the interactive latency of MST is generally the best of those. 6 Implementation and Application The ADMIRE[16] System is an IP based video conferencing system that could be accessed by both unicast and IP multicast users. The unicast users send/receive multimedia data to/from MFGs which exchange data for multicast and unicast users. As the scale of the system grows, the problems caused by the C/S structure such as single point failure and traffic centralization raise, causing the scalability and stability of the system cannot be guaranteed very well. So we will employ both protocols on the ADMIRE system. We will expand the conference types to personal meeting and business conference. For personal meeting, we use Group Cast to make end users to form an ALM overlay employing MST within a group. And for business conference, we provide MFGs to serve end users, and all the MFGs form an ALM overlay using Global Cast across groups. So the server resource is saved for more important business conferences. The bandwidth wastage will be reduced and the transmission latency is controlled within the acceptable level. 7 Conclusions This paper presents the Multiple Shared Trees design and two application layer multicast protocols based on it. The MST design improves data transmission efficiency and shortens the transmission latency of interactive users, and keeps protocol cost within the acceptable level, which can be adjusted manually. Group Cast builds ALM overlays among end users and Global Cast build ALM overlays among MFGs, which provide more reliable and stable service. More experiments need to be carried out to collect the performance data. Optimization algorithms and node failure detecting and repairing algorithms need to be further 869

6 improved to get better transmission efficiency, lower total latency, and higher system stability. Acknowledgment This research was jointly supported by National Basic Research Program of China (Grant No.2005CB321903) and Hi-tech Research and Development Program of China (Grant No.2006AA01Z19A). References [1] S. Deering, Multicast Routing in a Datagram Internetwork, Ph.D. dissertation, Stanford University, [2] C. Diot, B. N. Levine, B. Lyles, H. Kassem, and D. Balensiefen, Deployment issues for the IP multicast service and architecture, IEEE Network, vol. 14, no. 1, pp , / [Online]. Available: citeseer.ist.psu.edu/diot00deployment.html [3] Y. Chu, S. Rao, S. Seshan, and H. Zhang, A case for end system multicast, Selected Areas in Communications, IEEE Journal on, vol. 20, no. 8, pp , [4] P. Francis, Yoid: Extending the Internet Multicast Architecture, Unpublished paper, available at html, Apr, [5] S. Banerjee, B. Bhattacharjee, and C. Kommareddy, Scalable application layer multicast. ACM Press New York, NY, USA, [6] M. Castro, P. Druschel, A. Kermarrec, and A. Rowstron, Scribe: a large-scale and decentralized application-level multicast infrastructure, Selected Areas in Communications, IEEE Journal on, vol. 20, no. 8, pp , [7] E. Brosh and Y. Shavitt, Approximation and Heuristic Algorithms for Minimum-Delay Application Layer Multicast Trees, IEEE INFOCOM, vol. 4, pp , [8] Y. Zhu, B. Li, and J. Guo, Multicast with network coding in application-layer overlay networks, Selected Areas in Communications, IEEE Journal on, vol. 22, no. 1, pp , [9] A. Sobeih, W. Yurcik, and J. Hou, VRing: a case for building application-layer multicast rings (rather than trees), Modeling, Analysis, and Simulation of Computer and Telecommunications Systems, 2004.(MAS- COTS 2004). Proceedings. The IEEE Computer Society s 12th Annual International Symposium on, pp , [10] R. Tian, Q. Zhang, Z. Xiang, Y. Xiong, X. Li, and W. Zhu, Robust and efficient path diversity in application-layer multicast for video streaming, Circuits and Systems for Video Technology, IEEE Transactions on, vol. 15, no. 8, pp , [11] T. View, ostream: asynchronous streaming multicast in application-layer overlay networks, Selected Areas in Communications, IEEE Journal on, vol. 22, no. 1, pp , [12] P. Baumung, M. Zitterbart, and K. Kutzner, Improving delivery ratios for application layer multicast in mobile ad hoc networks, Computer Communications, vol. 28, no. 14, pp , [13] Y. Kunichika, T. Kusumoto, J. Katto, and S. Okubo, Application Layer Multicast with Proactive Route Maintenance over Redundant Overlay Trees, 2004 Packet Video Workshop. [14] S. Tan, G. Waters, and J. Crawford, A multiple shared trees approach for application layer multicasting, Communications, 2004 IEEE International Conference on, vol. 3, [15] A. Fei, J. Cui, M. Gerla, and M. Faloutsos, Aggregated multicast: an approach to reduce multicast state, Global Telecommunications Conference, GLOBECOM 01. IEEE, vol. 3, [16] T. Jin, J. Lu, and X. Sheng, Admire a prototype of large scale e-collaboration platform, Lecture Notes in Computer Science, vol. 3033, pp , Jan [17] B. Zhang, S. Jamin, and L. Zhang, Host multicast: a framework for delivering multicast to end users, IN- FOCOM Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3, [18] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RFC3550: RTP: A Transport Protocol for Real- Time Applications, Internet RFCs, [19] B. Shan, X. Sheng, and T. Jin, Border Media Gateway: Extending Multimedia Multicast Gateway to Support Inter-AS Conferencing, Communication Technology, ICCT 06. International Conference on, pp. 1 4,