Portal de Periódicos da CAPES

WidePLive: a coupled low‐delay overlay construction mechanism and peer‐chunk priority‐based chunk scheduling for P2P live video streaming

2020; Institution of Engineering and Technology; Volume: 14; Issue: 6 Linguagem: Inglês

10.1049/iet-com.2019.0618

1751-8636

Majid Sina, Mehdi Dehghan, Amir Masoud Rahmani, Midia Reshadi,

Image and Video Quality Assessment

IET CommunicationsVolume 14, Issue 6 p. 937-947 Research ArticleFree Access WidePLive: a coupled low-delay overlay construction mechanism and peer-chunk priority-based chunk scheduling for P2P live video streaming Majid Sina, Majid Sina orcid.org/0000-0003-2673-6895 Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this authorMehdi Dehghan, Mehdi Dehghan Department of Computer Engineering and Information Technology, Amirkabir University of Technology, Tehran, IranSearch for more papers by this authorAmir Masoud Rahmani, Corresponding Author Amir Masoud Rahmani rahmani@srbiau.ac.ir orcid.org/0000-0001-8641-6119 Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this authorMidia Reshadi, Midia Reshadi Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this author Majid Sina, Majid Sina orcid.org/0000-0003-2673-6895 Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this authorMehdi Dehghan, Mehdi Dehghan Department of Computer Engineering and Information Technology, Amirkabir University of Technology, Tehran, IranSearch for more papers by this authorAmir Masoud Rahmani, Corresponding Author Amir Masoud Rahmani rahmani@srbiau.ac.ir orcid.org/0000-0001-8641-6119 Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this authorMidia Reshadi, Midia Reshadi Department of Computer Engineering, Science and Research Branch, Islamic Azad University, Tehran, IranSearch for more papers by this author First published: 01 April 2020 https://doi.org/10.1049/iet-com.2019.0618Citations: 1AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract In recent years, peer-to-peer (P2P) live streaming is popularised by the scalability and cost-effectiveness of P2P networks. User satisfaction in P2P live streaming systems depends on several factors, including chunk scheduling techniques and overlay construction mechanisms in these systems. P2P live streaming systems are involved with the peer and chunk selection problems to improve quality parameters of streaming, such as playback continuity, startup delay, and playback latency. In this study, WidePLive as a P2P live video streaming system is proposed. In WidePLive, the authors proposed a low-delay overlay construction mechanism and a mixed strategy based chunk scheduling scheme which are coupled together by a contribution-aware peer selection strategy as a coupling feature to improve the quality parameter. The proposed overlay construction mechanism allows new peers to have the opportunity to connect with previous peers near the server and forms a low-depth and low-delay overlay. The proposed chunk scheduling scheme uses the benefits of Rarest First and Greedy strategies to trade-off between quality parameters. The evaluation of WidePLive simulation results demonstrates an acceptable improvement in streaming performance and shows that WidePLive has lower startup delay and playback latency and higher playback continuity compared to previous works. 1 Introduction In recent years, the transmission of video content over the Internet infrastructure has grown dramatically. According to forecasts provided by CISCO, about 82% of Internet traffic will include video traffic by 2022 [1]. Video streaming plays an important role in various areas of life, including communication, education, entertainment, and security [2]. The deployment of broadband networks has enabled the provision of services such as IPTV, YouTube, NetTV, and Netflix on the Internet. Video contents are provided in both live and on-demand manners, of which live video streaming has more sophisticated design challenges due to real-time constraints. Previously, client-server architecture has been used for both live and on-demand live video streaming. However, this architecture is not suitable due to the scalability problem for advanced applications. Hence, researchers have proposed peer-to-peer (P2P) networks for streaming video in search of a scalable solution. The result is the presentation of many scientific products including [2-9], as well as commercial applications such as PPLive, UUSee, CoolStreaming, and SopCast. In live video streaming, various quality parameters such as playback continuity, playback latency, and startup delay have a direct effect on user satisfaction. Therefore, to improve these qualitative parameters, researchers are seeking effective solutions in designing live P2P streaming systems. The most important factors affecting the performance of P2P streaming systems are overlay construction mechanism, free riding peers, and chunk scheduling schemes. An overlay network is a virtual network that is built on the existing physical network infrastructure, and peers are linked by logical links that may consist of one or more physical links in the physical network. Previously, in the field of overlay construction, many research works have been presented and from this perspective, P2P video streaming techniques can be divided into single-tree, multi-tree, mesh-based, and hybrid categories. The straightforward method of overlay design is the single-tree method, in which the peers are organised as a propagation tree. In tree-based systems such as ZigZag [10], peers are organised in a hierarchical structure that takes video from a single parent as the source, and each parent peer broadcasts video content to its children. Low overhead is one of the key properties of these systems. The fundamental disadvantage of this structure is its vulnerability to the churn phenomenon. The delay caused by re-organising the overlay in counteracting the churn phenomenon has a direct effect on reducing streaming efficiency. In addition, in the single-tree structure, leaf nodes cannot share their upload bandwidth with other peers. Therefore, in systems such as SplitStream [11], the multi-tree structure was proposed to solve the leaf node problem. In a multi-tree structure, the mainstream is converted into several independent sub-streams, and each one is streamed through a single tree. In this structure, any leaf node in a tree may be an intermediate node in other trees. The existence of problems in structural overlays led the researchers to unstructured and hybrid overlays [12]. Therefore, mesh-based overlays are used in most real-world applications to serve thousands of video channels [13]. In mesh-based overlays, each peer can communicate with a number of peers as neighbours and notify the neighbours' buffers by exchanging buffer-map (BM) messages. Each peer requests its required packets from its neighbours based on the received BMs and offers them its existing packages. However, mesh-based methods generally have higher playback latency and startup delay compared to structured methods, due to the strength of the mesh-based overlay against the churn phenomenon as well as the use of the bandwidth capacity of most peers, the mesh-based technology for streaming live video is more conventional. In addition, the hybrid overlays such as [14, 15] are proposed to take advantage of both tree-based and mesh-based overlays. There are generally push-based and pull-based methods for publishing video content. The push-based method is often used in tree-based structures, and the use of this method in mesh-based overlays can lead to duplicate packages by peers. For mesh-based overlays, pull-based and sometimes hybrid methods are often used [16]. Some popular examples of live streaming video systems, such as CoolStreaming, PRIME, PPLive, PPStream, and UUSee, serve millions of users in hundreds of video channels [17]. CoolStreaming/DONet is one of the first mesh-based streaming systems that use the random neighbour selection strategy in overlay construction. The PRIME overlay is also one of the first mesh-based unstructured systems with random connections that streams the video based on file sharing mechanisms like BitTorrent [7]. PPLive is one of the most popular Internet TV services built on P2P networks. PPLive is a mesh-based streaming system that locates video pieces using the BM exchange technique and uses gossip-based protocols to manage peers [4]. It has been shown in [18] that the method of neighbour selection in the overlay construction mechanism has a direct impact on the playback latency. Since most mesh-based systems use a pull-based method for transmitting chunks, the transmission delays can increase proportionally with the increase in the depth of the overlay; therefore, with the increasing number of peers, mesh-based systems suffer from the increase in playback lag between peers and video source. The tests presented in [19] show how playback latency and startup delay are directly related to the number of peers in the system. In live streaming, qualitative parameters such as playback latency, startup delay, and playback continuity play an important role in peer's quality of experience and peers that experience high startup delay and playback latency are more likely to exit the system. In existing streaming systems, playback latency and startup delay vary from hundreds of milliseconds to several minutes [4]. Zhou et al. [20] show that Greedy is able to produce better playback continuity on small-scale networks while Rarest First (RF) is much better at scaling. Also, if all peers use Greedy, the startup delay and playback latency in the system can be smaller [20]. In this paper, we focus on designing a coupled low-depth overlay construction mechanism and a two-sided mixed chunk scheduling strategy. In the proposed low-depth overlay construction mechanism, we focus on eliminating the dependency of the distance of each peer to the video source with the enter arrival time of that peer. Also, we proposed a mixed strategy based chunk scheduling that can be used to achieve the benefits of RF and Greedy strategies as two well-known and simple strategies in P2P file sharing. In addition, as the major contribution of this paper, we coupled low-delay overlay construction mechanism and peer-chunk priority-based chunk scheduling that use a priority-based peer selection strategy as a coupling feature for overlay construction and chunk scheduling mechanisms to achieve simultaneous reduction of playback latency and decrease startup delay and increase playback continuity compared to previous works. We performed extensive simulations to demonstrate the higher performance of WidePLive compared to the conventional policy and the proposed scheme in [21]. Results show that playback latency and startup delay in WidePLive is less than playback latency and startup delay in the conventional scheme and also the proposed scheme in [21]. Furthermore, WidePLive offers greater playback continuity than other similar systems. Therefore, the major contribution of this paper is a coupled low-delay overlay construction mechanism and peer-chunk priority based chunk scheduling that use a priority-based peer selection strategy as a coupling feature for overlay construction and chunk scheduling mechanisms to reduce playback latency and startup delay and increase playback continuity. The contributions of this research are summarised as follows: Designing a low-delay overlay construction mechanism with a priority-based peer selection strategy to reduce playback latency and startup delay with focusing on eliminating the dependency of the distance of each peer to the video source with the enter arrival time of that peer. Proposing a novel mixed strategy based chunk scheduling scheme that uses RF policy in receiver side and Greedy policy in sender side to chunk selection with a priority-based strategy to peer selection. Proposing a priority-based peer selection strategy as a coupling feature for overlay construction and chunk scheduling mechanisms that use the contribution level of peers with their neighbours in the overlay adaptation and sender side chunk scheduling algorithm to achieve simultaneous reduction of playback latency and decrease startup delay and increase playback continuity. The remainder of this paper is organised as follows. Related works are represented in Section 2. Section 3 discusses the design and implementation of our proposed coupled low-delay overlay construction mechanism and chunk scheduling scheme for P2P live video streaming. In Section 4, we perform experiments to verify the effectiveness and performance of our proposed approach. Finally, we conclude this paper in Section 5 with the discussion about the results. 2 Related works In conventional mesh-based systems, peers connect to each other in the order of entry and each peer can serve a limited number of neighbours due to limitations in peers' upload bandwidth. This procedure makes the distance between the new peers and the video server more than the previous peers, and their playback latency may be higher than previous peers [21]. Kim et al. [21] proposed a neighbour selection scheme called connection switching to reduce the average playback latency in the system. The focus of their proposed method is to give the chance of connecting to intermediate peers to new peers. In this scheme, when a new peer enters the system, if the two peers have a predefined threshold of buffer packets, their connection may be broken and then connected to the new peer. The proposed method in [21] has reduced the quality parameters including playback latency and startup delay in contrast to the conventional method. In [8], a three-stage peer selection strategy is proposed for managing the delay in mesh-based P2P live streaming systems. In [8], two priority-based peer selection algorithms are proposed at both peers and tracker levels. Additionally, the topology adaptation strategy is proposed to put the peers with higher upload bandwidths closer to the streaming source. Providing a peer selection method at the tracker level in [8] reduces playback latency and startup delay compared to [22]. To improve the efficiency of live video streaming systems, a balance is needed between peer selection techniques [8, 21] and chunk scheduling techniques [2, 23-25]. One of the major challenges faced by researchers in designing P2P live video streaming systems is the chunk scheduling problem. This can be verified from two perspectives: the receiver side and the sender side chunk scheduling. In push-based systems, the focus is often on sender side chunk scheduling algorithms and in pull-based systems the emphasis is on receiver side chunk scheduling algorithms [2]. In some references such as [26, 27], hybrid methods are proposed for achieving scalability, reliability, and encouragement of peers to collaborate. In recent years, the issues of neighbour selection and overlay construction have been other challenges for researchers in designing P2P live video streaming systems. In mesh-based P2P streaming systems, a variety of neighbour selection techniques have been proposed for the construction and maintenance of overlays, which QoS-aware techniques such as [8, 21, 28] and location-aware techniques such as [29-32] are suitable for real-time applications such as live streaming. In QoS-aware techniques, different metrics have been used to prioritise peers. In [33], peers are prioritised based on bandwidth capacity and latency. In [34], peers are prioritised by the ratio of upload bandwidth to latency. In [35], content availability has been considered for selection. The authors' effort in [36, 37] was that peer with higher upload bandwidths would have a higher pull rate. In [38], a priority-based scheduling algorithm is used for chunk selection in which parameters such as deadline, rarity, layer number, and packet size are used to prioritise chunks and a bandwidth-aware approach is also used to select peers. References such as [4, 39] have provided more comprehensive studies of pull-based scheduling schemes. 3 Proposed coupled low-delay overlay construction mechanism with mixed strategy based chunk scheduling scheme In this section, we describe WidePLive as a novel P2P live video streaming system and explain our proposed overlay construction mechanism, overlay maintenance process, chunk scheduling algorithms in the sender and receiver side, and peer (neighbour) selection algorithm in WidePLive. The WidePLive design follows main goals that ultimately lead to improvements in quality parameters such as playback continuity, playback latency, and startup delay. 3.1 P2P mesh-based system model We consider a mesh-based overlay network for live P2P video streaming. The overlay network (called swarm) consists of N nodes (called peers) that form a virtual network over the underlying physical network in the application layer. The swarm is formed based on our proposed specific overlay construction process. Each peer with a unique ID (e.g. IP address and port number) connects to a subset of peers in the swarm as its neighbours. The swarm is very highly dynamic because new peers may join the swarm at any time and joined peers may leave the swarm or crash. In this work, we do not consider Byzantine behaviour. Byzantine peers are adversarial or faulty peers caused by malicious attacks or software errors that behave arbitrarily [40]. In this model, video service provider uses a streaming server to stream video contents and a tracker server. The video source generates a video stream with a constant bit rate and the video streaming server divides the stream into sequential fixed length video chunks. Each video chunk has a unique identifier related to its real generation time. Each peer uses a chunk identifier to sort received chunks in the original order. The streaming server according to its upload bandwidth disseminates video chunks to a subset of peers in each swarm in a push-like mechanism and peers communicate with each other through a pull-based mechanism to exchange video chunks. A BM presents the availability of chunks in a peer's buffer. Each peer periodically exchanges its BM with its neighbours, then, according to received BMs from its neighbours, and based on the proposed receiver side chunk scheduling algorithm, it sends the desired chunk requests to selected neighbours. Each peer, based on the proposed sender side chunk scheduling algorithm serves received chunk requests from its neighbours. We use a peer system design with following three main modules that is depicted in Fig. 1. (i) Overlay manager, which helps the peer join the overlay and maintain an up to date and effective list of neighbours during its lifetime; (ii) Buffer manager, which helps the peer exchange BM with its neighbours to establish a continuous partnership with them; (iii) Chunk scheduler, which schedules video chunks in both chunk requestor and chunk sender sides. In this section, we describe how modules work and how they communicate with each other in the system. Fig. 1Open in figure viewerPowerPoint System diagram of a peer 3.2 Overlay manager Each peer has a unique ID, and when it arrives in the system, it connects to the tracker server and reports its information such as IP address and port number. When the new peer tunes in to watch a channel, if the video server has a free slot, which can directly serve it, it sends an acceptance message back to it and this new peer is called the root peer and receives video chunks directly from the server in a push manner. Otherwise, if the video server does not have a free slot, the tracker server randomly selects a subset of peers that watch the same channel as a list of candidate neighbours for newly joined peer and send back this list. We call this peer as a non-root peer. The non-root peer then tries to make connections to the proposed neighbours. If a candidate neighbour peer accepts a neighbour request, the non-root peer adds that candidate peer into its Accepted_Neighbour_Requests (ANR) list. The non-root peer sorts ANR list based on priority value of ANR members after predefined time interval. The priority value of ANR members for each accepted neighbour in ANR list is calculated based on the following equation: (1)where is the priority of which shows the ratio of upload bandwidth to its neighbours count. The higher value of is equal to the higher selection probability for . The parameter is the upload bandwidth of and is the number of neighbours of . Often the download bandwidth of the nodes is more than or equal to their upload bandwidth, and we have also assumed in this paper that the download bandwidth of each peer is large enough to fully download the video stream. Therefore, the download bandwidth of is not considered in (1). Then non-root peer selects candidate neighbour peers with higher priority as its own neighbours. The non-root peer after completing the join process begins exchanging video chunks with its neighbours. When a peer leaves its session with or without informing the tracker, its neighbours remove it from their neighbour list. To counteract the frequent arrivals and departures of the peers, each one periodically updates its neighbour's list during its session by requesting a fresh list of active peers from the tracker. In our design, this periodic update interval is set to 5 s and is called the reconnect interval. When a peer joins to the server as a root peer, the server runs a migration process. In the migration process, the server sends a migration request to all root peers. Each root peer () can migrate one of its non-root neighbours with lowest priority value calculated based on (2) to the new root peer for load balancing and efficient bandwidth provisioning. The procedure of joining a new peer to the system is expressed in Algorithm 1 (see Fig. 2). Fig. 3 illustrates a business process diagram of joining a new peer to the system in more details in BPMN 2.0 [41]. Fig. 2Open in figure viewerPowerPoint Algorithm 1: the procedure of joining peers to the system that runs in the server level Fig. 3Open in figure viewerPowerPoint Business process diagram of joining a new peer to the system As shown in [37], to improve system performance, higher bandwidth peers should be closer to the video source in order to more effectively contribute to chunk distribution. Therefore, we use three mechanisms: shrinkServer, shrinkPeer, and reconnect in our proposed overlay maintenance process. ShrinkServer mechanism: This process runs in the server level. The video server maintains a subset of peers as root peers and updates the list of root peers over time, a peer stays in root peer list until a new peer arrives in the system with higher upload bandwidth. According to this rule, peers with higher upload bandwidth will be closer to the source. When a new peer with higher upload bandwidth arrives in the system, it can be a root peer and according to the shrinkServer mechanism, it can join to the system, which is expressed in Algorithm 2 (see Fig. 4). Fig. 4Open in figure viewerPowerPoint Algorithm 2: the procedure of shrinkServer mechanism that runs in the server level ShrinkPeer mechanism: This process runs in the peer level. Each peer periodically shrinks its list of neighbours. For each , if is equal to , removes one of its neighbours from its list so that this neighbour will be selected based on priority values of its neighbours. If is a root peer it calculates the priority value of its neighbours based on the following equation: (2)where is the number of chunks that sent to in past intervals and is the duration of being a neighbour of with that is calculated based on the number of reconnection time intervals and is the list of current neighbours of . If is a non-root peer it calculates the priority value of its neighbours based on the following equation: (3)where is the number of chunks that received from and is the number of chunks that requested by from in past intervals and is the list of neighbours of . In this way, the peer can accept new neighbours with higher free upload bandwidth capacity from future neighbour requests. The procedure of peer shrinking is expressed in Algorithm 3 (see Fig. 5). Fig. 5Open in figure viewerPowerPoint Algorithm 3: the procedure of shrinkPeer of peeri that runs in the peer level Reconnect mechanism: This process runs in both peer and server levels. Each non-root peer periodically sends a new neighbour list request message to tracker server and then receives a non-empty fresh list of active peers as its candidate neighbours from tracker server in the current reconnect interval. Each non-root peer may remove one of its neighbours from its current neighbour list during the peerShrink mechanism. Therefore, the non-root peer can accept higher priority neighbours based on (1) from current ANR list. Also, if the server has no any free slot to acceptance of a new entered peer as a root peer, new peer must connect to swarm by reconnect mechanism. This procedure is expressed in Algorithm 4 (see Fig. 6). Fig. 6Open in figure viewerPowerPoint Algorithm 4: reconnect mechanism of peeri that runs in the server level 3.3 Buffer manager In our design, a video stream is divided into small fixed size video chunks with a unique sequence number similar to many BitTorrent-like P2P systems such as [42]. Each chunk contains video data for a specified time interval and disseminates to all peers through the mesh-based overlay, possibly from different paths. Each peer has a buffer to store and arrange the chunks prior to playback due to the possibility of chunks arriving out of order. A BM represents the chunks availability in the peer buffer; peers periodically exchange their BMs with each other. Each peer, after receiving BMs from its neighbours, according to the receiver side of its chunk scheduling algorithm decides which chunks should be requested from which peers, then prepares chunk request messages and sends them to the selected neighbours. In our design, each peer benefits from a sliding window to chunk scheduling and adjusts the reception of video streams to achieve video streams with a desired maximum loss ratio [43]. After completing the process of joining a new peer to swarm, it adjusts its slidingWindowBegin parameter with the playback point of the video server. In the proposed system, peers start playing the video after buffering 10 s of video chunks. Each peer after buffering 10 s of video chunks sets its slidingWindowBegin parameter to the first chunk of this buffered 10 s. 3.4 Chunk scheduler We rely on a pull-based approach that has been used in many live P2P video streaming systems such as [3, 43, 44]. In pull-based video streaming each peer after exchanging BM with its neighbours achieves chunk deployment status in its active neighbours. Then, according to its buffer status and collected information from neighbours, the peer must make the desired decision to fetch the expected chunks from appropriate neighbours. In some resources, such as [20, 39], there are comparisons between different strategies of chunk scheduling for pull-based streaming schemes in P2P networks. In WidePLive, two chunk scheduling algorithms are proposed on receiver and sender sides based on a weighted random selection strategy. In this paper, we proposed a mixed approach that combines two common chunk selection strategies in the pull-based streaming systems, known as Greedy and RF strategies with a weighted random peer selection strategy in the sender and receiver sides. In our design, forms the NeighboursPriorityList for its neighbours as the priority vector of its neighbours depends on their upload bandwidths. The greater value of upload bandwidth for a neighbour is equal to the higher priority for that neighbour from point of view. Then selects a neighbour at weighted random selection, based on NeighboursPriorityList and chooses an appropriate chunk based on BM of selected neighbour and RF strategy. In RF strategy, (i.e. the chunk requestor peer) will select a video chunk that has the least number of copies among its neighbours. The after selection of appropriate chunks forms chunk request (chunkReqBitmap) message for each selected neighbour and sends the request message to it. In RF strategy forms chunkReqBitmap messages depending on its missed chunks from end to begin of its playback buffer and so chunks that farther to its playback point will be selected first. The number of chunks that can request in the next 1 s time slot depends on its download bandwidth so each peer determines multiple peer-chunk combinations based on its download bandwidth. This procedure is expressed in Algorithm 5 (see Fig. 7). Fig. 7Open in figure viewerPowerPoint Algorithm 5: the chunk-request process that runs in peeri (the requester peer) On the opposite side, (i.e. the chunk sender peer) may receive multiple chunk request (chunkReqBitmap) messages from its neighbours. The waits for a 1 s time slot and during this time, it stores chunk request messages to Neighbour_Chunk_Request_Vector (NCRV), each element of which represents the chunk request from a particular neighbour. In our design, process a