Chapter 3 Design Approach
3.3 Data Retransmission
Here we first explain how to construct a SpareTable, and then describe the proposed retransmission mechanism. The SpareTable records spare nodes information. Nodes can find the targets in the SpareTable when nodes want to send requests. We present a spare nodes selection algorithm as shown in Figure 5, to construct a SpareTable. When a new node joins the network, it will contact the source node. The source node will select spare nodes for this new node. In a multicast tree, a node failure will cause its children not being able to receive data, but nodes in other sub-trees won’t be affected. So, the nodes in other sub-trees are suitable nodes to request for lost data. In our P2P network, there are several multicast trees.
Assume the number of stripes is N. There are N multicast trees. Assume the degree of a multicast Tree 1 is M (M<N). We divide multicast Tree 1 into M’s sub-trees. The source node chooses every node from the other M-1 sub-trees except the sub-tree the new node belonged to and construct one entry in the SpareTable. So there are N entries in the SpareTable.
Following is an example in Figure 2. Since there are two multicast trees in Figure 2, there are two entries in SpareTable of every node as shown in Figure 6. For node A in Figure 2. There are two entries for stripe 1 and stripe 2 respectively in SpareTable. For stripe 1, we choose the nodes B、E、H、F to be spare nodes because they are in other sub-tree. For stripe 2, we choose D、E、G、C to be spare nodes.
Figure 6. The spare table (SpareTable) of node A
In the P2P network, nodes receive frames and store them in the buffer. When one node receives one frame with a new sequence number, for example, sequence i, the node will check whether the frame sequence number (i-1) has been decoded. If decoded, there is no need to send any requests for this frame. If not, the node checks to which stripe number that frame (i-1) belong, and sends a request messages for lost blocks to a randomly selected node from the corresponding entry in the SpareTable. On the other hand, the node will check the receiving buffer whether the block of specific <sequence, stripe> is available after receiving a request message. If the requested block is available, the node will send back the block to the requesting node. If the requested block is not available, the node will not send back a reply.
We see an example to illustrate the retransmission process as shown in Figure 9. In Figure 9, node B failed. Nodes E and F may lose some blocks in stripe 1, so node E sends a request to node G. If the specific <sequence, 1> block is available of node G, it will send back the block to node E. Node F did the same. In tree 2, when node C lost blocks in stripe 2, it sends a request to a node in entry 2 of the SpareTable. Node C send a retransmission request and get a reply from spare node A in multicast tree 2.
Receive frame i
Receive a retransmission request
of the <seq#, stripe#>
block, check receiving buffer
Is <seq#, stripe#>
block available?
Send back the block
Yes
No need to send reply No
Figure 8. The flow char of the retransmission process:
the process of a node sending a reply.
Figure 9. The retransmission processes of two multicast trees. (a) Nodes E and F send retransmission requests and get replies from spare nodes G and D in multicast tree 1. (b) Node C send a retransmission request and get a reply from spare node A in multicast tree 2.
Chapter 4
Simulation Results
We first used FreePastry (version 2.0_04) [18] to implement the DHT layer (Pastry) [15], application layer multicast (Scribe), and streaming layer (SplitStream). Then we implemented our proposed HyStream scheme on this structure. We compare the proposed HyStream with SplitStream in Section 4.1 and with CoolStreaming in Section 4.2
4.1 Simulation against SplitStream
We implemented our simulation environment on Pastry overlay with 800 nodes and built a forest structure with these nodes. Repair time is determined primarily by SplitStream’s failure detection period, which triggers a tree repair when no heartbeats or data packets have been received for 30 seconds. The delivery ratio is defined as the number of packets that arrive at each node before the playback deadline over the total number of delivered packets.
Mean time to failure (MTTF) [19] is defined as the time interval to kill a portion of nodes.
The node failure rate [20] is defined as the percent of nodes that failed simultaneously. In Figure 10, we evaluate the delivery ratios under different node failure rate between 1% and 20% (which implies 8 to 160 simultaneous failures in the overlay with 800 nodes) with a fixed MTTF of 100 seconds. The result shows that the delivery ratio decreases as the node failure rate increases in our HyStream and SplitStream. We set the parameters with FEC (16, 15), and thus the encoded data has about 6% extra redundant packets. We can see that adding an FEC recovery method can improve the delivery ratio. However, when the node failure rate
average improvement is 11.7%. We can see that when the node failure rate increases, the improvement of HyStream increases.
Figure 10. Delivery ratios with various node failure rates under a fixed MTTF (100 seconds).
Figure 11. Extra control overhead with various node failure rates under a fixed MTTF (100 seconds).
0.5
In Figure 11, we show the extra control overhead with various node failure rates. We define the extra control overhead as the control traffic volume / video traffic volume at each node. The extra control traffic of HyStream is the retransmission requests. We observed that the extra control overhead increases as the node failure ratio increases. The maximum extra control overhead is lower than 0.5%. When the node failure rate is under 3%, we can recover most of data with a small number of retransmission requests and low extra control overhead.
4.2 Simulation against CoolStreaming
Here we evalue two metrics: delivery ratio and delivery latency. We compare the proposed HyStream with CoolStreaming in terms of delivery ratio and start-up delay, with CoolStreaming’s simulation results obtained from [5].
(1) Delivery ratio:
We first compare the delivery ratio between HyStream and CoolStreaming. The delivery ratio is defined as the number of packets that arrive at each node before the playback deadline over the total of number of delivered packets. We implemented a simulation environment according to [5]. We set the streaming rate as 500 Kbps. And the overlay size is 200 nodes.
We set each node to change its status according to the ON/OFF period. The node actively participates the overlay during the ON period and leaves (or fails) during the OFF period.
Both ON and OFF periods are exponentially distributed with an average of time T. Simulation results are shown in Figure 12. We found that the shorter ON/OFF period leads to a lower delivery ratio. We also found that the delivery ratio of SplitStream is lower with a lower ON/OFF period beacause SplitStream is a push-based method. Our approach uses a data
Figure 12. Delivery ratio as a function of ON/OFF period T (sec).
(2) Delivery latency:
We define the start-up delay as the waiting time that a node receives enough data to start playing after it joins the overlay. We implemented 1000 nodes in the overlay and recorded the start-up delay in cumulative distribution function (CDF), as shown in Figure 13. HyStream had the same start-up delay with SplitStream. We observed that 90th percentile nodes had the start-up delay of 15 in our HyStream. The 90th percentile nodes had the start-up delay of 50 seconds in CoolStreaming. Our HyStream is 35 seconds shorter in the start-up delay of the 90th percentile nodes. Since our approach is a push-based method, its start-up delay is very short.
ON/OFF period T (second)
Delivery ratio
Figure 13. CDF of start-up delays between HyStream and CoolStreaming.
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
0 5 10 15 20 25 30 35 40 45 50 55
CDF of start-up delay
Start-up delay (seconds)
CoolStreaming HyStream(proposed) (same as SpliStream)
Chapter 5
Implementation Issues
5.1 Applying our Approach to SplitStream
In this section, we introduce how to implement our HyStream method. Our HyStream method is an enhanced improvement of SplitStream’s streaming multicast. We can implement our approach based on the FreePastry project [18]. FreePastry is an open source project. We can modify its source code to implement our method. The original SplitStream method provides the functions of creating DHT networks, building multicast trees, and transferring streaming data. We may implement our approach by modifying the source code of the node behavior. We discuss how to modify the node behaviors of source and subscriber nodes as follows.
5.1.1 Behavior of Source Nodes
Video data are available in the source node. The source node divides the video data into frames, and each frame is assigned a sequence number to represent its playback order. We then separate the frame into several stripes and transfer them by different multicast trees. The source node encodes each frame with FEC. The source node stores the SpareTable of each multicast tree. The source node will transfer the SpareTable to a newly joined node.
Figure 14. The behavior of the subscriber node (a) the behavior of a subscriber node when receiving streaming data (b) the behavior of a subscriber node when receiving a retransmission request.
5.1.2 Behavior of Subscriber Nodes
When a node joins a P2P streaming system, it can subscribe to the multicast trees and becomes a subscriber node. The subscribe node will contact the source node and retrieve the SpareTable. The subscriber node receives data from its parent node. In Figure 14, we implemented four handlers in our HyStream: (1) The data handler processes the receiving data and detects whether suffering from data loss. If the number of received blocks is equal to or
handler performs an FEC algorithm to recover data and saves data to the receiving buffer. (3) The retransmission handler requests spare nodes to retrieve lost data and saves data to the receiving buffer; the detail is shown in Figure 7. (4) The request handler receives retransmission requests from other nodes and transfers the data to them. In addition, there is a receiving buffer maintained by each node. Three handlers save data to this buffer. The subscriber node plays the video from the data in the buffer.
5.2 Integration of Search and Streaming
Most P2P streaming systems provide live streaming or video on-demand. In live streaming, each user must watch the same streaming from a live channel, such as a live sport channel. In video on-demand, users can select a channel provided by the server. We can integrate our streaming system with the P2P search technique. When a user joins the P2P network, it can search the video file name and get a list of nodes that have this file. Nodes that have the video file will be the source node in the P2P streaming network. And other nodes that want to watch the video can join the streaming network. We can apply our streaming method to the streaming network to achieve the P2P streaming resilience.
Chapter 6 Conclusions
6.1 Concluding Remarks
In the proposed HyStream, we have integrated the ideas of the pull method with the tree-based architecture. We fragment the stream and build multiple trees to transfer data, and add an FEC data recovery mechanism to restore lost data. We have also used the pull-method to retransmit the data that we could not be recovered. Our approach has the advantages of the tree-push and mesh-pull methods. Simulation results have shown that our HyStream has a high delivery ratio in a peer churn environment and good resilience to node failures.
Simulation results have also shown that in average our approach has 11.7% improvement in delivery ratio against SplitStream under various node failure rates. The delivery ratio of the proposed HyStream is 2.2% higher than that of CoolStreaming in a peer churn environment.
The start-up delay of 90th percentile nodes of HyStream is 35 seconds shorter than that of CoolStreaming. Our approach has low overhead with 6% extra packets compared to SplitStream and CoolStreaming. And the extra control overhead is not more than 0.5% even in a high peer churn environment compared to that of SplitStream and CoolStreaming.
6.2 Future Work
We will implement the proposed HyStream in an actual internet environment, and experimental results will be evaluated to justify our simulation results.
Bibliography
[1] B. Li and H. Yin, “Peer-to-peer live video streaming on the internet: issues, existing approaches, and challenges,” IEEE Commun. Mag, vol.45, pp. 94-99, Jul. 2007
[2] A. Sentinelli, G. Marfia, M. Gerla, L. Kleinrock, and S. Tewari, “Will IPTV ride the peer-to-peer stream?” IEEE Commun. Mag, vol.45, pp.86-92, Jul. 2007.
[3] S. Xie, G.Y. Kung, and B. Li, “A measurement of a large-scale peer-to-peer live video streaming system,” in Proc. International Conference on Parallel Processing Workshops, pp. 57-57, Sept. 2007.
[4] J. Harju, A. Jantunen, M. Saukko, L. Vaatamoinen, I. Curcio, I. Bouazizi, and M.
Hannuksela, “Peer-to-peer streaming technology survey,” in Proc. International Conference on Networking, pp. 342 – 350, Apr. 2008.
[5] X. Zhang, J. Liu, B. Li, and Y.-S.P. Yum,” CoolStreaming/DONet: a data-driven overlay network for peer-to-peer live media streaming,” in Proc. 24th Annual Joint Conference of the IEEE Computer and Communications Societies, pp. 2102-2111, Mar. 2005.
[6] Y. H. Chu, S. G. Rao, and H. Zhang, “A case for end system multicast,” IEEE J. Sel.
Areas Commun., vol.20, pp. 1-12, Oct. 2002.
[7] Z. Liu, H. Yu, D. Kundur, M. Merabti, “On peer-to-peer multimedia content access and distribution” in Proc. International Conference on Multimedia and Expo, pp.557-560.
July. 2006.
[8] W. P. Yiu, X. Jin, S.H. Chan, “Challenges and approaches in large-scale p2p media streaming,” IEEE Multimedia, vol. 14, pp. 50-59, June. 2007.
[9] M. Castro, P. Druschel, A.M. Kermarrec, A. Nandi, A. Rowstron, A. Singh, “Splitstream:
high-bandwidth content distribution in a cooperative environment,” in Proc. Nineteenth ACM Symposium on Operating Systems Principles, pp. 292-303. Oct. 2003.
[10] V. N. Padmanabhan, H. J. Wang, P. A. Chou, and K. Sripanidkulchai, “Distributing streaming media content using cooperative networking,” in Proc. 12th International Workshop on Network and Operating Systems Support for Digital Audio and Video, pp.
177-186. Apr. 2002.
[11] K. Zao, Y.H. Guo, J.K. Zao, W.H. Peng, L.S. Huang, and F.P. Kuo, “Trickle: resilient real-time video multicasting for dynamic peers with limited or asymmetric network connectivity,” in Proc.International Symposium on Multimedia, pp.391-398, Dec. 2006.
[12] C. Liang, Y. Guo, and Y Liu, “Hierarchically clustered p2p streaming system,” in Proc.
Global Telecommunications Conference, pp. 236-241, Nov. 2007.
[13] L. Zhao, J. G. Luo, M. Zhang, W. J. Fu, J. Luo, Y. F. Zhang, S. Q. Yang, “Gridmedia: A practical peer-to-peer based live video streaming system,” in Proc. 7th Workshop on Multimedia Signal Processing, pp. 1-4, Nov. 2005.
[14] N. Magharei, R. Rejaie, “PRIME:peer-to-peer receiver-driven mesh-based streaming,” in Proc. 26th IEEE International Conference on Computer Communications, pp. 1415-1423, May.2007.
[15] A. Rowstron and P. Druschel, “Pastry: scalable, distributed object location and routing for large-scale peer-to-peer systems,” in Proc. IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), pp. 329–350, 2001.
[16] M. Castro, P. Druschel, A.M. Kermarrec, and A. Rowstron., “Scribe: a large-scale and decentralized application level multicast infrastructure,” IEEE J. Sel. Areas Commun., vol.
20, pp. 1489-1499, Oct. 2002.
[17] L. Rizzo, “Effective erasure codes for reliable computer communication protocols,”
ACM SIGCOMM, vol. 27, pp. 24-36. Apr. 1997.
[19] S. Birrer and F.E. Bustamante, “The feasibility of DHT-based streaming multicast,” in Proc.International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, pp. 288-298. Mar. 2005.
[20] S. Banerjee, S. Lee, B. Bhattacharjee, and A. Srinivassan, “Resilient multicast using overlays,” IEEE/ACM Trans. Network., vol. 14, pp. 237-248, Apr. 2006.
[21] H. W. Cheng, “Dependable peer-to-peer multi-streaming using DHT-based application level multicast,” in Proc. IASTED International Conference on Wireless and Optical Communications, July, 2009.
[22] W. L. Miller, R. M. Ollerton, A. Shum, C. J. Warner, “Proactive FEC-based forwarding for the collaborative reliable multicast protocol,” in Proc. Information Systems for Enhanced Public Safety and Security. IEEE/AFCEA, pp. 269-273. May. 2000.