Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM

Transcription

1 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM Eduardo Lidanski, Julius Rückert Technical Report PS-TR Fachgebiet Entwurfsmethodik für Peer-to-Peer-Systeme (PS)

2 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM Eduardo Lidanski, Julius Rückert Technical Report PS-TR First published: April 7, 2014 Last revision: April 7, 2014 For the most recent version of this report see Technische Universität Darmstadt Department of Electrical Engineering and Information Technology Institute of Computer Engineering Peer-to-Peer Systems Engineering Prof. Dr. David Hausheer

3 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM 1 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM Eduardo Lidanski, Supervisor: Julius Rückert Abstract Application Layer Multicast (ALM) systems have received increased attention from researchers in the past years as an alternative to traditional server-client-based streaming systems. These can be basically classified into tree-based approaches or mesh-based approaches. Some systems, for example MTreebone, have been proposed as hybrid overlays in order to combine these approaches. In the present article, our MTreebone implementation on the discrete event-based PeerfactSim.KOM simulation framework is presented. Its specific concepts, problems encountered and their respective solutions are thoroughly discussed. I. INTRODUCTION Video streaming systems are increasingly popular on the Internet. During video streaming the user can start watching the video content while downloading, without having to wait for the whole video to be loaded. This allows popular events (e.g. football matches or concerts) to reach a wide audience in near real-time. Traditional video streaming is done in a client-server manner, in which the clients download the video from the server while watching. This imposes big costs on the server, e.g. on bandwidth requirements. So clientserver architectures do not scale well for video streaming applications. For circumventing this scalability problem, P2P approaches have been proposed. In P2P video streaming systems, users contribute with their own resources, e.g. with their upload bandwidth capacity. These P2P approaches can be basically categorized into tree-based approaches or mesh-based approaches. These approaches have both advantages and drawbacks. Hybrid approaches, like MTreebone [5], aim at combining both approaches to a hybrid overlay. In this paper, we describe our implementation of the MTreebone system on a discrete event-based simulator for P2P systems. This paper is organized as follows. Section II presents necessary background information in order to understand the advantages and drawbacks of different streaming overlays. The simulation engine is also briefly presented. In Section III the MTreebone hybrid overlay is thoroughly discussed. Section IV then describes our own MTreebone implementation, with its specific concepts and problems encountered. Section V then presents open issues and ideas for further work on our MTreebone implementation. Finally, Section VI concludes the paper. II. BACKGROUND As shown on the previous section, traditional server-based video streaming incurs a significant cost. Therefore, research on alternatives has been intensely done in the past years. One prominent alternative is IP multicast. IP multicast is based on the Internet Protocol (IP), which supports multicast groups. On IP multicast, routers are responsible for the packet duplication while delivering the media content to the multicast group. However, it has never been widely deployed on the Internet because of the increased complexity on intermediate routers and protocols. In order to support IP multicast, all intermediate routers would have to be replaced. Because of the shown inapplicability, Application Layer Multicast (ALM) has been proposed as an alternative. In ALM, the duplication of the video packets is done at the application layer instead of at the IP layer. So the end-nodes are responsible for the packet duplication while multicasting, not the intermediate routers. The video contents are duplicated and sent to other users at the end-node applications. This contrasts with IP multicast, in which, as shown, the routers are in charge of this. Because of this fact, no intermediate routers must be changed in ALM, since the application layer of the end-hosts is responsible for all packet duplication and forwarding. In ALM systems, end-users contribute with upload bandwidth and processing capacity to other users, so they are promising P2P video streaming systems. Such ALM systems have a major drawback that must be addressed. End-nodes are, in contrast to routers, very unreliable. End-nodes can join and leave the system dynamically, i.e. at any moment. This leads to the fact that the actual set of currently available nodes is highly unpredictable. ALM systems must thus address this problem by maintaining and repairing the overlay when a participant leaves the system or when new users join the system. Several ALM techniques have been proposed. They can be classified in tree-based overlays, mesh-based overlays and hybrid overlays. These are presented next. A. Tree-based topologies As shown in the previous section, ALM systems are a promising solution for P2P video streaming. End-users contribute with upload bandwidth and processing power in order to forward the video contents to other users. The nodes in the multicast group must thus be coordinated in order to ensure that all peers receive the necessary packets for correct video playback in a timely manner. The most natural and efficient way in terms of bandwidth and delay optimization to organize peers in such an overlay is in a tree-based scheme, in which a tree is constructed to redistribute the video contents to all multicast participants. Tree-based topologies can be classified

4 2 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM as single-tree-based or multi-tree-based systems. In this article, single-tree-based topologies are discussed. An overview of multi-tree-based topologies can be found in [2]. These are more complex to be constructed and maintained and not further discussed here. In single-tree topologies, as the name suggests, a single tree is constructed routed at the streaming source. Users interested in the video join the overlay either as interior or as leaf nodes. The exact position of a joining node is determined by the protocol. The video is then pushed from the source to the leaves of the tree. For this reason, tree-based topologies are also called pushed-based topologies. Interior nodes are responsible of forwarding the video content to their own children. Children contribute to the system by duplicating the packets they receive from their parents and forwarding them to their own children using unicast. Since nodes automatically forward the content they receive to their children, no complex scheduling mechanisms have to be deployed because of the inorder packet delivery, which in turn maintains the data delivery delay low. Single-tree overlays have two major drawbacks that must be addressed for timely and correct video distribution. The first one is robustness. When a node leaves the system, the video delivery is immediately broken if the leaving node is an interior node. Its children loose video packets while the tree is being repaired, so they have significant playback interruptions. They are temporally disconnected from the overlay. Load balancing is a further issue of single-tree overlays, in which only a small subset of nodes (the internal nodes) forward video content to all peers. Leaf nodes (the majority of the nodes) only receive the media content without contributing to the system. Because of this, a great amount of potential upload bandwidth in the system is wasted. Figure 1 shows an example tree topology. In the figure, nodes A and B are responsible to forward the video content to their children C, D, and E. If one of them fails, e.g. node A, then nodes C and D will have playback interruptions because of the failure while re-attaching to the tree. Further, only the internal nodes A and B are responsible of forwarding all the video content, while the leaf nodes C, D, and E are only consuming content, without contributing to the system. Fig. 1. Example tree-based overlay (adapted from [3]) B. Mesh-based topologies In mesh-based systems, the individual peers periodically exchange their video content availability, i.e. which video blocks they currently possess, with a list of neighbors each peer maintains. Based on this information (called buffer maps), peers actively request blocks they need from their current neighbors. If a neighbor does not currently possess interesting blocks, a new connection to another peer may be opened. Because the video blocks are being actively requested, i.e. pulled, such systems are also called pull-based topologies. Because of this block availability exchange mechanism, mesh-based topologies are more resilient to node dynamics than tree-based topologies. If a node leaves, no other nodes are affected, i.e. no other nodes are disconnected from the system, in contrast to tree-based topologies. Nodes can remove neighbors from their current neighbor list dynamically, and nodes can request blocks from another neighbor that is currently present in the system who advertised the missing block previously. However, this mechanism adds delay in distributing the video content to all participants. A node has to wait for the buffer maps from its neighbors, then request missing blocks, and then wait for these requested blocks. This adds message overhead and thus higher delay to the system. Because of the reasons shown in the current section, meshbased systems are more robust than tree-based systems, but experience higher delays and higher control overhead. The system we implemented combines the advantages of both approaches and is presented in Section III. C. Simulation Framework We use in our implementation the PeerfactSim.KOM simulation framework [4], which is an event-based simulator for P2P systems. The simulator is structured in a layered architecture based on the ISO/OSI model of communication networks. For our implementation, we develop the MTreebone architecture in the Overlay Layer. This permits us to use the same overlay implementation on different network models, for example. This also allows us to evaluate the implementation on different churn models. Further details of the framework can be found in [4]. III. MTREEBONE MTreebone [5] is an approach to a hybrid overlay design, which combines the advantages of both tree-based systems and mesh-based systems. It aims at creating a system which is both robust and efficient, thus mitigating the drawbacks discussed in the previous section. The main idea is to construct a treebased backbone, called the treebone, which consists of the stable peers in the system. The treebone thus contains only a subset of all peers in the system, in contrast to tree-based overlays. All other unstable peers are attached to the backbone as outskirts. The video is then streamed from the source to the outskirts via the stable nodes in a tree-based way. Only stable peers are internal peers, which are less likely to fail or leave the system. In MTreebone, most of the video stream is pushed through the treebone, eventually reaching the outskirts. This is shown in Figure 2(a) in which the shadowed nodes represent the stable (treebone) nodes, and the white ones the unstable ones. Further, a mesh network is maintained as an auxiliary overlay. All nodes participate in this mesh overlay. Figure

5 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM 3 2(a) shows this mesh neighborhood as dotted lines. Similar to the presented mesh overlays, buffer maps are periodically exchanged between mesh neighbors, which contain their data availability. But, different from the mesh networks presented, a node does not actively schedule to request data blocks from its neighbors using the buffer maps information, but maintains this information as a backup to use on data outage. Figure 2(b) shows two node failures. Node A and node B leave the system. Since node A is an unstable node, its departure does not cause any data outage. No other node is dependent on it, so nothing else must be done. If a stable node e.g. B fails, other nodes will be dependent on it and will be affected. In the example, C is temporally disconnected from the treebone because of B s departure. But, even though C is affected, it can easily pull the missing data from its mesh neighbors while the treebone is being repaired and it can reattach. Thus, the mesh overlay mitigates the effect of node dynamics. The tree has to be repaired only when a stable node fails, and this happens, as shown in the current section, with a lower probability (thus less often) than an unstable node failure. has the drawback that, before T (0), i.e. before 30% of the total session length, no nodes are included in the treebone. In order to solve this problem, a randomized promotion algorithm is introduced for the initial period of the session. For a node arriving at time t, the algorithm aims to achieve a probability s/t (t) for the node to be in the treebone when its age is s. So each unstable node checks its status per unit time; for the s-th check it will be promoted to the treebone with probability 1/(T (t) s+1) (and 0 for s = 0). This algorithm thus allows nodes to be in the treebone before T (0). As already shown, the majority of the video stream is pushed over the treebone in MTreebone. If a gap appears in the stream received by a node, either because of temporal capacity fluctuation in the treebone or because of a node failure, the node pulls the missing packets from the mesh overlay. For this, a tree-push pointer is used to indicate the last data block received by the push method and a mesh-pull window aims to allow the peer to request missing blocks. Basically, if the mesh-pull window discovers a gap, it issues a request to the mesh overlay. Since the mesh-pull window is always situated behind the tree-push pointer, this gap indicates that some blocks were not delivered by the push method, so they have to be requested from the mesh overlay. This push/pull switch buffer thus coordinates the treebone and the mesh to make streaming efficient and robust. Figure 3 shows the described push/pull switch buffer. Fig. 2. MTreebone framework (adapted from [5]) Since the treebone is the core structure of the MTreebone overlay, it is very important to identify stable nodes that will be part of the treebone. A node s stability is proportional to its duration on the overlay, but this duration cannot be known before the node actually leaves. Thus, the node stability is predicted based on the node s session age. Existing studies [1] show that nodes already with higher ages tend to stay longer on the system. Thus, a node s age reflects its stability. In MTreebone, if the node s age passes some threshold, it is considered stable and can be used to forward packets to other nodes. The effectiveness of the treebone is dependent on the age threshold. If it is too low, a large number of unstable nodes are included on the treebone. But if it is too large, a small number of nodes would be considered stable, so most of the video streaming would be mesh-based, thus having a larger overhead and delay. The authors conclude that the optimal age threshold for a node arriving at time t is 30% of the remaining session length. For this, they optimize the Expected Service Time (EST) of a treebone node by selecting this appropriate age threshold. Each node checks periodically its own age in the system. Once this age exceeds the threshold T (t), where t is the node s arrival time, it promotes itself as a treebone node. This method Fig. 3. Pull/push buffer (adapted from [5]) IV. IMPLEMENTATION MTreebone has been implemented using Transit [3] as a framework code base. Most of its concepts and classes are used in MTreebone and have been adapted for the specific MTreebone needs. MTreebone has been implemented within the simulator overlay layer. Since we heavily relay on the Transit concepts, the most important ones and their specific MTreebone adaptations are described in this section. A. Functional Layers As stated in [3], a streaming system, and thus MTreebone, can be basically divided into two functional layers: the Neighborhood Layer and the Scheduling Layer. On the Neighborhood Layer, peers find neighbors and form connections to those neighbors. The Neighborhood Layer then provides the connections it manages to the Scheduling Layer, which is in charge of filling the buffer. For this purpose, the concepts of flows and requests are used. A flow is basically a contract between the sender and the receiver, i.e. between a parent and a child node. This

6 4 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM contract is arranged during the join phase. When a peer leaves, thus not being able to further fulfill the contract, the contract must be renegotiated. Flows forward the most recent blocks of a stream, regardless of the currently missing blocks of the receiver. So a flow describes basically the push-based mechanism described in the background section. In MTreebone, similar as in Transit, flows are managed by the MTreeboneSimpleFlowManager. In contrast to Transit, MTreebone only accepts a flow request if it can fulfill it completely. No partial fulfillments are supported (because the current MTreebone implementation doesn t support different SVC layers). So, in MTreebone, if a flow exists between two peers, that flow is always healthy, which means that all layers are received by flows. The decision of accepting or denying an incoming flow request is done in the processschedulerequest() method of the MTreeboneSimpleFlowManager. A flow request is granted if the connection to the requesting peer is open and within the correct direction (out), and if the current peer receives the flow from another peer (or is the streaming source) and has spare capacity for the flow request. When a flow request is granted, the peer agrees to forward its incoming flow to the requesting peer. Requests, on the contrary, aim at requesting specific blocks from the corresponding neighbor. Each block needed is requested in this scheme, so this procedure basically describes the pull-based mechanism described in Section II. In order to inform the neighbors about the block availability, buffer maps are periodically exchanged between neighbors. The BuffermapSender is in charge of this periodic buffer map delivery. The buffer map is actually piggybacked on control or payload messages in order to prevent message overhead. It is important to note that, although flows and requests basically describe the push and pull mechanisms presented, these concepts cannot be interchanged with each other. A flow might lead to a pull-based mechanism if it is very short-lived, and a request with a large amount of blocks will lead to a pushbased mechanism, in which the requested blocks are delivered one after each other. As stated earlier in this section, MTreebone uses the Neighborhood Layer in order to find neighbors and form connections to these neighbors. The initial set of neighbors is requested from the streaming source at the join phase. This is done using the InitialServerContactOperation. During this operation the peer gets the following information from the streaming source: Session length: the total session length, i.e. how long is the streaming event in seconds. This information is needed for the promotion calculation, as shown later in this section. Arrival time: when exactly the peer joined the system. This is also needed for the promotion calculation. Treebone contacts: a list of treebone contacts, i.e. nodes already on the treebone. These are stable nodes from which the peer can request flows. At least one treebone node must exist in the list. Since the streaming source is always in the treebone, it is guaranteed that at least one node is included here. If there are nodes in the treebone, these are always preferred over the streaming source node. In other words, the streaming source node is only included in this list when there are no other alternatives. Unstable contacts: a list of unstable contacts, i.e. any other nodes in the system (not in the treebone). This list may be empty. The maximum number of contacts returned is determined by the system parameters MAX_{TREEBONE,UNSTABLE}_NODES_TO_SEND. Good performance was achieved when using these values: MAX_TREEBONE_NODES_TO_SEND = 5. MAX_UNSTABLE_NODES_TO_SEND = 32. After retrieving the initial peers from the streaming source node, the Neighborhood Layer is responsible of opening and maintaining these connections. While opening these connections, peers further exchange their neighbors which each other, which permits them to know more and more contacts in case these are needed later, either because the current contacts do not have the needed video blocks or because they failed. Similar as in Transit, peers only communicate with peers they have established a connection to. In order to maintain these connections, heartbeat messages are periodically sent to all neighbors. Buffer maps, as indicated previously, are also periodically piggybacked into these control messages. Our MTreebone implementation extends the connection concept on an endpoint type. It is important for a peer to know if the peer it has a connection to is a treebone node, an unstable node, or even the streaming source node. As stated in [3], the method getconnections(direction, State, FlowState, RequestState) is very important for the Scheduler Layer, since it allows it to retrieve a list of currently available connections that match given criteria. MTreebone extends this criteria list on the endpoint type. This permits the Scheduler Layer to retrieve connections where the endpoint is e.g. a node in the treebone. This is necessary because, in MTreebone, flow requests are permitted only to treebone nodes, so the Scheduler Layer has to be able to retrieve those connections explicitly. As stated earlier, the Scheduling Layer is in charge of filling the buffer. In MTreebone, as shown in the previous section, a push/pull switch buffer is needed for seamlessly coordinating the push/pull mechanisms while streaming. This is achieved in the MTreeboneSchedulerImpl, specifically in the receivedliveblock() method, which is called each time the node receives a block from its subscribed flow. On receiving a live block, the method calculates which blocks must be explicitly requested because of a gap between the treepush pointer and the playback pointer, i.e. inside the meshpull window. If there are missing blocks between the current playback chunk and the live block just received, these blocks must be explicitly requested. Since in the current MTreebone implementation different SVC layers are not supported, we request all missing blocks in this mesh-pull window. When adding SVC support, only the missing blocks belonging to the actual layer and layers under them should be requested, and not all of them. A node could be completely disconnected from the treebone.

7 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM 5 There are basically two cases in which this situation may happen: The node tries to request a flow from the treebone nodes it knows, but they don t have enough capacity, so they all deny the flow request. Either there are no more nodes with enough capacity, or the current node just doesn t still know them. In both cases, the node doesn t find a treebone node with enough forwarding capacity. The node gets temporarily disconnected from the treebone because of a parent failure. In both cases, the node needs to continue streaming in order to avoid playback interruption, although the flow is cut. For this purpose, the push-pointer is disabled, since no live blocks could possibly arrive. Streaming is then solely based on the mesh-pull window. All blocks are thus requested from the corresponding neighbors. This occurs on the tick() method of the MTreeboneSchedulerImpl, since this method is called periodically for every playback operation executed (either while playing the video content or while stalling). MTreebone requests by default the missing blocks from the next 10 video blocks. Advanced scheduling schemes could be employed here instead of this simple scheme. So, when the push-pointer is disabled, the streaming is solely dependent on the mesh network and behaves like similar mesh-based protocols. When the node successfully requests a flow from another node, the push-pointer is enabled again and streaming is again push-based. The mesh is used then only when necessary, i.e. when a gap occurs between the flow pointer and the playback pointer. Fig. 4. Neighborhood and Scheduling Layers (adapted from [3]) Figure 4 shows the functional layers explained in this section. The Neighborhood Layer manages the neighbor connections and provides the Scheduling Layer with connections, which in turn fills the buffer using these connections. B. Promotion Mechanism As shown on Section III, there are two different mechanisms in order for a peer to become a treebone node: Each peer periodically checks its age and compares it to the age threshold T (t), with t being the node s arrival time. The age threshold used in MTreebone is 30% of the remaining session length. Since before T (0), i.e. before 30% of the session length, no peers are on the treebone, a randomized promotion algorithm is introduced in order to solve this problem. The described promotion management mechanisms are done at each peer locally in the PromotionOperation, which is executed periodically each 1 second by default. It is important to note that only nodes which currently receive (healthy) flows are permitted to promote to treebone nodes. When a node decides it should be promoted to a treebone, it has to communicate this to the rest of the nodes. The MTreebone paper [5] does not specify how exactly a node has to communicate this promotion event to the rest of the nodes, so we tried the three different approaches described next. The promoted node informs the streaming source node about its promotion. All nodes ask the source node periodically for new treebone nodes. The source node then replies with a list of current treebone nodes. This approach works well when the number of nodes is small, but it clearly has a scalability problem, since the source node is easily overloaded by the large amount of treebone node requests. Since the peers have to be informed of the new treebone nodes in a timely manner, they would request this information from the source node frequently, causing a large number of parallel requests. The source node has to answer all these requests while it forwards the video to its children, so it has to have free bandwidth available. This causes bandwidth waste, which would be only maintained in order to answer these requests. Further, most of the time, the treebone nodes will not change, thus having the source node send the same information over and over again. This causes a large unnecessary message overhead. Another problem of this approach is how the source node determines which treebone nodes to send to the requesters. Since the number of treebone nodes is limited, it may send them the same treebone nodes they already know, because it doesn t know which treebone nodes they already have. A solution for this could be to let the source save which treebone nodes it already sent to every node, but this clearly would cause another scalability problem and too much responsibility for the source node. The promoted node informs the streaming source node about its promotion, which in turn sends an update message to all nodes informing them about the event. Again, the main problem with this approach is scalability. The source is easily overloaded, since it would have to send the update message to a large number of nodes simultaneously. Further, as shown earlier, peers in our MTreebone implementation only communicate with peers they have previously established a connection to. Thus, the source node would have to maintain open connections to all nodes in order to send them the update messages, which is not possible for a large number of nodes. We implemented a controlled flooding algorithm in order to circumvent the problems described above. When a node becomes a treebone node, it sends a promotion message to all its neighbors, which, in turn, forward this message to their own neighbors. So the promotion message is flooded through the entire mesh overlay, thus eventually reaching all peers in the system. In order to

8 6 Implementing a P2P Live Streaming Overlay for PeerfactSim.KOM prevent further scalability problems, the message is only forwarded if it has not yet being forwarded by the current node. This ensures that the flooding algorithm eventually terminates. The MTreebonePromotionManager is in charge of the whole promotion process. This third approach works in our MTreebone implementation, but it may also become a scalability problem, so an idea for future work could be to disseminate new treebone nodes piggybagged with control or video data, similar to the dissemination of buffer maps already discussed. Figure 5 shows a screenshot of the MTreebone overlay visualization. Purple nodes are treebone nodes, and the purple arrows between them depict (healthy) flows. Most of the nodes are unstable nodes, attached to the treebone as outskirts, so they stream the video using push-based mechanisms. But, since the nodes only forward flows according to their upstream capacity, there may be nodes that cannot be attached to the treebone if there is no capacity available. These stream using the mesh overlay, as explained earlier in this section. These nodes are depicted green. Some nodes are stalling, which are depicted red. Figure 6 shows the mesh network. The figure clearly shows that the green nodes are receiving data packets from the mesh overlay although they are not directly connected to the treebone. V. FURTHER WORK The basic MTreebone system was implemented. So there is space for optimizations and further ideas. In the MTreebone paper, two of these possible optimizations are presented. In our system, data latency is not necessarily minimized. Two non-optimal substructures could exist, which are described next. A node can have more children than its parent. A swap of them could reduce the average depth of the treebone nodes. A treebone node closer to the source may still be able to accept new children. So treebone nodes closer to the source should be given a higher priority. Further, in the current implementation, nodes attach to random treebone nodes they know. An optimization could be to attach to one treebone node that is nearest to the source. This would further reduce the average depth of the treebone nodes. As we noted in previous sections, our MTreebone implementations does not support SVC layers. SVC could thus be integrated in the system, so that different SVC layers could be streamed over different flows. Of course, advanced mesh optimizations and neighbor discovery algorithms could also be implemented. Thorough evaluations could be done and compared to existing systems, e.g. Transit. VI. CONCLUSION In this paper, we presented our MTreebone implementation on the discrete event-based PeerfactSim.KOM simulation framework. Necessary background information was first presented, followed by a thorough description of the implemented MTreebone system. Specific concepts used in our implementation and the problems encountered were further presented. Finally, open issues and ideas for further work were discussed. Fig. 5. Treebone overlay visualization (based on Transit visualization framework) REFERENCES [1] Michael Bishop and Sanjay Rao. Considering priority in overlay multicast protocols under heterogeneous environments. In in Proc. of IEEE INFOCOM, III [2] Eduardo Lidanski. Multiple-tree push-based overlay streaming II-A [3] Björn Richerzhagen. Supporting Transitions in Peer-to-Peer Video Streaming. Master s thesis, Technische Universität Darmstadt, Germany, , IV, IV-A, 4 [4] Dominik Stingl, Christian Groß, Julius Rückert, Leonhard Nobach, Aleksandra Kovacevic, and Ralf Steinmetz. Peerfactsim.kom: A simulation framework for peer-to-peer systems. In Waleed W. Smari, editor, Proceedings of the 2011 International Conference on High Performance Computing & Simulation (HPCS 2011), pages , 445 Hoes Lane,Piscataway, NJ 08854, Jul IEEE, IEEE. II-C [5] Feng Wang, Yongqiang Xiong, and Jiangchuan Liu. mtreebone: A collaborative tree-mesh overlay network for multicast video streaming. IEEE Transactions on Parallel and Distributed Systems, 21(3): , I, III, 2, 3, IV-B Fig. 6. Mesh overlay visualization (based on Transit visualization framework)