Measuring P2P IPTV Systems

Thomas Silverston, Olivier Fourmaux

To cite this version:

Thomas Silverston, Olivier Fourmaux. Measuring P2P IPTV Systems. ACM NOSSDAV’07 - Network
and Operating Systems Support for Digital Audio & Video, Jun 2007, Urbana-Champaign, United
States. �hal-01311839�

HAL Id: hal-01311839

https://hal.science/hal-01311839
Submitted on 26 Oct 2022

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.

Distributed under a Creative Commons Attribution - NonCommercial| 4.0 International

License
 Measuring P2P IPTV Systems

Thomas Silverston Olivier Fourmaux

Université Pierre et Marie Curie - Paris 6 Université Pierre et Marie Curie - Paris 6
Laboratoire LIP6/CNRS, UMR 7606 Laboratoire LIP6/CNRS, UMR 7606
104 avenue du président Kennedy 104 avenue du président Kennedy
75016 Paris, France 75016 Paris, France
[email protected] [email protected]

lected. Through these analyses, we highlight design similar-

ABSTRACT ities and differences and point out global behavior in these
P2P IPTV systems start to be very popular on the Inter- P2P networks.
net. Measuring the impact they have on the network and During the 2006 FIFA World Cup, we measured network
understanding their behavior is an important field. Avail- traffic generated by several P2P IPTV applications. We
able applications are based on proprietary solutions, thus collected packet traces by using the following applications:
traffic analysis is the only feasible way to identify the mech- PPLive [2], PPStream [3], SOPCast [4] and TVAnts [5]. We
anisms used to get video streams. In this context, during chose these applications because they are the most popu-
the 2006 FIFA World Cup, we performed an extensive mea- lar on the Internet. We focused on collecting traffic during
surement campaign. During this worldwide event, we mea- World Cup because it is a large-scale event, which exhibits
sured network traffic generated by the most common P2P a live interest for the users. Thanks to all the collected
IPTV applications, namely PPLive, PPStream, SOPCast, data, we obtained a representative sample of large-scale P2P
an TVAnts. Our observations show that all these appli- IPTV applications. Our work differs from Hei [6] by the
cations generate different traffic patterns and use different number of applications we studied and the followed com-
underlying mechanisms. Each application has its own down- parative approach. To the best of our knowledge, this is the
load policy and maintains a different set of peers. From the first study, which focuses on a large-scale live event broad-
traces we collected, we extract several statistics, which help casted on P2P networks.
in having a better understanding of the behavior of P2P Results in this study focus on a single event day where two
IPTV systems. soccer games were scheduled and we analyzed the traffic gen-
erated by the four previously mentioned P2P applications.
We limit the scope of our analysis to these traces since we
1. INTRODUCTION noticed their representativeness of our data set. Our re-
The success of P2P file sharing and VoIP applications has sults show that all the applications generate different traffic
proved that the P2P paradigm is an efficient solution to de- patterns. The measured download traffic indicates that the
liver all kinds of content over the Internet. Nowadays, there applications use different mechanisms to get the video and
are P2P video live streaming applications (P2P IPTV) that they maintain a different peers neighborhood.
have been successfully deployed on the Internet. These ap- The remainder of this paper is organized as follows. In Sec-
plications are proprietary and claim to be swarming protocol tion 2 we present the related work. In Section 3 we describe
like Donet [1]. In these P2P systems, data are divided into our measurement experiment set-up. Then in Section 4 we
chunks and each peer exchanges with other peers informa- present and discuss the measurement results. We conclude
tion about the chunks they have. Then each peer is able and expand our future work in section 5.
to download data chunks from several peers concurrently.
However, the exact way of working of these emerging appli-
cations is still widely unknown. In this context, it is impor- 2. RELATED WORK
tant to evaluate the traffic impact of these P2P applications Measuring P2P live streaming systems is still an emerging
on the Internet. Even though lots of measurement studies topic, but there are previous measurement studies about live
have been conducted on P2P file sharing and telephony sys- streaming media delivered on the Internet. Sripanidkulchai
tems, very few tackled P2P IPTV. et al. [7] show that large-scale live streaming can be sup-
In this paper, we make comparisons between different ap- ported by P2P end-users applications despite the heteroge-
plications by analyzing the different traffic patterns we col- neous capacity of peers. In P2P IPTV systems, Zhang et
al. [8] present their own P2P IPTV system and give network
statistics like users’ behavior in the whole system and the
quality of video reception. Hei et al. [6] have a similar work
to ours. They study an existing P2P IPTV application by
collecting packet traces. Our work is different from theirs
since we do not focus on a single application but on several
applications. It helps us to highlight design differences and
to infer global behavior of such P2P network without being
strongly related to a single P2P system implementation. We

1
 TCPDUMP Table 1: Packet traces summary
PPLive PPStream SOPCast TVAnts
100 Mbps
Duration(s) 13 321 12 375 12 198 13 358
Internet
100 Mbps
Size(MB) 6 339 4 121 5 475 3 992
Download(%) 14.11 20.50 16.13 24.76
TCP 14.09 20.50 0.23 14.71
TCPDUMP
UDP 0.02 0 15.90 10.05
Campus Network
Upload(%) 85.89 79.50 83.87 75.24
TCP 85.81 79.50 3.89 61.67
Figure 1: Measurement experiment platform. Each UDP 0.08 0 79.98 13.57
node is a common PC directly connected to the In-
ternet via campus network

3
Upload
collected a larger and more various data set from a repre- Download
sentative panel of applications during an entire large-scale 2.5
event. Finally, an important distinction between Hei works
and ours come from the live interest of the measured event.

Throughput (Mbps)
2
It is intuitive but corroborated by Veloso et al. [9] that traffic
patterns have not the same characteristics whether broad-
1.5
casted content exhibits a live interest for users or not.
1
3. EXPERIMENT SETUP
Our measurements started with the 2006 FIFA World Cup 0.5
from June 2nd to July 9th. We collected a huge amount of
data, measuring most of the World Cup games with differ-
0
ent applications at the same time, under two different net- 0 50 100 150 200
work environments (campus Ethernet access and residential Time (minutes)
ADSL access). In this paper we focus on comparisons be-
tween four P2P IPTV applications according to their traffic Figure 2: Example of total download and upload
pattern. In all our data, we selected packet traces on June 30 throughput for TVAnts. All the applications have
because they are well representative of all of them. Two soc- the same throughput pattern.
cer games were scheduled: one in the afternoon (Germany
vs. Argentine) and one in the evening (Italy vs. Ukraine).
Fig. 1 describes our measurement experiment platform. We 3.1 Data Collection Methodology
used two personal computers (PCs) with 1,8 GHz CPU, and
We differentiate TCP sessions according to TCP Flags
common graphic capabilities. For the rest of this paper, the
and we only take a session into consideration if at least one
PCs will be called nodes. Operating system was Windows XP
of its TCP segment has a payload. Session durations are
because all the applications have been implemented for this
driven by TCP segment payload. A session start time was
OS. The two nodes were situated in our campus network
calculated as soon as we received (or sent) a TCP segment
and were directly connected to the Internet with 100 Mbps
with a data payload. The session duration was increased for
Ethernet access. We used tcpdump to collect the packets
each new TCP segment with a payload. A session ended
and their payload generated by the applications. During
when we received an explicit flag, but the end session time
each game, the nodes were running tcpdump and a distinct
was the instant where we received the last TCP segment
P2P application. The Ethernet cards did not suffer any
with payload. The session duration depends only on TCP
packet loss and captured all the packets. All the measure-
segment with payload. We compute session duration relying
ments have been done watching CCTV5, a Chinese sport
on UDP in the same payload-driven way.
channel available for all the measured applications. All the
applications used MPEG4 video encoding. We did not mea-
sure the traffic between the two consecutive games. From 4. MEASUREMENT ANALYSIS
the first game to the second one, we only changed the run- In this section, we show the results of our measurement
ning P2P applications on the nodes to get packet traces from study. We first analyze the traffic of all the applications.
different application. At the end of the experiments, we col- Then, we point out the download policies used by the ap-
lected four packet traces: one per application. We chose to plications to get the video and the peers neighborhood they
measure the first game by running PPStream and SOPCast maintain. Finally, we show the video peers lifetime for all
on the nodes, and the second one by running PPLive and the applications.
TVAnts. Collected packets can only provide from a node or
from remote peers in the Internet. Table 1 summarizes the 4.1 General Observations
four collected traces. Table 1 shows that PPStream relies only on TCP. Ma-
The two measured events are similar (a soccer game in jor part of PPLive traffic relies on TCP whereas SOPCast
the FIFA world cup) and exhibit the same live interest for traffic relies mostly on UDP. TVAnts is more balanced be-
users. We analyzed our packet traces by developing our own tween TCP and UDP. All the applications have download
perl parsing tools. throughput quiet constant and slightly above the video bi-

2
Table 2: Observations Summary for Traffic Patterns Table 3: Signaling overhead
PPLive PPStream SOPCast TVAnts
PPLive PPStream SOPCast TVAnts Signaling overhead 4.1% 13.6% 19.3% 10.2%
Video TCP TCP UDP TCP ratio
a few TCP UDP
Signaling TCP TCP UDP TCP
a few UDP a few TCP UDP transported by TCP, which is not a transport protocol ded-
icated for multimedia and real-time applications. As for
common Internet video streaming applications, TCP could
trate while upload fluctuates largely and at a higher rate. be justified to reach all kind of Internet users, even if there
As an example, Fig. 2 shows the total download and upload are behind filtering or NAT systems.
throughput for TVAnts. The plots for all the other appli-
cations can be found in [10]. These results were expected To evaluate the amount of signaling traffic overhead in
because the nodes attempt to download video at a constant the traces, we separated video and signaling traffic with an
bitrate and they have wide upload capacities. heuristic proposed in [6]. The heuristic works as follows:
for a session (same IP addresses and ports), we counted the
4.2 Traffic Patterns number of packet bigger or equal than 1000 Bytes1 . If a ses-
sion had at least 10 large packets, then it was labeled as a
These P2P applications are proprietary but claim to use
video session and we removed small packets (< 1000 Bytes)
swarming mechanisms where peers exchange information
from this session. We removed all non-video sessions from
about data chunks and neighbor peers as in Donet ([1]).
the traces. Table 3 presents the results of this heuristic for
In such P2P network, a peer will iteratively discover other
the four traces. The signaling overhead ratio is different for
peers and would establish new signaling or video sessions.
all the traces (from 4.1% to 19.3%). SOPCast overhead is
Video sessions are likely to have long duration because users
more important than the other and PPLive has the lower
want to watch the entire game whereas signaling sessions are
signaling overhead. PPStream and TVAnts have almost
likely to be shorter in time. Furthermore, video streaming
the same signaling overhead ratio. PPLive and PPStream
packets size is expected to be large and signaling session
have similar traffic patterns, but at the end, the signaling
packets size is supposed to be common. Fig. 3 plots the av-
overhead needed to manage the P2P network is different.
erage packet size according to the session duration using a
PPLive and PPStream should not use the same underlying
log-log scale. PPLive (Fig. 3(a)) and PPStream (Fig. 3(b))
mechanisms. PPStream and TVAnts have a similar over-
have similar TCP traffic patterns but PPLive uses UDP
head ratio but present different traffic patterns. Their un-
too. PPLive UDP sessions vary from short to long duration,
derlying mechanisms should also be different, as SOPCast,
but their average packet size is small and constant. PPLive
which has the more important signaling overhead ratio and
UDP traffic transports signaling sessions. PPLive and PP-
a specific traffic pattern. In the next sections, we give some
Stream exhibit two clusters in their TCP traffic patterns:
insights about underlying mechanisms used by all the pre-
the one in the middle of the plot is for signaling sessions
sented applications.
(small packets and short session duration) and the one in
the right top of the plot is for video sessions (large packet 4.3 Video Download Policies
and long session duration). PPLive and PPStream use TCP
In this section, our goal is to understand how our nodes
to transport video and signaling traffics. We are still inves-
download the video among the other peers on the Internet.
tigating the difference between signaling sessions relying on
For each trace, we computed the amount of data that our
UDP or TCP for PPLive. Regarding SOPCast traffic pat-
nodes downloaded from each of the other peers. We iso-
tern (Fig. 3(c)), we observe that it uses almost exclusively
lated the ten top peers traffic (peers which sent the biggest
UDP. We can still observe clusters in the middle (signaling)
amount of data to our nodes across the entire trace dura-
and on the right top (video) of the plot but they are not
tion). We isolated the top peer traffic in the same way (top
so clearly formed. SOPCast transports both signaling and
peer belongs to top ten peers). In Fig. 4, we plot the total
video traffic on UDP. We currently have finer analysis to
download traffic, the aggregate top ten peers and the top
understand why there are very few sessions relying on TCP.
peers download traffic. Each plotted value is a 60 seconds
Compare to the other measured applications, TVAnts traffic
average interval (bin duration is 60s).
pattern shows a balanced use of TCP and UDP (Fig. 3(d)).
SOPCast (Fig. 4(c)) received no traffic from minutes 130 to
We can distinguish signaling and video clusters but they
minutes 140 and we watched a black screen during this pe-
both contain TCP and UDP traffic. TVAnts transports sig-
riod. The problem did not occur for network reasons because
naling and video sessions both on TCP or UDP. However,
PPStream was working well during the same period. The
most part of TVAnts traffic is transported by TCP (≈ 75%,
video source has probably suffered technical problem during
table 1).
this period. All our SOPCast traces showed this kind of
Table 2 summarizes our observations from Fig 3: all the
trouble and we keep them for our study.
measured applications have different traffic patterns. PP-
The download policies for all the applications are totally dif-
Stream uses only TCP for video and signaling traffic while
ferent because aggregate top ten peers or top peer traffic do
PPLive adds UDP for some signaling traffic whereas TVAnts
not exhibit the same behavior. For PPLive (Fig. 4(a)), the
uses both TCP and UDP for all kind of traffic and SOPCast
top ten peers contribute to a major part of the download
uses almost entirely UDP. This is an important difference
between all the applications. If we take into account all 1
1000 Bytes instead of the 1200 Bytes proposed by the
the applications, we observe that the video traffic is mostly heuristic because it fitted better our traces

3
 1000 TCP 1000 TCP
UDP
Average packet size (Bytes)

Average packet size (Bytes)

100 100

10 10

1 1
0.0001 0.001 0.01 0.1 1 10 100 1000 10000 0.0001 0.001 0.01 0.1 1 10 100 1000 10000
Time (seconds) Time (seconds)
(a) PPLive (b) PPStream

1000 TCP 1000 TCP

UDP UDP
Average packet size (Bytes)

Average packet size (Bytes)

100 100

10 10

1 1
0.0001 0.001 0.01 0.1 1 10 100 1000 10000 0.0001 0.001 0.01 0.1 1 10 100 1000 10000
Time (seconds) Time (seconds)
(c) SOPCast (d) TVAnts

Figure 3: Average packet size according to peers session duration

traffic and the top peer contributes to almost all the traffic amount of the total traffic (like PPStream). TVAnts top
during its session duration. The top peer session is quiet peer does not contribute as few as PPStream’s one but does
short regarding all the trace duration. These observations not stay as long as PPStream top peer.
suggest that PPLive gets the video from only a few peers If we summarize our observations, the presented applica-
at the same time and switches periodically from a peer to tions implement different download policies and do not ex-
another one. Remember PPLive and PPStream have almost pect peers to have the same capabilities. Some download
the same traffic pattern (Fig. 3(a) 3(b)), it is interesting to policies expect peers to stay in the network for a long time
observe that PPStream download policy is the PPLive op- (like PPStream) or short time (PPLive, SOPCast), or ex-
posite. For PPStream (Fig. 4(b)) the top ten peers do not pect a peer to have huge capacities to send all the video
contribute to a large part of the download traffic and nei- (PPLive) or low (PPStream,TVAnts). According to the ap-
ther the top peer. PPStream has to get the data from many plication, a peer can get the video from only a few peers at
peers at the same time and its peers have long session dura- the same time or from many peers and its session duration
tion. SOPCast top ten peers (Fig. 4(c)) contribute to about is various. Different download policies highlight differences
half the total download traffic and top peer contributes to to maintain a neighborhood for a peer to get the video. This
all the top ten peers traffic during its session duration. In a will be point out in the next section.
way, SOPCast download policy looks like PPLive policy: it
switches periodically from provider peer. However, SOP- 4.4 Peers Neighborhood
Cast seems to always need more than a peer to get the In swarming P2P systems, peers have to maintain peers
video compare to PPLive where a single peer could be the neighborhood to get the data chunks from several peers
only video provider. TVAnts download policy (Fig. 4(d)) at the same time. In Fig. 5, we plot for each application
seems to mix PPStream and SOPCast policies. TVAnts top the video download peers neighborhood maintained by our
ten peers contribute to about half the total download traffic nodes during all the traces duration. A video download peer
(like SOPCast), but top peer does not contribute to a large is a peer, which has sent video to our controlled nodes. In

4
 800 800
Download Download
Top ten peers Top ten peers
700 Top peer 700 Top peer
600 600
Throughput (Kbps)

Throughput (Kbps)
500 500

400 400

300 300

200 200

100 100

0 0
0 50 100 150 200 0 50 100 150 200
Time (minutes) Time (minutes)
(a) PPLive (b) PPStream

800 800
Download Download
Top ten peers Top ten peers
700 Top peer 700 Top peer
600 600
Throughput (Kbps)

Throughput (Kbps)
500 500

400 400

300 300

200 200

100 100

0 0
0 50 100 150 200 0 50 100 150 200
Time (minutes) Time (minutes)
(c) SOPCast (d) TVAnts

Figure 4: Video download policies: total traffic, top ten peers traffic and top peer traffic. Bin duration is 60s

the following, we will refer to the number of video download whenever they want and are prone to suffer failures. P2P
peers as VDP. IPTV systems have to deal with the arrivals and departures
PPLive maintains a relatively low and constant VDP whereas of peers (churn of peer). It is a challenging issue because live
PPStream has a high and constant VDP. SOPCast’s VDP video has to respect playback instant to get smooth playback
can be as high as PPStream’s one but fluctuates largely. quality. A high churn of peers will involve additional delays
As expected, SOPCast has no VDP when our node running or jitter variations for packet delivery, which will decrease
SOPCast receives no traffic. TVAnts VDP number is high overall video quality. In this section, we show the video
and also fluctuates. peers lifetime to point out the churn of peers. Since our
All the applications maintains for our controlled peers a dif- nodes have only a local view of all the peers in the network,
ferent peers neighborhood, which corroborates the applica- the video peer lifetime is the duration between the first time
tions have different download policies to get the video. As and the last time our controlled nodes exchange video traffic
expected, there is a large set of steady peers for PPStream, with another peer.
only a reduced set for PPLive. SOPCast and TVAnts have As an example, Fig. 6 plots the TVAnts complementary cu-
high and fluctuating VDP. VDP fluctuations are observed mulative distribution function (CCDF) of video peers life-
for applications, which use an important part of UDP traf- time. For all the applications, the video peers lifetime CCDF
fic (table 1). These VDP fluctuations may come from the follows a Weibull distribution. The CCDF plots for the other
non reliability of UDP, which causes more packet losses and applications can be found in [10]. The Weibull distribution
forces peer to make its VDP always evolving to get the video. functions used to fit the measured video peers lifetime are
presented in table 4. It also shows average peer lifetime.
4.5 Video Peers Lifetime The Weibull distribution is an exponential-like distribution
In P2P IPTV, end-hosts are responsible to duplicate flows often used in reliability testing and failure analysis. For all
to each other. End-hosts are not entities dedicated to stay the applications, there are no more than 10% of peers, which
in the networks all time: they can join or leave the network stay in the network during an entire game. Moreover, the

5
 120
PPLive Table 4: Video peers lifetime summary
Number of video download peers (VDP)
PPStream
100 SOPcast Video lifetime Distribution Avg. Peer
TVants
lifetime (s)
80 0.24
PPLive 2.01 ∗ e−(x/12.262) 393
−(x/322.07)0.39
60 PPStream 1.20 ∗ e 1222
−(x/993.79)0.45
SOPCast 1.08 ∗ e 1861
40
−(x/1572.76)0.59
TVAnts 1.23 ∗ e 2778
20

0
0 50 100 150 200 measured applications generate different traffic patterns and
Time (minutes)
use different mechanisms to get the video. The application
maintains different peers neighborhood and peers get the
video by using different download policies. Our measure-
Figure 5: Peers neighborhood for all the applica-
ments show that for all the applications, the video peers
tions. Bin duration is 60 seconds
lifetime CCDFs follow a Weibull distribution but do not
have the same average time. The Weibull distribution is
1 driven by users’ behavior while the different average video
peers lifetime comes from the underlying mechanisms used
by the applications.
CCDF Video peers lifetime

0.1 Thanks to our measurement observations, we have a bet-

ter understanding of P2P IPTV systems. This knowledge
will be used in our other works to model and simulate these
0.01 systems.

ACKNOWLEDGMENTS
0.001 This work is supported by the European Union under the
TVAnts IST Content project (FP6-2006-IST-507295).
Weibull fit

0.0001
1 10 100 1000 10000
6. REFERENCES
Time (secondes) [1] X. Zhang, J. Liu, B. Li, and T. P. Yum,
“Coolstreaming/donet: A data-driven overlay network
Figure 6: Example of Video peers lifetime for for peer-to-peer live media streaming,” in Proc.
TVAnts. All the applications have the same Infocom, 2005.
Weibull-like distribution for video peers lifetime. [2] http://www.pplive.com.
[3] http://www.ppstream.com.
[4] http://www.sopcast.com.
average video peers lifetime is different for all the applica- [5] http://www.tvants.com.
tions and far from an entire game duration. The departure [6] X. Hei, C. Liang, J. Liang, Y. Liu, and K. W. Ross,
of a peer can be due to an user, which stops to watch the “Insights into pplive: A measurement study of a
game or due to the application’s mechanisms, which force large-scale p2p iptv system,” in Proc. of IPTV
a peer to switch from a video peer to another one. Since Workshop, 2006.
all the applications exhibit a Weibull distribution for video
[7] K. Sripanidkulchai, A. Ganjam, B. Maggs, and
peers lifetime, our meaning is that Weibull distributions are
H. Zhang, “The feasibility of supporting large-scale
driven by users’ behavior of P2P IPTV applications. The
live streaming applications with dynamic application
mechanisms used by the applications are responsible for the
end-points,” in Proc. of SIGCOM, 2004.
different average video peers lifetime since it has been shown
in this study that all the measured applications implement [8] X. Zhang, J. Liu, and B. Li, “On large-scale
different mechanisms to allow peers to get the video. peer-to-peer live video distribution: Coolstreaming
and its preliminary experimental results,” in Proc.
MMSP, 2005.
5. CONCLUSION [9] E. Veloso, V. Almeida, W. Meira, A. Bestavros, and
In this paper, we explored the behavior of popular P2P S. Jin, “A hierarchical characterization of a live
IPTV systems by measuring and analyzing their network streaming media workload,” in Proc. of ACM
traffic. We chose the following applications: PPLive, PP- SIGCOMM IMW, 2002.
Stream, SOPCast and TVAnts because they are the most [10] T. Silverston and O. Fourmaux, “P2p iptv
popular on the Internet. We measured their traffic during measurement: A comparison study,”
the 2006 FIFA World Cup since it is a large-scale event http://www.arxiv.org/abs/cs.NI/0610133, 2006.
with a live interest for users. Our analyses show that the