BM-ALM: An Application Layer Multicasting with Behavior ... - CiteSeerX

BM-ALM: An Application Layer Multicasting with Behavior Monitoring Approach Dewan Tanvir Ahmed and Shervin Shirmohammadi Distributed & Collaborative Virtual Environments Research Laboratory School of Information Technology and Engineering University of Ottawa, Ottawa, Ontario, Canada {dahmed, shervin} @discover.uottawa.ca

Abstract IP multicasting is the most efficient way to perform group data distribution, as it eliminates traffic redundancy and improves bandwidth utilization. Application Layer Multicast (ALM) has been proposed to overcome some of the limitations in IP multicasting such as scalability and deploy-ability. Limited computing power, scarcity of bandwidth and endhost’s reluctance to share bandwidth make ALM difficult to spread. In this paper, we keep eye to those problems and present an ALM that scrutinizes the commitment of the ALM nodes. Failure to provide quality of service agreement triggers performance penalty for the node in concern. Thus, every node has an obligation to its descendants; as a result, a nice collaboration among the end-hosts is achieved for group communication. It has good performance for content distribution, as it reflects physical network topology onto the overlay network constructed by the end-hosts. Tree refinement and backup path strategies are taken to better satisfy heterogeneous QoS requirements.

1. Introduction Arguably the most influential development to encourage and bring about the idea of application layer multicasting has been the tremendous success of peerto-peer file sharing applications such as Napster and its successors such as Kazaa. Peer-to-peer file sharing unequivocally illustrated the power of end systems (i.e. user machines) cooperating with one another in order to distribute media over the Internet without requiring any especial service from the underlying infrastructure other than the already provided best-effort unicast service. Millions of home Internet users with bandwidth limited dial-up and DSL connections could cooperate together in order to distribute Gigabits of

media content on the global network. Its success therefore encouraged the implementation of other forms of media distribution services such as teleconferencing and media on demand using the end systems acting as cooperating peers. Multicasting is proposed to support group data distribution. Traditionally, multicasting is implemented at the network layer, in the way that routers define a data delivery tree. As packets flow on this tree, they are replicated by the routers at the different branch points of the tree. IP Multicasting [1] is the most efficient way to perform group data distribution, as it eliminates traffic redundancy and improves bandwidth utilization on the wide-area network. After a decade of research into the various aspects of IP Multicasting such as routing, group management, address allocation, authorization and security, quality of service (QoS) and scalability, the widespread deployment of IP Multicast on the global inter-network has been dogged by technical, administrative and business related issues [2][3]. One of the problems is the deployment difficulty. Current deployment practices of IP Multicasting require manual configuration at routers to form the MBone, which makes it expensive to set up and maintain. Therefore an alternative has been proposed to shift multicast support from core routers to end systems. This is Application Layer Multicasting. In ALM, data packets are replicated at end-hosts instead of at routers. ALM systems are constructed on top of Internet unicast infrastructure where end-hosts self organize themselves into a logically connected network to support group communication. Usually self-governing ALM nodes are loosely coupled with each other and have the freedom to join/quit the multicast session at any time. These end-hosts have limited resources such as bandwidth and computing power. Moreover, nodes are reluctant to share their bandwidth. These constraints make it challenging to design an efficient

and robust ALM structure for multicasting. In this paper, we present a novel application layer multicasting method that monitors the commitment of ALM nodes to improve the overall system performance. We call it Behavior Monitored ALM (BM-ALM). Failure to provide agreed quality of service may trigger performance penalties for its own. Thus every node has an obligation to its descendants; as a result, a nice collaboration among the end-hosts is ensured for continual group communication. The rest of the paper is organized in the following sections. Section 2 covers a brief related work in this field. We present the BM-ALM architecture and the protocol in Section 3, while simulation results are discussed in Section 4. Finally we conclude the paper in section 5.

2. Related work There have been significant research activities in ALM-based protocols, some directed to real-time collaboration. Yusung et al. [4] proposed to construct topologically-aware data paths among the multicast group members. It does not need exact network topology, but it requires relative position of the members using the landmarks. Protocol partitions the members into topologically-aware clusters based on the ordering of their close landmarks. Topologicallyaware data paths can reduce unnecessary high latency and redundant network resource usage with low overhead over the existing scalable approaches. Instead of maintaining landmarks, BM-ALM uses endto-end delay to discover the physical topology. Wierzbicki et al. introduced Fastcast [5] for efficient peer-to-peer applications. It is a root based, online, and topology-aware ALM. It is controlled by a parameter, and by changing this parameter it is possible to tradeoff between used traffic and the worst-case length of the application layer path. BM-ALM considers resource limitation of end-hosts and assigns out-degree to each host based on the available uploading bandwidth. Yoid [6] defines a protocol for building a multicast tree using the distributed end hosts. It uses hop count as a measure of distance. BM-ALM on the other hand uses end-to-end delay which yields better results for real-time collaboration. Guo et al. proposed a solution to deal with the problem of disruption in live video streaming to a group of clients [7]. Video continuity is maintained in spite of the departing clients using a combination of time-shifted streams at the server and video patching. Both techniques demand high bandwidth not only from the server but also from the end users. BM-ALM considers the out-degree of each

node. Thus a client does not face the scarcity of bandwidth after joining the multicast group but the duration of audio/video disruption in BM-ALM might be longer than the approach of Guo et al. It is possible to combine these approaches to get the benefits of both. We observed that many ALM protocols (such as RMX, Gossamer, Bayeux, Borg, Scribe) operate based on an existing peer-to-peer substrate that serves as a mesh on top of which an overlay multicast tree can be constructed using either a reverse-path forwarding scheme (Gossamer, RMX, Scribe), or a forward-path forwarding scheme (Bayeux) or both (Borg). The advantages of these approaches include low control overhead and distributed management of the multicast tree, but they do not restrict the degree of each node and they are sub-optimal. Instead of maintaining a multicast tree, a multicast DAG (Directed Acyclic Graph) is constructed in ROME [8], to better satisfy heterogeneous QoS requirements from various receivers simultaneously by setting up multiple paths. This leads to extra overhead as compared to other ALM protocols. Moreover, ROME is suitable for MANs not for WANs. BM-ALM does not use fraction resources of a client. One of the focuses of it is to minimize the communication delay of the system. Thus it shuffles the organization of the overlay to let the resourceful node at the top of the multicast tree. If we are able to use the residual bandwidth of zero outdegree nodes like DAG and include the features that BM-ALM has, the overall performance of the system would be high in terms of resource usage and communication delay at the expense of message overhead.

3. The monitored ALM protocol With the involvement of ALM nodes, BM-ALM constructs an overlay structure for group communication. Dedicated proxy servers are deployed in the system and act like initial entry points for the participating nodes. An ALM node in BM-ALM is not only a receiver but also a forwarder to distribute the content to its children (if there is any) provided that it has enough resources in terms of bandwidth. The following sub-sections present design principles of the application layer multicast with behavior monitoring approach.

3.1. A mapping - Bandwidth to out-degrees Actually the feasibility of group communication over the ALM depends on whether or not there is

available bandwidth at the end-hosts. Usually the end hosts have asymmetric downloading/uploading rates. Moreover, the heterogeneity of outgoing bandwidth of the end-hosts can not be ignored when designing the protocol. In the reality, around 50% of hosts have zero out degree [9]. A node with zero out degree makes ALM not to scale beyond that point on the overlay structure. This fact cannot be overlooked and hence the protocol assigns degrees to nodes by considering their capabilities. For example, if the required bit rate is 244 kbps and a user has an outgoing bandwidth of 256 kbps making its degree to 1. It may happen that a user has zero out degree, e.g. pure receiver. This situation encourages us to refine the overlay structure.

3.2. Node signup In BM-ALM each node explores the overlay structure to find its best parent in terms of end-to-end delay. Every new member starts up by sending a JOIN _ REQ to its nearest proxy server. In order to lower the overhead of parent searching process in the multicast tree, the joining node also provides the depth limit as a scoping parameter. Once the server receives the join request, it delegates the request to its children to take care of the new node. If the server has a free out degree, it also reports the fact to the requester. All the children do the same as the server does. This parent searching process continues within the depth limit. It then chooses one of them as a real parent based on the end-to-end delay. If it does not receive any response it can re-send JOIN _ REQ with an increased maximum depth limit. This time it has to increase its waiting period to get the response just like the exponential back-off mechanism. Dewan and Shervin presented such node joining approach with an example in [10]. Moreover, instead of specifying the depth limit, node can also wait for a period of time after making the join request. This would be an indirect way to emulate the depth limit.

3.3. Backup parent – A fault tolerance method BM-ALM allows node to keep a spare connection to handle ungraceful parent departures. We named this spare connection as backup connection (parent). When the connectivity between the host and the real parent fails, the host quickly activates the backup connection without a new JOIN _ REQ which eventually reduces communication overhead and decreases lag time significantly. We consider two approaches for backup parent selection purpose. The simplest way to choose a

backup parent is to select the next best parent from the potential parent list that was built up during the primary parent selection phase. Naturally it is found that a group of people from the same locality has a common interest. So this might lead to blocking a good degree of an ALM node in its close locality. After while, when another node of the same region/proximity joins to the multicast session may suffer from the best close parent and hence ultimately increases cumulative end-to-end delay of the entire system. To handle such situation and keeping room for other nodes, it randomly selects the backup parent from the middle of the list that is sorted based on endto-end delay for the node in concern. In fact, this backup node might be a good parent for another new node. But when the protocol’s objective is to carry time dependent data, we target not to lose any data sent from the true sender (e.g. multicast source). It is chosen from the list of potential parents during the node joining phase. Thus there is no extra overhead associated with this policy. Obviously, backup parent must reserve the necessary bandwidth for its potential children. Say, Tbuffer is the playable time of the stored media of a host. Let the base time of the stream at the switching node and at the potential backup parent are Tbase _ switch and Tbase _ bp respectively. End-to-end delay between these two nodes is RTTswitch ,bp . We assume that member leaves a multicast session safely, i.e., it informs its children before departing the session and children are capable of continuing playback from the buffer at most Tbuffer time. A node selects a backup parent who satisfies the following equation:

(Tbase _ bp + RTTswitch ,bp + α ) ≤ (Tbase _ switch + Tbuffer )

We include α in this equation that represent switching overhead. If all potential parents fail to satisfy above equation, it chooses the best one among them. This policy tries to maximize continual playback during the parent switching period.

3.4. Tree refinement – Improving the overlay Depending upon the order of joining requests for the same set of nodes, constructed trees might be different and have different perception quality. Usually the quality of the path between any pair of members is comparable to the quality of the unicast path between that pair of members. So, we need a low height ALM tree. That is why we allow controlled refinement in the application layer multicast tree. BM-ALM applies refinement operation only at the node joining phase to

let Node N to pick Node P as its parent. Node P will be Node N’s child after the refinement operation if following conditions are satisfied; (1) delay ( N , par ( P )) < delay ( P, par ( P )) , (2) degree(N) > degree(P) , and (3) gain > 1 , where gain =

delay( P, par( P)) + ∑x∈child ( P ) (1 + N ( x)) × delay( x, P)

delay( N , par( P)) + ∑x∈child ( P ) (1 + N ( x)) × delay( x, N )

N(x) and par(x) represent number of descendants and parent of Node x. Nodes having higher degree (i.e. bandwidth) are moved up in order to limit the height of the multicast tree by the use of second condition. First and third conditions focus on the local and the global optimization of the tree.

3.5. Handling member departures The most critical part of the ALM approach is to deal with the node departures. Whenever a node decides to leave, it has to cleanup all its active connections. So it requires informing all active communication partners to make the system consistent. But in real situation this is not so easy. Actually, departures can be divided into two categories graceful departure and ungraceful departure. In a graceful departure situation, a leaving node notifies its communication partners and then it leaves, so the nodes can update their states and reconstruct the tree. The member is permitted to leave after all of its children are able to join the tree. In an ungraceful situation, the node leaves without any notification. To handle this case, every node must deploy a node departure detection mechanism. This mechanism is similar to the fault-detection algorithms, where a “keep alive” message is sent to a communication partner, and timer is started, say for T seconds. If the timer elapses and it does not receive any acknowledgment, then the node can be confirmed that the other partner has been departed and then acts accordingly. Children of departing node then switch to their backup parents. Nodes can re-initiate JOIN _ REQ to discover their new backup parents while being connected to the multicast tree.

3.6. Monitoring ALM nodes – Quality control The performance of ALM indeed depends upon the cooperation of the ALM nodes. Most of the cases endhosts are reluctant to share their bandwidth but on the other hand they themselves demand high bit rates. In order to monitor the behavior of the ALM nodes, we deploy behavior monitoring policy. Each node learns the identity of its grandparent through an explicit query

to the proxy server. Node then reports to its grandparent about the behavior of its parent. Based on the feedbacks grandparent can take an action by reducing the service to that particular node. As all the nodes have some obligation to ensure certain performance, hence the performance of the entire system is guaranteed to a certain extent. This is a way to fulfill the commitment in an indirect way. A l bps W B x bps

C D y bps z bps

Figure 1. Controlling QoS The multicast tree is constructed incrementally according to the agreed bit rates between a pair of nodes. In Figure 1, Node B, C and D report to Node A about the committed and offered services of their parent (here the parent is Node W). If there is no discrepancy between committed and offered services, that node of the tree is performing a good job. Moreover the performance of the tree is not hampered by that node at least. Otherwise, by applying following formula Node A calculates the percentage of average service deviation caused by that node. CS ( x) − OS ( x) × 100 ∑ x∈child ( w ) CS ( x) , service _ deviation, d % = NOD(W ) where CS and OS are committed service and offered service respectively and NOD(W) represents number of descendants of Node W. In that case Node A will reduce the offered service by an amount of d % for Node W (Figure 1). But there is a chance of chain of complains. For example Node W can complain about Node A to its grandparent. To handle this situation, Node A informs to its parent, i.e. grandparent of Node W, about the penalty of Node W to nullify impious complain. This reporting is cross-checked to make the system operational. Hence the behavior monitoring scheme provides punishment for each node when it goes against its commitment. The root of the tree has no parent to whom level-one children can send complains. Actually this is unnecessary, as the root is the true sender of multicast data. This feedback of service is carried out in periodic fashion and allows the nodes to recover from punishment if there are any.

Moreover, a wicked node may decide to report to its children that it leaves the network and obtain a highquality connection from its parent without further distribution of the content to the children. To handle this situation, grandchildren reports up to the grandparent and grand-backup parent about the incident. So the wicked node can easily be detected during the multicast session and get the punishment of low bit rate.

4. Simulation results We verified the performance of BM-ALM through extensive simulation. In an area of 106 square units, servers and nodes are placed randomly. We assume that each node has the information of its nearest server where it will send its join request. Around 1000 nodes start joining to a multicast session at a particular instant of time. We define system utilization as a ratio of used bandwidth to available bandwidth. BM-ALM maps each node’s bandwidth to its out degree and hence system utilization becomes the ratio of consumed degrees to available degrees. The consumed resources are in the range of 22% to 28%. This is a good indication of a scalable system. It also indicates that reservation of bandwidth through spare connection is not superfluous. Due to space limitations we are not mentioning detail results and discarded the figures. The quality of the constructed overlay is verified through the depth of the tree, the average and the standard deviation of the end-to-end delay to parents. With a single server, even though the average and the standard deviation are almost identical for a large number of hosts but the joining latency is high that indicates the necessity for multiple servers. Hence to carry time dependant media over ALM multiple servers/proxies are essential. The tree refinement policy deployed by BM-ALM enhances system’s performance by reducing cumulative end-to-end delay. This is because through refinement operation a node having higher degree and lower communication latency joins close to the server. We compare the performance of BM-ALM with ProBaSS [11]. ProBaSS is a greedy approach where a node searches all the nodes from the root to the leaf on a particular path. As compared to BM-ALM, it may have lower communication delay to its parents. But scalability is a big issue in ProBaSS. In a real situation, many of the nodes have zero out-degree. So when a zero out degree host joins to the ALM tree it can’t scale beyond that point. And if all nodes on that path are engaged then a joining host following that path fails to join. But BMALM applies depth limit search that explores all the paths within the depth limit.

5. Conclusion In this paper we presented a monitored ALM approach to distribute group data in multicast fashion. Collaboration architecture of BM-ALM is designed to support heterogeneous end-hosts. It constructs efficient overlay structure with the help of multiple-servers and reduces overall end-to-end latency through tree refinement operation. BM-ALM scrutinizes the commitment of ALM nodes. Failure to provide the QoS agreement may trigger performance penalty. Thus, every node has an obligation to its descendants; as a result, a nice collaboration among the end-hosts is ensured for continual group communication.

6. References [1] S. Deering and D. Cheriton, "Multicast routing in datagram internetworks and extended LANs,” ACM Trans. on Computer Systems, 8(2):85--110, May 1990. [2] A. El-Sayed, V. Roca, and L. Mathy, "A survey of proposals for an alternative group communication service," IEEE Network Magazine, vol.17, no.1, pp.46– 51, Jan-Feb. 2003. [3] B. Zhang, S. Jamin, and L. Zhang, "Host multicast: A framework for delivering multicast to end users," Proc. of IEEE INFOCOM, pp.1366–1375, New York, NY, June 2002. [4] K. Yusung and K. Chon, “Scalable and Topologicallyaware Application-layer Multicast”, Proc. of GLOBECOM, vol. 2, pp. 1266 – 1270, 2004. [5] A. Wierzbicki, R. Szczepaniak, M. Buszka, “Application Layer Multicast for Efficient Peer-to-Peer Application”, Proc. of IEEE WIAPP, pp. 126-130, 2003. [6] P. Francis, "Yoid: Extending the multicast Internet architecture," 1999, white-paper, http://www.icir.org/yoid/ [7] M. Guo and M.H. Ammar, “Scalable live video streaming to cooperative clients using time shifting and video patching.” Proc. of IEEE INFOCOM, Vol. 3, pp. 1501 – 1511, 2004. [8] Y. Jiong, “Deliver Multimedia Streams with Flexible QoS via a Multicast DAG”, Proc. of ICDCS, pp. 126135, 2003. [9] K. Sripanidkulchai, A. Ganjam, B. Maggs, and H. Zhang, "The feasibility of supporting large-scale live streaming applications with dynamic application endpoints", Proc. of SIGCOMM, 2004. [10] D.T. Ahmed and S. Shirmohammadi, “A Hybrid P2P Protocol for Real-Time Collaboration”, Proc. IEEE Workshop on Collaborative P2P Information Systems, Manchester, U.K., June 2006. [11] Y. Zhong, S. Shirmohammadi and A. El Saddik, “Measurement of the Effectiveness of ApplicationLayer Multicasting”, Proc. of IEEE IMTC, 2005.