1Neighborhood Filtering Strategiesfor Overlay Construction in P2P-TV Systems:

Design and Experimental ComparisonStefano Traverso Member, IEEE, Luca Abeni Member, IEEE, Robert Birke Member, IEEE,

Csaba Kiraly Member, IEEE, Emilio Leonardi Senior Member, IEEE,Renato Lo Cigno Senior Member, IEEE, Marco Mellia Senior Member, IEEE

AbstractPeer-to-Peer live-streaming (P2P-TV) systems goal isdisseminating real time video content using Peer-to-Peer technol-ogy. Their performance is driven by the overlay topology, i.e., thevirtual topology that peers use to exchange video chunks. Severalproposals have been made in the past to optimize it, yet fewexperimental studies have corroborated results. The aim of thispaper is to provide a comprehensive experimental comparisonbased on PeerStreamer, in order to benchmark different strate-gies for the construction and maintenance of the overlay topologyin P2P-TV systems. We present only experimental results inwhich fully-distributed strategies are evaluated in both controlledexperiments, and the Internet, using thousands of peers.

Results confirm that the topological properties of the overlayhave a deep impact on both user quality of experience andnetwork load. Strategies based solely on random peer selectionare greatly outperformed by smart, yet simple and actually im-plementable strategies. The most performing strategy we deviseguarantees to deliver almost all chunks to all peers with a play-out delay as low as 6 seconds even when system load approaches1, and in almost adversarial network scenarios. PeerStreameris Open Source to make results reproducible and allow furtherresearch by the community.

I. INTRODUCTION

Peer-to-Peer live streaming (P2P-TV) applications haveemerged as valid alternative to offer cheap live video streamingover the Internet. Real-time TV programs are delivered tomillions of users thanks to the high scalability and low costsof the P2P paradigm. Yet, exploiting the available resourcesat peers is a critical aspect, and calls for a very careful designand engineering of the application.

Similarly to file sharing P2P systems, in P2P-TV systemsthe video content is sliced in pieces called chunks, whichare distributed onto an overlay topology (typically a genericmesh). But, contrary to file sharing P2P systems, chunks aregenerated in real time, sequentially and (in general) period-ically. They must also be received by the peers within a

Stefano Traverso, Emilio Leonardi and Marco Mellia are with the Depart-ment of Electronic and Telecommunications (DET), Politecnico di Torino,Italy; e-mail: {lastname}@tlc.polito.it

Luca Abeni and Renato Lo Cigno are with the Department of InformationEngineering and Computer Science (DISI), Univesity of Trento, Italy; e-mail{luca.abeni,renato.locigno}@unitn.it

Csaba Kiraly is with Fondazione Bruno Kessler (FBK), Trento, Italy; e-mail: csaba.kiraly@fbk.eu. Csaba Kiraly was with DISI, University of Trentoat the time of this work.

Robert Birke is with IBM Research Zurich Lab., Switzerland; e-mail:bir@zurich.ibm.com

deadline to enable real time playback. Chunk timely deliveryis thus the key aspect of P2P-TV systems. This makes thedesigns of P2P-TV systems and P2P file sharing applicationsdeeply different.

Building a mesh-based P2P-TV system, there are two keycomponents driving performance: i) the algorithms adoptedto build and maintain the overlay topology [1], [2], [3], [4],[5], [6], and ii) the algorithms employed to trade chunks [7],[8], [9]. We explicitly focus on the first problem, decouplingits performance from the choice of chunk trading algorithm.Most of the previous works have mainly a theoretical flavor,where performance analysis has been carried out in ratheridealized scenarios, by means of simulations or analyticalmodels [3], [4], [5], [6]. Few works undergo implementationand present actual experiments, and even those are usuallylimited to few tens of peers [10], [11]. See also Sect. VIII fora more complete presentation of the related works.

The goal of this paper is to fill this gap: by using the Peer-Streamer P2P-TV application, we present a comprehensive andpurely experimental benchmarking of different strategies forthe construction and the maintenance of the overlay topol-ogy for P2P-TV systems. We thoroughly evaluate differentpolicies, assessing the impact of signaling, measurements,implementation issues, etc. Both synthetic scenarios and Plan-etLab experiments are proposed. The first allows assessing theproperties of the different algorithms in increasingly adver-sarial scenarios. In such scenarios we have the full controlof all network parameters, thus they form a scientific andreproducible benchmarking set. The second permits us tofurther check the validity of the previous conclusions withinthe Internet, where unpredictable uncertainty has to be faced.

The system design we present is fully distributed. No cen-tralized tracker or oracle is assumed, and peers collaborateto find the best configuration to use. Topology constructionalgorithms are based on selection and replacement criteriaaccording to which each peer chooses the peers it would liketo download chunks from. This turns out to be very simpleand easy to implement. A blacklist-like hysteresis preventspeers to select neighbours previously discarded due to poorperformance. Overall, we explore 12 different combinationsof criteria (24 with blacklisting), based on metrics such asRound Trip Time (RTT), upload capacity, number of receivedchunks, etc. Their performance is thoroughly benchmarked byrunning fairly large scale experiments (thousands of peers)

2under different system and network conditions. Measurementsare performed considering first traditional Quality of Ser-vice (QoS) metrics (e.g., frame loss, delivery delay, etc.) toprune those combinations that perform poorly. Afterwards, weconsider the Quality of Experience (QoE), measured by theStructural Similarity Index (SSIM) [12], to include all elementsin the P2P-TV video distribution chain. The results presentedhave been collected in experiments that amount to more than1500 hours of tests.

While the intuition and ideas of our algorithms are simpleand well understood in the community, their actual imple-mentation and experimental validation constitute a major steptoward the engineering of large scale P2P-TV live streamingsystems. As such, the guidelines and results presented in thispaper may be useful for researchers, designers and developersinterested in P2P-TV application. Our tests show that evensimple improvements to a random-based policy for the over-lay construction may lead to significant QoE enhancement.Finally, we highlight that the software used in this paper isreleased as Open Source and includes all the componentsnecessary to build a fully functional P2P-TV system includingvideo transcoding at the source and play-out at clients.

A preliminary version of this paper was presented in [13].In this version we include an additional scenario devised tobring the system to its limits, and we extend the experimentsusing PlanetLab. Finally, we introduce some theoretical con-siderations to support algorithm design choices.

II. PEERSTREAMER DESCRIPTION

Empowering this work is PeerStreamer1, an Open SourceP2P-TV system that stems from the developments and researchof the NAPA-WINE project [14], whose overall architectureand vision are described in [15]. PeerStreamer leverages GRA-PES [16], a set of C libraries implementing blocks that enablebuilding P2P-TV applications with almost arbitrary charac-teristics, thus allowing experimental comparison of differentchoices. Fig. 1 describes the logic and modular organizationof PeerStreamer. The overlay management, the focus of thispaper, is detailed in Sect. II-B, while in the following wesketch the high level organization of the other applicationcomponents.

A. PeerStreamer Architecture

PeerStreamer is based on chunk diffusion. Each peer offersa selection of the chunks it possesses to some peers in itsneighborhood. The receiving peer acknowledge the chunks itis interested in, thus avoiding multiple transmissions of thesame chunk to the same peer. The negotiation and chunktransmission phase is based on signaling exchanges withOffer and Select messages. For chunk scheduling, Offersare sent to neighbors in round-robin. They contain the buffer-map of the most recent chunks the sender possesses at thattime. After receiving an Offer, a peer selects one chunk basedon a latest useful policy, and sends back a Select message.This has been proven optimal for streaming systems with

1Available at http://www.peerstreamer.org

FFMPEGor equiv.

FFMPEGor equiv. CHUNKIZER

CHUNK BUFFER

SCHEDULING ANDOFFERING CHUNKS

MAINLOOP

PEERSAMPLER

MONITORINGAND MEASURES

DECHUNKIZER

MESSAGING, TCP, UDP, NAT TRAVERSAL, ...

Content Playout or generation

Chunk Trading Protocol

Overlay Management

NEIGHBORHOODMANAGER

Figure 1. PeerStreamer peer architecture.

centralized and distributed scheduling associated to specificpeer choices in [7], [9]. The number of offers per second a peersends plays a key role in performance. Intuitively, it shouldbe large enough to fully exploit the peer upload capacity,but it must not be too large to cause the accumulation ofchunks to be transmitted adding queuing delay prior to chunktransmissions. We adopt Hose Rate Control (HRC) proposedin [17] to automatically adapt the number of offers to peerupload capacity and system demand. Simpler trading schemesare less performing and can hide the impact of the overlay onthe overall system performance.

The source is a standard peer, but it does not participatein the Offer/Select protocol. It simply injects copies (5 in ourexperiments) of the newly generated chunk into the overlay.It implements a chunkiser to process the media stream (e.g.,a live stream coming from a DVB-T card, or from a web-cam). The chunking strategy used in PeerStreamer is chosento avoid mingling its effects with the topology-related ones:one-frame is encapsulated into one-chunk to avoid that amissing chunk would impair several frames due to, e.g.,missing frame headers. The chunkiser is implemented usingthe ffmpeg libraries2, so that several different codecs (e.g.,MPEG, theora, H.264, etc.) are supported. Receiving peers,instead, implement a de-chunkiser, which reads from the localchunk buffer and pushes the chunks in the correct sequenceto the play-out system.

The main loop (at the center of Fig. 1) implements theglobal application logic. It is responsible for the correct timingand execution of both semi-periodic tasks, e.g., sending newoffers, and asynchronous activities, e.g., the arrival of a chunkor signaling message from the messaging layer.

The PeerStreamer architecture is completed by the messag-ing and monitoring and measures modules. The messagingmodule is a network abstraction layer that masks the appli-cation from all details of the networking environment, e.g.,the presence of NAT, middle-boxes and other communicationdetails. It offers a connection-oriented service on top of UDP,with a lightweight retransmission mechanism that allows therecovery of lost packets with low retransmission delay.

The monitoring and measures module extracts network in-formation by running passive and/or active measurements [15].

2http://www.ffmpeg.org

3In this paper we rely on the measurements of i) end-to-endpath delay between peers (e.g., RTT), ii) packet loss rate, andiii) transmission rate of a peer.

B. Overlay Management

The approach for building the overlay topology in Peer-Streamer is fully distributed: each peer builds its own neigh-borhood following only local measures, rules and peer sam-pling. The overlay topology is represented by a directed graphin which the peer at the edge head receives chunks from thepeer at the edge tail, which is the one sending Offers. Eachpeer p handles thus an in-neighborhood NI(p) and an out-neighborhood NO(p). NI(p) collects all peers that can sendchunks to p (p in-neighbors); NO(p) collects all peers that canreceive chunks from p (p out-neighbors). Alternatively, NI(p)is the set of peers that Offer p new chunks; while p Offers itschunks to peers in NO(p). Distinguishing between NI(p) andNO(p) guarantees a larger flexibility in topology managementthan algorithms imposing the reciprocity between peers. Theoverlay topology TS is then obtained as union of all the edgesconnecting peers in NI(p) to p, i.e.:

TS =pSNI(p) {p} (1)

where S is the set of all the peers in the swarm and the symbol denotes the Cartesian product operator3.

Referring again to Fig. 1, the topology management is splitinto two separate functions. The peer sampler has the goal ofproviding p with a stochastically good sample of all the peersin S and their properties: PeerStreamer implements a variationof Newscast [18] for this function. The neighborhood managerinstead realizes the task of filtering the most appropriate peersfor interaction. Filtering is based on appropriate metrics andmeasures, and it is the main focus of this paper.

III. NEIGHBORHOOD AND TOPOLOGY CONSTRUCTION

In PeerStreamer every peer p selects other peers as in-neighbors and establishes a management connection withthem. Thus each peer p actively selects in-neighbors to possi-bly download chunks when building the set NI(p). Similarly,p passively accepts contacts from other peers that will form theset NO(p) of out-neighbors. There is no limitation to NO(p)4.

Every peer p manages a local blacklist of peers in which itcan put peers that were perceived as very poorly performing in-neighbors. Peers in the blacklist cannot be selected for inclu-sion inNI(p). Blacklisted peers are cleared after the expirationof a time-out (set to 50 s in the experiments). Blacklist is usedby peers just to avoid to select underperforming parents. Thus,even if blacklisted by some other peers, a peer is not preventedfrom receiving the stream, as it can always be in NO(p).

The size NI of NI(p) is equal for every peer p: its goal is toguarantee that p has enough in-neighbors to sustain the streamdownload with high probability in face of churn, randomness,

3Notice that since NO(p) are built passively, they do not contribute toconstruction of the swarm topology.

4In the actual implementation NO(p) is limited to 200 peers, but the limitis never reached.

network fluctuations, etc. The size NO(p) of NO(p) is insteada consequence of the filtering functions of the peers that selectp as in-neighbor. The goal is to let the dynamic filteringfunctions of peers q {S \ p} select NO(p) in such a waythat the swarm performance is maximized. For example, peerswith higher upload capacity should have larger number of out-neighbors than peers with little or no upload capacity [4].

The update of neighborhoods is periodic, maintaining thetopology dynamic and variable, so that churn impairment islimited, and the swarm can adapt to evolving networkingconditions. In particular, every Tup seconds each peer pindependently updates NI(p) by dropping part of the old in-neighbors while adding fresh in-neighbors. Two parametersare associated to this scheme: the update period Tup and thefraction Fup of peers in NI(p) that is replaced at every update.The add operation guarantees NI(p) has size NI (if at leastNI peers are known). Overall, the in-neighbor update rate canbe defined as

Rup =FupNITup

(2)

If not otherwise stated NI = 30, Tup = 10 s and Fup = 0.3.The latter two values result in a good compromise betweenadaptiveness and overhead. Their choice is robust: a sensitivityanalysis is presented in Sect VI-C.

A. Metrics Driving the Neighborhood Selection

At every update, NI(p) is the result of two separate filteringfunctions: one that selects the peers to drop, and another oneselecting in-neighbors to add. For these filtering functions weconsider both simple network attributes such as peer uploadbandwidth, path RTT or path packet loss rate, and someapplication layer metrics, such as the peer offer rate5 ornumber of received chunks from an in-neighbor.

Some metrics are static peer metrics: once estimated, theycan be broadcasted with gossiping messages and are knowna-priori. Other metrics instead are path attributes betweentwo peers and must be measured and can only be used asa-posteriori indicators of the quality of the considered in-neighbor as perceived by p.

Both add and drop filtering functions are probabilistic toavoid deadlocks and guarantee a sufficient degree of random-ness. Considering a metric, we assign a selection probabilitywq to every candidate q as

wq =mq

sNS(p)ms(3)

where mq is the metric of q and NS is either NI for drop, orthe set of candidate in-neighbors for add.

B. Add Filters

We consider the following four criteria to add new in-neighbors:RND: Neighbors are chosen uniformly at random: q,mq = 1;BW: Neighbors are weighted according to their upload band-width Cq: q,mq = Cq;

5HRC adapts the peer offer rate to peer upload capacity. It can thus be seenas an indirect measure of its available upload bandwidth.

4RTT: Neighbors are weighted according to the inverse of theRTT between p and q: q,mq = 1/RTTq(p); if RTTq(p) isstill unknown, RTTq(p) = 1 s6;OFF: Neighbors are weighted according to the rate they sendoffer messages Rq: q,mq = Rq; Rq are advertized by peers7.

C. Drop Filters

We evaluate three criteria to select neighbors to be dropped:RND: Neighbors are dropped randomly: q,mq = 1;RTT: Neighbors are dropped with a probability directly pro-portional to the RTT between p and q: q,mq = RTTq(p);RXC: Neighbors are dropped with a probability proportionalto the inverse of the rate at which it transferred chunksto p: q,mq = 1/RXCq(p); this metric assigns a qualityindex related to the in-neighbor ability to successfully transferchunks to p; RXCq(p) are evaluated on a window of 3 s.

D. Blacklisting Policies

Finally a peer in NI(p) is locally blacklisted if any one ofthe following criterion is met:CMR: the ratio of corrupted/late chunks among the last 100chunks received by p from q exceeds a threshold of 5%;PLOSS: the packet loss rate from q to p exceed a thresholdof 3%; measured over the last 300 packets received;RTT: RTTq(p) is greater than 1 s.

Combining add and drop criteria we define 12 differentoverlay construction and maintenance filters. In the following,we name them stating the ADD-DROP policies, e.g., BW-RTT for add BW and drop RTT. Sect. V reports results fordifferent resulting combinations. Blacklisting can be super-posed (or not) to all of them, and its impact will be studiedselectively. We tested also other metrics and combinations,whose results are less interesting and not reported here. RND-RND is used as a baseline benchmark, as it is a policy basedon pure random sampling of the swarm.

E. A Few Theoretical Considerations

Depending on the neighbor selection strategy adopted bypeers, the resulting overlay topology TS , as defined in (1), mayexhibit fairly different macroscopic properties, especially when|S| grows large. Some considerations based on elementarynotions on random graphs will help to better understand theeffect of different neighbors selection policies.

On the one hand, it would be highly desirable to obtain anoverlay topology TS with very good structural properties, suchas high node resilience, short diameter and large conductance.Observe, indeed, that the graph theoretical concept of node re-silience can be almost immediately re-interpreted as resilienceto peer churning, while conductance/diameter properties of thegraph have been recently shown to be tightly related with theminimum time needed to spread information over a graph withhomogeneous edge capacities [19].

6RTTq(p) are locally cached at p so that they may be available a priori.Active measurements could also be used to quickly estimate the RTT.

7Note that the number of offers is roughly proportional to the availableupload bandwidth of the peer [17].

On the other hand, just structural graph properties of TSmay not be sufficient to represent well how good the topologyis, since peers upload bandwidth may be highly heterogeneousand edge latencies (i.e., RTTs) may play an important role onperformance. Neighbor selection policies should favour localedges (i.e., edges between peers that are geographically and/ornetwork-wise close) reducing edge latencies (with the positiveside effect of localizing the traffic). Furthermore they shouldnot build topologies with a constant degree of connectivity,but privilege strategies that lead to high connectivity degreesfor high bandwidth peers to exploit their upload resources atthe best. As it will be evident in the following, to achieve highand reliable performance it is important to properly balancethe previous ingredients, aiming at obtaining a topology TSthat blends good global (topological) properties, with a biastoward the exploitation of local properties like vicinity andbandwidth availability.

The simplest possible selection strategy is RND-RND. It isknown to produce an overlay topology TS with good globalproperties, and for these reasons it is adopted by severalP2P systems [20]. Indeed the overlay topology resulting bythe adoption of RND-RND can be modeled as an n-regular(directed) random graph instance with n = NI . Such graphshave high resilience (whenever n is larger than few units),logarithmic diameter, and high conductance. The limit ofRND-RND consists in the fact that it completely ignores peerattributes (such as location and upload bandwidth).

Policies that select/drop neighbors according to the peer-to-peer distances (i.e., RTTs) better localize the neighborhoods.Of course the application can profit from neighborhoodslocalization since message latencies/chunk transfer times arepotentially reduced. However, a too strict localization ofneighborhoods can jeopardize the global properties of TS , withdetriment of the application performance as already observedin [5], [21], [22]. The danger of an excessive localization ofneighborhoods can be easily explained from a graph theoret-ical perspective; indeed geographical graphs (i.e., graphs inwhich edges are established only between nodes which areclose with respect to some parameter) exhibit poor diame-ter/conductance properties (the graph diameter, for example,scales as the square root of number of nodes in bi-dimensionalgeographical graphs). Furthermore, when nodes are non ho-mogeneously distributed over the domain, the topology maybecome disconnected (conductance equal to zero) even if theaverage connectivity is high. Thus, localization must be pushedonly up to a given point, guaranteeing the presence of anon-marginal fraction of chords (i.e., non local edges). Thepresence of a significant fraction of random chords guaranteesthe resulting overlay TS to exhibit small word properties,i.e., good diameter/conductance properties. At the same timethe massive presence of local edges potentially permits toreduce the negative effects of large latencies. Observe thatto guarantee a significant amount of chords our RTT basedselection/dropping filter are probabilistic.

The adoption of policies that select peers taking into accountdirect or indirect measurements of the peers upload bandwidth(such as BW or OFF) make the average out-degree propor-

5Table INUMBER OF PCS PER SUBNET.

Subnet 1 2 3 4Number of PCs 43 63 60 38

Table IIRTTS IN ms BETWEEN SUBNETS OF PEERS.

1 2 3 41 20 10% 80 10% 120 10% 160 10%2 80 10% 20 10% 140 10% 240 10%3 120 10% 170 10% 20 10% 200 10%4 160 10% 240 10% 200 10% 20 10%

tional to the peer upload bandwidth8. We observe that thesepolicies directly influence the conductance of the resulting TS ,as they increase average weight of edges. This is due to aglobal policy whose goal is building an n-regular directedgraph, so that the number of edges in the topology is roughlyconstant. Having more edges insisting on high bandwidth linksand less on low bandwidth ones increases the average weight.

It is harder, instead, to predict the effect on TS of theadoption of RXC dropping filters. In this case, we attemptto correlate neighbor filtering decisions to an estimate of thereal neighbors quality, with the goal of preserving the bestin-neighbors (peers that have shown to be helpful in retrievingchunks in the recent past) while discarding bad in-neighbors(peers that were scarcely helpful). It can be argued, however,that also in this case the outcome of the strategy is an increasedtopology conductance, as the actual or a-posteriori weightof edges is proportional to the amount of chunks correctlytransferred along it. Again we ensure that a significant amountof random edges are in TS by adopting probabilistic filteringto guarantee good global properties.

IV. TEST-BED CONFIGURATION

We need to benchmark the different algorithms in a knownand reproducible scenario. To achieve this goal, we runexperiments in a possibly complex, but fully controlled net-work to avoid fluctuations and randomness due to externalimpairments. The test-bed is built in laboratories available atPolitecnico di Torino, with 204 PCs divided in four differentsubnets. Table I shows the number of PCs in each subnet. Weused tc, the standard Linux Traffic Controller tool, togetherwith the netem option to enforce delay and packet droppingprobability when needed. Each peer selects an average delayE[RTT ] in the tuples detailed in Table II. Then, each packetwill be delayed according to a uniform distribution [E[RTT ]0.95;E[RTT ] 1.05]. The upload bandwidth is limited bythe application itself, exploiting the feature of a simple leakybucket (with a memory of 10 Mbytes) to limit the applicationdata rate to a given desired value. Peer upload capacities Cpare shown in Table III. Configurations in Tables II and III havebeen designed to resemble a world-wide geographic scenario,where peers are distributed over continents (clusters), and theyrely on different kinds of access technologies, i.e., ADSLor FTTH interfaces, that provide different up-link capacity.

8OFF can be however affected by other system parameters such as NI andby the system load conditions

Table IIICHARACTERISTICS OF PEER CLASSES.

Class Upload Bandwidth Percentage of Peers1 5 Mb/s 10% 10 %2 1.6 Mb/s 10% 35 %3 0.64 Mb/s 10% 35 %4 0.2 Mb/s, 10% 20 %

Those configurations are not meant to be representative ofany actual case, but rather they are instrumental to createbenchmarking scenarios with different properties. Each PCruns 5 independent instances of PeerStreamer simultaneously,thus, a swarm of 1020 peers is built in every experiment, ifnot otherwise stated. The source peer runs at an independentserver (not belonging to any of the subnets). It injects in theswarm 5 copies of each newly generated chunk, correspondingto roughly 6 Mbit/s.

The well known Pink of the Aerosmith video sequencehas been used as benchmark. The nominal sequence lengthcorresponds to 200s, with a time resolution equal to 25frame/s. The sequence is looped for a total stream durationof about 20min. After the initial 12min of experiment, eachpeer starts saving on local disk a 3min long video that we useto compute QoE metrics.

We selected the H.264/AVC codec to encode the videosequence. A hierarchical type-B frames prediction scheme hasbeen used, obtaining 4 different kinds of frames that, in orderof importance, are: IDR, P, B and b. The GOP structure isIDR8 {P,B,b,b}. The nominal video rate of the encoder rsis 1.2Mbit/s if not otherwise specified. This corresponds toa system load = 0.9 defined as = rs/E[Cp] whereE[Cp] = 1.32Mbit/s is the average upload bandwidth of peers.

The source node generates a new chunk regularly every40ms, i.e., every new frame. The chunk size is instead highlyvariable due to the encoded video characteristics. Each peerimplements a chunk buffer of 150 chunks. Given the one-frameone-chunk mapping, and 25 frame/s of the video, thiscorresponds to a buffer of 6 s, i.e., the play-out deadline isonly 6 s.

All figures in this paper report average results considering10 different runs of 15 minutes each.

A. Network Scenarios

The generic setup described above is used as a base for threedifferent scenarios to evaluate significant situations. The firstscenario, G Homo hereafter, is geographically homogeneous:the distribution of the peers of different Cp classes is thesame in any area, so that there is the same distribution ofbandwidth everywhere. This scenario is useful to understandthe fundamental behavior of different neighborhood filteringstrategies.

The second scenario, G Bias hereafter, assumes that band-width rich peers (Class 1) are all concentrated in a singlesubnet. This situation is particularly challenging for a topologymanagement system that tries to localize traffic to reduce thenetwork footprint of the application.

The third scenario, G Lossy hereafter, is again geograph-ically homogeneous, but the long-haul connections between

6 0

1

2

3

Add RND Add BW Add OFF Add RTT

Lost

Chu

nks

%Drop RNDDrop RXCDrop RTT

0

2

4

6

8

10

Add RND Add BW Add OFF Add RTT

Pee

rs o

ver 1

% L

osse

s % Drop RND

Drop RXCDrop RTT

0

1

2

3

Add RND Add BW Add OFF Add RTT

Pee

rs o

ver 3

% L

osse

s % Drop RND

Drop RXCDrop RTT

Figure 2. Frame loss for different strategies in G Homo scenario: Floss (average) (left), percentage of peers whose Floss(p) > 0.01 (center), percentage ofpeers whose Floss(p) > 0.03 (right).

the subnets 13, 14, 23, 24 are subject to packet losswith probability p = 0.05, while the intra-subnet links andthe links between 12 and 34 are lossless. This situation isuseful to understand if black-listing can really help in buildingbetter topologies, or if its use should be limited to isolatemisbehaving and malicious nodes.

The fourth and final scenario, G Adver hereafter, combinestogether G Bias and G Lossy in such a way that large band-width peers are amassed in the subnet 1, while the four subnetsexperience the same packet loss configuration on long-haullinks described above. This case, even if adverse, represents aninteresting challenge for those strategies that seek the tradeoffbetween location and bandwidth awareness, and it is useful todetect possible conflicts with the black-listing functionality.

Finally, churning of peers is modeled: a fraction Pnochof peers never leaves the system, while Pch = 1 Pnochchurning peers have a permanence time uniformly distributedbetween 4 and 12min. To keep the number of peers constant,once a churning peer has left the system, it will be off foran average time equal to 30 sec before re-joining the swarm(with a different ID, i.e., as a new peer).

B. Performance Indices

To assess the QoE for each peer p, we consider the frameloss probability, Floss(p), and the SSIM (Structural SimilarityIndex), Sssim(p), a well-known method for measuring thesimilarity between two images in the multimedia field [12].Given the highly structured organization of the video streams,the degradation of the received video quality becomes typicallynoticeable for values of Floss(p) higher than 1%, while lossprobability of a few percent (3-4%) significantly impair theQoE. In the following, we report both average frame loss,Floss = Ep[Floss(p)], and the percentage of peers that sufferFloss(p) larger than 1% and 3%, respectively.

Performance however should also take into account the costfor the network to support the application. As network cost we consider the average of the distance traveled by informationunits. Formally, let bq(p) the number of bits peer p receivedfrom peer q; the peer p network cost (p) is computed as

(p) =

q RTTq(p)bq(p)

q bq(p)(4)

while the average network cost is = Ep[(p)]. This isstrictly valid only if all peers receive the same amount ofdata, i.e., if the streaming is working correctly, otherwise theaverage network cost should be weighted by the amount ofdata received by each peer. As peers that receive less than,say, 95% of the stream would have unacceptable quality and

hence leave the system, this further refinement of the metricis not necessary.

V. CONTROLLED ENVIRONMENT EXPERIMENTSA. G Homo Scenario

We start considering the case in which the distribution ofCp is geographically homogeneous.

The left-hand plot in Fig. 2 shows the average frame lossprobability experienced by different policies, while center andright-hand plots report the percentages of peers that experi-enced Floss(p) > 0.01 and Floss(p) > 0.03, respectively.

RND-RND is the reference, and we immediately observethat the other algorithms modify the loss distribution, i.e.,they can have a different impact on different percentiles. Forinstance BW-RTT improves the average loss rate and thepercentage of peers with Floss(p) > 0.01, but at the expenseof the percentage of peers with bad quality (Floss(p) > 0.03),while RTT-RTT improves the number of peers with Floss(p) >0.01, but both the average and the percentage of peers withbad quality (Floss(p) > 0.03) are worse.

In general, the use of policies sensitive to peer bandwidth(BW and OFF for adding and RXC for dropping) appear tobe more effective in reducing losses. However the behaviorof BW-RXC, for which Floss tops at 2.5%, indicates thatusing a single metric for selecting the neighborhood can bedangerous. BW-RXC biases too much the choice toward highbandwidth peers, which become congested and are not able tosustain the demand. To better grasp these effects, Fig. 4 reportsthe smoothed9 histogram of the out-degree NO(p). NO(p) ofpeers belonging to different classes is significantly different aslong as bandwidth aware policies are adopted; out-degrees areinstead independent for RND-RND as expected. It would bedesirable to have an out-degree of a peer proportional to itsup-link bandwidth. This is roughly achieved by adopting BW-RND policy. Under BW-RXC, instead, the degree distributiondepends too much on Cp. As a result, high bandwidth peerstends to be oversubscribed while medium and low bandwidthpeers may be underutilized. Measures of the bandwidth uti-lization, not shown for lack of space, show that all bandwidthaware policies select an out-degree that completely saturatesthe available bandwidth, so that the out-degree distribution isa good indicator of over subscriptions.

Policies sensitive to RTT perform well in the consideredscenario, with the exception of RTT-RTT, which is too aggres-sive in strictly selecting the closest in-neighbors. Indeed, as

9The distribution of NO(p) inside classes is binomial as expected fromtheory. This distribution results in a large noisiness of the plot, so we applya smoothing window of length 30 in plotting, basically showing the averageNO in each class.

7Figure 3. Topology representations and N0 PDFs for RND-RND, RND-RXC, RTT-RXC and BW-RXC policies, G Homo scenario.

0

20

40

60

80

100

120

140

0 200 400 600 800 1000

Out

Deg

ree

Peer

Class 4 Class 3 Class 2 Class 1

BW - RXCBW - RND

RND - RXCRND - RND

Figure 4. Out-degree distribution of peers, G Homo scenario.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

0 50 100 150 200

CD

F

Network Cost [ms]

RTT - RTTRND - RTTRTT - RXCRND - RXCBW - RND

RND - RND

Figure 5. CDF of the distance traveled by information units, G Homoscenario.

Table IVTOPOLOGY STATISTICS VS. POLICY IN G Homo SCENARIO.

Edges E[NO] Frac. of ChordsRND - RND 29052 29.46 0.74RND - RXC 29058 29.93 0.73RTT - RXC 29550 29.97 0.30BW - RXC 29550 29.97 0.70

observed in [5], policies that force a too strict traffic localiza-tion induce performance degradations due to poor topologicalproperties of the swarm. To complement previous informationFig. 5 reports the Cumulative Distribution Function (CDF) ofnetwork cost (p). As expected, RTT aware policies signif-icantly reduce this index thanks to their ability to select in-

neighbors within the same area.The observations above are confirmed by Fig. 3 and Tab. IV.

The former reports a graphical representation of the overlaytopology, coupled with the PDF of NO, for several policieswhen considering G Homo scenario. Peers, grouped in clus-ters as described in Tab. I and Tab. II, are represented bydots whose size is proportional to their out-going degree.Color as well has been made lighter for larger values of NO.This graphical representation easily shows that: i) schemes notimplementing any location-aware policy show a larger fractionof chords, i.e., edges connecting peers belonging to differentclusters (Tab. IV details the actual graph characteristics);and ii) BW-RXC scheme biases the choice towards largebandwidth peers, possibly overloading them.

Remark A As a first consideration, we can say that:i) bandwidth aware policies improve the application per-formance; ii) RTT aware policies reduce the network costwithout endangering significantly the video quality if appliedto add peers; when used to drop peers, however, RTT posessignificant bias impairing QoE; iii) the preference toward highbandwidth peers/nearby peers must be tempered to achievegood performance. The policy RTT-RXC improves qualityand reduces the network cost at the same time, offering thebest trade-off in this scenario. Interestingly, this policy is alsoeasy to be implemented, since it requires to measure simpleand straightforward metrics. In general, bandwidth aware addschemes offer better QoE performance, at the cost of morecumbersome available capacity estimation. However, the RXCdrop filter measures the ability of the parent peer to offer usefulchunks as seen by the child peer. This is easy to measure aposteriori, after having tested a peer as a parent.

B. G Homo with Smaller NIWe consider the same network scenario but we set NI = 20.

This is a more critical situation where choosing the good in-neighbors is more important. The value of NI is related withthe signaling overhead which increases with NI , so havingsmall neighborhood is desirable. However, a too small NIwould impair the availability of chunks.

8 0 1 2 3 4 5 6 7 8

Add RND Add BW Add OFF Add RTT

Lost

Chu

nks

%Drop RNDDrop RXCDrop RTT

0

2

4

6

8

10

Add RND Add BW Add OFF Add RTT

Pee

rs o

ver 1

% L

osse

s % Drop RND

Drop RXCDrop RTT

0

2

4

6

8

10

Add RND Add BW Add OFF Add RTT

Pee

rs o

ver 3

% L

osse

s % Drop RND

Drop RXCDrop RTT

Figure 6. Frame loss for different strategies in G Homo scenario with NI = 20: Floss (average) (left), percentage of peers whose Floss(p) > 0.01 (center),percentage of peers whose Floss(p) > 0.03 (right).

0

0.2

0.4

0.6

0.8

1

0 0.02 0.04 0.06 0.08 0.1 0.12 0.14

CD

F

Chunk Loss Probability

BW - RNDRND - RXCRTT - RXCRND - RND

BW - RTTRND - RTTRTT - RTT

Figure 7. CDF of the frame loss probability for four different strategies,G Bias scenario.

Results are plotted in Fig. 6 (the y-scales in Figs. 2 and 6 aredifferent for readability reasons, and this is the reason why atfirst sight some policies seem to perform better with a smallerNI ). The performance of RND-RND significantly degrades inthis case. The reason is that the out degree of Class 1 peersunder RND-RND is often not enough to fully exploit theirbandwidth. Bandwidth aware strategies, instead, successfullyadapt NO(p) to Cp maintaining high performance. Also RTT-RND and RTT-RTT, which are bandwidth unaware, performbetter than RND-RND, since RTT-aware selection policiesreduce the latency between an offer and the actual chunktransmission that follows it, helping in exploiting the peersbandwidth. Results for network cost are similar to those inFig. 5 and are not reported for the sake of brevity.

Remark B Random selection policies, which are widelyemployed by the community [20], are robust, but performpoorly if the number of peers in the neighborhood is small: allpeers suffer 8% of frame loss, practically making it impossibleto decode the video. As already seen with NI = 30, the policythat combines bandwidth and RTT awarenesses (RTT-RXC)improves both performance and network costs. Similarly,wisely selecting high-capacity in-neighbors is vital, as testifiedby the excellent performance of add BW policies.

C. G Bias Scenario

Maintaining unchanged the Cp distribution, we localize allhigh bandwidth peers in geographical area 1. This scenario,in principle, constitutes a challenge for the policies that tryto localize traffic. Indeed as side effect of the localization wecan potentially have a riches with riches, poors with poorsclusterization effect that may endanger the video qualityperceived by peers in geographical regions other than 1.

Fig. 7 reports the CDF of Floss(p) for the strategies per-forming better in the G Homo scenario, plus the benchmark

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

0 50 100 150 200

CD

F

Network Cost [ms]

RTT - RTTRND - RTTBW - RTT

RTT - RXCRND - RXCRND - RNDBW - RND

Figure 8. CDF of distance traveled by information units, G Bias scenario.

Table VAVERAGE FRACTIONS OF INCOMING TRAFFIC FOR CLUSTER 2.

1 - good 2 - local 3 - bad 4 - bad + farRND - RND w/o BL 0.23 0.32 0.28 0.15RND - RND w BL 0.28 0.34 0.24 0.12BW - RND w/o BL 0.22 0.35 0.27 0.14BW - RND w BL 0.23 0.36 0.24 0.13

RTT - RXC w/o BL 0.12 0.68 0.11 0.07RTT - RXC w BL 0.13 0.70 0.09 0.05

RND-RND. In this case if RTT is the only metric usedas in RTT-RTT, the performance degrades unacceptably, andpeers in area 1 are in practice the only one receiving agood service. In general, any policies based on drop RTTperform poorly. Strategies RTT-RXC, RND-RXC and BW-RND perform similarly; however, the only policy that can alsoreduce the network cost is RTT-RXC, as shown in Fig. 8 thatreports the CDF of (p).

Remark C This result essentially proves that also inG Bias scenario it is possible to partially localize the trafficwithout endangering the video quality perceived by the user, aslong as RTT awareness is tempered with some light bandwidthawareness, as in RTT-RXC. Interestingly, the RTT drivenpolicies perform much better if the RTT is used to addpeers rather than to drop peers. Indeed, in this latter case,aggressively dropping far away, but high capacity, in-neighborspenalizes peers which are located in areas where little highcapacity peers can be found.

D. G Lossy Scenario

We consider another scenario in which large bandwidthpeers are uniformly distributed over the four subnets, butpacket losses are present in some long haul connections.

Fig 9 plots the CDF of frame losses (top) and the CDFof chunks delivery delays (bottom) for the selected policies.Blacklisting improves the performance of every policy. RTT-RXC emerges again as the best performing policy and with

9 0

0.2

0.4

0.6

0.8

1

0 0.02 0.04 0.06 0.08 0.1 0.12 0.14

CD

F

Chunk Loss Probability

RTT - RXC w BLRTT - RXC w/o BL

BW - RND w BLBW - RND w/o BLRND - RND w BL

RND - RND w/o BL

0

0.2

0.4

0.6

0.8

1

0 0.5 1 1.5 2

CD

F

Chunk Delivery Delay [s]

RTT - RXC w BLRTT - RXC w/o BL

BW - RND w BLBW - RND w/o BLRND - RND w BL

RND - RND w/o BL

Figure 9. CDF of chunk loss probability (top) and CDF of chunk deliverydelays (bottom) for six different strategies with and without adopting blacklistmechanism in G Lossy scenario.

blacklisting practically all peers are able to receive all chunks.This is an excellent result, since the system is facing a verychallenging scenario while working with a load of 0.9.

Benefits of the blacklisting mechanism are confirmed byTable V that reports the normalized volume of incoming trafficfor peers in cluster 2 from peers in all clusters. Keeping inmind that in G Lossy scenario peers belonging to cluster 2experience lossy paths from/towards peers in cluster 3 and4 (as explained in Sec. IV), it is easy to see that volumes ofincoming traffic from cluster 3 and 4 are nicely reduced thanksto blacklisting mechanism.

Remark D Blacklisting can play a significant role toavoid selecting lossy paths. Indeed, exploiting the blacklistmechanism every peer should identify and abandon poorlyperforming peers, biasing the neighborhood toward goodperforming in-neighbors. This effect reinforces policies thatnaturally bias the selection of neighbor peers employing peerquality. RND-RND, BW-RND and RTT-RXC have emergedas the most promising criteria (RND-RND being the baselinebenchmark). RTT-RXC with blacklisting is shown to guar-antee excellent performance to all peers even in this almostadversarial scenario.

E. G Adver Scenario

Fig. 10 plots the CDF of frame losses for different poli-cies in G Adver scenario when the system load = 0.9.Policies which showed best performance in G Lossy whereconsidered. Comparing Fig. 10 with Figs. 7 and 9 (top plot),it is immediately evident how combining together G Bias andG Lossy configurations has a negative impact on performance.However, even in this difficult context, RTT-RXC policiesstill shows the lowest chunk loss probability, confirming tobe the best choice. As seen in Sec. V-D, also in this case

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

CD

F

Chunk Loss Probability

RTT - RXC w BLRTT - RXC w/o BL

BW - RND w BLBW - RND w/o BLRND - RND w BL

RND - RND w/o BL

Figure 10. CDF of chunk loss probability for six different strategies with andwithout adopting blacklist mechanism in G Adver scenario.

blacklisting improves the performance, especially of thosefiltering strategies which do not exploit location-awareness,such as RND-RND and BW-RND. This instead does nothold completely for RTT-RXC, and induce to think that thetradeoff between location and bandwidth awareness is enoughto provide acceptable performance in this challenging scenario.Indeed, given the peculiar configuration of G Lossy, choosingin-neighbors based on their location represents a sufficientcriterion to avoid lossy links, so that blacklisting does notbring any further benefit.

Remark E Blacklisting confirms to be in general a usefulhelp in the filtering process, letting peers drop lossy connec-tions, especially when no location-based filtering strategy isadopted.

VI. VIDEO PERFORMANCE EVALUATION

A. Video performance versus load

We now summarize the results by aessessing the actualaverage QoE by reporting Sssim for different policies anddifferent system loads. We consider G Lossy and G Adverscenarios, and let rs range from 0.6 Mb/s to 1.4 Mb/s. Recallthat the mean peer capacity E[Cp] = 1.324 Mb/s.

Fig. 11 shows the average Sssim considering RND-RND,BW-RND and RTT-RXC with and without blacklisting. SSIMmeasures the distortion of the received image compared withthe original source (before encoding and chunkization). Itis a highly non linear metric between 1 and 1. Negativevalues correspond to negative images, and are not considered.Values above 0.985 indicates excellent quality. SSIM hasbeen computed considering the video between min 12 and13 (60x25 frames) received by 200 peers (50 for each class),and then averaging among all of them. The EVQ (EncodedVideo Quality) curve in the plot is the reference value forthe encoding rate and it obviously increases steadily as rsincreases. For all policies, when the system load is small

10

0.9 0.91 0.92 0.93 0.94 0.95 0.96 0.97 0.98 0.99

1

0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4

SS

IM

rs [Mbps]

=1.0

EVQRTT - RXC w BL

RTT - RXC w/o BLBW - RND w BL

BW - RND w/o BLRND - RND w BL

RND - RND w/o BL

Figure 11. Sssim (average) index varying the video rate. G Lossy scenario.

0.5

0.6

0.7

0.8

0.9

1

0.6 0.7 0.8 0.9 1 1.1 1.2 1.3

SS

IM

rs [Mbps]

=0.9

EVQRTT - RXC w BL

RTT - RXC w/o BLBW - RND w BL

BW - RND w/o BLRND - RND w BL

RND - RND w/o BL

Figure 12. Sssim (average) index varying the video rate. G Adver scenario.

Similarly, Fig. 12 shows the average Sssim consideringRND-RND, BW-RND and RTT-RXC in the G Adver scenario,both with and without blacklisting functionality. As expected,the adversarial scenario makes it more challenging to achieve agood QoE, even for 0.75.

B. Scaling with swarm size

Considering again G Homo scenario, we study how thesystem scales when increasing the swarm size N from 200to 2000 peers. Due to the lack of space, we only report inTable VI the average Sssim for the RND-RND and RTT-RXCschemes. The video is encoded at rs = 1.2 Mb/s, i.e., systemload = 0.9. The simple bandwidth-aware scheme, RTT-RXC, always ensures better performance than RND-RND, i.e.,the average Sssim improves from 0.8 to 0.99, a remarkablegain. Increasing N has a negligible impact on performance,especially when the smart RTT-RXC policy is adopted.

C. Sensitivity to NI and Update Rate with Churning andFlash Crowd

Consider a G Homo scenario with Pchurn fraction of peersthat join and leave the swarm. We investigate what are the besttrade-off values for the size of the incoming neighborhood NIand its update frequency Rup, as defined in (2).

Table VIAVERAGE Sssim VERSUS N . G Homo SCENARIO, rs = 1.2 MB/S.

N 204 612 1040 1428 1836 2080RND - RND 0.858 0.812 0.829 0.783 0.799 0.799RTT - RXC 0.984 0.981 0.988 0.979 0.988 0.991

0.8

0.85

0.9

0.95

1

10 20 30 40 50 60 70 80

SS

IM

In-Degree

Pchurn = 0.50

RTT-RXCRND-RND

Figure 13. Average Sssim vs NI with Pchurn = 0.5. Schemes RND-RNDand RTT-RXC in G Homo scenario with 1000 peers and rs = 1.0 Mb/s.

0

0.1

0.2

0.3

0.4

0.5

400 420 440 460 480 500 520

Loss

Rat

e

Time [s]

RND-RND, NI = 30BW-RXC, NI = 30

RND-RXC, NI = 30RTT-RXC, NI = 30RTT-RXC, NI = 5

Figure 14. Average loss rate vs time before, during and after a flash crowdevent. G Homo scenario with 1000 peers and rs = 1.0 Mb/s.

Fig. 13 reports Sssim (computed and averaged over peersthat never leave the system) varying the size of the incomingneighborhood NI . In particular, we set Fup = 0.3, Tup = 10and change NI [5, 80]. For this case we consider RND-RND and RTT-RXC schemes in G Homo scenario with rs =1.0 Mb/s and a fraction of churning peers Pchurn = 0.5.First, observe that both schemes show good performance forwhatever value of NI [25, 45]. Indeed, a too small incomingneighborhood, e.g. NI = 5, is not enough to guarantee thepeers to find a good and stable set of in-neighbors from whichto download chunks; on the other hand setting too large valuesof NI leads to a larger overhead and, thus, to a worse percievedQoE, especially for the case in which no location-aware policyis employed (see RND-RND when NI = 80).

We go further in our investigation and consider a flashcrowd scenario derived from G Homo. The experiment startswith only half of the peers, i.e., all peers in subnets 1and 2. The other half of the peers, belonging to subnets 3and 4, join the system abruptly all together after 7 min ofexperiment generating a flash crowd event. Fig. 14 reportsthe chunk loss rate (computed and averaged over peers thatnever leave the system) for different policies and different sizesof the incoming neighborhood NI . In particular, we considerRND-RND, BW-RND, RND-RXC and RTT-RXC schemes in

11

0.7

0.75

0.8

0.85

0.9

0.95

1

0.125 0.25 0.5 1 2 4

SS

IM

Rup

Pchurn=0.0Pchurn=0.25Pchurn=0.50Pchurn=0.75

Figure 15. Average Sssim vs Rup for different Pchurn. Scheme RTT-RXCin G Homo scenario with 1000 peers and rs = 0.8 Mb/s.

0

20

40

60

80

100

0 100 200 300 400 500 600 700 800 900

Out

-Nei

ghbo

rood

siz

e

Time [s]

Rup=2 peer/sRup=1 peer/s

Rup=0.5 peer/sRup=0.2 peer/s

Figure 16. The evolution during time of the average outgoing neighborhoodsize setting different Rup values. Scheme RTT-RXC in G Homo scenariowith rs = 1.0 Mb/s.

G Homo scenario with rs = 1.0 Mb/s. Observe that given areasonable size of the in-neighbors set, i.e., when NI = 30,all considered schemes nicely react to the sudden ingress of500 peers. Indeed, in all cases, the swarm takes only 30s toget back to a stable regime. Instead when NI = 5, the systemtakes a longer time to stabilize.

Fig. 15 reports the Sssim (computed and averaged overpeers that never leave the system) varying the rate of updateRup. We set NI = 30, Fup = 0.3 and change Tup [2, 100] saccordingly. For this case we adopted scheme RTT-RXC andrs = 0.8 Mb/s. The plot shows that the system is very robust todifferent Rup values. Only under stressed scenarios, such as forPchurn >= 0.5, Rup becomes critical: too high Rup does notlet the swarm achieve a stable state, impairing performance.On the other hand, too low Rup induces peers to react slowlyto sudden changes brought by churning peers.

We now consider the G Homo scenario again, and forceall high-bandwidth peers to experience an abrupt up-linkbandwidth reduction from 5 Mbit/s to 0.64 Mbit/s (on average)at time 480 s. This scenario is rather artificial, but it allowsquantifying the reactivity of the topology to such abruptchanges. We consider the RTT-RXC scheme. Fig. 16 reportsthe evolution over time of the average size of the outgoingneighborhood NO of class 1 peers. Different values of in-neighborhood update rate Rup are considered. Two observa-tions hold: first, smaller values of Rup slow down the systemreactivity; second, too large values, e.g., Rup = 2 peer/s,impair the performance as well, as peers do not have enoughtime to collect significant measurements about the in-neighborquality (amount of received chunks), and thus find it difficult

Table VIICHARACTERISTICS OF PEER CLASSES IN THE PLANETLAB EXPERIMENT.

Class Upload Bandwidth Percentage of Peers1 2.00 Mb/s 10% 50 %2 0.64 Mb/s 10% 50 %

0.8

0.85

0.9

0.95

0 0.2 0.4 0.6 0.8 1

SS

IM

Rank

rs = 0.8

RTT - RXCBW - RXC

RTT - RNDRND - RND

0.8

0.85

0.9

0.95

0 0.2 0.4 0.6 0.8 1

SS

IM

Rank

rs = 1.0

RTT - RXCBW - RXC

RTT - RNDRND - RND

Figure 17. Sssim(p) for rs = 0.8 Mb/s and rs = 1.0 Mb/s for PlanetLabexperiments.

0.8 0.82 0.84 0.86 0.88

0.9 0.92 0.94 0.96 0.98

1

0.8 0.85 0.9 0.95 1 1.05 1.1 1.15 1.2 1.25 1.3

SS

IM

rs [Mbps]

=0.9

RTT - RXCBW - RXC

RTT - RNDRND - RND

Figure 18. Sssim (average) index when varying video rate for PlanetLabexperiments.

to distinguish good from bad in-neighbors. Also in thiscase Rup = 1 peer/s setup represents a good trade off.

Remark G Fast topology updates allow the overlaytopology i) to react quickly to changes in the network scenario;and ii) to prune quickly peers which left the system, e.g., inheavy churning conditions. However, too fast updates intro-duce instability in the overlay construction process, drivingpeers to never achieve a stable incoming neighborhood, andthus leading to bad system performance. The best trade-offvalue is Rup = 1 peer/s, i.e., Tup = 10 s.

VII. PLANETLAB EXPERIMENTS

We now present similar experiments on PlanetLab. Weselected all active PlanetLab nodes, excluding those that had

12

configuration issues or severe reachability problems. As aresult, we obtained a set of 449 nodes scattered worldwide.No artificial latency or packet loss were imposed, so that con-nections among these nodes reflect natural Internet conditions.

In order to achieve a scenario similar to the experimentsof the previous section, peer upload capacity has been limitedby the PeerStreamer embedded rate limiter. Observe that thisonly guarantees an upper bound to the actual available peerupload bandwidth which may be smaller due to competingexperiments running on the same PlanetLab node or due toother bottlenecks on the access links of the node. For thisreason, contrary to previous experiments, we did not use a5 Mbit/s class, and restricted the scenario to two classes asshown in Table VII: half of the peers have 2 Mbit/s at their up-link, and 0.64 Mbit/s the other half. Average upload capacityresults to have an upper bound of 1.32 Mbit/s, but the actualvalue largely depends on the status of PlanetLab nodes andtheir network connection. Blacklisting was active by defaultfor these experiments.

Fig. 17 reports each peers individual SSIM performance,Sssim(p), for rs = 0.8 Mbit/s (top) and rs = 1.0 Mbit/s(bottom). Sssim(p) has been sorted in decreasing values toease visualization. Each curve represents the average of 10different runs. Observe that when the amount of system re-sources is large enough with respect to the video-rate, i.e, whenrs = 0.8 Mbit/s (top plot), different schemes for topologymanagement perform rather similarly. Observe, however, thatthere is always a certain fraction of nodes that cannot receivethe video due to congestion at local resources.

Increasing system load, i.e., rs = 1.0 Mbit/s (bottom plot),highlights differences among schemes and confirms resultsobtained in the controlled environment: random-based policies(RND-RND) perform badly in general; the same holds forschemes based on pure proximity that can lead to disconnectedtopologies and, then, to bad QoE performance (RTT-RND). Infact, the right side of the RTT-RND curve shows that a groupof peers (with rank around 0.8) received the video with lowerquality than other peers.

A pure bandwidth based policy (BW-RXC) provides goodperformance, delivering the video in good quality to morepeers than the previous two policies. However, the bestquality (the highest portion of peers receiving good quality)is achieved combining bandwidth-awareness with proximity-based schemes (RTT-RXC). Thus, this last policy achieves thegoal of localizing traffic without impairing performance.

Results depicted in Fig. 17 are confirmed in Fig. 18 thatshows the average Sssim as a function of video-rate rs, andthus system load , for the same four policies (RND-RND,RTT-RND, BW-RXC, RTT-RXC). Again RTT-RXC proves tobe the most reliable choice, consistently outperforming otherpolicies for each value of rs.

Fig. 19 complements the information about users perceivedperformance with statistics about network cost reporting theCumulative Distribution Function (CDF) of network cost (p)given a system load equal to 0.75 (rs = 1.0 Mbit/s). Oncemore, RTT aware policies significantly reduce (p) thanksto their ability to select closer in-neighbors, thus producinga lighter footprint on network resources. Observe that when

0

0.2

0.4

0.6

0.8

1

0 50 100 150 200 250 300 350 400

CD

F

RTT [ms]

RTT-RNDRTT-RXCBW-RXC

RND-RND

Figure 19. CDF of the distance traveled by information units. PlanetLabexperiments.

RTT sensitive policies are adopted, more than 55% of datais exchanged with peers with less than 50 ms RTT. When nolocation awareness is enabled, this fraction reduces to less than30%, increasing both network cost and chunk delivery times.

Although RTT-RXC is only second best in terms of networkcost the difference is marginal, and it is the only policythat can combine good performance with low network costs,confirming again to be the best choice to adopt.

VIII. RELATED WORK

Many popular commercial applications such as PPLive [23],UUSee [24], PPStream [25], SopCast [26] were proposed inrecent years, but almost no information about their internalimplementation is available, making any statement about theiroverlay topology design strategies impossible.

Only a few recent measurement studies suggest that simplerandom based policies are adopted by SopCast [20], andsome slight locality-awareness is implemented in PPlive [27].Focusing on available literature on purely mesh-based P2P-TVsystems, many solutions can be found, but also in this case, tothe best of our knowledge, none of them provides general anddetailed guidelines for the overlay topology design process.

An early solution called GnuStream was presented in [28].Based on Gnutella overlay, GnuStream implemented a loaddistribution mechanism where peers were expected to con-tribute to chunks dissemination in a way proportional to theircurrent capabilities. A more refined solution called PROMISEwas introduced in [29]. Authors proposed an improved seederchoice based on network tomography techniques; peers wereinterconnected through Pastry overlay topology which imple-ments as many others P2P substrates like Chord [30] or CANsome location awareness based on number of IP hops. DONet(or Coolstreaming) [2] is a successful P2P-TV system im-plementation. This design employs a scheduling policy basedon chunk rarity and available bandwidth of peers, but its data-driven overlay topology does not exploit any information fromunderlying network levels. Many new features were introducedin [31] to improve the streaming service and, in particular,authors proposed a new neighbor re-selection heuristic basedonly on peers up-link bandwidth. In [32], authors showed thedesign aspects of their application called AnySee. Even if par-tially based on multicast, this hybrid mesh-based system relieson an overlay topology that aims at matching the underlyingphysical network while pruning slow logical connections.

13

However, no deep investigation about performance of theiroverlay design strategy is provided. In [33] authors presenteda study about some key design issues related to mesh-basedP2P-TV systems. They focused on understanding the reallimitations of this kind of applications and presented a systembased on a directed and randomly generated overlay. Somefundamental improvements were introduced: e.g., the degreeof peers made proportional to their available bandwidth.

Turning our attention on more theoretical studies about theoverlay topology formation, in [3] the problem of building anefficient overlay topology, taking into account both latency andbandwidth, has been formulated as an optimization problem;however, the interactions between overlay topology structureand the chunk distribution process are ignored.

In [34] a theoretical investigation on optimal topologies isformulated, considering latency and peer bandwidth hetero-geneity; scaling laws are thus discussed. In [4], a distributedand adaptive algorithm for the optimization of the overlaytopology in heterogeneous environments has been proposed,but network latencies are still ignored. Authors of [35] proposea mechanism to build a tree structure on which informationis pushed. They show that good topological properties areguaranteed by location awareness schemes. Similar in spirit,but in unstructured systems, we propose in this paper anoverlay topology design strategy that, taking into accountlatency and peer heterogeneity, aims at creating an overlaywith good properties and low chunk delivery delays. In highlyidealized scenarios, [36] shows with simple stochastic modelsthat overlay topologies with small-world properties are partic-ularly suitable for chunk distribution in P2P-TV systems.

Finally, in [10], authors experimentally compare unstruc-tured systems with multiple-tree based ones, showing thatformer systems perform better in highly dynamic scenariosas well as in scenarios with bandwidth limitations. Thisstrengthen our choice of exploring topology managementpolicies for mesh-based streaming systems.

IX. CONCLUSIONS

P2P-TV systems are extremely complex, and the assessmentof their performance through experiments has been rarelyundertaken. In particular, the impact of different constructionand maintenance strategies for the overlay topology is ofthe utmost importance, and remains extremely difficult tostudy. The work presented in this paper partially fills thisgap. PeerStreamer was developed within the framework of theNAPA-WINE project. Its modularity and flexibility allowedthe selection of arbitrary strategies for the construction of theoverall topology. In a fully controlled networking environment,we have run a large campaign of experiments measuring theimpact of different filtering functions applied to the man-agement of peer neighborhoods. Results show that propermanagement, based on simple RTT measurements to addpeers, coupled with an estimation of the quality of the peer-to-peer relation to drop them, leads to a win-win situation wherethe performance of the application is improved while thenetwork usage is reduced compared to a classical benchmarkwith random peer selection.

REFERENCES

[1] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, and A. E. Mohr,Chainsaw: Eliminating trees from overlay multicast, in IPTPS, Ithaca,NY, US, February 2005.

[2] X. Zhang, J. Liu, and T. Yum, Coolstreaming/donet: A data-driven over-lay network for peer-to-peer live media streaming, in IEEE INFOCOM,Miami, FL, US, March 2005.

[3] D. Ren, Y. T. H. Li, and S. H. G. Chan, On Reducing Mesh Delay forPeer-to-Peer Live Streaming, in IEEE INFOCOM, Phoenix, AZ, US,April 2008.

[4] R. Lobb, A. P. Couto da Silva, E. Leonardi, M. Mellia, and M. Meo,Adaptive Overlay Topology for Mesh-Based P2P-TV Systems, in ACMNOSSDAV, Williamsburg, VA, US, June 2009.

[5] A. Couto da Silva, E. Leonardi, M. Mellia, and M. Meo, ChunkDistribution in Mesh-Based Large Scale P2P Streaming Systems: a FluidApproach, IEEE Trans. on Parallel and Distributed Systems, vol. 22,no. 3, pp. 451463, March 2011.

[6] X. Jin and Y.-K. Kwok, Network aware P2P multimedia streaming:Capacity or locality? in IEEE P2P, Kyoto, JP, August 2011.

[7] Y. Liu, On the minimum delay peer-to-peer video streaming: howrealtime can it be? in ACM Multimedia, Augsburg, DE, September2007.

[8] T. Bonald, L. Massoulie, F. Mathieu, D. Perino, and A. Twigg,Epidemic live streaming: optimal performance trade-offs. in ACMSIGMETRICS, Annapolis, MD, US, June 2008.

[9] L. Abeni, C. Kiraly, and R. Lo Cigno, On the Optimal Scheduling ofStreaming Applications in Unstructured Meshes, in IFIP Networking,Aachen, DE, May 2009.

[10] J. Seibert, D. Zage, S. Fahmy, and C. Nita-Rotaru, Experimental com-parison of peer-to-peer streaming overlays: An application perspective,in IEEE LCN, Montreal, QC, CA, October 2008.

[11] F. Picconi and L. Massoulie, Is there a future for mesh-based live videostreaming? in IEEE P2P, Aachen, DE, September 2008.

[12] Z. Wang, A. C. Bovik, H. R. Sheikh, and E. P. Simoncelli, Imagequality assessment: From error visibility to structural similarity, IEEETrans. on Image Processing, vol. 13, no. 4, pp. 600612, April 2004.

[13] S. Traverso, L. Abeni, R. Birke, C. Kiraly, E. Leonardi, R. Lo Cigno,and M. Mellia, Experimental comparison of neighborhood filteringstrategies in unstructured p2p-tv systems, in IEEE P2P, Tarragona, ES,September 2012.

[14] NAPA-WINE. [Online]. Available: http://www.napa-wine.eu/[15] R. Birke, E. Leonardi, M. Mellia, A. Bakay, T. Szemethy, C. Kiraly,

R. Lo Cigno, F. Mathieu, L. Muscariello, S. Niccolini, J. Seedorf, andG. Tropea, Architecture of a Network-Aware P2P-TV Application: theNAPA-WINE Approach, IEEE Comm. Magazine, vol. 49, June 2011.

[16] L. Abeni, C. Kiraly, A. Russo, M. Biazzini, and R. Lo Cigno, Designand implementation of a generic library for P2P streaming, in Workshopon Advanced Video Streaming Techniques for Peer-to-Peer Networks andSocial Networking, Florence, IT, October 2010.

[17] R. Birke, C. Kiraly, E. Leonardi, M. Mellia, M. Meo, and S. Traverso,A delay-based aggregate rate control for p2p streaming systems,Computer Communications, vol. 35, no. 18, pp. 2237 2244,2012. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0140366412002332

[18] N. Tolgyesi and M. Jelasity, Adaptive peer sampling with newscast,in Euro-Par, Delft, NL, 2009.

[19] F. Chierichetti, S. Lattanzi, and A. Panconesi, Rumour spreading andgraph conductance, in ACM-SIAM SODA, Austin, TX, US, 2010.

[20] I. Bermudez, M. Mellia, and M. Meo, Passive characterization ofSopCast usage in residential isps, in IEEE P2P, Kyoto, JP, August2011.

[21] R. Fortuna, E. Leonardi, M. Mellia, M. Meo, and S. Traverso, QoE inPull Based P2P-TV Systems: Overlay Topology Design Tradeoffs, inIEEE P2P, Delft, The Netherlands, August 2010. [Online]. Available:http://www.telematica.polito.it/traverso/papers/p2p10.pdf

[22] F. Lehrieder, S. Oechsner, T. Hossfeld, Z. Despotovic, W. Kellerer, andM. Michel, Can p2p-users benefit from locality-awareness? in IEEEP2P, Delft, NL, August 2010.

[23] PPLive. [Online]. Available: http://www.pplive.com[24] UUSee. [Online]. Available: http://www.uusee.com[25] PPStream. [Online]. Available: http://www.ppstream.com[26] SOPCast. [Online]. Available: http://www.sopcast.com[27] L. Vu, I. Gupta, K. Nahrstedt, and J. Liang, Understanding overlay

characteristics of a large-scale peer-to-peer iptv system, ACM Trans.Multimedia Comput. Commun. Appl., vol. 6, no. 4, pp. 31:131:24, Nov.2010. [Online]. Available: http://doi.acm.org/10.1145/1865106.1865115

14

[28] X. Jiang, Y. Dong, D. Xu, and B. Bhargava, Gnustream: a P2P mediastreaming system prototype, in IEEE ICME, Washington, DC, US,2003.

[29] M. Hefeeda, A. Habib, B. Botev, D. Xu, and B. Bhargava, Promise:peer-to-peer media streaming using collectcast, in ACM Multimedia,New York, NY, US, 2003.

[30] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan,Chord: A scalable peer-to-peer lookup service for internet applications,SIGCOMM Comput. Commun. Rev., vol. 31, pp. 149160, August 2001.

[31] B. Li, S. Xie, Y. Qu, G. Y. Keung, C. Lin, J. Liu, and X. Zhang, In-side the new coolstreaming: Principles, measurements and performanceimplications, in IEEE INFOCOM, Phoenix, AZ, US, April 2008.

[32] X. Liao, H. Jin, Y. Liu, L. M. Ni, and D. Deng, Anysee: Peer-to-peerlive streaming, in IEEE INFOCOM, Barcelona, ES, April 2006.

[33] N. Magharei and R. Rejaie, Prime: Peer-to-peer receiver-driven mesh-based streaming, in IEEE INFOCOM, Anchorage , AK, US, May 2007.

[34] T. Small, B. Liang, and B. Li, Scaling laws and tradeoffs in Peer-to-Peer live multimedia streaming, in ACM Multimedia, Santa Barbara,CA, US, October 2006.

[35] T. Locher, R. Meier, S. Schmid, and R. Wattenhofer, Push-to-Pull Peer-to-Peer Live Streaming, in Distributed Computing, ser. Lecture Notesin Computer Science, A. Pelc, Ed. Springer Berlin / Heidelberg, 2007,vol. 4731, pp. 388402.

[36] J. Chakareski, Topology construction and resource allocation in p2plive streaming, in Intelligent Multimedia Communication: Techniquesand Applications, ser. Studies in Computational Intelligence. SpringerBerlin / Heidelberg, 2010, vol. 280, pp. 217251.

Stefano Traverso received his Ph.D. degree inNetworking Engineering at Politecnico di Torino,Italy, in 2012. His research interests include P2Pnetworks, streaming systems, overlay networks, net-work measurements, and content delivery networks.During his Ph.D. and Post-doc he has been visitingTelefonica I+D research center in Barcelona, Spain,and NEC Laboratories in Heidelberg, Germany. Heis currently a Post-doc Fellow of TNG group ofPolitecnico di Torino.

Luca Abeni is assistant professor at DISI, Univer-sity of Trento. He graduated in computer engineer-ing from the University of Pisa in 1998, and re-ceived a Ph.D. degree at Scuola Superiore S. Anna,Pisa in 2002. From 2003 to 2006, Luca workedin Broadsat S.R.L., developing IPTV applicationsand audio/video streaming solutions over wired andsatellite (DVB - MPE) networks. His main researchinterests are real-time operating systems, schedulingalgorithms, Quality of Service management, multi-media applications, and audio/video streaming.

Robert Birke received his Ph.D. degree from thePolitecnico di Torino in 2009 with the telecommu-nications group under the supervision of professorFabio Neri. Currently he works as a postdoc inthe system fabrics group at IBM Research ZurichLab. His main research interests are peer-to-peer,high performance computing, and datacenter net-works with special focus on performance, qualityof service, and virtualization.

Csaba Kiraly , at the time of this work, was researchassociate at DISI, University of Trento, Italy, as partof the Systems and Networks group. He graduatedin Informatics and Telecommunications from theBudapest University of Technology and Economicsin 2001, and he received his Ph.D. from the sameuniversity. His main research interests are in designand performance evaluation of overlay networks,with particular focus on P2P streaming and privacyenhancing technologies. Csaba Kiraly is member ofthe IEEE and ACM. He is co-author of more than

30 scientific papers.

Emilio Leonardi (SM09) received a Dr. Ing. degreein Electronics Engineering in 1991 and a Ph.D. inTelecommunications Engineering in 1995 both fromPolitecnico di Torino. He is an Associate Professorat the Dipartimento di Elettronica of Politecnico diTorino. His research interests are in the field of:performance evaluation of computer and commu-nication networks, scheduling, queueing theory andpacket switching.

Renato Lo Cigno (SM11) is Associate Professor atthe Department of Computer Science and Telecom-munications (DISI) of the University of Trento,Italy, where he leads a research group in computerand communication networks. He received a degreein Electronic Engineering with a specialization inTelecommunications from Politecnico di Torino in1988, the same institution where he worked until2002. From 1998 to 2006, he was with the ComputerScience Department, University of California, LosAngeles, as a Visiting Scholar for a total of 14

months. His current research interests are in performance evaluation ofwired and wireless networks, modeling and simulation techniques, congestioncontrol, P2P networks and networked systems in general. Renato Lo Cignowas Area Editor for Computer Networks, and is regularly involved inthe organizing and technical committees of leading IEEE, ACM and IFIPConferences, such as Infocom, Globecom, ICC, P2P, MSWiM, WONS. He issenior member of IEEE and ACM.

Marco Mellia (SM08) is with the Dipartimentodi Elettronica e Telecomunicazioni at Politecnicodi Torino as an Assistant Professor. In 1997, hewas a Researcher supported by CSELT. Duringhis Ph.D., he has been with the Computer Sci-ence Department of Carnegie Mellon University. In2002 he visited the Sprint Advanced TechnologyLaboratories, California, and in 2011 and 2012 hevisited Narus Inc, California. He has co-authoredover 180 papers published in international journalsand presented in leading international conferences,

all of them in the area of telecommunication networks. He participated inthe program committees of several conferences including ACM SIGCOMM,ACM CoNEXT, IEEE Infocom, IEEE Globecom and IEEE ICC. He is AreaEditor of ACM CCR. His research interest are in the design and investigationof energy efficient networks and in traffic monitoring and analysis. He iscurrently the coordinator of the mPlane Integrated Project that focuses onbulding an Intelligent Measurement Plane for Future Network and ApplicationManagement

IntroductionPeerStreamer DescriptionPeerStreamer ArchitectureOverlay Management

Neighborhood and Topology ConstructionMetrics Driving the Neighborhood SelectionAdd FiltersDrop FiltersBlacklisting PoliciesA Few Theoretical Considerations

Test-bed ConfigurationNetwork ScenariosPerformance Indices

Controlled Environment ExperimentsG_Homo ScenarioG_Homo with Smaller NIG_Bias ScenarioG_Lossy ScenarioG_Adver Scenario

Video Performance EvaluationVideo performance versus loadScaling with swarm sizeSensitivity to NI and Update Rate with Churning and Flash Crowd

PlanetLab ExperimentsRelated WorkConclusionsReferencesBiographiesStefano TraversoLuca AbeniRobert BirkeCsaba KiralyEmilio LeonardiRenato Lo CignoMarco Mellia