DISSECTING PPLIVE, SOPCAST, TVANTS
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Dissecting PPLive, SopCast, TVAnts
Akos Horvath Dario Rossi Delia Ciullo
Miklos Telek Paolo Veglia Maria Antonieta Garcia
Budapest University of TELECOM-ParisTech Emilio Leonardi
Technology and Economics Marco Mellia
Politecnico di Torino
Abstract
Early P2P-TV systems have already attracted a millions of users, and many new commercial solutions are
entering this market. Little information is however available about how these systems work. Therefore, experi-
mental studies are required to characterize the traffic generated by P2P-TV applications, as well as to infer some
properties of the adopted algorithms. To this extend, in this paper we present a large scale set of experiments to
compare three of the most successful P2P-TV systems, namely PPLive, SopCast and TVAnts.
By means of extensive measurements, we are able capture some insight on the mechanisms that govern the
data transfer. We show that for all applications, the selection of the peer-set from which downloading the video
content is strongly affected by the peers upload bandwidth (as intuitively expected). On the contrary, only in
TVAnts and partly in PPLive, , peer location information are exploited by the application. Turning the attention
to the overlay discovery algorithms, PPLive peers are very aggressive contacting new peers at a fixed rate, while
both in TVAnts and SopCast the peer discovery rate is slowed down after the initial peer bootstrap.
1 Introduction and Motivations
The Internet proved to have an awesome capability of adapting to new services, migrating from the initial pure
datagram paradigm to a real multi-service infrastructure. One of the most recent step of this evolution is con-
stituted by P2P-TV applications, i.e., large-scale real-time video-streaming services exploiting the peer-to-peer
communication paradigm.
Several commercial P2P streaming systems such as PPLive [1], SopCast [2] and TVants [3] to mention some
of the most popular ones, are already available and they are attracting millions of users [4]. This first generation
of P2P-TV systems offer low-quality narrow-band P2P video streaming (200–400 kbit/s). Next-generation, high-
quality P2P streaming applications (1–10 Mbit/s) is just beyond the corner, as commercial video P2P applications,
such as Joost [5], Babelgum [6], Zattoo [7], TVUnetworks [8], are at an advanced stage of beta-testing and are
likely to be fully launched in the next few months.
While the clear potentialities of P2P-TV systems has drawn the attention of Telecom operators and Service
providers, little information is available about the internal algorithms and protocols used by these applications.
Indeed, all adopt proprietary solutions, which are in general not public. Similarly, these same potentialities of P2P-
TV systems constitute a worry for network carriers since the traffic they generate may potentially grow without
control, causing a degradation of quality of service perceived by Internet users or even the network collapse (and
the consequent failure of the P2P-TV service itself).
One of the goals of the recently funded Project called “Network-Aware P2P-TV Application over Wise Net-
works ” (NAPA-WINE) [9], is therefore to provide a careful analysis of the impact that a large deployment of
general P2P-TV services may have on the Internet, through a detailed characterization of the traffic they generate.
To this extent, in this paper, we aim at providing an assessment of currently deployed systems, in order to shed
some light on the characteristics of the traffic generated by P2P-TV applications and the algorithms these applica-
tions may adopt. We investigated some of the most popular application, both narrow-band (PPLive, SOPCast and
TVants) as well as high-quality (Joost and Babelgum). However, from our experience the latter systems are not yet
at a mature stage of deployment: the offered content is mostly Video on Demand and the number of users seems
to be still marginal so that the video distribution is still mostly sustained by servers rather than coming from P2P
clients. For these reasons, in this paper we focus on more mature and largely adopted first generation systems.SopCast TVAnts PPLive
Bandwidth strong strong strong
Locality weak strong average
Hop count negligible average weak
Tit-for-tat no no no
Overlay discovery controlled efficient greedy
Table 1: Summary of the application properties.
The methodology we pursue in our investigation is the following. We have deployed a fairly large active
testbed, involving 44 controlled-peers hosted at seven different Institutions scattered over 4 European countries.
Different network setups (e.g., access technology, security policies, etc.) and peers configurations (hardware
configurations, Operating Systems, etc.) are part of the testbed. For each application under investigations, we
conducted several experiments, where all partners’peers were forced to watch the same channel at the same time.
Packet-level traces of the exchanged traffic are collected and analyzed. The major goal is to infer the most inter-
esting properties, similarity and differences among these systems. Similarly, we aim at highlighting the possible
parameters that influence the peer selection, both considering the overlay discovery, and data neighbors.
Table 1 summarized the main achievements of our work. In particular, we show that all applications exhibit
a strong bias involving, when possible, almost exclusively high-bandwidth peers in the video content distribution
process.
Focusing instead, on the localization of the peers, we show that SopCast is almost unaware of the peers
location, while PPLive tends to favor the exchange of data between peers in the same SubNet. In addition to
this, TVAnts favors the data exchange between close peers (where the distance is expressed in hop count) and
between peers belonging to the same AS. Now turning the attention to a specific peer, the sets of peers from which
it downloads the content, and the set of peers to which it upload the content are usually almost disjoint. This
is in contrast with what happens in P2P based content distribution applications, like BitTorrent, where incentive
policies like tit-for-tat are implemented.
Considering now the peer discovery mechanism performed by a single peer, both TVAnts and SopCast show
a controlled behavior that limits the rate at which pears are contacted after the initial bootstrap. To this extend,
TVAnts is more efficient, limiting the number of contacted peers to few hundreds. On the contrary, PPLive peers
greedily contact other peers, at an almost constant rate. After one hour, up to 40.000 peers can be contacted by a
single node. Incidentally, peer lifetime of most of contacted peers is negligible.
2 Related Work
A fairly large number of public P2P architectures and algorithms for the support of video distribution over the
Internet has been proposed in the last three-four years within the scientific community [10, 11, 12, 13, 14, 15].
Despite their clear merit, the above systems have only gained limited popularity – especially in comparison with
commercial systems like [1, 2, 3]. The latter systems have attracted a larger audience, up to several millions of
users. At the same time, it has to be stressed that the most widely deployed commercial systems cited above follow
a closed and proprietary design: this has motivated further research [16, 17, 18, 19, 20, 21, 22, 23, 24], aimed at
understanding these systems through on-field measurements.
Some works focus on single system, as [16, 17, 18]. Such works, which exploit partial reverse engineering
techniques and typically rely on active crawling methodologies, face the daunting task of understanding and
implementing part of the system under analysis. As a consequence this methodology is limited by the ability
to break closed and proprietary systems, and we believe that they can be hardly extended to characterize all the
possible P2P-TV applications. For example, [16] investigates PPLive, whereas [17] focuses on the commercial
re-engineer of Coolstreaming, and [18] considers UUSee. All these papers focus on complementary metrics with
respect to our work.
Other works, such as [19, 20] instead study specific aspects of a P2P streaming system. For instance, [19]
gives some preliminary results on the node degrees of popular versus unpopular channels in PPLive. Authors in
[20] instead investigate the stability of nodes in P2P live video streaming system, considering again PPLive, and
devising schemes to identify the most stable nodes in the system.
2Host Site CC AS Access Nat FW
1-4 BME HU AS1 high-bandwidth - -
5 ASx DSL 6/0.512 - -
1-9 PoliTO IT AS2 high-bandwidth - -
10 ASx DSL 4/0.384 - -
11-12 ASx DSL 8/0.384 Y -
1-4 MT HU AS3 high-bandwidth - -
1-4 ENST FR AS4 high-bandwidth - Y
5 ASx DSL 22/1.8 Y -
1-3 FFT FR AS5 high-bandwidth - -
1-8 WUT PL AS6 high-bandwidth - -
9 ASx CATV 6/0.512 - -
1-5 UniTN IT AS2 high-bandwidth - -
6-7 high-bandwidth Y -
8 ASx DSL 2.5/0.384 Y Y
Total
44 7(+7) 4 6(+7) 7
Table 2: Summary of the hosts, sites, Countries, Autonomous Systems and Access types of the peers involved in
the experiments.
Quality of service is of concern in [21, 22]. Authors in [21] exploit an analysis of PPLive buffer maps,
collected through protocol reverse engineering, to infer QoS metrics such as network-wide playback continuity,
startup latency, playback lags among peers, and chunk propagation timing. Authors in [22] focus on similar
metrics but instead exploit logs made available from an (unspecified) commercial P2P streaming system.
Despite all the above valuable work, to date, very few measurement works [23, 24] exist that compare different
systems. Authors in [23] analyze and compare PPLive and SOPCast, but results are reported mainly for PPLive,
investigating the time evolution of different metrics, like transmitted/received bytes, number of parents and chil-
dren, etc. Closest work to ours is [24], which presents a comparative evaluation of four commercial systems
(namely PPLive, PPStream, SOPCast and TVAnts). Authors compare these systems showing flow-level scatter
plots of mean packet size versus flow duration and data rate of the top-10 contributors versus the overall download
rate.
Our work differ from [24] in several aspects. The first is the aim, as our work focuses on a systematical
exploration of the metrics, if any, that drive the peer-selection in the different systems. Second, we consider
different aspects related to the overlay setup and download policies which are complementary to those addressed
in [24]. An important last difference lies on the scale of the testbed, which in our case involves multiple vantage
points scattered across European countries and it is representative of very different network setups.
3 Experimental Setup
The results of this paper are based on 4 different experiments performed in the context of NAPA-WINE Project,
a Seventh Framework Programme STREP project funded by the EU [9]. Partners took part in the experiments by
running P2P-TV clients on PCs connected either to the institution LAN, or to home networks. Table 2 summarizes
the experimental setup. A total number of 44 peers was involved in the experiments, including 37 PCs from 7
different industrial/academic sites, and 7 home PCs. Probes are distributed over four countries, and connected to 6
different Autonomous Systems. Home PCs are connected to 7 other ASs and ISPs. The different peers are further
representative of diverse environment (e.g., Campus LAN or DSL/CABLE connectivity, Public Addressing or
NAT access, presence of Firewalls, different PC configuration and OS version, etc.). All 44 PCs that were involved
in the experiments will be referred as “NAPA-WINE peers” in the following, while the terms “high-bandwidth”
and “low-bandwidth” will be used to distinguish Fast Ethernet or DSL/CABLE connected peers.
During the experiments, each PC ran the same P2P-TV application at the same time. PCs were synchronized
via a NTP, and Microsoft Windows scheduler service was used to automatically start the application and tune to the
selected channel. Each experiment lasted one hour during which packet-level traces were collected and later offline
31500 kbps 1500 kbps 2000 300 300 100 % 1500 kbps 1500 kbps 400 150 150 100 %
1 1
SopCast TVAnts
DSL DSL
0.8 0.8
0.6 0.6
0.4 0.4
0.2 0.2
0 0
Average
streaming
rate RX
Average
streaming
rate TX
Number of
contacted
peers
Number of
contributing
peers RX
Number of
contributing
peers TX
Failing
peers
Average
streaming
rate RX
Average
streaming
rate TX
Number of
contacted
peers
Number of
contributing
peers RX
Number of
contributing
peers TX
Failing
peers
1500 kbps 1500 kbps 20 000 150 150 100 % 1500 kbps 15 Mbps 40 000 3000 3000 100 %
1 1
PPLive PPLive Popular
DSL DSL
0.8 0.8
0.6 0.6
0.4 0.4
0.2 0.2
0 0
Average
streaming
rate RX
Average
streaming
rate TX
Number of
contacted
peers
Number of
contributing
peers RX
Number of
contributing
peers TX
Failing
peers
Average
streaming
rate RX
Average
streaming
rate TX
Number of
contacted
peers
Number of
contributing
peers RX
Number of
contributing
peers TX
Failing
peers
Figure 1: Global statistics collected during all the experiments.
analyzed. During each experiment, no other application was running on the participating computers, so that only
the P2P-TV client was generating network traffic. No packet sampling or loss occurred, and broadcast/multicast
packets were filtered out.
Here is a detailed description of the experiments reported in this paper:
• SopCast: this experiment started at 14:00-CET during April 4, 2008. SopCast was tuned to “CCTV-1”
channel during China peak hour. This corresponds to a popular channel watched during peak hours [16].
• TVAnts: this experiment started at 17:00-CET during April 4, 2008. TVAnts was tuned to “CCTV-1”
channel during China peak hour.
• PPLive: this experiment started at 18:30-CET during April 4, 2008. PPLive was tuned to “HebeiTV”
channel during off peak hour. This corresponds to an unpopular channel during China off-peak hour.
• PPLive-Popular: this experiment started at 14:30-CET during February 29, 2008. PPLive was used and
“CCTV-1” channel was selected during China peak hour.
In all cases, the nominal stream rate was 384kbps and Windows Media 9 Encoder was used. The whole dataset
corresponds to more than 160hours of experiments, corresponding to more than 189.000.000 collected packets.
Other experiments were locally organized by partners during different time periods and watching different
channels. In this paper, we show results referring only to the above selected set of experiments, since they are
the largest one and therefore the most representatives. Collected traces are also made available to the research
community from the Napa-wine website upon request.
4 Traffic Characterization and Geographical Distribution
Figure 1 gives some preliminary insights from collected data. The following simple metrics are reported for the
four experiments: i) average peer received data rate, ii) average peer transmitted data rate, iii) number of contacted
4peers, iv) number of RX contributing peers, i.e. peers from which some video segment has been received 1 , v)
number of TX contributing peers, i.e. peers to whom some video segment has been transmitted, and vi) percentage
of peers that have never replied to any message. The figure reports the individual values for every peer taking part
to experiment. In addition also the mean value (averaged over all the peers taking part to the experiment) is shown.
Crosses correspond to the high-bandwidth peers, while squares refer to the peers having low-bandwidth access
or being behind NAT or Firewall. To simplify the presentation of results values are normalized, trying to use the
same normalization factor whenever possible. The normalization factors are reported on the top of each plot.
The first and the second columns show the average inbound and outbound global data rate, including both
video and control traffic. As we can expect, on the reception side, apart from some peers who experienced
problems in receiving the streaming (these peers exhibit a very low incoming rate), little significant differences
can be observed among the peers, and among the different applications. This is due to the fact that the dominant
component of received traffic is provided by the video content whose average streaming rate is the same for all the
peers and applications (recall that all the considered applications adopt the same streaming encoding technique).
Considering PPLive experiments, some additional considerations hold: first, during the PPLive experiments, all
the PoliTO peers failed after 20’ due to a network outage. This caused local peers to keep sending packets
(possibly trying to reconnect to the service), but no incoming traffic could be received2 . Considering instead the
PPLive-Popular dataset, it can be seen that the receiver rate can be significantly higher than the stream rate. This
is due to the large incoming signaling traffic that a high bandwidth peers receives.
More interestingly, the data rate values on the transmission side are significantly more scattered. This is due to
the fact that the transmission data rates is strongly dependent on the specific mechanism adopted by each system
to distribute the video content. First, observe, that the transmission data rate is largely correlated to the upload
bandwidth of peers; all the applications are able to successfully identify high bandwidth peers, demanding to some
of them a significant contribution. High-bandwidth NAPA-WINE peers are therefore acting as “amplifiers”, i.e.,
they upload much more than what they download. All peers that are connected by CABLE/DSL, indeed show
much smaller upload rate. On this regard, observe that PPLive-Popular may result significantly demanding with
high bandwidth peers pushing their average transmission data rate to more than 10Mbit/s, with short time peaks
reaching 30Mbit/s (note the different normalization factor).
Huge difference among the different systems are observed when the number of contacted peers, i.e. the number
of peers that successfully exchanged at least one packet with the considered NAPA-WINE peer, is observed. The
number of contacted peers is the order of tens of thousands for PPLive (in both cases), up to one thousand for
SopCast, and in the order of few hundreds for TVAnts. Moreover, note that no significant differences in the
number of contacted peers between high bandwidth peers and DSL peers are observed. We believe that the huge
difference in the number of contacted peers is mainly due to the algorithms used to discover the topology. Further
insights will be given in the following.
The fourth and the fifth columns report the distribution of the number of RX contributing peers and TX
contributing peers, respectively. If we compare the number of contacted peers against the number of contributing
peers, we can see that TVAnts exploits the contacted peers at the highest degree, i.e., one third of the contacted
peers are also contributing peers. Considering SopCast, about 1/10 of the contacted peers are used to download
some content. Finally, in the PPLive and PPLive-Popular cases, the number of contacted peers is more than 2
order of magnitude higher than the number of contributing peers. Turning our attention to the number of TX
contributing peers, i.e., peers to which some content has been transmitted to, it can be observed that peers with
low upload bandwidth usually serve fewer other peers than peers with high bandwidth; this fact can be somehow
expected since low upload bandwidth peers have limited capability to make the data available to other peers.
The significantly large number of both contacted peers and contributing peers experienced by PPLive-Popular
peers explains why those peers exhibit an higher upload rate.
The last column shows the fraction of the peers which did not reply at all, i.e., failing peers. All systems show
a very high failing ratio (more than 10% on average, and peaks of 45%). This hints to little optimization on the
P2P-TV control plane, so that outdated information is still distributed in the overlay. Moreover, we noticed that in
all experiments, local peers tried to contact peers with private IP address.
Figure 2 shows the geographical distribution of the number of contacted peers (#) and the amount of received
and transmitted bytes (labeled TX and RX respectively). The labels on the bars refer to China (CN) and the four
countries in which experiments were performed. “OTH” refers to the rest of the World. The total number of
1 Peer i is a “RX contributing” peer for j if the number of j → i packets that take the exact value of the typical data packet length is larger
than a threshold M = 5. Similarly, j is a TX contributing peer for i if the number of typical data-length packers from i → j id larger than
M . We verified that this heuristic gives accurate and conservative results in [25].
2 These failing peers were removed from the calculus of the average rate.
5100 OTH OTH OTH OTH
PL
OTH OTH OTH OTH
PL OTH
OTH PL PL
FR FR PL
IT
80 FR FR
HU OTH PL
IT
IT
IT FR
60 HU IT FR
IT
CN CN
IT CN
HU IT
40 CN HU
CN HU CN
CN HU
HU
20 CN
CN
CN
CN CN
0
# RX TX # RX TX # RX TX # RX TX
SopCast TVAnts PPLive PPLive Popular
Figure 2: Geographical distribution of the peers, the received and the transmitted bytes.
observed peers is 4057 for SopCast, 550 for TVAnts, 93878 for PPLive and 181729 for PPLive-Popular. This
huge difference may stem from both a different number of peers using each system, and more likely from differ-
ent policies adopted in the overlay discovery algorithm (as we will show later on). Considering distribution of
contacted peers, it is not surprising that the majority of the contacted peers are in China for all applications. But
while in the PPLive experiments (in which the population of contacted peers contain tens of thousands peers) less
than 5% of peers are outside China, in the cases of SopCast and TVAnts more than 35% and 60% of peers are
actually outside China respectively. In the case of TVAnts for example, it is surprising that a significant fraction
of the 550 contacted peers are actually located in the country in which our peers were located. We believe that
TVAnts implements a peer selection policy that limits the number of contacted peers by carefully selecting with
high probability those within the same country the local peer belongs to (see also Fig. 1). This apparently is
not enforced in by PPLive and SopCast, in which case a more “random-like” peer selection policy seems to be
implemented, leading to a peer geographical distribution that matches the actual worldwide peer distribution.
Considering the geographical distribution of uploaded and downloaded data, we observe that a SopCast peer
downloads data mostly from China, but some data are actually downloaded from other NAPA-WINE peers; how
it will become clearer in the following. In TVAnts, about 70% of traffic is exchanged among NAPA-WINE peers,
even if they account only to less than 10% of contacted peers. Finally, this bias is even more marked considering
PPLive experiment, during which 80% of traffic is exchanged among NAPA-WINE peers, while they only account
for a very marginal percentage of contacted peers! The previous bias toward NAPA-WINE peers (and as a result
their countries) can be the outcome of either a mechanism that efficiently exploits peer locality while selecting the
contributing peers (note that several NAPA-WINE peers lies within the same LAN), or of a mechanism that favors
the download from high-bandwidth peers (we remind that most of the NAPA-WINE peers are high bandwidth
peers). In the following we will better explore these issues. Finally, considering the PPLive-Popular experiment,
the bias versus the NAPA-WINE peers is still present, but much less evident. This effect can be explained by
the fact that, being the total number of active peers in the system much higher (recall, this experiment consider a
very popular channel during peak hour), the number of possibly high bandwidth/relatively close peers from which
downloading the video stream is higher too.
5 Peer Selection Analysis
5.1 Dynamics of Contacted Peers
To better understand the peer selection process, Figures 3 plot the dynamics of the contacted peers over time.
One arbitrary NAPA-WINE peer is represented in each figure, since they are qualitatively all similar. For PPLive-
Popular, the behavior of both high-bandwidth and DSL nodes are reported. The continuous line refers to the total
number of contacted peers over time, while the squared dots and crosses refer to the arrival and departure time
of video contributing (RX contributing) peers, i.e., the time of the first and last observed packet from a video
contributing peer. For PPLive , the total number of contacted peers is separately reported since it is a two order
6400
140 All TVAnts
350 Contributing Birth
120 Contributing Death
300
SopCast All 100
250 Contributing Birth 80
Contributing Death
Peer ID
Peer ID
200 60
150 40
100 20
50 0
0 -20
-50 -40
0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500
Time [s] Time [s]
2500
140 PPLive
All PPLive
120 Contributing Birth 2000 All Birth
Contributing Death All Death
100
1500
80
Peer ID
Peer ID
60 1000
40
500
20
0 0
-20 -500
-40
0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500
Time [s] Time [s]
400 400
PPLive Popular - DSL node PPLive Popular - Fast Ethernet node
All All
300 Contributing Birth 300 Contributing Birth
Contributing Death Contributing Death
200 200
Peer ID
Peer ID
100 100
0 0
-100 -100
-200 -200
0 500 1000 1500 2000 2500 3000 3500 0 500 1000 1500 2000 2500 3000 3500
Time [s] Time [s]
Figure 3: Arrival and Departure process of the all and video contributing peers.
of magnitude larger than other quantities. Positive y-axis reports the peers contacted first, while negative y-axis
reports peers that first contacted the NAPA-WINE peer.
As already observed in Fig. 1, with the exception of PPLive-Popular, in all the other three cases the number
of contributing peers is limited to few tens. In addition, the set of contributing peers is rather stable along the
whole experiment duration, i.e., the contributing peer contact time lasts several tens of minutes. In the case of
PPLive-Popular, on the contrary, the number of contributing peers is much higher (several hundreds, up to one
thousand) and it exhibits a higher degree of variability. This can be explained considering the fact that the number
of possibly good candidates to become a contributing peer is higher in this experiment, and the peer selection
policy continuously tries to improve performance testing new contribution peers. No major difference is shown
between DSL or high bandwidth nodes, except that the number of peers that first contacted the high-bandwidth
peer is larger than the one that contacts the DSL node. This suggests that the information about the peer upload
capacity is made available to other peers by gossiping algorithms. The plots also show the different total rates at
which new peers are contacted (solid lines). Both TVAnts and SopCast limit this rate as soon as a good set of
contributing peers is obtained (after about 250s and 500s respectively). On the contrary, PPLive has a stronger
greedy behavior essentially contacting new peers at an almost constant rate. These different overlay exploration
71
0.8
0.6
CDF
0.4
SOPCAST
0.2 TVANTS
PPLIVE
PPLIVEPOPULAR
0
0 5 10 15 20 25 30 35 40
Number of peers
Figure 4: CDF of common contributing peers.
algorithms clearly drive the total number of contacted peers, which is then much higher for PPLive. Notice that
the PPLive peer contact time is in general very small except for contributing peers.
Figure 4 shows the Cumulative Distribution Function (CDF) of the common contributing peers, i.e., the prob-
ability that a contributing peer is seen by N different NAPA-WINE peers. In case a random i.i.d selection is
performed, the common peers CDF follows a Binomial distribution. On the contrary, in case of correlated choice,
a different trend is expected, e.g., a more linear CDF. The Figure 4 therefore clearly shows that for all the ex-
periments, with the exception of PPLive-Popular the selection of peers from which to download is performed
according to some algorithm that tends to correlate this choice. Indeed, note that there are a bunch of peers that
have been selected as contributing peers by most of the NAPA-WINE peers. In case PPLive-Popular, the larger
set of possibly good candidates makes the choices at several peers to look apparently more uncorrelated.
5.2 Bandwidth Preference
Given that all applications clearly show a not random peer selection policy, we further investigate on possible pa-
rameters that impact this choice. At first, we are interested to observe if the information about available bandwidth
on the download path is exploited. Since it is impossible to accurately estimate this index [25], we use the min-
imum Inter Packet Gap (IPG) to coarsely classify peers as high-bandwidth or low-bandwidth peers. Indeed, the
minimum IPG is inversely proportional to the packet transmission time on the bottleneck link. Figure 5 shows the
scattered plots of the amount of downloaded data versus the minimum IPG considering all high-bandwidth NAPA-
WINE peers. Log/log scale is used to better highlight results, and video contributing peers are reported using large
dots. The plots clearly show that the observed minimum IPG allows to easily identify low-bandwidth peers (i.e.,
IPG larger than 0.1ms, corresponding to DSL/CABLE upstream bandwidth range) and high-bandwidth peers (i.e.,
IPG smaller than 0.01ms, corresponding to much larger bottleneck capacity). Given this coarse classification, the
scattered plots clearly shows that all applications largely prefer to download video from high-bandwidth peers.
Indeed, in all cases more than an astonishing 98% of data is downloaded from high-bandwidth peers only.
5.3 Locality Preference
To assess whether the considered systems exploit locality information while selecting peers from which download
data, Figure 6 reports the CDF of contacted peers (solid line) and of the received bytes (dashed line) versus the
distance between peers in hop count3 . While SopCast seems to completely ignore peer distance, both TVAnts and
PPLive seem clearly to favor local peers. This effect is rather strong especially in TVAnts, where 18% of traffic is
received by peers within the same LAN (even if the number of such peers is negligible compared to the peer set).
Moreover, TVAnts and PPLive show a higher probability to download data from closer peers than from far away
peers, e.g., no data is received from peers that are further than 25 hops.
To better explore the issue related to peer locality, Figure 7 shows the average amount of traffic transferred
from a high bandwidth NAPA-WINE peer belonging to AS-i to a high bandwidth NAPA-WINE peer within AS-j,
3 The hop count has been evaluated as 128 minus the TTL of received packets, since 128 is the most commonly adopted initial TTL. Clearly
wrong hop counts have been filter out. See [25].
81e+08 1e+08
SopCast TVAnts
1e+07 All 1e+07 All
Contributor Contributor
1e+06 1e+06
Bytes RX
Bytes RX
100000 100000
10000 10000
1000 1000
1e-06 1e-05 0.0001 0.001 0.01 0.1 1e-06 1e-05 0.0001 0.001 0.01 0.1
IPG IPG
1e+08 1e+08
PPLive PPLive Popular
1e+07 All 1e+07 All
Contributor Contributor
1e+06 1e+06
Bytes RX
Bytes RX
100000 100000
10000 10000
1000 1000
1e-06 1e-05 0.0001 0.001 0.01 0.1 1e-06 1e-05 0.0001 0.001 0.01 0.1
IPG IPG
Figure 5: Scattered plot of the amount of received bytes versus the minimum IPG.
for all the AS pairs. The intra-AS traffic is enlightened in black.
At a first look, only the PPLive-Popular experiment clearly suggests that the system favors intra-AS traffic
over inter AS-traffic. However, we notice that most of the intra-AS traffic is in this case local traffic (hop count
equal to zero). To a better look, also TVAnts presents some bias in favor intra-AS traffic. Indeed, the ratio between
the average amount traffic exchanged among intra-AS peers (reported in black) versus inter-AS peers (reported
in gray) R is equal to 1.93, i.e., about twice the traffic is exchanged among peers within the same AS compared
to peers in other ASs. Moreover the contribution provided by non local traffic is significant in this case. Neither
SopCast nor PPLive show such bias, being R = 0.2 and R = 0.98 respectively.
Thus, we conclude that both SopCast and PPLive do not tend to favor traffic exchange within the same AS
(excluding the traffic exchanged among peers in the same SubNet). As already noted in Figure 2, however, intra
high-bandwidth NAPA-WINE traffic is significant. This strong bias exhibited by intra high-bandwidth NAPA-
WINE peers confirms that both applications tend to only favor downloading traffic from high-bandwidth peers
(as shown in Fig. 5). In the case of PPLive-Popular, we expect that NAPA-WINE peers constitute only a small
fraction of high-bandwidth peers, thus justifying the fact that most of the traffic comes from outside; for the other
experiments, we have the suspect that NAPA-WINE peers represent a significant fraction of high bandwidth peers
connected to the system, and thus are chosen to serve other peers with a relatively high probability.
In conclusion from results shown in Figures 5, 6 and 7, it turns out that for all the systems, the peer up-
load bandwidth seems to be the dominant metric that drives the selection of the peers from which downloading.
However PPLive and especially TVAnts exploits also some form of locality while in SopCast the choices seem
completely independent on the peers location.
5.4 Incentive mechanisms
Finally, we explore if the considered systems implement some sort of incentive mechanism to favor collaboration
between two peers that are exchanging data. In particular, considering P2P based content delivery applications,
incentives mechanisms have been successfully introduced to improve system performance, e.g., BitTorrent clients
play a tit-for-tat game with data rate. Figure 8 reports the amount of transmitted versus received bytes considering
91 1
0.9 SopCast 0.9 TVAnts
0.8 Peers 0.8 Peers
bytes bytes
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
0 5 10 15 20 25 30 35 0 5 10 15 20 25 30 35
Hop Number Hop Number
1 1
0.9 PPLive 0.9 PPLive Popular
0.8 Peers 0.8 Peers
bytes bytes
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
0 5 10 15 20 25 30 35 0 5 10 15 20 25 30 35
Hop Number Hop Number
Figure 6: CDF of the number of peers and the amount of received data versus the number of hops.
the contributing peers seen from all the NAPA-WINE peers. Log/log scale is used to better represent results.
Intuitively, if a tit-for-tat like incentive mechanism were implemented, then a strong correlation should be observed
resulting in a points accumulation along the y = x diagonal. Looking at Figure 8, this trend is clearly not
observable. On the contrary, some information on the overlay structure arises. For all applications it is possible
to observe that points are preferentially distributed along two parallel lines, corresponding to two different upload
versus download ratios. For example, looking at the TVAnts plot, points accumulate along the y = 10x and
y = 1/10x lines. The two lines correspond set of peers that mostly download data from a NAPA-WINE peer, and
peers that mostly upload data to one NAPA-WINE peer. Similarly, in the PPLive-Popular experiment, since the
NAPA-WINE peers are acting as amplifiers, a large amount of points accumulate on the y = 0.03x line, i.e., much
more data are sent than received. Therefore, from these Figures, there is no evidence of a symmetric tit-for-tat like
incentive.
6 Conclusions
An extensive set of measurements collected in several countries and involving a large and heterogeneous set
of nodes have been presented to characterize some of the most popular P2P-TV applications, namely, PPLive,
SopCast and TVAnts. We investigated the properties of the algorithms driving the peer-to-peer data exchange; i)
the bias with respect to the peer bandwidth, ii) the exploitation of peer locality information, and iii) the presence
of incentive mechanisms that govern the data exchange. Results show that, for all applications, data are mostly
downloaded from high-bandwidth peers (as intuitively expected). Only TVAnts and partly PPLive exploit some
form of peer locality information to reduce network load.
Considering the P2P overlay discovery mechanisms, PPLive implements a very greedy policy according to
which the number of contacted peers linearly increases over time, while both SopCast and TVAnts limits the rate
at which new peers are contacted after the initial bootstrap.
From our results, TVAnts appears to be the best engineered system, able to quickly find high-bandwidth and
networks-wide close peers from which downloading the stream. SopCast on the contrary, seems to implement a
more random-like peer selection policy, and, at last, PPLive shares some characteristics of TVAnts, but is much
10Figure 7: Average amount of exchanged data among the ASs involved in the experiments.
more aggressive while exploring the P2P overlay.
Acknowledgments
This work has been funded by the European Commission under that 7th Framework Programme Small or Medium-
Scale Focused Research Project (STREP) “Network-Aware P2P-TV Application over Wise Networks” (NAPA-
WINE). We would like to thank all partners that took part in the experiment for the valuable contribution to collect
the data set.
References
[1] PPLive, http://www.pplive.com.
[2] SOPCast, http://www.sopcast.com.
[3] TVAnts, http://www.tvants.com.
[4] G. Huang, “Experiences with PPLive”, Sigcomm 2007 Peer-to-Peer Streaming and IP-TV Workshop (P2P-
TV), Kyoto, JP, August 2007.
[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] “Network-Aware P2P-TV Application over Wise Networks ”, http://www.napa-wine.eu.
111e+08 1e+08
SopCast TVAnts
1e+07 1e+07
1e+06 1e+06
Bytes RX
Bytes RX
100000 100000
10000 10000
1000 1000
1000 10000 100000 1e+06 1e+07 1e+08 1000 10000 100000 1e+06 1e+07 1e+08
Bytes TX Bytes TX
1e+08 1e+08
PPLive PPLive Popular
1e+07 1e+07
1e+06 1e+06
Bytes RX
Bytes RX
100000 100000
10000 10000
1000 1000
1000 10000 100000 1e+06 1e+07 1e+08 1000 10000 100000 1e+06 1e+07 1e+08
Bytes TX Bytes TX
Figure 8: Scattered plot of the amount of received versus transmitted bytes considering contributing peers.
[10] Yang-Hua Chu, Sanjay G. Rao, S. Seshan, H. Zhang, “Enabling conferencing applications on the internet
using an overlay multicast architecture,” ACM SIGCOMM, San Diego, CA, Aug. 2001.
[11] S. Banerjee, B. Bhattacharjee, C. Kommareddy, “Scalable application layer multicast,” ACM SIGCOMM,
Pittsburgh, PA, 2002.
[12] V.N. Padmanabhan, H.J. Wang, P.A. Chou, K. Sripanidkulchai, “Distributing streaming media content using
cooperative networking,” ACM NOSSDAV’02, Miami, FL, May 2002.
[13] M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Rowstron, A. Singh, “SplitStream: High-bandwidth
multicast in a cooperative environment,” ACM SOSP’03, Lake Bolton, NY, Oct., 2003.
[14] X. Zhang, J. Liu, B. Li, T.-S.P. Yum, “DONet/CoolStreaming: A data-driven overlay network for peer-to-
peer live media streaming,” IEEE INFOCOM 2005, Miami, FL, Mar. 2005.
[15] R. Rejaie, A. Ortega, “PALS: Peer-to-Peer Adaptive Layered Streaming,” ACM NOSSDAV’03, Monterey,
CA, June 2003.
[16] X. Hei, C. Liang, J. Liang, Y. Liu, K.W. Ross, “A Measurement Study of a Large-Scale P2P IPTV System,”
IEEE Transactions on Multimedia, Vol.9, No.8, pp.1672-1687, Dec. 2007.
[17] B. Li, Y. Qu, Y. Keung, S. Xie, C. Lin, J. Liu, X. Zhang, “Inside the New Coolstreaming: Principles,
Measurements and Performance Implications”, IEEE INFOCOM’08, Phoenix, AZ, Apr. 2008.
[18] C. Wu, B. Li, S. Zhao, “Multi-channel Live P2P Streaming: Refocusing on Servers” IEEE INFOCOM’08,
Phoenix, AZ, Apr. 2008.
[19] L. Vu, I. Gupta, J. Liang, K. Nahrstedt, “Measurement of a large-scale overlay for multimedia streaming”
Proc. of the 16th International Symposium on High Performance Distributed Computing,, Monterey, CA,
June 2007.
12[20] F. Wang, J. Liu, Y. Xiong, “Stable Peers: Existence, Importance, and Application in Peer-to-Peer Live Video
Streaming” IEEE Infocom’08, Phoenix, AZ, Apr. 2008.
[21] X. Hei, Y. Liu, K.W. Ross, “Inferring Network-Wide Quality in P2P Live Streaming Systems,” IEEE JSAC,
special issue on P2P Streaming, Vol.25, No.9, pp.1640-1654, Dec. 2007.
[22] S. Agarwal, J. P. Singh, A. Mavlankar, P. Baccichet, and B. Girod, “Performance and Quality-of-Service
Analysis of a Live P2P Video Multicast Session on the Internet,” IEEE IwQoS’08, Enschede, NL, June 2008.
[23] S.Ali, A.Mathur, H.Zhang, “Measurements of Commercial Peer-To-Peer Live Video Streaming,” In Proc. of
Workshop on Recent Advances in Peer-to-Peer Streaming, Waterloo, ON, Aug. 2006.
[24] T. Silverston, O. Fourmaux, “Measuring P2P IPTV Systems,” ACM NOSSDAV’07, Urbana-Champaign, IL,
June 2007.
[25] D.Ciullo, M.A. Garcia, A. Horvath, P. Veglia, ‘Characterization of P2P-TV traffic,” NAPA-WINE technical
Report WP3.1n1. http://www.napa-wine.eu/
13You can also read
