A Bandwidth-Aware Scheduling Strategy for P2P-TV Systems∗

Ana Paula Couto da Silva, Emilio Leonardi, Marco Mellia, Michela MeoPolitecnico di Torino

Dipartimento di ElettronicaCorso Duca degli Abruzzi, 24 - 10129 - Turin, Italy

anapaula@tlc.polito.it, {emilio.leornadi,mellia,michela.meo}@polito.it

Abstract

P2P-TV systems distribute live streaming contents by or-ganizing the information flow in small chunks that are ex-changed among peers. Different strategies can be imple-mented at the peers to select the chunk to distribute and thedestination neighboring peer. Recent work showed that agood strategy consists in selecting the latest received chunkand a random neighboring peer (latest useful chunk, ran-dom peer). In this paper, leveraging on the idea that it isconvenient to favor those peers that can contribute the mostto the chunk distribution, we propose to select the destina-tion peer with a probability proportional to the peer uploadbandwidth. We show that the proposed scheme has a limitedsensitivity to cheating peers that maliciously declare higherbandwidth than they actually have.

Considering the overlay topology, we evaluate both sys-tems in which nodes have fixed degree and systems whoseoverlay setup takes into account the actual peer bandwidthby assigning more neighbors to peer with higher bandwidth.

We evaluate the performance in terms of delay per-centiles and loss probability and evaluate the achieved im-provements. Simulation results considering scenarios withup to 10,000 peers shows that the proposed schemes signif-icantly outperform the traditional ones, so that the chunkdistribution delay drops to less than 2s from about 12s.

1. Introduction and Related Works

Peer-to-peer represents a viable and effective approachfor the large scale distribution of video contents over theInternet.

Several P2P video streaming systems, P2P-TV for short,such as PP-Stream [1], PPLive [2], SOPCast [3] andTVants [4], just to mention the most popular ones, offering

chunks is then regulated by the sender, as a function of itsown upload capacity.

While several studies have analyzed the performance ofpull-based systems, only very few works have recently ex-plored the performance of push-based mechanisms.

In [11, 12, 13], an analysis of the performance of push-based mechanisms have been carried out. Three differentmechanisms considering (Chunk selection, Peer selection)have been proposed and analyzed: (random useful chunk,most deprived peer); (latest blind chunk, random peer) and(latest useful chunk, random peer). In particular in [13],under some assumptions, the asymptotic optimality (opti-mality in order sense when the number of users n → ∞) ofthe last policy has been proved both in terms of delay andthroughput. Although results [11, 12, 13] make an impor-tant step in the direction of understanding the fundamentallimiting performance of push-based P2P-TV systems, theirvalue is mainly theoretical due to their asymptotic nature.Despite its asymptotic optimality, (latest useful chunk, ran-dom peer) could potentially result largely suboptimal in re-alistic scenarios. In particular, notice that no knowledge ofthe neighbors’ upload bandwidth is exploited. In this paperwe show how significant performance improvements can beachieved by intelligently exploiting this information duringthe peer selection. In addition, we also investigate how theinformation about peers’ bandwidth can be exploited duringthe overlay topology setup. Experimental results obtainedby considering overlay with up to 10, 000 peers show thatthe proposed approach leads to improvements up to 80%considering both chunk delivering delay and loss probabil-ity.

2 System

In this paper we consider a “live” mesh-based P2P-TVsystem in which a single source is responsible to encodeand seed the content. Peers in the system adopt a swarm-like mechanism to distribute the chunks, using a push-basedprotocol. The information to be transmitted is organizedinto small chunks each of fixed size L. The system is com-posed of one source and a set of peers N , with cardinality|N |: the source generates chunks at rate λ and sends themto its neighbors; the chunk diffusion in the network is thenaccomplished by the peers themselves.

We are interested to the effect of the chunk and peer se-lection policy, so that the effect of peer churning (i.e., |N |remains constant during the content diffusion) can be ne-glected since peer lifetime is much larger than the chunkdistribution time. Let L be the set of links that connect thepeers and Np ⊂ N the neighbor-list of a given peer p. Forany p ∈ N , we denote by u(p) the upload bandwidth ofp; u(p) is the maximum amount of bits per time unit that apeer can send. We assume that the amount of bits received

per time unit by peer p is unbounded; peers send one chunkat a time. Thus, the chunk transfer rates are limited onlyby the peers upload bandwidth. In this paper we explicitlyconsider the case of heterogeneous upload bandwidth.

As well-known, the overlay topology can be describedby a random graph G = (N ,L)[16]. We shall focus on theclass of Quasi Regular Random Graphs (QRRGs) in whichthe arcs are randomly placed. Each peer selects k0 randomneighbors. Links are bidirectional, so that if peer p is cho-sen by peer s as a neighbor, the neighbor-list of p also in-cludes s, and chunks are exchanged between s and p in bothdirections. Thus, the neighbor-list of p, Np, contains, on av-erage, < k >= 2k0 links. In Section 4, we will investigatedifferent ways of creating the neighbor-list.

The results derived in this paper are based on push-baseddiffusion schemes where the transmission of a chunk is ini-tiated by the sender. The scope of our study is limited toschemes in which the chunk to be delivered is chosen be-fore selecting the receiver peer.

Each peer p maintains a sender-collection-list Cp, thatcontains the chunks that p can transmit to its neighbors inNp; the list is a sliding window of size w that keeps thew-latest received chunks. The window mechanism “forces”the system to slide on time, avoiding that very old chunksare kept; the rationale being that old chunks are likelydropped by the application, due to tight delay constraintsof live streaming services. Each peer has also a received-collection-list C(r)

p that keeps the information of all chunksalready received.

Peer p can adopt different strategies to choose the chunkto transmit to its neighbors. The one we use here, thatwas proved to be one of the most effective, is called lat-est first (or, following [13], latest blind chunk). The senderp chooses the chunk with the highest index (which is usu-ally the latest received one) in its sender-collection-list Cp.Then, it chooses a destination peer in its neighborhood Np.Different policies are possible for the peer selection. Thesepolicies may use the information on whether the destina-tion peer has already received the chunk or not; the lattercases are referred to as blind strategies. Blind policies re-quire less signaling overhead, since the sender collection listCp must not be continuously updated to reflect the status ofneighbors’ missing chunks. The main focus of this paper isthe proposal of a new peer selection strategy. Our scheme,that is described in the next section, is not blind, and willalso make a smart use of the window mechanism.

3. Bandwidth-Aware Peer Selection

3.1. Description

The basic idea of Bandwidth-Aware (BA) is to select thepeer with a probability proportional to its upload bandwidth.

280

Intuitively, BA tends to first deliver the chunk to peers that,due to their high upload bandwidth, can contribute more tothe chunk diffusion.

According to the BA strategy, peers that have the largestupload bandwidth are favored: the probability πp(ni) that pchooses neighbor ni, ∀i ∈ Np, is proportional to the uploadbandwidth u(ni). Moreover, in order to avoid useless trans-missions of duplicate chunks, peer p uses the informationgiven by the received-collection-lists C

(r)ni , of all ni. As-

sume that the latest chunk in the list of p is j; p choosesneighbor ni in the set of its neighbors that do not have j,namely N

(j)p ⊂ Np:

N (j)p = {d|(d ∈ Np) ∧ (j 6∈ C

(r)d )}.

Then, the probability that p chooses ni to deliver j is:

πp(ni) =u(ni)

|N(j)p |

.

3.2. Simulation Results

3.2.1 Implementation assumptions

First, it is worth describing some key issues related to theimplementation of the BA strategy. First, we consider onlythe chunk transmissions, assuming that peers have a per-fect knowledge of the lists C

(r)p of their neighbors. This is

achieved by signaling messages that are continuously ex-changed among neighbors. A discussion on the requiredsignaling bandwidth will be presented later. Second, thechunk diffusion is no preemptive. If a peer p receives achunk with higher index that the one that it is sending toa neighbor ni, the new chunk is scheduled to be deliveredonly after finishing the current upload. Third, the cost ofdelivering any chunk is given by only the transmission time

L/u(p) in each link. At last, the window mechanism al-ways discards the chunk with the lowest index (among thew− latest chunks).

3.2.2 Simulation setting

An event-driven simulator was developed to evaluate theperformance of the proposed scheduling policy. A simula-tion is organized in two phases. First, a random topology isgenerated according to the desired graph specification andsystem parameters. During the second phase, the chunk dis-tribution dynamics are simulated until all nodes have com-pleted the content download.

Chunks are generated periodically by the source at a rateof λ = 1chunk/s, chunk size is constant and equal to 0.3Mb (L = 37kB), the source upload bandwidth is 1Mbps.All peers have infinite download and finite upload band-width, i.e., the bottleneck is the uplink access bandwidth.Based on their upload bandwidth, peers are partitioned intothree classes: peers in class P1 have upload bandwidthuniformly extracted in [0.18, 0.22]Mbps, peers in P2 have[0.3, 0.4]Mbps and peers in P3 have [3, 4]Mbps. These ratesare set in accordance with several measurements performedusing the PPLive, one of the most popular P2P-TV system[14].

The main performance indices we consider are

• Delays. Chunk delay distribution, i.e., the time sincethe chunk is generated at the source up to when it is re-ceived at the peers, is derived at each peer; mean valuesand percentiles of these distributions are then consid-ered. In particular, since chunks received with largedelays are equivalent to losses and losses may have astrong impact on video quality, much attention is de-voted to the distribution of the 99−th delay percentilesover all peers.

• Losses. For each peer, the number of lost chunks (i.e.,chunks that are never received) is evaluated. Again, thedistribution and mean value of losses over all peers areconsidered.

• Improvement of scheme A over scheme B, consid-ering a given performance index, is defined in the fol-lowing way: let X and Y be the measured index forscheme A and B, respectively; the improvement I isgiven by I = |Y − X |/Y .

3.2.3 Reference scenario

We start by considering a reference scenario that consistsof a QRRG with 1,000 peers (including the source) and anaverage node degree < k >= 8 (k0 = 4). 270 peers are inclass P1; 660 in P2 and 69 in P3.

281

The scenario is simulated considering 25 different ran-domly chosen QRRGs. For each of them, simulation resultsare obtained by averaging over 50 independent simulationruns. The video content consists of 200 chunks. Longervideo has been simulated, leading to the same conclusions.We prefer to show results obtained considering 200 chunksso that the assumption of no peer churning can be realistic.At last, the peer window size is equal to 5.

3.2.4 BA Performance

In this section we compare the performance of the BAscheduling strategy against the Random strategy.

For comparison purposes, we select two overlays out of25, namely overlays A and B which respectively reachedthe worst and the best improvements, considering the meanvalue of the 99−th delay percentile distribution.

Fig. 1 shows the cumulative distribution function overall peers of the 99−th delay percentile for overlays A andB under the two considered scheduling schemes. The sys-tem enjoys significant performance gain by applying a peerselection that takes into account the knowledge of neigh-bors’ upload bandwidth. Consider overlay B (best improve-ment). The dramatic delay improvement (up to 50%) canbe explained based on how the neighbor-lists are assignedto peers. From the analysis of the graph structure, it re-sults that peers with the largest upload rate are either di-rectly connected to the source or placed a few hops apartof it. Just for a better picture, the first jump of the curverepresents the delay of roughly 28 peers that are connectedto the source by paths with 1, 2 or 3 hops of P3 peers. So,the chunks can be diffused among them in a delay less than2s. This peer configuration leads to the phenomenon of avirtual clusterization: chunks are more likely to be first dif-fused among the fastest peers that create a sort of fast back-bone. These peers then effectively distribute the chunks tothe slowest peers. BA policy then maximizes the utilizationof P3 peers’ upload capacity compared to the Random Se-lection policy.(This behavior gives us a clue about the per-formance improvement of establishing a real clusterization,during the overlay setup; we have preliminary simulationresults that encourage further studies on this topic.) On thecontrary, in overlay A, no P3 peer is connected directly tothe source, so that higher delay is suffered. Also in this case,BA policy outperforms Random Selection policy (18% ofimprovements).

We now examine more closely the peer behavior underthe BA policy. Let NS be the set of peers that are neighborsof the source S. Consider a peer j ∈ P3 and j ∈ NS . Fig.2compares the delay of each chunk delivered to j under theRandom and BA scheduling policies. As expected, since BAfavors P3 peers with respect to other peer classes, the chunkdelay of j is smaller in BA than in the Random case. Small

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14

Dist

ribut

ion

Delay (99th Percentile)[s]

BA Selection Overlay A

BA Selection Overlay B

Random Selection Overlay A

Random Selection Overlay B

Figure 1. Distribution of the 99-th Delay Per-centile for overlays A (worst enhancement) andB (best enhancement).

variations of the delay are given by the presence of anotherP3 peer into NS and the rare cases in which peers withsmaller upload rates are chosen first. The kind of periodicalpattern is due to the limited source upload bandwidth thatallows for two or three chunks to be uploaded during thechunk intergeneration time Ts = 1/λ, this translates intoalternating large or small delays in starting transmitting thefollowing chunk. Under the Random selection policy, thehighest values of delay occur when the scheduling mech-anism is, by chance, unfavorable and some additional de-lay is introduced by the latest chunk selection policy. Slowpeers in NS , not shown here for the sake of brevity, perceivelarger delays under the BA than in the Random case. To givethe intuition of the better resource utilization that BA policyachieves, the total number of chunks uploaded by peer j is66% larger than considering the Random policy.

Let us now consider the total number of lost chunks, re-ported in Fig. 3. Under the BA policy, losses drasticallydecrease. Indeed, by better exploring the system resources,the BA guarantees a faster diffusion of chunks that dimin-ishes the possibility of discarding chunks. The number ofpeers with no losses at all increases by a factor 2 in overlayA and by a factor of 3 in overlay B. Interestingly, in over-lay A, the peer that undergoes the largest number of lossesis the same for both scheduling policies, and the number oflosses itself is about the same (around 85): this means thatmain responsible for this bad performance is a specific veryunlucky position of the peer in the topology. For overlay B,the BA makes the maximum number of losses drop by 47%.

At last, we present the performance improvementreached by using the BA policy, considering all the 25 sim-ulated overlays. Figs. 4 and 5 show the improvement on themean delay and losses, respectively, sorted in increasing or-

282

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 20 40 60 80 100 120 140 160

Dela

y [s

]

Chunk Identifier

Class 3 Peer - BA Selection

Class 3 Peer - RandomSelection

Figure 2. Chunk delays for a P3 peer con-nected to the source of the P2P system.

1

10

100

20 30 40 50 60 70 80 90 100

Tota

l Num

ber o

f Los

t Chu

nk

Peers(%)

Random Selection Overlay A

Random Selection Overlay B

BA Selection Overlay A

BA Selection Overlay B

Figure 3. Log scale plot of the total numberof lost chunks seen by the peers.

der for easy of visualization. The BA policy consistentlyreduced the average delay and losses, achieving improve-ments up to 40%. It is worth noticing that the enhancementis not completely correlated. A particular overlay that hasthe best delay improvement not necessarily has the smallestnumber of losses also.

3.2.5 Impact of graph degree

To gauge the impact of the graph degree in the BA policy,Figs. 6 and 7 report the improvements in terms of mean de-lay and losses when the average node degree < k > changesfrom 8 to 20 (k0 = 10). It is not surprising that increasingthe degree, delay and losses decrease. The high connectiv-ity makes P3 peers exploit at best their upload capacity. Onthe contrary, low values of < k > limit the upload band-

15%

20%

25%

30%

35%

40%

0 5 10 15 20 25

Mea

n De

lay

Overlay

Figure 4. Mean delay improvement of the BApolicy over the Random Selection policy foreach overlay.

width utilization. However, an important cost of increasingconnectivity is related to signaling traffic, ignored in previ-ous presented simulation results, as well as in the simulationresults reported in [13].

Peers have to exchange with neighbors several controlmessages to update the buffer map of the chunk collectionsowned by the peers[15], to propagate information abouttheir neighborhood and its possible changes due to churn-ing, or any other possible network information. Signalingtraffic is roughly proportional to node degree. Being it notmarginal, it should be accounted for as a limitation to theconnectivity increase.

For a first estimation of the possible signaling trafficoverhead, we refer to recent measurements performed overthe PPLive system that show that the mean signaling trafficexchanged between any two peers is approximately equal to5Kbps [14]. Fig. 8 reports the total rate needed at peers forthe maintenance of overlay A. In case of < k >= 20 half ofthe bandwidth of peers P1 must be devoted to signaling.

3.2.6 Impact of window size

In this section we discuss the impact of window size on theBA policy. Let us consider that each peer has a windowsize w = 10 (it was w = 5 in previous results). We ex-pect that the window size have little impact on delay but itcan reduce the occurrence of losses. Fig. 9 reports the re-sults. Larger window sizes give higher chances to chunkto be delivered, e.g., improvements by factors of 1.2 and 2considering topologies A and B respectively.

283

0

5%

10%

15%

20%

25%

30%

35%

40%

45%

0 5 10 15 20 25

Mea

n Ch

unk

Loss

es

Overlay

Figure 5. Chunk loss improvement of the BApolicy over the Random Selection policy foreach overlay.

3.2.7 Impact of the presence of malicious peers

The BA policy requires each peer p to tell each neighbor itsupload rate u(p). This mechanism poses a potential issue oftrust among peers. We thus study the presence of malicious(or untrusted) peers, and evaluate the impact of these peerson the BA performance.

We suppose that P1 peers may be malicious and prop-agate false values of u(p), pretending that it is the same asthe one of P3 peers. We consider cases in which the amountof malicious peers varies among 10%, 50% and 100% of P1

peers. While these rates are very high and a little unrealis-tic, they allow us to stress the scheduling strategy and showits robustness in extreme scenarios. Figs. 10 and 11 re-port the results, considering the previous overlays A and B.As expected, the presence of malicious peers on the overlaydegrades the BA performance. Observe the case with 100%of malicious P1 peers: the BA performance almost turns tothe Random peer selection one; indeed, the BA randomlychooses between peers with the same declared bandwidth.The remaining small improvement is given by the presenceof P2 peers. Similar conclusions are drown from Fig. 11.

Let us now examine more closely the behavior of a P1

peer, using the overlay B and 50% of P1 cheating peer sce-nario. Let us first consider a malicious peer p that is neigh-bor of the source. Fig. 12 shows the impact of cheatingon the delay of p and on the delay of a honest peer thatbelongs to P3 and to NS . Curves A and D show the BAperformance for a system with no malicious peers; as ex-pected, peer p perceives much larger delay than the consid-ered P3 peer. In curves B and C, that refer to the scenariowith malicious peers, we can see that, by cheating, peer pdrops its own delay and increases the delay of the trusted

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

55%

0 5 10 15 20 25Overlay

Mea

n De

lay

Figure 6. Mean delay improvement in theBA policy when the average node degree in-creases from 8 to 20.

peer. The delay increase for peers that could effectively de-liver the chunk to other peers translates into larger overallsystem performance degradation. The propagation of theperformance degradation can be seen on Fig. 13, in whichwe consider a malicious peer far away from the source; thesystem performance degradation is such that this cheatingpeer perceives worse performance than in the case with nocheating peers at all. Clearly, a similar but less significantperformance degradation is observable also in the case with10% class P1 cheating peers.

Finally, the presented results are representative of BA ro-bustness also in case of erroneous declaration of bandwidth.Assume that, in order to propagate information about its up-load bandwidth, a peer performs some measurement of thelink capacity. Some peers may, not intentionally, return in-accurate values. The scenario would be similar to the oneanalyzed above.

4. Impact of Overlay Topology

4.1. Description

Considering the overlay structure, any peer p selects atrandom k0 neighbors with constant k0 regardless of u(p).It is not surprising that the system may waste valuable re-sources (upload bandwidth) during the chunk diffusion pro-cess if k0 is small.

Table 1 gives some numerical results to corroborate thisstatement by reporting the upload bandwidth utilization forsome P3 peers; results were collected from our previoussimulations in overlay B. A natural and straightforwardmodification in the overlay setup is to assign to any peer p aneighborhood that takes into account the actual u(p). Once

284

0

10%

20%

30%

40%

50%

60%

70%

0 5 10 15 20 25

Mea

n Ch

unk

Loss

es

Overlay

Figure 7. Mean loss improvement in the BApolicy when the average node degree in-creases from 8 to 20.

more, it is important to emphasize the trade-off between theneighborhood cardinality and the signaling overhead gener-ated by exchanging information among peers.

Table 1. Upload bandwidth utilization, for asubset of P3 peers.Peer Random Peer BA (k0 = 4) BA (k0 = 10)

1 6.8% 9.7% 49.7%2 6.0% 10% 76.3%3 7.32% 14% 47.5%4 10.4% 24.2% 21.3%5 16.7% 28.3% 27.8%

We propose a new scheme to build the overlay in a moreefficient way which is called Variable Neighborhood (VN)overlay construction.

Denote by φp the neighborhood size of peer p. Let Tp

be the time p needs to deliver a chunk, Tp = L/u(p). Ts

is the time interval for generating chunks at the source. Inorder to select the neighborhood size of p , we establish thefollowing constraint:

φpTp ≤ cTs; ∀p ∈ N ,

with c an constant.In words, we are coupling the time to deliver a chunk

with the chunk generation time interval. The value of φp

should be large enough to make the overlay structure havelarge degree and to allow that the upload bandwidth of p isalmost always used. If c = 1, the bandwidth of p is poten-tially fully used to deliver the chunks to all the neighbors;

20

40

60

80

100

120

140

160

0 100 200 300 400 500 600 700 800 900 1000

Kbps

Peer Identifier

Figure 8. Signaling overhead, for each p ∈ Nwhen average node degree is equal to 20 and8, respectively.

1

10

100

70 75 80 85 90 95 100

Peers (%)

Window 5 Overlay A

Window 10 Overlay A

Window 10 Overlay B

Window 5 Overlay B

Tota

l Nu

mbe

r of L

ost C

hunk

Figure 9. Log scale plot of the total numberof lost chunks seen by the peers.

the total needed time is φpTp. However, since often someneighbors already have received the chunk through an alter-native path, a setting c > 1 is preferable. We choose c = 2,which guarantees that the bandwidth of p is always used,even if only half of its neighbors do not have the chunk.

4.2. Simulation Results

4.2.1 Reference scenario

In what follows, we consider a reference scenario that con-sists of a QRRG graph with 10,000 peers. The peers aredivided into classes with the same partition as before. Wealso keep the same values for the upload bandwidths.

We analyze the performance of the proposed VN overlayapproach in a range of 20 randomly chosen QRRGs graphs.

285

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14

Dist

ribut

ion

Delay (99th Percentile)

Random Peer Selection

Without Malicious Peers

10% of Malicious Peers

50% of Malicious Peers 100% of Malicious

Peers

Figure 10. The impact of the presence of ma-licious peers in class P1 for the overlay A.

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12

Dist

ribut

ion

Delay (99th Percentile)[s]

100% of Malicious Peers

Random Peer Selection

Without Malicious Peers

10% of Malicious Peers

50% of Malicious Peers

Figure 11. The impact of the presence of ma-licious peers in class P1 for the overlay B.

For each of them, simulation results are obtained by averag-ing over 15 independent simulation runs. The video contentconsists of 500 chunks. The peer widow size is equal to 5.

4.2.2 VN Overlay Performance

Fig. 14 reports the cumulative distribution function of the99−th delay percentile for overlays A and B (as usual, se-lected with the worst and the best enhancements), respec-tively. Random Selection policy is used. As expected,VN overlay provides a very significant delay improvement.Note that, as for the previously noted in Fig 1, the perfor-mance of the chunk diffusion process is closely related withthe overlay construction.

Let us briefly introduce the results regarding the set ofoverlays. Considering the mean delay, the VN topologyguarantees improvements between 35% and 65%. The per-

0

0.5

1

1.5

2

2.5

3

3.5

4

0 20 40 60 80 100

Mov

ing

Aver

age

Dela

y [s

](ove

r 10

chun

ks)

)

A: Peer Class 3 (without Malicious Peers)

B: Peer Class 3 (with 50% Malicious Peers)

C: Peer class 1 is Malicious

D: Peer class 1 is not Malicious

10-Chunk Identifier

Figure 12. Impact on the chunk delay when50% of peers are malicious (overlay B); con-sidering one P1 peer and one P3 peer that areneighbors of the source.

formance enhancement also extends to the mean losses,where the VN topology improves performance in a rangefrom 25% to 60%.

Fig. 15 shows that coupling the Bandwidth-Aware selec-tion policy with the Variable Neighborhood topology largeimprovements can be achieved. Indeed, the BA policy re-duces the delay of about 50% with respect to the RandomSelection policy also in case a VN topology is considered.The total improvement reached by adopting BA and VNmechanisms is 85% (i.e., delay drops to less than 2s fromabout 12s)!

In what follows, we show the signaling overhead by ap-plying the VN overlay approach. Coupling the upload band-width to the neighborhood size permits at the same timeto limit the impact of signaling on nodes with limited up-load bandwidth and to fully exploit the upload bandwidthof nodes with larger bandwidth. Fig. 16 shows the signal-ing overhead considering a subset of 2000 peers. It clearlyshows that peers with large bandwidth (all of them have peeridentifier larger than 9000) must manage a large signalingoverhead, while slow peers do not have to deal with (use-less) large amount of signaling.

5. Conclusions

In this paper, we have explicitly considered heteroge-neous scenarios in which peers with different characteristicscoexist. By leveraging on this heterogeneity, performanceof “live” P2P-TV systems can be significantly improved byintelligently exploiting the information on the peers’ uploadbandwidth. This information can be capitalized both at levelof overlay topology setup and chunk distribution.

286

5

6

7

8

9

10

11

0 20 40 60 80 100 120 140 160 180 200

Chunk Identifier

Dela

y [s

]

Peer class 1 is Malicious

Without Malicious Peers

Figure 13. Impact on the chunk delay when50% of peers are malicious (overlay B); con-sidering one P1 peer apart of the source.

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14 16 18 20

Dist

ribut

ion

Delay (99th Percentile) [s]

VNOverlay B

FNOverlay B

VNOverlay A FN

Overlay A

Figure 14. Distribution of the 99−th delaypercentile for overlays A (worst enhancement)and B (best enhancement). Comparison ofFixed Neighborhood and Variable Neighbor-hood topologies. Random Selection policycase.

A new scheduling algorithm along with a scheme forthe overlay topology setup have been proposed. Simula-tion results in scenarios with up to 10,000 peers have shownthat the proposed schemes significantly outperform the tra-ditional ones, so that the chunk distribution delay drops toless than 2s from about 12s.

References

[1] PPStream, http://www.PPStream.com.

[2] PPLive, http://www.pplive.com.

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14

Dist

ribut

ion

Delay (99th Percentile) [s]

RandomOverlay A

BA Overlay A

RandomOverlay B

BA Overlay B

Figure 15. Distribution of the 99−th delay per-centile for overlays A (worst enhancement) andB (best enhancement), using Variable Neigh-borhood topology and BA policy case.

0

20

40

60

80

100

120

140

160

180

8000 8500 9000 9500 10000

Kbps

Peer Identifier

Figure 16. Signaling overhead for the VN over-lay B.

[3] SOPCast, http://www.sopcast.com.

[4] TVAnts, http://www.tvants.com.

[5] Joost, http://www.joost.com.

[6] Babelgum, http://www.babelgum.com.

[7] Zattoo, http://www.zattoo.com.

[8] Tvunetworks, http://www.tvunetworks.com

[9] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, A.Rowstron, and A. Singh, “Splitstream: High-bandwidthmulticast in cooperative environments”. Symposium onOperating System principles (SOSP 2003), Bolton Land-ing, NY, October 2003.

287

[10] N. Magharei, R. Rejaie, and Y. Guo. “ Mesh ormultiple-tree: A comparative study of live p2p streamingapproaches” INFOCOM, 2007, Anchorage, AK, May2007.

[11] L. Massoulie, A. Twigg, C. Gkantsidis, and P. Ro-driguez. “Randomized decentralized broadcasting algo-rithms” INFOCOM, 2007, Anchorage, AK, May 2007.

[12] S. Sanghavi, B. Hajek, and L. Massoulie, “Gossipingwith multiple messages”, INFOCOM, 2007, Anchorage,AK, May 2007.

[13] T. Bonald, L. Massouli, F. Mathieu, D. Perino, A,Twigg, “Epidemic Live Streaming: Optimal Perfor-mance Trade-Offs”, Sigmetrics 2008, Annapolis, ML,June 2008

[14] D. Ciullo, E. Leonardi, M. Mellia, M. Meo “Un-derstanding P2P-TV systems through on field measure-ments”. Technical Report, No.120208Polito, 12 Febru-ary 2008

[15] X. Hei, Y. Liu, K.W. Ross, “Inferring Network-WideQuality in P2P Live Streaming Systems,” IEEE JSAC,special issue on P2P Streaming, December 2007.

[16] Bela Bollobas. ”Random Graphs”, Cambridge Univer-sity Press, 2001.

288