P2P Streaming: a Study on the Use of Advertisements as Incentives

Transcription

1 P2P Streaming: a Study on the Use of Advertisements as Incentives Bo-Chun Wang, Alix L.H. Chow, Leana Golubchik Department of Computer Science, University of Southern California Nokia Research Center, Beijing, China {bochunwa@usc.edu, alix.chow@nokia.com, leana@usc.edu} ABSTRACT P2P streaming systems, such as PPLive, PPStream, and TVUPlayer, have become popular services with the widespread deployment of broadband networks. However, P2P streaming systems still face free-riding problems, similar to those that have been observed in P2P file sharing systems. Thus, one important problem in providing streaming services is that of providing appropriate incentives for peers to contribute their upload capacity. To this end, we propose the use of advertisements as an incentive for peers to contribute upload capacity. In the proposed framework, peers enjoy the same quality of streamed media, with the difference in quality of service being achieved through different amounts of advertisements viewed, based on the resource contributions to the system. An extensive simulation-based study is performed to evaluate the proposed approach. The results demonstrate that our approach provides appropriate incentives for peers to contribute their resources. Categories and Subject Descriptors C.2 [COMPUTER-COMMUNICATION NETWORKS]: Distributed networks General Terms Design; Performance Keywords P2P streaming systems; incentive; advertisement; token-based;. INTRODUCTION The use of Peer-to-Peer (P2P) technology has led to efficient distribution of content over large scale networks. For instance, Bit- Torrent [] is one of the most successful file sharing applications in use today. In the past few years, P2P-based streaming has become another popular service, with the widespread deployment of broadband networks. P2P-based approaches to streaming have become popular, as compared to traditional client-server-based approached, due to the following advantages: low cost, scalability, and ease of deployment. There are already several P2P streaming applications deployed on the Internet, such as PPLive [3], PP- Stream [5], and TVUPlayer [6]. Moreover, a number of efforts have focused on measurement and analysis of such P2P streaming systems [9, 2, 27]. However, P2P streaming systems still suffer from free-riding problems, i.e., similarly to the free-riding problems observed in P2P file sharing systems. For example, X. Hei et al [9] provide four measurement results of PPlive (two from university campuses and two from residential locations). Peers in one of the residential locations do almost no uploads. These peers may be considered as freeriders. Moreover, they have also shown that deployed streaming systems performance depends on peers with high upload capacities, given that there is significant upload bandwidth heterogeneity on the Internet. In order to provide satisfactory performance, the quantity of peers with high upload capacities in streaming systems should be sufficiently high []. Therefore, the problem of how to provide appropriate incentives for peers to contribute their upload capacity to the system is an important one in the context of P2P-based streaming systems. Although some approaches exist for addressing this problem in the context of P2P file sharing systems, providing incentives in streaming systems can be a more complex problem. For instance, such approaches in file-sharing systems typically provide a reduction in file downloading time as an incentive. However, in streaming systems, a peer s quality of service depends on video quality (e.g., smoothness of video delivery), rather than on how fast the entire stream (e.g., video) can be downloaded. Hence, there is a need for re-considering the problem of providing appropriate incentives for peers to contribute resources in the context of P2P streaming systems. To address the incentives problem in streaming systems, several techniques have been proposed in the literature, such as [, 4 6, 8, 2, 2, 23, 25]. Most of these works use improved video quality as an incentive, achieved through layered coding-based or MDC-based techniques [4, 5, 7]. Briefly, the basic idea here is that peers will have better video quality when they upload more data. (A more detailed description is given in Section 5.) In this paper we consider an alternative direction for providing incentives in P2P streaming systems, namely that of using the amount of advertisements viewed as an incentive to contribute more resources, as described next. Our approach is orthogonal to (and can be combined with) previous efforts whose goals are to provide better video quality (as detailed below). Advertisement supported service has become a popular business

2 model. Many popular systems ask users to watch advertisements before users start to watch videos (e.g., Youtube [7] and Hulu [2]). Since advertisements could provide additional revenue for a service provider in a P2P streaming system, such providers could include advertisements in the distributed content (e.g., as is currently done on television). Since all peers (whether high or low capacity) are concerned with video quality (e.g., in the form of smoothness in data delivery), controlling the amount of advertisements viewed by a peer would be another approach to providing incentives for peers to contribute resources in a P2P streaming system. (In a sense, our system is analogous to having broadcast (free) TV and paid TV channels, e.g., such as HBO. For instance, a user can view movies on a paid TV channel without advertisements, or the user can view the same movie on a free TV channel with advertisements. In our case, the payment" we consider is the peers resource contribution.) Briefly, in our proposed system, peers who contribute more upload capacity view fewer advertisements than peers who contribute less upload resources. Thus, unlike in layered coding/mdc based schemes, low capacity peers can still enjoy good video quality but with more advertisements than higher capacity peers. In this paper, we focus on the architecture of such a system and its evaluation, including issues such as tracking of peers contributions while preventing malicious behavior as well as efficient distribution of advertisements. One important challenge in such a system is accounting for peers contributions, on which the system can in turn base the computation of the amount of advertisements a peer should view. One possible approach is to allow peers to report their own contributions. However, since malicious peers may report more than their actual contribution, such a method is open to abuse by free-riders or malicious peers. Therefore, in this paper, we design token-based schemes to address the problem of determining how much contribution each peer is making. Token-based schemes have been used in P2P file sharing systems [3, 9, 26, 29] as well as other systems. In [3, 26, 29], token-based schemes are considered as a form of credit systems or micro-payment systems, where peers can exchange tokens, as virtual currency, to receive resources or services, and a service provider can charge based on the amount of tokens attained. In [9], token-based schemes are used for two incentive purposes, reputation and payment. Peers should maintain high reputation, otherwise, other peers may refuse to interact with them. In addition, peers pay" with tokens for downloading content and receive tokens for uploading content to other peers. Thus, a free-rider cannot download data due to lack of tokens. In this paper, we adopt the idea of using tokens as payment in designing our system. Our main purpose in utilizing tokens is in creating a mechanism for accounting for peers contributions. Unlike other efforts where tokens are used to limit downloading or support reputation, we use tokens to determine the amount of advertisements peers should view. (The details of our system architecture are given below.) Briefly, in our token-based schemes, a peer pays" with tokens when downloading steaming content. A peer receives tokens, when contributing its upload capacity for streaming data to other peers. Then, the amount of advertisements shown to each peer is based on the number of tokens each peer possesses. The advantage of this token-based approach is that the use of tokens can prevent malicious peers from reporting incorrect contributions. In addition, we insure that malicious peers do not fake" tokens (i.e., generate tokens on their own) through the use of cryptographic-based signatures. Our contributions in this paper can be summarized as follows. We consider the use of advertisements as an incentive in P2P streaming systems for peers to contribute upload resources and propose a corresponding P2P-based streaming system architecture. Since, advertisement supported services are likely to become more and more popular, our approach could provide peers an important incentive for contributing their upload capacity. In Section 3, our simulation-based study demonstrates the utility of this approach - for instance, when peers increase their uploading rate, the system provides reduced amount of advertisement based on true contributions. Moreover, we also focus on efficient distribution of advertisements in Section 3.. We propose a token-based framework as an approach to address the problem of accounting for peers contributions so as to determine the amount of advertisements peers should view (see Section 2). We propose three token-based schemes and explore their characteristics, such as overhead, reliability, management, and resilience to malicious behavior (see discussion in Section 4). In Section 3, we present our simulationbased study that illustrates several useful characteristics of our schemes. These include, a demonstration of how to reduce overhead needed for implementing such token-based schemes in Section 3.2 and what are the trade-offs between overhead reduction and accuracy in Section 3.3. Our results provide system developers with insight into efficient development of P2P-based streaming systems that utilize advertisements as incentives for resource contribution. 2. THE PROPOSED SYSTEM In this section, we present the proposed system which uses advertisements as incentives in a P2P streaming system. In this system, peers view different amounts of advertisements, based on their resource contributions to the system. An advertisement in our system can be any object - e.g., it can be a video clip, flash animation, streamed media, and so on. In general, the type of advertisement is determined by the content provider. For ease of exposition, in this paper we focus on one type of advertisement, namely streamed media. The main challenge in our system is that of determining peers true resource contributions. One possible approach is to allow peers to report their own contributions. However, this method does not prevent malicious peers from reporting incorrect contributions. That is, in order for advertisement-based incentives to produce a desired effect, we need to construct a system where peers contributions can be determined reasonably accurately (at least relative to each other). To this end, we design token-based schemes. schemes include three functions: token generation: How are tokens generated? Our token-based token exchange: How do peers exchange tokens in order to download streamed content? contribution calculation: How are peers contributions calculated, and how is the amount of advertisements peers have to view determined?

3 Streaming Server Token Server Streamed media Tokens Advertisement Peer with high uploading rate ti,p ai,p ti,p+ ai,p+ Figure 2: Time Interval: peer views streaming content during time interval t i,p and views advertisements during time interval a i,p Figure : System Architecture Peer with low uploading rate Pi Pj Pk (a) Since token generation and contribution calculation could be done at the peer-side or the server-side, we consider different combinations and propose the following schemes in this paper: Token generation at Peer-side and Contribution calculation at Peer-side (TPCP) Token generation at Server-side and Contribution calculation at Peer-side (TSCP) Serial Number Timestamp Pi s ID Pj s ID Pk s ID (b)reuse Serial Number Timestamp Pi s ID Pj s ID # of tokens (c)non-reuse Token generation at Peer-side and Contribution calculation at Server-side (TPCS) Figure 3: Token Structure Note that, using different token-based schemes does not affect the quantity of peers contributions. The motivation for considering different schemes is to explore overhead and reliability characteristics of each schemes. The information can help system developers choose appropriate schemes by considering the trade-offs between overhead and reliability. Note that, we do not consider token generation at the server-side and contribution calculation at the serverside because this scheme is completely centralized and is not appropriate for P2P systems. Fig. illustrates our system architecture. The system consists of a streaming server and peers. In the TSCP and TPCS schemes, the system also includes a token server. The streaming server and the token server are managed by the service provider. The streaming server is responsible for generating the streamed content as well as the advertisements, while the token server is responsible for generating tokens or computing peers resource contributions. The sources of advertisements could be the service provider or sponsors. The streaming format considered in the remainder of the paper is single-layer video with substreams, as in [6]. The basic idea of substreams is to encode a video stream into several substreams, each having the same video rate, i.e., the streaming server encodes streamed content into k substreams and distributes k substreams through the P2P system. The main advantage of a system using substreams is that it can be extended to using different coding schemes. In [6], the authors have shown that such a substream-based mechanism can be applied to several different coding schemes, including single-layer video, layered coding-based video, and MDC. Since the use of video quality as an incentive is not our goal here, for simplicity of illustration, we use single-layer video with substreams. However, as noted earlier, our approach can be combined with layered coding-based video or MDC schemes. In the TSCP and TPCS schemes, when a peer wants to join or depart from the overlay system, it has to contact the token server. The token server keeps login information of each peer, as a way of checking whether the peer exists in the system or not. The login information is used when the token server distributes tokens to peers or calculates a peer s contribution. After a peer joins the overlay network, it connects to n neighbors to download streaming content and advertisements. In addition, peers randomly choose new neighbors periodically. In the system, a peer has to provide tokens when it downloads data from other peers. Conversely, it receives tokens from other peers when it streams (uploads) data to them. The amount of data, δ, that a peer can download upon providing one token is determined by the service provider. Moreover, uploading advertisements is also considered as a peer s contribution, since such upload bandwidth contribution can reduce the load on the streaming server. A peer making a greater contribution accordingly receives a greater number of tokens from other peers. In our system, the downloaded content and advertisements are kept in the local cache of a peer. Peers must view advertisements after they have viewed some amount of content. For instance, consider the example in Fig. 2, where peer i views content in the p-th time interval, t i,p. Then, the system displays advertisements of length a i,p which is calculated based on peer i s contribution during t i,p. Therefore, a i,p is different from interval to interval. The length of time interval t i,p is the same for every peer, and it is determined by the service provider. At the end of each time interval, t i,p, peers contributions are calculated and used to determine the amount of advertisements that each peer should view. Below, we describe in detail our token-based schemes and how peers contributions are calculated in our system. For convenience, a summary of notation used in the paper is given in Table.

4 k n δ N t i,p a i,p c i,p r i,p g i,p s i,p f i,p Max(f) Def(f) Min(f) Min(c) Equal(c) number of substreams number of a peer s neighbors amount of data a peer can download per one token number of tokens the token server sends to a peer for each content interval p-th time interval for viewing content p-th time interval for viewing advertisements peer i s contribution during t i,p number of tokens received by peer i during t i,p number of tokens generated by peer i during t i,p number of tokens sent by peer i to other peers during t i,p ratio of advertisement time length to time length of streamed content maximum value of f i,p default value of f i,p minimum value of f i,p a peer s contribution if it is free-rider a peer s contribution while its income is equal to its spending amount Table : Notations list Token generation: Now, we describe how to generate tokens in our system. In the TPCP and TPCS schemes, tokens are generated by peers; tokens are generated by the token server in the TSCP scheme. The corresponding token structure is depicted in Fig. 3(b). Each token has a different serial number and timestamp for uniqueness. Moreover, a token includes the generator s ID and the receiver s ID. In the TSCP scheme, the generator s ID is the token server s ID, e.g., in Fig. 3, peer i is the generator and peer j is the receiver. After peer i generates a token, it encrypts the token to prevent other peers from faking tokens. In the TPCP and TPCS schemes, peers can generate tokens as needed. In the TSCP scheme, tokens are generated by the token server. Then, the token server sends tokens to peers at the start of each content interval, t i,p, as depicted in Fig. 2. The number of tokens sent, N, is sufficient for that peer to download (stream) all content needed for that content interval. Therefore, a peer does not need to generate tokens on its own. Token exchange: The token exchange function is the same for all schemes. When a peer downloads a stream from other peers, it can pay" for it by either (i) using tokens it received from other peers, or by (ii) generating new tokens, e.g., if that peer does not have sufficient tokens accumulated from serving other peers. If a peer pays for content by using received tokens, then the new owner of that token appends its ID to the token (e.g., peer k s ID in Fig. 3(b)). In our system, received tokens can be reused, and a peer does not have to generate new tokens each time it wants to download (stream) content. Contribution calculation: Now, we describe how to calculate peers contributions and how to calculate the amount of advertisement, 9 In our system, we encrypt tokens, rather than use digital signatures. The main reason is that use of encryption results in a more secure protocol than one with digital signatures. We discuss this in more detail in Section 4. a i,p, that each peer should watch. In our system, the amount of advertisement is based on a peer s resource contribution. Therefore, we have to calculate the peers contributions first. Contribution calculation is done at the end of t i,p. In the TPCP scheme, peer s contribution is calculated the at peer-side. The number of tokens received by peer i, r i,p, is regarded as the peer s income, and the number of tokens generated by peer i, g i,p, is considered as the peer s spending amount. Note that, if a peer reuses its received tokens, those tokens are not accounted for in r i,p or g i,p. We define the peer s contribution, c i,p, as the difference between r i,p and g i,p, normalized by time, i.e., c i,p = r i,p g i,p t i,p () In the TPCS scheme, the token server is responsible for calculating contributions. Therefore, peers have to report received tokens to the token server. The definition of a peer s contribution in TPCS is the same as Eq. (). In the TSCP scheme, a peer s contribution is also calculated at the peer-side. However, the definition of a peer s contribution is different from Eq. (). In the TSCP scheme, tokens are generated by the token server. Therefore, a peer s income includes the number of tokens received from the token server, N, and the number of tokens received from other peers, r i,p. A peer s spending amount is the number of tokens sent to other peers, s i,p. A peer s contribution in the TSCP scheme, c i,p, is c i,p = N + ri,p si,p t i,p (2) The method used to calculate a i,p is the same in all schemes. We define f i,p, the ratio of the advertisement time length to the time length of streaming content, e.g., in Fig. 2, f i,p is the ratio of a i,p to t i,p. Intuitively, the value of f i,p is inversely proportional to c i,p. Therefore, there are many functions which can be used to determine the value of f i,p, e.g., exponential, linear, logarithm, etc. This choice depends on how quickly" the system would like to reward" peer contributions, e.g., if an exponential function is used, the value of f i,p would decrease quickly as a peer s contribution increases. In this paper, we use a piecewise linear function, as explained next. We classify peers into three groups based on their c i,p. (The service provider defines default, minimum, and maximum values of f i,p, which are described next.) Intuitively, if a peer is a free-rider who does not contribute resources, its resource contribution is Min(c). The value of Min(c) derived from Eq. () in TPCP and TPCS is g i,p/t i,p, and the value of Min(c) derived from Eq. (2) in TSCP is (N s i,p )/t i,p. Then, a free-rider s f i,p is set to the maximum value, Max(f), if it is the maximum length of advertisements for free-riding. Otherwise, a peer s f i,p decreases as its resource contribution increases. If a peer s income is equal to its spending amount, its c i,p is Equal(c) and its f i,p is set to the default value, Def(f), whereas if a peer s c i,p exceeds a threshold, λ, its f i,p is set to the minimum value, Min(f). The value of Equal(c) derived from Eq. () in TPCP and TPCS is, and the value of Equal(c) derived from Eq. (2) in TSCP is N/t i,p. The definition of f i,p is given in Eq. (3), with a corresponding depiction in Fig. 4.

5 Max(f) Def(f) Min(c) Equal(c) i,p+ Min(c) Def(f) Equal(c) Max(f) Min(c) Equal(c), if c i,p < f i,p = (Def(f) Min(f)) c Equal(c) λ i,p+ Equal(c) Min(f) λ Def(f) Equal(c) λ Min(f), if c i,p < λ, if λ c i,p (3) Max(f) Number of peers : 6: 2: 8: 24: Time f i,p Def(f) Figure 5: Population of peers viewing streaming data in the PPLive system Min(f) Min(c) Equal(c) λ c i,p Figure 4: The function used by the token server to calculate f i,p. Finally, we define the amount of advertisement, a i,p, for each peer i as a i,p = f i,p t i,p. In the TPCP and TSCP schemes, the software at the peer-side calculates each peer s a i,p. In the TPCS scheme, the token server sends each peer a message with its a i,p value. After receiving the a i,p value, the display of advertisements, kept in local cache, begins. In addition, the value of f i,p is reported to the streaming server. The streaming server can use this information to decide on the proportion of advertisements to content, when it distributes streamed media. We define f as the ratio of advertisements to content. In our system, the streaming server chooses f to be equal to the average value of f i,p. Reducing overhead: We, now, discuss the issue of token reuse. In our system, received tokens can be reused, and a peer does not have to generate new tokens each time it wants to download (stream) content. An advantage of reusing tokens is the decreased overhead, particularly the amount of computation needed to perform decryption at the token server (as each token is signed by its generator to prevent malicious users from generating fake tokens). We give an example to demonstrate the computational overhead of decryption, using an Intel Xeon E542 and 32GB of memory. There are strings whose lengths are 5 bytes, and these strings are encrypted by 24 bits RSA. The total time to decrypt these strings is about 4 minutes. Although the token server can afford such computational overhead, reusing tokens can decrease it. We depict the token reporting packet structure of reusing tokens and non-reusing tokens in Fig. 3. The two structures are similar - both include serial number, timestamp, generator s ID, and receiver s ID. The difference is that in the reusing mechanism, there is a signature of the token s new owner". As a result, one drawback of reusing tokens is an increase in token reporting packet s length, as the token s new owner" has to append its signature to the token reporting packet. If tokens cannot be reused, a peer can send a packet which includes several tokens, i.e., the last row of the non-reuse packet structure gives the number of tokens", as depicted in Fig. 3. However, even though a packet can include several tokens, the amount of reported packets in the non-reusing mechanism is still higher than the amount in the reusing mechanism. The reason is that peers have to report every packet in the non-reusing mechanism. We note that, in the reusing mechanism, each packet indicates only one token because the receiver cannot split the packet into two packets with a smaller number of tokens. For example, if peer i sends peer j a packet which indicates 5 tokens, and the packet has been encrypted by peer i, then, peer j cannot divide this packet into two packets with 2 and 3 tokens, respectively, as the packet has been encrypted. This limitation may result in more transmitted packets between peers in the reusing tokens mechanism. In Section 3, we compare the overhead and corresponding performance of the reusing tokens and non-reusing tokens mechanisms. 3. EVALUATION In this section, we evaluate the proposed token-based schemes. The goal of this paper is to explore the utility of an approach that uses advertisements as incentives in P2P streaming systems, rather than exploring such a system s implementation. To this end, we use simulations to demonstrate essential characteristics of our system and to study its characteristics in a more controlled environment. An advantage of using simulations is that we can control different parameters and observe effects of each parameter. We develop a simulator to evaluate the proposed token-based schemes, where we use traces to simulate peer dynamics. The traces are available from the PPLive Project at [4], collected from the PPLive streaming system. Specifically, the PPLive crawler takes system snapshots every ten minutes and records peer IDs. The traces used in our simulation are collected during one day. Fig. 5 depicts the population of peers viewing media during a one day period. The simulator assigns the uploading bandwidth of peers based on the distribution given Table 2, which corresponds to measurements in [8]. Because peers typically do not contribute all of their uploading capacity, by default (i.e., unless otherwise stated) we begin with a conservative view and consider peers contributing 6% of their uploading capacity. We also vary this contribution in our simulations (as detailed below). Furthermore, we assume that the downloading bandwidth of peers is sufficient to stream the video (i.e., greater than the streaming rate). We consider single-layer video in our simulations. As stated in [9], most video rates in PPLive are between 25 kbps and 4 kbps;

6 Upload bandwidth (kbps) Distribution (%) Upload bandwidth (kbps) Distribution(%) Table 2: Uploading bandwidth distribution parameter default value k n δ 5kb t i,p min Max(f) Def(f).3 Min(f). Table 3: Default value of parameters thus, in our simulations, the video rates of streaming content is 3 kbps. The number of substreams is k =, which is the same as in [6], i.e., the video is divided into substreams, each with the same video rate. We assume a peer can download an entire substream from one neighbor. Therefore, in our simulations, peers connect to neighbors simultaneously. A peer randomly chooses new neighbors every 3 seconds. (We do not consider peer selection algorithms here since video quality is not the focus of this work.) In these experiments, the default amount of data a peer can download from its neighbor when paying one token, δ, is 5kb. Moreover, the default value of content interval, t i,p, is minutes (which is similar to content intervals used in TV programs), and the amount of advertisements a peer has to view, a i,p, is calculated at the end of each t i,p. In what follows, we vary the values of δ and t i,p (as detailed below). Table 3 summarizes the default parameter values. We now show evaluation results of our system. All results are based on the following assumptions: tokens are received or reported correctly and there are no malicious attacks. Because tokens are encrypted, we can assume malicious peers cannot fake tokens, and tokens can be received or reported correctly. We discuss malicious behavior in Section 4. In our simulations, we need to set the maximum, default, and minimum values of f i,p. We set Max(f) =. The time length of advertisement a peer views is not greater than the time length of content a peer views. In addition, if peer i is a free-rider, the time length of advertisements it has to view is equal to the time length of content it has viewed. Then, we set Def(f) and Min(f) to.3 and., respectively. We base these on statistics given in [24], which show that from 952 to 2, the average of f i,p of TV programs increased from.5 to.47. Because service providers of P2P streaming systems may provide fewer advertisements than TV, to attract users, we believe these are reasonable settings for Def(f) and Min(f). In addition, in our experiments, we use Min(f) >, motivated as follows. As a service provider can receive revenue from displaying advertisements to peers, it is likely to have peers view some amount of advertisements. We also set λ to g i,p /t i,p in TPCP and TPCS schemes and to (N+s i,p )/t i,p in TSCP scheme - that is, if a peer s received tokens are more than twice of its generated or sent tokens (derived from Eqs. () and (2)), its f i,p =.. Since, the ratio of average uploading bandwidth to streaming rate is less than 2 (in this work), we believe this is a reasonable threshold setting. We illustrate that our system can provide peers differentiated service, using the amount of advertisements they view, based on their resource contributions. Fig. 6 demonstrates the average of f i,p for different peer classes in three token-based schemes. The results of the three schemes are similar because we use the same equation to calculate a peer s contribution. The results are not affected by where tokens are generated and contributions are calculated. Our results show that the average of f i,p decreases as a peer s contribution increases. Since the uploading rate of a peer in the first three classes is less than its downloading rate, its f i,p is higher than Def(f). If a peer wants to view fewer advertisements, it needs to increase its uploading rate. Thus, in the next experiment, we increase a peer s uploading rate from 6% of total uploading capacity to 7% and 8%. The trends of f i,p for different peer classes, under 7% and 8% uploading capacity, are qualitatively similar to those when uploading bandwidth is 6% of the capacity. Therefore, we only depict the average of f i,p in Fig. 7. This figure indicates that the average of f i,p decreases about 28% when a peer increases its uploading rate from 6% to 8% of the capacity. This indicates that we can use advertisements as incentives in P2P streaming systems, i.e., in order to view fewer advertisements, a peer needs to contribute more. 3. Advertisement Distribution Recall that in our system, after peers download advertisements, they are kept in the local cache. If the amount of downloaded advertisement is more than the amount of advertisement a peer has to view, some downloaded advertisements would not be displayed. On the other hand, if the amount of downloaded advertisement is less than the amount of advertisement a peer has to view, some downloaded advertisements would be repeated. Therefore, it is an important consideration for the streaming server to determine how much advertisement should be distributed. That is, distributing too much advertisement data causes network overhead and results in some useless advertisements being downloaded by peers. However, distributing too little advertisement content results in peers viewing a lot of repeated advertisements. This situation may not be satisfactory for a service provider as their profit might depend on how often a particular advertisement is viewed. We now consider simple strategies for advertisement distribution. (More sophisticated techniques are possible but are outside the scope of this paper.) To this end, we define the following two performance metrics: surplus: the ratio of advertisement which is not viewed relative to all of downloaded advertisement. The value of i surplus is [max(f,f i,p) f i,p ], where f is the ratio of advertisement to streamed media content and f i,p is based on a i f peer s contribution; repeat: the ratio of repeated advertisement to all of downloaded advertisement. The value of repeat is i [f i,p min(f,f i,p )]. i f In our experiments, we use three different values of f: Min(f), Max(f), and the average of f i,p, Avg(f), and evaluate their surplus and repeat. Because the results of the three schemes are similar, we show the result from the TPCP scheme only. Based on our experiments, the average of surplus and repeat are depicted in Fig.8 and Fig.9, respectively.

7 f i,p f i,p TPCP TPCS TSCP.2. f i,p f i,p uploading bandwidth (kbps) (a) TPCP uploading bandwidth (kbps) (b) TPCS uploading bandwidth (kbps) (c) TSCP Figure 6: average f i,p for peers with different uploading bandwidth in three schemes The results indicate that using Min(f) as f causes less network overhead, with no surplus advertisements. However, this strategy has to display the same advertisement repeatedly. On the other hand, using Max(f) guarantees that peers do not view repeated advertisement; however, it results in significant surplus in advertisement content. Fig.8 demonstrates that the average surplus advertisement is more than 5% of all downloaded advertisement. One approach to finding a balance between these two metrics is to use Avg(f). Our results indicate that the average of surplus and repeat (when using Avg(f)) are both about.. That is, compared to Min(f) and Max(f), using Avg(f) as f can reduce surplus advertisement, while also reducing repeated advertisement. 3.2 Reusing tokens vs. Non-reusing tokens uploading ratio (%) Figure 7: average f i,p for peers with different uploading ratio in three schemes We now focus on reusing tokens vs. non-reusing tokens mechanisms. In the above experiments, peers were allowed to reuse received tokens. As noted earlier, the main advantage of reusing tokens is to reduce overhead of the system, especially in the TPCS scheme, where peers have to report tokens to the token server. Since each token has been encrypted by its generator, there is significant overhead involved in the token decryption process; hence, it is the motivation for reusing tokens in our system. In this section, we use results from the TPCS scheme. Now, recall that in the nonreuse mechanism, after a peer receives tokens from its neighbors, it reports these tokens to the token server immediately, whereas in the reuse mechanisms, a peer can reuse received tokens. Firstly, we focus on the overhead of these two mechanisms. We first define the following parameter. α: the average number of packets reported to the token server by each peer during time interval t i,p. The value of α is # of packets (# of peers)*t i,p. Since the token server s overhead increases as the value of α increases, our goal is to reduce α. Fig. depicts the value of α in these two mechanisms under different values of δ. In the non-reuse mechanism, α remains constant as a function of δ. The reason for this is that in the non-reuse scheme, each packet can include several tokens, as shown in Fig. 3. Fig. illustrates that α decreases in the reuse mechanism as δ increases. This indicates that the reuse mechanism reports fewer packets than the non-reuse mechanism when δ is sufficiently large (e.g., 25kb and 5kb in our experiments). Hence, reusing tokens can reduce overhead. However, the performance of the reuse mechanism degrades when δ is too small (e.g., kb in our experiments). If δ is too small, a peer has to generate too many tokens. Then, the reuse mechanism behaves worse in terms of overhead than the non-reuse mechanism. Thus, the value of δ should not be too small; otherwise, peers would generate too many tokens, thus increasing the token server s overhead. 3.3 Content Interval, t i,p Now, we focus on the effects of t i,p. If the service provider chooses a small value of t i,p, then the system can reflect peers behavior better. However, if t i,p is too small, the system interrupts peers frequently to display advertisements, which would not lead to good service. Thus, we focus on whether choosing different content in-

8 .6.2 surplus Min(f) Max(f) Avg(f) f difference (%) t i,p (min) Figure 8: The average of surplus by using different f repeat Min(f) Max(f) Avg(f) Figure 9: The average of repeat by using different f α f δ (kb) reuse nonreuse Figure : The value of α under different δ tervals, t i,p, affects accuracy when calculating peers contribution. We also consider overhead at the token server under different t i,p values. Therefore, we use results from the TPCS scheme. We vary t i,p from minute to 2 minutes and calculate f i,p under different t i,p s. We use f i,p with the minute setting as our baseline. Then, we define difference as the difference between f i,p under different t i,p s and the baseline. The equation for difference is i f i,p fi,p baseline i f i,p baseline, and the results are given in Fig.. (Here, we focus on the overall system performance rather than on per class behavior.) Figure : The average of difference under different t i,p difference (%) uploading ratio (%) Figure 2: The average of difference when peer s uploading ratio changes from 6% to %, t i,p = min When t i,p increases, the difference also increases. By using short t i,p, the system can account for peers contributions in real time. On the other hand, if the system updates using longer time intervals, the results represent peers average contributions during t i,p. In addition to t i,p, peers uploading rate also affects results. In Fig.2, t i,p is fixed at min, and a peer s uploading rate changes from 6% of upload capacity to %. The results indicate that the difference increases when a peer increases its uploading rate. When a peer increases its uploading rate to % of the capacity, the average uploading bandwidth is higher than the video rate. Then, a peer has more choices when selecting from which peers to download. Therefore, the number of uploading connections for each peer may change dramatically while the number of downloading connections stays the same. In such a case, the difference may increase. We now consider the token server s overhead under different t i,p s. We depict α, the average number of reported tokens, in Fig.3(a). In addition, we define β as the average number of times each token has been reused, with results depicted in Fig.3(b). Fig.3 demonstrates that α decreases and β increases, when the token server chooses longer t i,p s. The results indicate that using longer t i,p s can reduce overhead at the token server, i.e., tokens can be reused more times when t i,p is longer. 4. DISCUSSION

9 α β t i,p (min) (a) α: the average number of reported tokens t i,p (min) (b) β: the average number of times each token has been reused Figure 3: The overhead in token servers. Extending to multi-layer streaming: Our experiments use singlelayer streaming. However, our token-based schemes can be extended to multi-layer-based streaming. Briefly, in the TPCP and TPCS schemes, a peer with low uploading bandwidth can just download the base layer and generate fewer tokens. A peer with high upload bandwidth can download more enhanced layers and pay more tokens. In the TSCP scheme, the token server sends peers tokens. Although the number of tokens is sufficient to download all streaming content, including base and enhanced layers, a peer with low upload bandwidth can just download the base layer and keep the rest of the tokens. In such a case, its contribution can increase because its s i,p decreases as shown in Eq. (2). The usage depends on a peer s preference. If a peer prefers higher video quality, it can use the tokens to obtain enhanced layers and view more advertisement. Otherwise, a peer can choose lower video quality streaming and view fewer advertisements. Overhead of distributing advertisement: In our system, peers have to download advertisements. When peers connection capacities are poor, distribution of advertisements may make such a situation even worse. There are two possible solutions for solving the problem. The first solution is to pre-load advertisements before peers start to download content. Then, peers can just download content later. The second solution is to display downloaded advertisements repeatedly. Therefore, peers do not have to download new advertisements and can save bandwidth for downloading content. However, the two solutions may conflict with the service provider s profit. The service provider may prefer that peers watch new advertisements each time. In such a case, the service provider can deliver low quality advertisements or different types of advertisements whose sizes are small, such as flash animation, to reduce transmission overhead. Overhead of token decryption: In our system, every token is encrypted to prevent peers from faking tokens. However, decryption is a significant computational overhead in our system. Therefore, in order to reduce such overhead, peers are allowed to reuse tokens. When the length of a token is sufficiently large, an alternative mechanism that can reduce computational overhead is the use of digital signatures. In such a mechanism, peer i uses hash functions to generate a message digest of a token. Then, peer i encrypts the message digest with its private key. The result is peer i s digital signature for the token. Finally, peer i appends the digital signature to the token. After peer j receives this token from peer i, peer j can decrypt the signature by using peer i s public key and verify whether the token is sent by peer i. Because the length of a digital signature is shorter than the length of a token, the overhead of decrypting a digital signature is less than the overhead of decrypting an encrypted token. However, this would prove that a token is sent by a specific peer, but will not prevent peers from faking tokens. After malicious peers receive tokens with digital signatures, they can extract tokens content and fake tokens. In addition, malicious peers can just remove appended digital signatures from tokens and modify tokens. This is in contrast to encryption algorithms where a token can be decrypted only by token servers. Hence, we adopt encryption algorithms. 4. Comparisons between token-based schemes In Section 3, we show that using different schemes does not affect peers contribution. In this paper, the motivation for considering different schemes is to explore several issues. We discuss these issues below. Reliability: First, we discuss reliability characteristics of the three schemes. Among these schemes, TPCP is more reliable than TPCS and TSCP. The reason is that TPCP is a distributed scheme and it does not have to worry about token server failure. However, in the other schemes, the system has to deal with token server failure. In TPCS, the token server is responsible for calculating peers contributions and informing peers about the amount of advertisement they have to watch. If the token server fails, peers do not know how much advertisement they have to watch. To solve this problem, we can set a timer. If the waiting time for a token server s message exceeds the timer, the system starts to display advertisements. The length of advertisements can be based on peers history or the default value set by the service provider. In TSCP, the token server is responsible for delivering tokens to peers. If the token server fails, there are no tokens sent to peers, and peers cannot download data because of lack of tokens. In our future work, we will focus on how to increase system reliability. Overhead: In all token-based schemes, token generation, distribution, and decryption all represent overhead for the system. In TPCP, the overhead is shared by peers. However, in TPCS and TSCP, the token server has to deal with tokens. In TPCS, the token server needs to decrypt tokens before it calculates peers contributions. To reduce decryption overhead, we propose the reusing token mechanism, and our results demonstrate that this mechanism can reduce the amount of reported tokens. In the TSCP scheme, the token server is responsible for encrypting and distributing tokens to peers. To reduce such overhead, the token server can send tokens using a staggered schedule, rather than sending tokens to all peers at once. However, this may reduce system reliability.

10 Token Management: Although TPCS and TSCP are less reliable than TPCP, they result in better token management. In TSCP, tokens are generated by the token server. Therefore, the token server can control the number of tokens distributed to peers and force peers to contribute their resources. In this paper, we assume the number of tokens generated by the token server is enough for peers to download the entire content. In order to force peers to contribute resources, the token server can generate fewer tokens. In such a case, peers would have to contribute more to earn more tokens for downloading the entire content. In TPCS, tokens are reported to the token server. Therefore, the token server has better information about peers contributions and behavior. The information can be used for further system analysis and development. Service providers can use the information to decide how to distribute advertisements and which advertisements should be distributed. In our system, we use the information to determine the amount of advertisements distributed during each time interval. Service providers can use different mechanisms. For example, since service providers must satisfy advertisers needs, they can design a display schedule of advertisements based on how long peers watch advertisements and make sure every advertisement is viewed at least a specific number of times. They can also have several schedules to maximize revenues based on different peers behavior. Another example is that service providers can change system settings based on peers behavior. They can measure how much bandwidth peers are willing to contribute and determine whether they should increase or decrease the amount of advertisements. Such directions are outside the scope of this paper and are part of future efforts. In addition, peers contributions are calculated by the token server in TPCS. It can eliminate falsifying contributions at the peer-side. Malicious attacks: The motivation for using token-based schemes, in addition to reporting contributions by peers, is to determine true peers contributions. Using encrypted tokens can also prevent peers from faking tokens. Here, we discuss some attack methods and show how to protect our system from these attacks. One possible attack is from colluding peers. For instance, a peer with high upload bandwidth can forward its tokens to other peers without receiving uploads, in order to help them increase their contributions. To address this attack, when the system calculates a peer s contribution, it can consider a peer s income and spending amount simultaneously. For example, when malicious peers forward their tokens to others, the tokens would be considered as their spending. When their spending amount increases, their contribution would decrease. Thus, malicious peers would hurt their contributions by forwarding their tokens to other peers. Another solution is for service providers to change contribution calculation functions. We give two possible methods to demonstrate the idea of how to modify such functions. We define t i as the number of tokens peer i has and c i as its contribution. In this paper, we use a linear function to calculate c i. Therefore, one possibility for service providers is to change coefficients of the function. For example, the contribution calculated by the new function, c new i, is c i k, where k is larger than. In such a case, a peer needs k times the number of tokens to maintain the same contribution. Another alternative for service providers is to consider non-liner functions. Then, when a peer receives a token, the increased value of its contribution is different and is based on the number of tokens it has. For example, service providers can use an exponential function to calculate peers contributions (e.g., c new i = e t i ). In such a case, when a peer forwards its tokens to other peers, the decreased value of its contribution may be larger than the increased value of other peers contributions. Therefore, it may cause a significant loss for malicious peers contributions to forward their tokens to others. The solutions may not eliminate colluding attacks totally if a peer has a lot of tokens. However, such solutions can reduce the the number of peers that can participate. Another possible attack in TPCS is to ignore messages from the token server. For this attack, the solution is the same as the method used when the token server is down. The software will display advertisements after a set timer is exceeded. Finally, in TPCP and TSCP, contributions are calculated at the peerside. Therefore, malicious peers may try to modify software parameters, such as Max(f), Def(f), and Min(f), and affect results of contribution calculation. However, to execute such attacks, malicious peers need to modify the software. It is typically difficult (i.e., requires a certain level of expertise) to make such modifications. This issue is outside the scope of this paper and is part of future efforts. 5. RELATED WORK Since P2P streaming services became popular, there has been a number of efforts focusing on measurement and analysis of P2P streaming systems, e.g., as in [9, 2, 27]. For instance, [9] and [27] both focus on the PPLive system [3], where [9] characterizes user behavior and traffic profiles, while [27] indicates characteristics of the PPLive system that are different from those of P2P file-sharing systems. In [2] the authors focus on the Coolstreaming system and discuss various associated issues, including highly skewed resource distribution, excessive start-up time, and high failure rates during flash crowds. These works demonstrate several characteristics of existing P2P streaming systems that could be helpful for improving current streaming systems or designing future systems. Although several deployed systems have a significant number of users, [3, 5, 6, 3], the architectures of these systems are not open. Therefore, a number of other design efforts can be found in the literature, e.g., [22, 28]. For instance, [22] proposes an unstructured, mesh-based system and indicates that in such systems, the tit-fortat mechanism can result in reasonable streaming performance. In [28], the authors investigate a framework for multi-channel P2P streaming systems, which can address two problems, excessively long channel switching delays and poor performance in channels with a small number of peers. One of the main challenges in P2P streaming systems is provision of incentives for users to contribute their resources to the system - these are the efforts that, in terms of a high level goal (i.e., incentives) are closer to ours. A number of efforts have considered this problem, from a variety of perspectives, e.g., [, 4 6, 2, 2, 23]. For instance, [4] and [5] propose layered coding/mdc schemes with a tit-for-tat type strategy. The schemes use video quality as an incentive for peers to increase their upload rates. In [], the authors design an unstructured protocol that can reduce the end-to-end streaming delay and improve delivered content quality. Specifically, they combine a push-pull scheme and a scorebased scheme as an incentive method. In [23], the authors address two main problems in tree-based systems and propose an unstructured swarm overlay system. A credit-based incentive scheme is adopted in order to fully utilize upload bandwidth. In [2] the authors study the effects of a local pairwise incentive mechanism and focus on resource availability and the average quality of paths. The work in [2] demonstrates that a tit-for-tat scheme may not work