ESPE Ciencia & Tecnologa, Vol. 4, No.

1, 2013

ESPE
CIENCIA Y TECNOLOGIA

EDITOR-IN-CHIEF Luis H. Cumbal Flores, Ph.D.

Centro de Investigaciones Cientficas and Department of Life Sciences, Escuela Politecnica del Ejercito, Sangolqui, Ecuador.

lhcumbal@espe.edu.ec
EDITORIAL BOARD

Sukalyan SenGupta, Ph.D.

Civil & Environmental Engineering Dept., University of Massachusetts, Darmouth, Massachusetts, USA. ssengupta@umassd.edu!

Gonzalo Olmedo, Ph.D.

Electrical and Electronics Department, Escuela Politecnica del Ejercito, Sangolqui, Ecuador.

golmedo@espe.edu.ec. Ulker Beker, Ph.D.

Chemical Engineering Department, Yildiz Technical University, Davutpasa Campus, Istanbul, Turkey. ubeker@gmail.com

Dina Lopez, Ph.D.

Clippinger Laboratories, Department of Geological Sciences, Ohio University, Athens, OH, USA. lopezd@ohio.edu"!

Jochen Bundschuh, Ph.D.

National Centre for Engineering in Agriculture (NCEA), University of Southern Queensland, Toowoomba, Australia. jochenbundschuh@yahoo.com

Maria Soledad Benitez, Ph.D.

Post-doctoral associate, Duke University, Durham, NC, USA msbenitezponce@gmail.com! !

Printing

: Editorial of the Escuela Politecnica del Ejercito

ISSN 1390-4612 ! 2013 ESPE, Sangolqui, Ecuador

! ! !

Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador !

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013

On the design of protocols for efficient multimedia streaming over Internet

A.G. Streit
University Center of Braslia, DF, Braslia, Brazil RWTH Aachen University, Aachen, North Rhine-Westphalia, Germany

C.K. da S. Rodrigues
Electrical and Electronics Department, Polytechnic School of Army, Sangolqu, Ecuador University Center of Braslia, DF, Braslia, Brazil

ABSTRACT: This article presents two novel protocols for efficient multimedia streaming over Internet: Sequential Streaming BitTorrent (SSB) and Interactive Streaming BitTorrent (ISB). They are both based on the BitTorrent paradigm and one of them is specially designed for interactive access. Furthermore, the main simulators that may be used to evaluate these protocols are herein discussed as well. By means of theoretical analysis as well as comparisons with other works in the literature, we may conclude that the novel protocols are very competitive since they maintain a satisfactory compromise between time constraints and diversity of data pieces in the system. Keywords: BitTorrent, multimedia, streaming, protocols, simulators.

1 INTRODUCTION Since its deployment, Internet has faced significant changes and improvements in order to provide its users with high-quality multimedia streaming applications such as YouTube and Google Hangout (D'Acunto et al. 2012, Rao et al. 2002). While trying to make the world more and more connected, this evolution also tackles the scalability issue since these applications usually demand a plethora of servers to distribute hundreds of thousands of multimedia objects (videos, classes, clips, songs, etc.) with an acceptable quality to millions of users every day. Significant research effort has then focused on the use of the Peer-to-Peer (P2P) architecture to deal with the limitations that arise from the classical client-server architecture (Carlsson & Eager 2007, Hoffmann et al. 2011, Vlavianos et al. 2006, Yang et al. 2010). If well implemented, the P2P approach may provide an attractive scalability and drastically cut down the bandwidth cost of streaming service providers (D'Acunto et al. 2012). The P2P approach presents though some new challenges and Quality-of-Service (QoS) requirements (Hoffmann et al. 2011). Firstly, when dealing with streaming over the Internet, it is very difficult to guarantee a continuous playback, where users do not suffer from interruptions while playing a multimedia object such as a movie or a video clip. Secondly, there is almost always a delay experimented by users before the object playback begins (i.e. the startup delay). One well-known P2P protocol is BitTorrent (Cohen 2003). Its success in the P2P field is mainly justified by its piece and peer selection policies, respectively. The piece selection policy refers to the order in which parts of a file (i.e. pieces) are going to be selected by a user for download. The peer selection policy determines to whom these pieces should be uploaded to. These two policies must obviously stimulate the cooperation and reciprocation between peers. The BitTorrent protocol was though originally designed for efficient object replication rather than for streaming applications (Legout et al. 2006). More recently, the BitTorrent protocol has been considered for the implementation of streaming services (Carlsson & Eager 2007, Hoffmann et al. 2011, Vlavianos et al. 2006, Zhou et al. 2007, Shah & Pris 2007). The resulting proposals are essentially based on modifications of the piece and/or peer selection policies (Borghol et al. 2010, Huang et al. 2008) and their main goal Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador 25

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

is to guarantee the QoS requirements for streaming systems while maintaining the high efficiency of the original BitTorrent protocol (D'Acunto et al. 2012). The majority of the works in the literature make use of simulators when evaluating BitTorrent adaptation approaches. The use of simulators for analyzing P2P systems instead of monitoring and measuring real networks is mainly justified by the dynamic nature and the highly complex architecture of these kind of systems. Due to that, many researches (Kangasharju et al. 2007, Katsaros et al. 2009, Mansilha et al. 2008) have focused on the development of P2P simulators. This work mainly focuses on the window-based design strategy (Hoffmann et al. 2011) to adapt the BitTorrent protocol for streaming. This strategy has shown to be very competitive in several previous works (Shah & Pris 2007, Savolainen et al. 2008, Stais & Xylomenos 2012, Zaky et al. 2011). Besides, this design strategy together with several enhancements in the original peer selection policy make it possible to take into account some of the most important performance problem factors of streaming applications such as heterogeneity of peers and freeriding (D'Acunto et al. 2012, Konrath et al. 2007). Within this context, this work has two important contributions. The first one is the proposal of two novel BitTorrent-based protocols for streaming systems. One of these protocols is named Sequential Streaming BitTorrent (SSB) and is specifically designed for streaming over static environments. The second one, named Interactive Streaming BitTorrent (ISB), applies to streaming over interactive environments, where users may execute interactive actions like in a Blu-ray player. The second contribution is the classification and review of the main simulators used to evaluate P2P protocols. The remainder of this text is organized as follows. In Section 2, we briefly explain how the BitTorrent protocol operates as well as comment on the most popular window-based pieceselection design strategies for adapting BitTorrent to streaming service. Besides, we also present the user-behavior model (De Vielmond et al. 2007) deployed in one of our proposals. The goal of this section is to provide the basis for a thorough understanding of this text. Section 3 presents the main window-based protocols devoted to the adaptation of the BitTorrent protocol to the media-delivery service (Borghol et al. 2010, Hoffmann et al. 2011, Savolainen et al. 2008, Shah & Pris 2007). These proposals are the state-of-art of this research field and are all considered in the competitive theoretical analysis included in this work. Our proposals are thoroughly explained in Section 4. In Section 5, we discuss the main classes of P2P simulators founded in the literature. At last, conclusions and future work are included in Section 6. 2 BASIS 2.1 BitTorrent structure BitTorrent is a P2P protocol that seeks to efficiently replicate a specific file (i.e. multimedia object) between a set of users (i.e. peers). To participate in the system (i.e. swarm), a user firstly has to download a torrent file, where metadata of the desired file can be found. The user is then able to contact a centralized entity called tracker. The main responsibility of this entity is to keep track of the participants of the distributed system and to provide the user with a random list of other peers that belong to the swarm. The user then establishes TCP connections with a subset of peers from the list mentioned above, also called neighbors, and starts making requests. These requests are for specific parts of the desired file, also known as pieces. Instead of simply selecting those pieces for download in an arbitrary manner, the BitTorrent protocol defines a policy known as rarest first. This strategy determines that the less available pieces, among the neighbors, are the ones to be selected. This will cause a fast piece replication among peers and increase the diversity of pieces in the swarm.

Figure 1. Rarest first piece strategy from BitTorrent.

26

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013

As shown in Figure 1, the user has information about how many replicated copies of each piece of the file its set of neighbors has. In the example, both pieces b1 and b4 are the less replicated ones, and are therefore included in the rare piece set. At this point, the user can randomly choose any of those pieces since both of them have the same rarity. Sometimes the user makes a piece request to a neighbor and is not served. In this case, the user was choked by its neighbor. This is another strategy introduced by the BitTorrent protocol and is named peer selection policy. The strategy determines that interested peers are only going to be served by their neighbors (i.e. unchoked) when they themselves have recently provided good download rates. In this sense, this policy motivates cooperation and reciprocation between the participants of the swarm, avoiding selfish peers (i.e. free riders) that do not contribute with the file transmission over the network. 2.2 Window-based piece-selection strategies Different window strategies have been proposed in the literature in order to adapt the BitTorrent protocol to be used for implementing P2P streaming applications (Borghol et al. 2010, Huang et al. 2008). A window consists of piece (data) subsets of the file that usually follow the playback position and that are planned to be played soon by the user. The pieces of these subsets should be then downloaded with a higher priority than other pieces of the file. The most important window strategies may be categorized as follows: (i) fixed window (Shah & Pris 2007); (ii) stretching window (Savolainen et al. 2008, Vlavianos et al. 2006, Zhou et al. 2007); (iii) adaptive window (Borghol et al. 2010); and (iv) autonomous windows (Hoffmann et al. 2011). Considering the first strategy, the window is characterized by a fixed size during the download of the whole file. In this case, the window never changes the distance between its first and last pieces, even if it covers pieces that the user has already downloaded. Under the second strategy, the window does not have a fixed distance between the first and the last pieces, changing its size as the download is being executed. The third strategy implies a window that can adapt its size, usually according to the pieces already received by the user and to the playback point. Lastly, the autonomous windows strategy is characterized by the division of the media file into two different subsets (i.e. two different windows). This strategy is normally designed for interactive environments, where the user can change the position of the file being played. Usually, the windows from the strategies above slide when their first piece is recovered or when this piece is missed by the user. In this work we refer to a missed piece when it is not downloaded in time to be played. However, in interactive environments, the windows may also slide when an interactive action is done by the user. We finally outline that windows may change their sizes when some requirements for its growth or reduction are met. 2.3 User-behavior model In this subsection the user-behavior model presented in the work of De Vielmond et al. (2007) is briefly described. The model constitutes a hierarchical HMM (hidden Markov model) to represent the user behavior when accessing a multimedia server. In order to define and parameterize the model, the logs from students attending the CEDERJ course of a real distance learning application were used (De Souza e Silva et al. 2006). The classes of this course were previously recorded and then stored in the multimedia RIO server (De Souza e Silva et al. 2006).

Figure 2. Determination of the interactive model (high, medium or low) to predict user's behavior.

Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador

27

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

The logs are categorized in function of the user-interactive level, which is a function of the number of interactivity actions the user has done during his session. A user model is then generated and trained for each interactivity level. After the training phase, which is based on the set of real logs, the user model can be used to emulate a sequence of interactive actions. This sequence works as the prediction of the user's future interactive actions. When a new user arrives in the system, it is necessary to determine to which interactivity level he belongs to. To determine the interactivity level, a sample of length x seconds is examined. This sample is used as an input to each of the user-behavior models (high, medium and low interactivity) and the maximum likelihood function is computed in order to determine the best fitting model. This idea is depicted in Figure 2, adapted from the work of Hoffmann et al. (2011). We point out that the user-behavior model referred in this work can also be named userbehavior predicting model, since the model is actually used to predict future actions of the user during the playback of the media file. 3 RELATED WORK Herein we present the most important protocols devoted to the adaptation of the BitTorrent protocol to streaming services (e.g. Hoffmann et al. 2011, Savolainen et al. 2008). These proposals are some of the state-of-art algorithms belonging to this research field and are all considered in the competitive analysis carried out in Section 4. 3.1 Unique and simple window The protocols Shah-Pris (Shah & Pris 2007) and Stretching (Savolainen et al. 2008) fall in this category. Both of them are devoted to streaming over static environments. While the Stretching protocol only modifies the original piece selection policy from BitTorrent, the ShahPris protocol defines changes in both the piece and the peer selection policies. The modification in the piece selection policy of both protocols is done by defining a sliding window. Shah-Pris states that this window is fixed and has w consecutive pieces. On the other hand, Stretching designs a window with a dynamic size with two established thresholds: nmax and dmax. The value nmax states a maximum number of non-retrieved pieces by the user inside the window. The value dmax is the absolute maximum distance between the first and the last piece of the window. Essentially, in both protocols the rarest first strategy only operates within the window. In the peer selection policy proposed by the Shah-Pris protocol, each peer should randomly select some neighbors interested in their pieces at every playback interval (i.e. at every window of w pieces retrieved) to be unchoked, so as to help newcomer peers to receive their first piece. At all other moments, the peer follows the same peer selection policy stated in the original BitTorrent protocol. 3.2 Unique and unlimited window This category includes the Adaptive protocol proposed in the work of Borghol et al. (2010). This protocol was essentially developed for streaming over static environments and it only modifies the original piece selection policy from BitTorrent. The modification in this policy is done by defining an adaptive sliding window. The size of the window is adapted according to the download progress reached by the user. With probability p the selection of pieces happens under the rarest first strategy. But the pieces may also be selected through their sequential order with probability (1 - p). The size of the window may be adapted every time the user selects a piece under the Equation 1 defined below: (1) where: d = last contiguous recovered piece; r = playback position (i.e. the piece that is currently being played back); = threshold that sets a lower bound on the number of contiguous pieces

28

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013 required before the window can grow; k = scaling coefficient; and wmin = pre-defined minimum size for w. Before the playback starts, the window size is determined by its minimum size wmin. At this moment, the quantity of pieces inside the window is determined by the distance between its first and last pieces. However, as soon as the playback starts, the minimum size wmin of the window (Equation 1) is not related to this distance anymore. It comes to be related to the number of nonretrieved pieces by the user. 3.3 Double and simple window The protocols BIP-F and BIP-S (Hoffmann et al. 2011) belong to this category. They were specifically designed for streaming over interactive environments. Both are essentially based on the modification of the piece selection policy of the BitTorrent protocol and make use of two different types of windows. The BIP-F protocol determines that the piece selection can happen inside and outside its two windows with different probabilities. The BIP-S protocol, on the other side, restricts the selection of pieces inside the two windows. One of these windows is named playback window, covering pieces that follow the playback point of the media file. The other is the prevision window which encompasses the subset of pieces determined by the user-behavior model presented in the work of De Vielmond et al. (2007). For the selection of pieces inside the playback window, BIP-F has two different variants. The first variant uses the rarest first strategy, while the second variant retrieves pieces in their sequential order. For the remaining pieces of the file, the rarest first strategy is used. For BIP-S, the selection of pieces follows the rarest first strategy in both windows alternately. Finally, when an interactive action is done by the user, the prevision window slides in both protocols. But the playback window behaves differently in each protocol. More specifically, in BIP-F, it is also updated when an interactive action is executed. But, in BIP-S, it only slides when the new playback point, chosen by the user, is not a piece that was already inside it. 4 TWO NOVEL PROTOCOLS 4.1 Sequential Streaming BitTorrent 4.1.1 Operation As already mentioned in the introduction, the Sequential Streaming BitTorrent (SSB) is a BitTorrent-based protocol designed for media streaming over static environments. To do so, we concentrated our efforts on the improvement of the original piece selection policy from BitTorrent. Firstly, the pieces are categorized into three sets: Hp, Lp and Rp. These sets cover different parts of the media file. The Hp set (high priority set) includes pieces that were not recovered yet by the user but are going to be played by the player soon. This set has an adaptive size of n pieces. On the other hand, the Lp set (low priority set) covers pieces that still have to be recovered by the user but are not going to be played soon. Finally, the Rp set (recovered-pieces set) includes pieces that have already been downloaded by the user. The user always selects for download the piece from Hp that is the rarest among its neighbors (i.e. rarest first strategy). Moreover, another set is also defined: Sw (sliding window). The Sw covers all the pieces inside the Hp set and can also include some pieces from the Rp set. It has an adaptive size w = n + q, where n refers to the pieces inside Hp and q refers to the recovered pieces inside the window (i.e. part of the Rp set). The size w of this window can change accordingly to two different limits: wmin and wmax. These two values can be adapted every time the user selects a piece under Equations 2 and 3, defined below: (2) (3) Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador 29

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

where: d = last contiguous recovered piece; r = playback position (i.e. the piece that is currently being played); = threshold that places a lower bound on the number of contiguous pieces required before wmin and wmax can grow; kmin and kmax = scaling coefficients; and vmin = pre-defined minimum size for wmin and wmax. The limits wmin and wmax are adapted in function of the users download performance. But it is important to notice that wmin can never be greater than wmax. In this way, when determining the values of the scale coefficients, kmin has to be smaller than or equal to kmax. When the scale coefficients are equal (i.e. kmin = kmax), the size of the window w still can be adapted, but the limits wmin and wmax are always going to be the same (i.e. wmin = wmax). These limits can also be equal when the user cannot surpass the threshold of consecutive recovered pieces from the playback position. In this case, wmin = wmax = vm and, when a piece is recovered inside the window Sw, w is going to maintain the same value, but the size of the Hp set is going to decrease. In this situation, the idea is basically to restrict the retrieval of pieces that are closer to the playback position. On the other hand, when the user has a good download rate, the limits wmin and wmax can receive different values, depending on kmin and kmax, and the size w of the window can fluctuate between these two limits. Different fluctuation intervals are exemplified in Figure 3. In the example depicted in Figure 3, vm = 5 and the coefficients kmin and kmax are equal to 1 and 3, respectively. As already mentioned, when wmin = wmax, the window Sw cannot change its size. However, when wmin < wmax, the window Sw can fluctuate between different size intervals. For example, in interval 1 the window varies between six and eight pieces, while in interval 2 it varies between seven and eleven pieces. The better is the users download rate, the greater is the fluctuation interval that is allowed. Besides, as the fluctuation interval gets larger, users can select for download different pieces that are not necessarily close to the playback position. The points in the graph from Figure 3 represent the limit wmax and the decreasing lines represent the behavior of the window Sw when it has already reached wmax and more pieces are recovered inside it. In this situation, as pieces are received by the user, the value of n decreases and the value of q increases in a compensatory way. It may be noted that the size w of the window Sw can be changed by two different reasons. First, due to the subset of Rp that is inside the window (i.e. quantity q). The second reason is due to the limit wmin. Every time this limit is adapted by Equation 2, the size of Hp (i.e. quantity n) also changes. Thus, since the window Sw can never have fewer pieces than n, the value n is directly related to the value wmin.

Figure 3. Sizes of the window Sw in function of the values n and q.

30

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013

Figure 4. Algorithm and example of the SSB protocol after starting playback.

Before the playback begins, the first w pieces should be downloaded by the user. This is called startup delay. In order to minimize the duration of this delay, the SSB protocol sets wmin = wmax. Thereby, the initial pieces are prioritized for download. When these w pieces are received by the user, the download of the remaining pieces from the media file continues according to the steps described in the algorithm of Figure 4. First, in step (1) the values wmin and wmax are updated according to Equations 2 and 3. Then, in step (2) the user selects the rarest piece inside Hp. In step (3) a request is done for the selected piece. The piece is removed from the Hp set and then added into the Rp set, as shown in steps (4) and (5) respectively. After that, three different cases can take place. Case 1 happens when the downloaded piece is actually the first piece of the window (i.e. piece w1). In the example, the user receives the piece b13 at time t0. At time t1, the window Sw slides until its first position corresponds to the piece b14, since this piece has not been retrieved yet (i.e. is not inside the Rp set). After the window slides, both sets Hp and Lp are updated in step (7). It can be noticed that when the updateSets command is executed, the sizes of Hp and Lp can change, considering the limits wmin and wmax and the subsequent pieces that the user can have already retrieved in another moment. Case 2 happens when the window reaches its limit of growth (i.e. the limit wmax). In the example, the user retrieves the piece b8 and the Hp set reduces its size, as executed in step (8), because it does not receive the next piece from Lp. In this case, the window size w stays constant, but the values n and q change. Finally, Case 3 happens when the window Sw retrieves a piece that is beyond w1, increasing its size. As exemplified, in step (9) the next piece from the Lp set (i.e. the piece b12) is selected. The following steps show this piece being transferred to the Hp set. In this situation, Hp maintains its size n, but the window size w increases because of the variable q. It may happen that a piece is not downloaded in time to be played (i.e. the piece is missed). When this happens, the playback is paused and, while the user experiences this interruption, the procedure described below in Figure 5 needs to be executed. In this moment it is very important to keep the limits wmin and wmax equal in order to concentrate the piece retrieval close to the paused position p. As shown in Figure 5, the playback of the media file can only be restarted when all pieces inside the sliding window Sw, which have not been downloaded by the user before, are received. This procedure is important to users with low download rates since it prevents them from having too many interruptions during the playing of a media file. Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador 31

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

Figure 5. Algorithm and example of the SSB protocol when a piece is missed by the user.

4.1.2 Comparative analysis Table 1 shows the main characteristics between different BitTorrent-based protocols designed for streaming over static environments: Shah-Pris, Stretching, Adaptive and SSB. The only protocol that modifies the original peer selection policy is Shah-Pris. All others keep the original BitTorrent policy since it is still considered an efficient strategy (Carlsson & Eager 2007, Legout et al. 2006, Shah & Pris 2007) for selecting neighbor peers.
Table 1. Comparative table of BitTorrent-based protocols for streaming over static environments. ________________________________________________________________________________________________________ Protocols Peer selection policy Piece selection policy Window size Adapted thresholds ________________________________________________________________________________________________________ Shah-Pris Stretching Adaptive SSB modified original BitTorrent original BitTorrent original BitTorrent unique and simple window unique and simple window unique and unlimited window unique and fixed dynamic and limited dynamic and unlimited dynamic none none wmin wmin and wmax

limited window and limited ________________________________________________________________________________________________________

On the other hand, all these protocols change the original piece selection policy. Both ShahPris and Stretching modify this policy by defining a simple sliding window where the rarest pieces are selected. Shah-Pris is the only one that has a fixed window size. However, the Stretching protocol defines a dynamic window with a maximum distance threshold (i.e. the limit wmax). The protocols Adaptive and SSB have a sliding window that can adapt its size according to the download users performance. But, while the Adaptive protocol only adapts the minimum window size (i.e. the limit wmin), the SSB protocol adapts both minimum and maximum thresholds (i.e. the limits wmin and wmax). Two main different aspects may be thus noted between these protocols. The first aspect is their limitation nature. This aspect is clearly done by Shah-Pris, Stretching and SSB protocols. The limitation of Shah-Pris is predefined and is never greater than the window size. Furthermore, the limitation of Stretching is, in spite of also being predefined, greater than the window size. SSB, on the other hand, has an adaptive and not predefined limitation, which can both represent the window size or be greater than it. The second aspect is their adaptive nature. Even though the Stretching protocol has a dynamic size, enabling the window to increase and decrease, it does not have an adaptive nature since its thresholds are predefined. Besides, the adaptive nature from Adaptive is restricted because it only considers the wmin threshold. In this case, the window may grow without restriction until it reaches the last piece of the media file. SSB shows to be more complete, adapting both wmin and wmax thresholds as the download is performed. It is important to consider both aspects in order to achieve a good balance between piece diversity in the system and time requirements for streaming applications over static environments. Specifically, the presence of the limitation aspect stimulates the selection of pieces that are clos-

32

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013 er to the playback point. And when the maximum threshold is greater than the window size, it may not compromise the piece diversity requirement. Together with this aspect, the adaptation aspect can stimulate the diversity of pieces only when this is beneficial to the user, decreasing the probability of happening interruptions during the playback of the media file. As the SSB protocol encompasses both aspects, it turns to be more efficient than the others. 4.2 Interactive Streaming BitTorrent 4.2.1 Operation As already mentioned in the introduction, the Interactive Streaming BitTorrent (ISB) is a BitTorrent-based protocol designed for media streaming over interactive environments. To do so, we concentrated our efforts on the improvement of the original piece selection policy from BitTorrent. The pieces can be categorized into three sets: Hp, Lp and Rp. These sets cover different parts of the media file. The Hp set (high priority set) includes pieces that will be played soon by the user. The set Lp (low priority set) covers pieces that may be selected to be played by the user in the future, following the user-behavior model proposed by De Vielmond et al. (2007). Finally, the Rp set (recovered-pieces set) includes pieces that have already been retrieved by the user. The user selects for download the rarest pieces from the Hp and Lp sets in an alternating fashion. Moreover, two other sets are defined: Sr (sliding playback window) and Sp (sliding prevision window). The first window covers all the pieces inside the Hp set and can include some pieces from the Rp set. It has an adaptive size wr = nr + qr, where nr refers to the pieces inside Hp and qr refers to the recovered pieces inside the playback window (i.e. part of the Rp set). The prevision window Sp includes the Lp set and can also cover some pieces from the Rp set. It has a fixed size wp = np + qp, where np refers to the pieces inside Lp and qr refers to the recovered pieces inside the prevision window (i.e. part of the Rp set). As the goal of the prevision window Sp is to prevent users from having interruptions during the playback, while an interactive action is executed, it only pursuits to stimulate the download of consecutive pieces. In this way, the window Sp has a fixed quantity wp of pieces. On the other hand, the goal of the playback window Sr is to stimulate the retrieval of pieces that are following the playback point before their download deadlines are reached. In this case, it is possible to adapt the size of the window if the user has a good download rate. This adaptation occurs under the Equation 4 defined below: (4) where: d = last contiguous recovered piece; r = playback position (i.e. the piece that is currently being played back); = threshold that places a lower bound on the number of contiguous pieces required before the window can grow; k = scaling coefficient; and wr_min = pre-defined minimum size for wr. As exemplified in the graph from Figure 6, the size wr of the Sr window may have different quantities according to the download performance achieved by the user. In this example, wr_min = 5 and k = 2. When the window has size wr equal to 5 (i.e. wr = wr_min), it means that the user did not surpass the threshold eshold ld of consecutive recovered pieces fr from the playback position.

Figure 6. Sizes of the window Sr in function of the values nr and qr.

Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador

33

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

Figure 7. Algorithm and example of the ISB protocol after starting playback.

But when wr > wr_min, it can increase its quantity in function of the variables k and d. The decreasing lines from the graph represent the behavior of the window Sr when more pieces are recovered inside it. In this situation, as pieces are received by the user, the value of nr decreases and the value of qr increases in a compensatory way. It can be noted that the size wr of the window Sr can be changed only due to Equation 4, when the size of Hp (i.e. quantity nr) also changes. Thus, since the window Sr can never have fewer pieces than nr, the value nr is directly related to the value wr. Before the playback begins, the first wr pieces should be downloaded by the user. At this moment, called startup delay, the ISB protocol defines that wr = wr_min, in order to prioritize the download of the initial pieces and to decrease this delay. When the playback begins, the selection of pieces is done from Hp and Lp sets alternately. In Figure 7, the specific algorithm for this moment is described. In step (1) of the algorithm, the window Sr is updated. In this procedure, the size of the set Hp is also updated accordingly to the variation of the window size wr. Then, in steps (2) and (3) the rarest piece of Hp is selected and downloaded by the user. This piece is then removed from Hp and added to the set of received pieces (i.e. Rp set), as it is executed by steps (4) and (5). After that, two different cases can take place. Case 1 happens when the downloaded piece bx is the first piece of the window (i.e. bx = wr_1). In the example, the user receives the piece b13 at time t0. At time t1, the window Sr slides until its first position corresponds to the piece b14, since this piece has not been retrieved yet (i.e. is not inside the Rp set). After that, the set Hp is updated in step (7). It may be noticed that when the updateSet command is executed, the size of Hp and, consequently, the values nr and qr may change, considering the size wr of the window Sr and the subsequent pieces that the user may have already retrieved in another moment.

Figure 8. Algorithm and example of the ISB protocol when an interactive action is executed by a user.

34

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013

Figure 9. Algorithm and example of the ISB protocol when a piece is missed by the user.

Case 2 happens when the window Sr retrieves a piece that is beyond wr_1. In this situation, the value qr increases while the value nr decreases. The value wr still maintains its size constant. Now the recovery takes place inside the Sp window (i.e. inside the Lp set). The only difference from the steps previously described is that it is not necessary to update the size wp, since the window Sp has a fixed size during the download of the whole file. Another important moment provided by ISB is when an interactive action is executed by the user. In this case, the user modifies the playback position and starts to watch another piece of the media file. In step (1) of Figure 8, the playback position r is updated from piece b12 to piece b16 at time t0. Depending on where the new playback point is, the playback window Sr may also need to change its location. More specifically, if the new point is not a piece covered by Sr, than the location changes. Otherwise, as shown in the example of Figure 8, the playback window remains where it is. On the other hand, the prevision window Sp is always updated. The execution of step (2) from Figure 8 returns a piece defined by the user-behavior model in function of the new playback point r. In step (3), this model returns piece b19 and the prevision window Sp slides until it covers the next non-recovered piece (i.e. piece b20). Then, in step (4) the set Lp is updated. Finally, when a piece is not recovered in time to be played (i.e. the piece is missed), in order to avoid quality degradation, the media file is paused and a quantity x of pieces is estimated. This quantity is based on the average of pieces played without the execution of interactive actions by a user. A user with a higher interactive behavior will have a lower x than another that executes less interactive actions during the playback. As shown in Figure 9, the piece b24 was missed while the user was watching the piece b23. The playback is paused and the quantity x is estimated, as defined in steps (1) and (2). This quantity determines the size of the playback window Sr during the recovery time. For example, in step (3), the size of this window changes from four pieces, at time t0, to six pieces, at time t1. The playback of the media file can only be restarted when all the pieces inside the sliding window Sr, which have not been downloaded by the user before, are received. Then, this window slides in step (5) and the playback restarts in step (6). This procedure is important for users with low download rates because it tries to prevent a higher quantity of interruptions considering the users interactive behavior. 4.2.2 Comparative analysis Table 2 shows the main characteristics among different BitTorrent-based protocols designed for streaming over interactive environments: BIP-F, BIP-S and ISB. All the protocols keep the original peer selection policy from BitTorrent. Furthermore, all protocols define two different windows for selecting pieces: the playback window and the prevision window. Both playback and prevision windows from BIP-F and BIP-S protocols have a fixed size during the download of the media file. However, these windows behave differently in the ISB proSemestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador 35

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

tocol. This protocol defines a playback window that can adapt its size according to the download performance of the user. On the other hand, the prevision window of ISB maintains a constant size.
Table 2. Comparison of BitTorrent-based protocols for streaming over interactive environments. _______________________________________________________________________________________________________ Protocols BIP-F BIP-S ISB Peer selection original BitTorrent original BitTorrent original Piece selection double and simple window double and simple window double and Playback fixed fixed dynamic Prevision fixed fixed fixed Selection of inside and outside inside inside policy policy window size window size pieces _______________________________________________________________________________________________________

BitTorrent limited window and limited _______________________________________________________________________________________________________

Furthermore, the selection of pieces does not necessarily need to happen inside the playback and prevision windows. As defined by BIP-F, the user can select for download, with a lower probability, pieces that are outside these windows. In the experiments done by Hoffmann et al. (2011), this strategy can provide better piece diversity in the system, but as a shortcoming, this also can harm the performance experienced by the user, as it introduces more complexity to the protocol. This way, both BIP-S and ISB determine the selection of pieces inside the two windows only. Three important aspects are considered by these protocols. The first aspect is the interactivity nature. The introduction of a prevision window, which follows a user-behavior model in order to predict future pieces to be accessed by the user, is really important in an interactive environment. The idea of predicting future actions can provide a better playback experience for the user even when he changes the part of the file being played. The second aspect is the adaptive behavior of the playback window. The ISB protocol only provides diversity to the system when this is beneficial to the user, without compromising its playback performance. But it is important to consider that this adaptive behavior is different from the other protocol introduced in this work (i.e. the SSB protocol). The difference is that, when the new size of the playback window of the ISB protocol is calculated by Equation 4, the window will have a constant behavior until the equation is considered again. But the window from SSB is dynamic and can change its size according to its adaptive limits. When dealing with an static environment, this can guarantee a better quality to the end user, but when dealing with a more complex environment, where interactive actions may be executed, the playback window from the ISB protocol should only increase its size when the user has a good download performance, since the protocol already guarantees better piece diversity when it defines two different windows for selecting pieces. Trying to provide low complexity is actually the third important aspect. As mentioned, the BIP-F protocol is the only one that has a high complexity. Concluding, it is important to consider all these aspects in order to achieve a good balance between piece diversity in the system and time requirements of streaming applications over interactive environments. As the ISB protocol owns these three aspects (i.e. interactivity nature, adaptive nature and low complexity), it becomes to be more efficient than the others. 5 SIMULATORS In this section we review the main simulators found in the literature and that are used to evaluate P2P protocols. The information presented herein has the purpose to better distinguish and clarify the main differences between these simulators, making it easier to choose which one is more pertinent to analyze and accomplish the results wanted for a given study. In order to better understand the purpose of a simulator, it is first important to know what the basic idea of the simulation process is. Bhardwaj et al. (2010) define simulation as the process of modeling a system to be scientifically studied. Then, looking at the operation of the modeled

36

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013 system as black box, the execution of a simulation is basically done to observe the outputs generated by different inputs and parameters. A simulator can thus be defined as the environment that carries out simulations (i.e. the modeling of systems) and that can implement different operations over these models. Being aware that real P2P networks are complex and difficult environments to control, the use of simulators instead of real experiments in networks is highly justified and motivated, especially because of the high costs that would be associated (Bhardwaj et al. 2010). The network simulators reviewed in this work are classified into three different categories depending on their abstraction level (Bhardwaj et al. 2010, Xu et al. 2011): (i) packet-based simulators; (ii) fluidbased simulators; and (iii) hybrid simulators. The packet-based simulators aim to define the details of the network layer. The idea is to individually handle all the data packets transmitted in the network. On the other hand, the fluidbased simulators do not consider so many details, abstracting the components of the simulated network. In this case, the network traffic is represented as a continuous fluid flow. The hybrid simulators, however, allow the execution of both types of simulations (i.e. packet-based simulation and fluid-based simulation) within their environment. In Figure 10, the main P2P simulators found in the literature are classified into these three categories. These three categories have different characteristics between each other. First, it is observed that the hybrid simulators provide greater flexibility, since it supports the realization of both packet-based and hybrid-based simulations. They allow the users to select the desired detail level for the simulation according to their needs. The packet-based simulators allow the modeling of the network with a high degree of accuracy. However, this precision comes with a dose of complexity that can hinder the modeling phase and may compromise the scalability of the model to be simulated. The opposite happens with the fluid-based simulators. In this case, the complexity is minimized but, at the same time, the results obtained are not so accurate. As a result, the packet-based simulators provide outputs that are closer to the ones obtained in real systems. However, when the simulation is performed, for example, for purposes of comparison and analysis of different piece selection strategies with the BitTorrent protocol, the main goal is not to obtain the real results, but to conclude which strategy is more competitive in the same simulated scenario (Kangasharju et al. 2007). In this sense, for such type of analysis, the low complexity associated with the fluid-based simulators is more suitable, making the modeling process easier to the user and facilitating the achievement of the desired results.

Figure 10. Example of the main P2P simulators.

6 CONCLUSIONS AND FUTURE WORK This work presented two novel protocols for streaming service: the Sequential Streaming BitTorrent (SSB) and the Interactive Streaming BitTorrent (ISB). Both proposals are based on the well-known BitTorrent Protocol and use the window-based strategy to define sets of pieces to be selected for download by the user. The main goal of these proposals is to contribute for a solution that ensures a good user experience while playing a media file, with low latency to begin the playback as well as a continuous playback, where users do not suffer from interruptions. Besides, we review and compare three different categories of simulators used in the literature to evaluate different policies of P2P proSemestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador 37

Streit & Rodrigues/ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013/25-40

tocols. These categories are named packet-based simulators, fluid-based simulators and hybrid simulators. Among the most important conclusions achieved in this work, we may outline the two following ones: (i) The SSB and ISB protocols are more efficient than the other window-based protocols found in the literature. Considering the comparative theoretical analysis carried out in this work, our proposals showed to account important aspects for settling a better trade-off between piece diversity in the system and time requirements of streaming applications; (ii) The simulators of the fluid-based and hybrid-based categories are the most appropriate ones when evaluating competitive P2P approaches. Both of them allow the execution of fluid-based simulations, which are known to facilitate the modeling process and the achievement of the desired results for the simulation. We believe future work in this field of study includes further analysis of the window concept in order to determine which other functionalities may still be added to it. We also point out the possible study of different neighbor selection policies along with our proposals, in addition to carrying out simulations in order to illustrate and quantify the efficiency of our proposals. Still, the work presented by D'Acunto et al. (2012) shows that the indirect reciprocity strategy, proposed in Mol et al. (2008), provides several interesting insights when working together with some piece selection strategies. We therefore see how important it is to also consider other than the conventional peer selection strategy that has been originally proposed in the work of Cohen (2003). Besides, as the P2P architecture has also been pointed out as an interesting approach for the studies in the Future Internet area (Fouda et al. 2010), we find it interesting to assign additional responsibilities to the tracker. For example, besides keeping track of the participants of a swarm, the tracker could also act as a network sensor and make decisions to improve the dynamics of the distributed system. At last, the transition to the IPv6 network protocol (Ladid & Chochliouros, 2012) can also address some new research directions in the field of streaming services. Even though this protocol is primarily being deployed to enable more connected devices to the Internet, it promises to come with some new features that can change the data transmission dynamics in the network. This way, we mention the necessity to study the implications of this protocol in BitTorrent streaming systems as well. REFERENCES
Amoretti, M., Agosti, M. & Zanichelli, F. 2009. DEUS: a discrete event universal simulator. In 2nd International Conference on Simulation Tools and Techniques, Italia. Baumgart, I., Heep, B. & Krause, S. 2007. OverSim: A flexible overlay network simulation framework. In 10th IEEE Global Internet Symposium (GI '07) in conjunction with IEEE INFOCOM 2007, Anchorage, USA. Bharambe, A. R., Herley, C. & Padmanabhan, V. N. 2006. Analyzing and improving a BitTorrent networks performance mechanisms. In IEEE INFOCOM 2006, Barcelona, Spain. Bhardwaj, R., Upadhyay, A. K. & Dixit, V. S. 2010. An overview on tools for peer to peer network simulation. International Journal of Computer Applications. Borghol, Y., Ardon, S., Carlsson, N. & Mahanti, A. 2010. Toward efficient on-demand streaming with bittorrent. In IFIP Networking, Chennai, India. Bracciale, L., Piccolo, F. L., Luizzi, D. & Salsano, S. 2007a. OPSS: an overlay peer-to-peer streaming simulator for large-scale networks. In ACM SIGMETRICS Performance Evaluation Review. Bracciale, L., Piccolo, F. L., Luizzi, D. & Salsano, S. 2007b. Simulation of peer-to-peer streaming over large-scale networks using OPSS. In 2nd International Conference on Performance Evaluation Methodologies and Tools, France. Carlsson, N. & Eager, D. 2007. Peer-assisted on-demand streaming of stored media using bittorrent-like protocols. In Proceedings of the IFIP NETWORKING 2007, EUA, Springer: 570-581. Cohen, B. Incentives build robustness in BitTorrent. 2003. In First Workshop on Economics of Peer-toPeer Systems, Berkeley, EUA. D'Acunto, L., Chiluka, N., Vink, T. & Sips, H. 2012. BitTorrent-like P2P approaches for VoD: A comparative study. Computer Networks. De Souza e Silva, E. & Leo, R. M. M. 2009. The TANGRAM-II integrated modeling environment for computer systems and networks. ACM SIG-METRICS: performance evaluation review, New York.

38

ESPE Ciencia & Tecnologa, Vol. 4, No. 1, 2013

De Souza e Silva, E., Leo, R. M. M., Santo, A. D., Azevedo, J. A. & Netto, B. C. M. 2006. Multimedia supporting tools for the CEDERJ - distance learning initiative applied to the computer systems course. In 22th ICDE World Conference on Distance Education, Rio de Janeiro, Brazil. De Vielmond, C. C. L. B., Leo, R. M. M. & de Souza e Silva, E. 2007. Um modelo HMM hierrquico para usurios interativos acessando um servidor multimedia. In Simpsio Brasileiro de Redes de Computadores, Belm, Par, Brazil. In Portuguese. Fouda, M. M., Taleb, T., Guizani, M. & Kato, N. 2010. Towards efficient P2P-based VoD provisioning in future internet. In Communications and Networking in China (CHINACOM). Hoffmann, L. J., Rodrigues, C.K.S. & Leo, R. M. M. 2011. BitTorrent-like protocols for interactive access to VoD systems. European Journal of Scientific Research, v. 58 (4): 550-569. Huang, Y., Fu, T. Z., Chiu, D. -M., Lui, C. & Huang, J. C. S. 2008. Challenges, design and analysis of a large-scale P2P VoD system. In ACM SIGCOMM Conference on Data Communication, Seattle, USA. Hwang, K. W., Misra, V. & Rubenstein, D. 2008. Stored media streaming in bittorrent-like P2P networks. Tech Report, Columbia University, NY. Kangasharju, J., Schmidt, U., Bradler, D. & Schrder-Bernhardi, J. 2007. Chunksim: Simulating peer-topeer content distribution. In Spring Simulation Multiconference, San Diego, EUA. Katsaros, K., Kemerlis, V. P. & Xylomenos, G. 2009. A BitTorrent module for the OMNeT++ simulator. In 17th IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS), UK. Konrath, M. A., Barcellos, M. P. & Mansilha, R. B. 2007. Attacking a swarm with a band of liars: evaluating the impact of attacks on bittorrent. In 7th IEEE International Conference on Peer-to-Peer Computing. Ladid, L. & Chochliouros, O. I. 2012. The Impact of IPv6 on Video-to-Video and Mobile Video Communications. IFIP Advances in Information and Communication Technology 382: 322-331. Legout, A., Urvoy-Keller, G. & Michiardi, P. 2006. Rarest first and choke algorithms are enough. In 6th ACM SIGCOM Conference on Internet Measurement, Rio de Janeiro, Brazil. Mansilha, R. B., Barcellos, M. P. & Brasileiro, F. V. 2008. TorrentLab: um ambiente para avaliao do protocolo BitTorrent. In SRBC, Rio de Janeiro, Brazil. In Portuguese. Mol, J. J. D., Pouwelse, J. A., Meulpolder, M., Epema, D. H. J. & Sips, H. J. 2008. Give-to-get: freeriding-resilient video-on-demand in P2P systems. In Proceedins of the SPIE MMCN. Montresor, A. & Jelasity, M. 2009. PeerSim: A scalable P2P simulator. In 9th IEEE International Conference on Peer-to-Peer Computing. Pujol-Ahullo, J. & Garca-Lopez P. 2009. PlanetSim: An extensible simulation tool for peer-to-peer networks and services. In 9th IEEE International Conference on Peer-to-Peer Computing (P2P '09), 2009. Rao, K, Bojkovic, Z. & Milovanovic, D. A. 2002. Multimedia Communication Systems: Techniques, Standards and Networks. Englewood Cliffs, NJ: Prentice-Hall. Savolainen, P., Raatikainen, N. & Tarkome, S. 2008. Windowing BitTorrent for Video-on-Demand: Not all is lost with Tit-for-Tat. In IEEE GLOBECOM, New Orleans, LA, EUA. Shah, P. & Pris, J. -F. 2007. Peer-to-Peer multimedia streaming using BitTorrent. In IEEE International Performance, Computing, and Communications Conference IPCCC, New Orleans, EUA. Stais, C. & Xylomenos, G. 2012. Realistic media streaming over BitTorrent. In Proceedings of the Future and Mobile Summit 2012 Conference. Vlavianos, A., Iliofotou, M. & Faloutsos, M. 2006. BiToS: Enhancing BitTorrent for supporting streaming applications. In 9th IEEE Global Internet Symposium, Barcelona, Spain. Xu, H., Wang, S. -P., Wang, R. -C. & Tan, P. 2011. A survey of peer-to-peer simulators and simulation technology. Journal Of Convergence Information Technology: 260-272. Yang, W. & Abu-Ghazaleh, N. 2005. GPS: a general peer-to-peer simulator and its use for modeling BitTorrent. In 13th IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems. Yang, Y., Chow, A. L. H., Golubchik, L. & Bragg, D. 2010. Improving QoS in bittorrent-like VoD systems. In Proceedings of the IEEE INFOCOM: 1-9. Zaky, A. B., Salama, M. A & Zayed, H. H. 2011. Adaptive Sliding Piece Selection Window for BitTorrent Systems. Advances in Multimedia - An International Journal (AMIJ). Zhou, Y., Chiu, D. M. & Lui, J. C. S. 2007. A simple model for analyzing P2P streaming protocols. In: IEEE International Conference on Network Protocols ICNP.

Semestral Magazine of the Escuela Politecnica del Ejercito, Sangolqui-Ecuador

39