Analysis of the network impact of P2P-TVapplications

Trinh Thanh SuUPMC Sorbonne University

4, place Jussieu,75005 Paris, France

Email: sutrinh@gmail.com

Olivier FourmauxUPMC Sorbonne University

4, place Jussieu,75005 Paris, France

Email: olivier.fourmaux@upmc.fr

Abstract—Nowadays, P2P-TV technology is more and moredeveloping. Unlike other TV technologies. P2P-TV tries to movetraffic burden to distributed users instead of basing on dedicatedinfrastructures. Because of its interesting idea, there is a varietyof researches about P2P-TV. To dissolve in its trend, this paperwill focus on some novel measurements about P2P-TV trafficconsisting of locality characteristic, traffic impact in restrictednetwork environment.

Foremost, our result shows that P2P traffic behavior isdynamic and different depending on different channels as well asdifferent moments. Especially, we emulate a worse network condi-tion (higher delay) over P2P-TV channels, measure and comparetheir impacts. Then, we examine what the traffic behavior iswhen we switch to another channel in such network condition.Afterwards, we court the geographical locality characteristic ofP2P-TV application. Last but not less, we draw conclusions andfurther works.

Index Terms—P2P-TV, Peer to peer computing, Data networkmeasurement, User behavior, Locality, Channel switching.

I. INTRODUCTION

Technology advances of converged network are enablingus to consolidate these disparate networks onto one platform.This brings many advantages of interesting services for users,especially in broadcast audio/video services. In order to adaptto the rain-storm development of Internet, with the aim ofoptimizing network resources, a plenty of technologies wereborn such as IPTV, HDTV, CDN, P2P-TV,. . .

Besides their widely contributions, these technologies stillremain many issues: HDTV requires the use of enormousnetwork resources, IPTV −a leap of converged network− iseither local and limited to residential operators. CDN althoughreduces bandwidth cost, improves end-user performance, opti-mize delivery process based on user’s location, it is costly andtakes huge infrastructures for many available nodes all over theworld. Therefore, P2P approaches seem to be a good choicefor the sake of resource leverage and distributed computing.P2P traffic largely contributes to the Internet traffic. We can listsome most popular P2P-TV applications including of SOPCast[1], PPLive [2], PPStream [3] or UUSee [4].

One of the downsides of these applications is that they areproprietary and closed. Nevertheless, there are a large deal ofresearches about P2P applications. In [11], the authors pro-vided us a comprehensive view of P2P traffic. They revealed

the behavior of P2P traffic in many different aspects of dif-ferent P2P applications including of P2P behavior, downloadand upload policies, protocol and port statistics, a heuristicto distinguish signaling and video in session aspect,. . . Oncontrary, the paper [7] use a different separation method inpacket size aspect. Some other papers as [7], [9] discuss aboutthe impact of P2P traffic when zapping channel. For [12],the author defined a modeling framework of P2P traffic. Inanother side, the paper [8] introduced the geographical localityof traffic and peers. All of them bring an enjoyable feeling toreaders as well as help us have a deeper understanding aboutunderlying mechanisms of closed P2P applications. However,almost of those studies have been done in a good networkenvironment. This paper accompanies a different approachwith more delay network condition. With some pre-definedmeasurements, we collect data, analysis, compare results anddraw some conclusions about the impact of P2P traffic in suchenvironment.

In particular, we proposed four measurements:

1) First of all, we study how P2P-TV channels behavein normal environment but with different channels atdifferent moments.

2) After that, by using NISTNet [5], we gradually increasethe delay for all of peers and then examine, compare theresult.

3) The third measurement is about zapping channel inadverse network condition.

4) Finally, we find out about the geographical distributionof traffic and peers in respect of total, downloadedand uploaded data when we put more delay to peersoutside Europe. In addition, we also make the similarmeasurement but with directional limitation of delay.

The remainder of this paper is organized as follows: the sec-tion II deals with the measurement setup. The section III, IVdenotes to the measurement with one channel in both cases ofnormal and abnormal higher delay condition. About the thirdmeasurement, we talk about zapping between two channels inmore delay environment in section V. Continuously, we studythe locality characteristic in section VI and after all others, wediscuss about issues and draw conclusions in section VII.

Fig. 1. Topology

Fig. 2. Timing diagram with one channel.

II. DESCRIPTION OF THE EXPERIMENTS

Here, we only focus on SOPCast. We captured about100 traces of P2P-TV traffic. Most of them were measuredduring November and December 2011 at different moments.In the first measurement of one channel case, we collectedtraces from many channels including of CCTV-1, CCTV-2 andCCTV-4. The remaining measurements were done with onlychannel CCTV-1. Each captured file was measured within 270seconds. In our graphs, each sample was got each 0.5 second.

We use a popular tool, namely NISTNet [5] to emulate aworse network environment. Based on figure 1, all incomingpackets are caught by a Linux PC which is installed NISTNet,has two network interfaces and plays role as a traffic controller.In addition, we built a program in this PC. The information ofincoming packets is extracted to peer’s IP addresses, inferredcountry codes [14] from GeoIP [15] database. Thence, fromthis program, we call NISTNet commands in order to addsome values of delay to the captured IP addresses and thenforward to destination(s).

Moreover, the hardware configuration should be also men-tioned here. The audiovisual PC runs Windows XP ServicePack 3 with CPU Intel Celeron 3.2 GHz, memory 1 GB. Aboutthe delay insertion router, we use Scientific Linux version4.0, CPU Intel Celeron 2.6 GHz, memory 512 MB. They arelocated in the campus of UPMC Sorbonne university (Paris,France) whose 100 Mbps Internet access via Ethernet NICs.

We made two timing diagrams. Two first measurementshave been done by using the 1-channel diagram and the mea-surement of zapping between 2 channels used the 2-channelsdiagram. For the first diagram (fig. 2), at the beginning, we runWireshark [6] and then open SOPCast but we do not chooseany channel yet. Until the time comes to 30th second, we startto select channel. After next 120 seconds, we assume the P2P-TV traffic go to a steady state (stable state, has no transient

Fig. 3. Timing diagram with two channels.

traffic). This state occupies 60 seconds before we close theP2P application at the moment of 230th second. From thatpoint, we still wait for a more short period of time becausewe want to observe the behavior of P2P peers and traffic afterclosing channel.

About the 2-channels diagram, it is nearly similar to thefirst diagram except from the moment of 50th second. It isthe time we change to another channel. After that, we keepthe same timeline as the 1-channel diagram.

Before we discuss about the measurements. Let us have ashort thinking about how to distinguish signaling and video.Many previous papers proposed different methods. We wouldlike to group them round two main ideas: in-band and out-bandseparation. In-band means signaling and video packets are inthe same session (same IP addresses and ports). Inversely, out-band term is explained that signaling and video packets cannot be in the same session. The paper [11] followed out-bandviewpoint and insisted: ”for each session (same IP addressesand ports), we count the number of packets larger than orequal to 1200 Bytes. If a session has at least 10 of such largepackets, then it is labeled as a video session. All the non-videosessions are supposed to carry signaling information”. Yet theauthors of [7] considered that packet size is an importantfactor to separate signaling and video packets. They chose1200 bytes for the threshold of separation. For our opinion,we advocate the second view but we change the threshold from1200 to 1000 bytes. It is because our observation revealed thatfor some certain peers, a large amount of small size packetsand large size packets (greater than 1000 bytes) are mixedin the same session. In addition, some peers has many largesize packets with 1043 bytes or some other sizes less than1200 bytes. We do not think 1043-bytes packets are signallingpackets. It is the reason why we choose in-band approach and1000-bytes threshold.

III. PERFORMANCE WITH ONE CHANNEL

In this section, we analyze traffic characteristic of one-channel traces in normal network condition. Specifically, tounderstand what differences of different channels behave, weexamine three channels: CCTV-1, CCTV-2 and CCTV-4. Themoment when we measured these traces were closed togetherbecause it reflects more exactly. Moreover, we also comparedtraffic behavior of the same CCTV-1 channel in differentmoments.

For the first sub-case, please look at three first items intable I. We can easily see that with nearby moments, each

TABLE ISTATISTICAL RESULT WITH ONE SOPCAST CHANNEL

Trace peers Duration Data (KB) Download UploadKB % Sig./Vid. Rate (Kbps) KB % Sig./Vid. Rate (Kbps)

CCTV-1 18h20 12/12/2011 1145 Full 61206 19861 32.45% 21.75% 588 41345 67.55% 6.99% 122560 8467 (14%) 2636 31.13% 21.15% 351 5831 68.87% 7.17% 777

CCTV-2 18h35 12/12/2011 56 Full 24798 17967 72.45% 9.13% 532 6830 27.54% 21.91% 20260 3911 (16%) 2275 58.18% 12.05% 303 1636 41.82% 13.68% 218

CCTV-4 18h43 12/12/2011 564 Full 34442 18692 54.27% 14.13% 554 15750 45.73% 12.57% 46760 5170 (15%) 2510 48.55% 16.31% 335 2660 51.45% 11.55% 355

CCTV-1 9h32 18/11/2011 215 Full 31345 19281 61.51% 12.80% 571 12063 38.48% 18.92% 35760 3754 (12%) 2414 64.29% 14.42% 322 1340 35.71% 24.61% 179

CCTV-1 15h40 10/12/2011 351 Full 33783 18652 55.21% 13.99% 553 15130 44.79% 16.33% 44860 3854 (11%) 2329 60.44% 13.08% 311 1524 39.56% 23.70% 203

CCTV-1 18h41 11/12/2011 1415 Full 46002 21033 45.72% 17.30% 623 24969 54.28% 16.90% 74060 5871 (13%) 3512 59.82% 13.63% 468 2359 40.18% 22.70% 315

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 4. Arrived and left peers - one channel without adding delay

channel had specific total number of peers depending on theircontents, events. CCTV-1 had 1145 peers, CCTV-2 had 56peers and CCTV-4 had 564 peers. Prior to choosing channel,there were still many arrived peers and data but not very much(fig. 4). Those peers may be used to connect to SOPCastservers, download channel list or play other certain roles.

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 5. Total number of peers - one channel without adding delay

Few of them had short live periods as the left peer’s curve(fig. 5). After the channel selection, the quantities of peerswere significantly increased. Many peer relationships wereestablished and more exchanged data (fig. 9). In majority ofcases, the total number of peers came to peak values beforesteady state. Until we closed the P2P application at 230th

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 6. Topten download peers - one channel without adding delay

second, the total number of peers was gradually decreased.In spite of closing channel, we still captured packets formore 40 second because we want to observe how the peersbehave after closing channel. Consequently, there were lessexchanged data in this period. Although we stopped our tracingat 270th second, we kept observing P2P-TV packets. From ourobservation, there were many small size packets (less than 100bytes) of many different peers which were downloaded by ouraudiovisual PC (we virtually did not see upload data). It isinteresting that those packets had the same destination port.This phenomenon was also right with other measurementsbut the values of port were different. The capturing PC onlyopened one port for reporting or peer relationships. In fact,opening many ports may put more processing on NAT devicesas well as leaving a security hole.

About download and upload policies, the figures 6, 7state that the top-ten download peers contributed to almostall the traffic in full duration but the top-ten upload peersonly occupied about half of upload traffic. This judgement isdifferent from [7] which believe both top-ten download anduploaded peers own almost of P2P traffic. From aspect of top

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 7. Topten upload peers - one channel without adding delay

peer, the importance of top download peer was higher thanthe upload one. The top download peers from our figurespossessed from 26.15% to 49.76% whereas the exchangedtraffic of top uploaded peers only gained from 10.56% to24.06%. As well as [7], the download top-ten peers’ set hasonly a little intersection with the one of upload. It testifies thatthe algorithm of choosing top-ten peers in P2P applications iscomplicated and unpredictable.

We also pay attention to the process of exchanging data. Thefig. 9 indicate the download process took place earlier thanthe upload process. The download curves had a transient peakafter we chose channel. It is due to the fact of that the essentialprinciple of P2P system is ”we upload what we downloaded”.Another note is that signaling packets were exchanged moreregularly than video packets (fig. 8).

Now, let us examine the table. I. We have several followingcomments:• Firstly, in comparison with the proportion of peer, the data

proportion had a slower increase. For example, althoughthe CCTV-1 peer quantity (first row in the table) washigher about 20 times than CCTV-2 channel (1145 against

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 8. Signaling and Video comparison - one channel without adding delay

56), the total amount of CCTV-1 data was only 2.5 timesof CCTV-2 data.

• Secondly, The percentage of data in steady state over fullduration is from 11% to 16%. In some other measure-ments, this ratio may be higher but not exceed 30%.

• The third point is about the ratios of download data toupload data. Three first rows were measured at the similarmoments but with different channels. As a result, dif-ferent channels gave us different proportions. MeanwhileCCTV-1 downloaded data only held 32.45% of total data,CCTV-2 channel has 72.45% downloaded data. WithCCTV-4, it is 54.27%. There is no relationship betweenthese proportions and total number of peers. If we glancearound three last items in table. I, which were measuredonly CCTV-1 channel but at different moments, theirproportions of downloaded to uploaded data were alsovariable. Even about the comparison between ”CCTV-1 18h20 02/12/2012” and ”CCTV-1 18h41 11/12/2012”which has the similar measuring time, they were treatedin different ways. We can conclude that the algorithm ofP2P application is independent with time and channel.

(a) CCTV-1

(b) CCTV-2

(c) CCTV-4

Fig. 9. Data comparison - one channel without adding delay

The download percentage is sometimes greater than theupload one but other measurements may generate theopposite results. For our opinion, it is reasonable becausecurrently the world have many different kinds of Internetaccess. In many places in the world, for instance: Asia,people usually access by using asymmetric line likeADSL. Besides, some places use NAT which many peersshare the same IP address. Thus, it is not feasible toinvolve P2P clients have the download percentage equalto upload percentage. P2P applications need dynamic andflexible algorithms to adapt to this issue.

• Next, we would like to take about the ratio of signallingto video data. As mentioned in section. II, we considerpacket size is a main factor to discriminate them and 1000bytes threshold is sensible. From our table, most ratioswere less than 25%. Download and upload signaling wereexchanged regularly. Their percentages are also similartogether. But the video packets were more bursty.

• Finally, we have a smooth playback when watching video.By numeric statistic in table. I, the download averagebandwidth of cases was about 570 Kbps. Compared with

(a) without NISTNet

(b) sr500

(c) sr1000

(d) sr1500

Fig. 10. Total number of peers - add delay to both directions

usual bit rate of live channels (520 Kbps), it is good forplayback. Upon upload average rate, the result gave us573 Kbps.

IV. ONE CHANNEL IMPACT IN MORE DELAYENVIRONMENT

The aim of this measurement is to discover how P2Papplications behave in more delay network condition. Here, weonly measure CCTV-1 channel. In this experiment, we keepthe same measuring way as the previous one but graduallyincrease delay to 500, 1000 and 1500 miliseconds. The resultis summarized in table. II and graphs.

(a) without NISTNet

(b) sr500

(c) sr1000

(d) sr1500

Fig. 11. Data - add delay to both directions

For the first judgement, the total amount of data was notmuch differential in all of cases. This is opposite with ourformer predict: because of higher delay, the data quantity willbe decreased. Perhaps, the P2P application has some trafficadjustment mechanisms. Data of steady state in all of caseshold about 30% total number of data.

Subsequently, we look at figure. 10 to see how were thechanges of peer quantity. Although it is not very obviouslybut in general, adding more delay made peer relationships areestablished longer. This tardiness is also right with the thirdcolumn in table. II in which reveals the moment we can see

(a) without NISTNet

(b) r500

(c) r1000

(d) r1500

Fig. 12. Data - add delay to receiving direction

video.Thirdly, the download percentage increased from 72.70%

to 90.32%, the upload percentage reduced from 27.30% to9.68%. From figure. 12, 13, whatever we added delay tosending or receiving direction, it was not easy to find thedifferences.

About download and upload policies, our statistic showsthat topten peers became less importantly. The download andupload top peers were also decreased their dominances inhigher delay environment.

In the other hand, the ratios of signaling to video for

(a) without NISTNet

(b) s500

(c) s1000

(d) s1500

Fig. 13. Data - add delay to sending direction

downstream were slightly increased when we added moredelay. However, for the similar ratio of upload, they werestrongly increased. In detail, if we put more delay in receivingdirection, the average disparity between r500, r1000, r1500and without NISTNet cases was about 3,9 times. With addingdelay to sending direction, the similar value was triple. Aboveall others, the average disproportion was 6,7 times when weincreased more delay in both directions.

Let move our eyes to rate productivities, in average, thedownload rate still kept at 564.5 Kbps. Compared with non-delay adding, the upload rate notably declined 5.7 times. If

(a) without NISTNet

(b) sr500

(c) sr1000

(d) sr1500

Fig. 14. Topten download peers - add delay to both directions

we glance around steady state, both download and upload rateswere increased. For download rate, it was raised from 564.5 to657.76 Kbps. For upload rate, it was increased from 99.95 to155.14 Kbps. These numeric result indicates the steady state’sroles play more importantly in such condition.

In short, we consider that even in worse network condition,P2P application still tries to keep the same download rateby laying down upload video traffic. Morever, steady statemay come in late. The roles of topten and top peers are lessdominant.

(a) r500

(b) r1000

(c) r1500

Fig. 15. Topten download peers - add delay to receiving direction

V. ZAPPING IN MORE DELAY NETWORK CONDITION

TABLE IIIPEER COMPARISON WITH ZAPPING 2 CHANNELS

w.o NISTNet sr500 sr1000 sr1500Total: 157 163 206 188nonCh1Ch2: 43 (27.39%) 44 (26.99%) 25 (12.14%) 5 (2.66%)Channel1: 58 (36.94%) 43 (26.38%) 44 (21.36%) 31 (16.49%)Channel2: 56 (35.67%) 76 (46.63%) 137 (66.50%) 152 (80.85%)

This section shows our research about P2P behavior whenwe zap between two channels (CCTV-1 and CCTV-2). Inthis measurement, we used the second timeline as fig. 3. Itis similar to the first timing diagram except from one thingthat we switch to another channel at 50th second. Channel1 performs in 20 seconds and channel 2 have 210 secondsfor performing duration. To have a better understanding, wedefine some terms:

• Useless peer list: is a list of peers that arrive before weselect the first channel.

TABLE IISTATISTICAL RESULT WITH ONE CHANNEL IN MORE DELAY ENVIRONMENT

Trace peers Moments Duration Data (KB) Download UploadKB % Sig./Vid. Rate (Kbps) KB % Sig./Vid. Rate (Kbps)

w.o NISTNet 311 48 Full 27218 19787 72.70% 9.80% 586 7431 27/30% 35.82% 22060 7987 (29%) 4696 58.79% 11.88% 626 3291 41.21% 21.78% 439

r500 243 45 Full 22826 19379 94.90% 11.45% 574 3447 15.10% 92.22% 10260 5461 (24%) 4696 85.98% 12.06% 626 766 14.02% 155.79% 102

r1000 325 58 Full 20560 17897 87.05% 12.49% 530 2663 12.95% 153.38% 7960 5368 (26%) 4667 86.94% 12.43% 622 701 13.06% 209.40% 93

r1500 238 49 Full 21937 19294 87.95% 12.89% 572 2643 12.05% 172.12% 7860 6228 (18%) 5109 82.03% 13.30% 681 1119 17.97% 91.56% 149

s500 293 49 Full 23530 19283 81.95% 12.66% 571 4247 18.05% 66.80% 12660 6372 (27%) 4896 76.83% 13.92% 653 1477 23.17% 54.57% 197

s1000 279 61 Full 23330 19896 85.28% 12.95% 589 3434 14.72% 108.64% 10260 5977 (26%) 4945 82.73% 12.97% 659 1032 17.27% 96.66% 138

s1500 215 79 Full 19892 17436 87.65% 11.45% 517 2457 12.35% 147.08% 7360 5717 (29%) 4911 85.89% 11.42% 655 806 14.11% 134.53% 108

sr500 276 75 Full 22438 20050 89.36% 13.76% 594 2387 10.64% 263.94% 7160 6088 (27%) 5353 87.92% 14.51% 714 735 12.08% 236.37% 98

sr1000 283 72 Full 21895 18868 86.18% 13.05% 559 3027 13.82% 136.32% 9060 6230 (28%) 5084 81.61% 13.61% 678 1146 18.39% 101.04% 153

sr1500 203 77 Full 20624 18628 90.32% 13.33% 552 1996 9.68% 322.04% 5960 5539 (27%) 4977 89.85% 12.66% 664 562 10.15% 370.69% 75

TABLE IVDATA COMPARISON WITH ZAPPING 2 CHANNELS

Trace Period Full NonCh1Ch2 Channel 1 Channel 2KB % KB % KB % KB %

w.o NISTNet0→30 67.33 0.24% 67.33 0.24% 0.00 0.00% 0.00 0.00%30→50 3885.03 13.81% 6.76 0.02% 3878.27 13.79% 0.00 0.00%50→270 24117.28 85.95% 16.27 0.06% 15.80 0.06% 24145.21 85.84%

sr5000→30 153.28 0.77% 153.28 0.77% 0.00 0.00% 0.00 0.00%30→50 1388.57 7.02% 7.70 0.04% 1380.87 6.98% 0.00 0.00%50→270 18250.75 92.21% 2224.45 11.24% 381.82 1.93% 15644.48 79.04%

sr10000→30 83.46 0.44% 83.46 0.44% 0.00 0.00% 0.00 0.00%30→50 326.60 1.70% 11.90 0.06% 314.70 1.64% 0.00 0.00%50→270 18757.17 97.86% 16.69 0.09% 224.69 1.28% 18495.79 96.50%

sr15000→30 11.41 0.05% 11.41 0.05% 0.00 0.00% 0.00 0.00%30→50 58.52 0.26% 5.45 0.02% 53.07 0.23% 0.00 0.00%50→270 22649.55 99.69% 16.21 0.07% 3.10 0.01% 22630.24 99.61%

• Channel 1 peer list: from 30th to 50th second, if a newpeer does not exist in useless peer list before, it will beput to channel 1 peer list.

• Channel 2 peer list: after 50th second, all new peers thatare neither in useless peer list nor in channel 1 peer listare considered as a member of channel 2 peer list.

According to our figures, at the beginning, it has a littleof traffic and peers. The red lines in figure. 20 proclaimthe number of channel 1’s peers increased from 30th to50th second. But after that, it was significantly decreased.In particular, the useless peer was decreased from 27.39% to2.66%. With channel 1 peer list, it reduced from 36.94% to16.49%. Interestingly, in some measurements as our figureswith sr500 and sr1000, some channel 1’s peers had many datain the performing period of channel 2 (from 50th second to theend). From our point of view, it is because some other peersalso switch the channel from CCTV-1 to CCTV-2 as we did.We checked this phenomenon many times with different traces.This phenomenon appeared unpredictably and the quantity ofpeers, which we supposed changed their channels, was nearly

less than 15% total number of peer. This consolidates ourexplaination.

As shown in table II, when we added more delay, the datapercentages in useless period and in channel 1’s duration overthe whole peer quantity were decreased . In other side, thepercentage of channel 2’s data was increased from 85.84%to 99.61%. We expound that before exchanging data, it takesa short period so that peers build their mutual relationships.Previous to choosing channel and during the performingduration of channel 1, the peers have no enough time for allpeer relationship establishments (some peers did not establishin time) because of high delay. For the period after 50thsecond, the performing duration is longer, peers have enoughtime to have many establishments with other peers and thenexchanging data.

VI. LOCALITY

We would like to divide this measurement into two smallsub-measurements: distribution with directional traffic anddistribution with directional limitation of delay.

(a) s500

(b) s1000

(c) s1500

Fig. 16. Topten download peers - add delay to sending direction

A. Distribution with directional limitation of delay

We measured only CCTV-1 channel. The aim of this mea-surement is to show the geographical locality among P2Pusers from different countries when we add more delay byusing NISTNet. Instead of putting a large quantity of delays,we only chose 4 values for adding delay: 0, 500, 1000 and1500 miliseconds (ms). The gap between each step is 500 msbecause we think that the larger the gap is, the clearer ourresults perform. The results were collected from 4 measuredtimes. Each point in graphs is collected as an average numberof those times. Besides, because the exchanging data of Frenchpeer is so few and insignificant, we created a group which ison behalf of all european countries, namely “EUROPE”. Thisgroup was not affected by delay adding.

First of all, we measured in normal condition (withoutusing NISTNet). After that, in succession, we increase thedelay directionally. In other words, we add delay only insending direction (denoted by “s” before the value of delay) orreceiving direction (”r”) or both directions (”sr”). For instance:sr500 stands for adding 500 ms delay in both directions; s1000means we only put 1000 ms to upload traffic; r1500 is an

(a) without NISTNet

(b) sr500

(c) sr1000

(d) sr1500

Fig. 17. Topten upload peers - add delay to both directions

acronym of putting 1500 ms delay to download direction.The fig. 22 contains the information regarding to the data

distribution. Without NISTNet, EUROPE group holds about15% of total traffic. We judge that the EUROPE percentageincreased slowly (to 29%) when we put more delay to sendingdirection. As previously stated in section. III, we learned thatthe effect of delay adding over download traffic is larger thanthe one of upload traffic. The ratio of upload over downloadpercentage is also decreased. It brings about the EUROPEgroup in this case had not much increased upload percentage.On contrary, if we raised more delay to download direction

(a) r500

(b) r1000

(c) r1500

Fig. 18. Topten upload peers - add delay to receiving direction

or both directions, the EUROPE occupation would be moreconsiderable. The highest percentage is up to 66%.

It is also notable that although the data population waschanged because of adding delay, the fig. 23 proclaims thetotal number of peers in all cases seem to be stable. Theykept their values from 35% to 40%. Thenceforward, by addingdelay, we can stretch the distribution of traffic sparser.

Furthermore, let have a look at the table. V which recordedthe moments (from start time) we can see the video. This tablereflects how long the videos were buffered. We noted it afterfour measurements and the last column contains the averageresult of those four times. Each time, not whenever more delayis added, we can see the video earlier but if we take intoaccount the average result, it shows us that P2P applicationwill buffer video longer and we can see TV channel moretardy in more delay network condition.

B. distribution with directional limitation of delay

Now, we change the measuring method. We increase moredelay in both directions and monitor what are different impactsbetween download and upload traffic. The fig. 24 express the

(a) s500

(b) s1000

(c) s1500

Fig. 19. Topten upload peers - add delay to sending direction

TABLE VTHE MOMENTS WHEN WE CAN SEE THE VIDEO WITH OPTIMIZING

LOCALITY

1st 2nd 3rd 4th Avg.w.o NISTNet 45 46 48 44 46s500 49 47 69 48 53s1000 55 47 64 47 53s1500 55 56 58 49 55r500 52 50 52 46 50r1000 73 51 57 49 58r1500 70 60 51 53 59sr500 49 53 47 55 51sr1000 97 85 59 62 76sr1500 97 83 84 90 89

higher delay we put, the more data EUROPE group gained,first and foremost download traffic. As we see, four last redbars of download augmented faster than the upload. It is alsocaused by our old explaination: the impact of download trafficis more obvious than the upload influence in more delayenvironment.

In general, we can make some following conclusions:• Optimizing locality by putting more delay to further peers

(a) without adding delay

(b) sr500

(c) sr1000

(d) sr1500

Fig. 20. Zapping 2 channels with adding delay to both directions - peercomparison

can not improve peer locality.• Data distribution is better in more delay network environ-

ment, especially download traffic. It is good for overallP2P traffic, doffing the burden of P2P traffic in Asiawhere has a large P2P community. We can navigate P2Ptraffic to dodge some ISPs who want to restrict P2Ptraffic.

• From user’s aspect, it is not better. Despite with localityoptimization, users can get more data from nearer peers,the total number of data is almost not differential from

(a) without adding delay

(b) sr500

(c) sr1000

(d) sr1500

Fig. 21. Zapping 2 channels with adding delay to both directions - datacomparison

without delay adding. Further, users often wait longer toable to see video.

VII. SUMMARY AND OUTLOOK

In this document, we presented a research about P2P-TVbehavior in normal and more delay network condition. Ourresults indicate that P2P-TV application behaves differentlybased on the differences of channel, content and watchingmoment. Its algorithm has a good stabilization. They sacrificeupload video for download video in higher delay environment.By this way, users can still get enough data to perform video

Fig. 22. Data distribution with directional limitation of delay.

Fig. 23. Data distribution with directional limitation of delay.

Fig. 24. Data distribution with directional limitation of delay.

but upload less data to the others. This disparity betweendownload and upload proportion can be compensated by otherpeers. Besides, the roles of topten and top peers hold asignificant percentage. However, their importances will bedecreased if P2P-TV users live in a worse delay condition.We also find out that whatever direction we add delay to,the difference is not very clear but they share the samecharacteristic: in such environment, download traffic impactis more than the upload one. In addition, our experiment withlocality optimization reveals that we can only improve datadistribution but from users’ view, the video quality is notbetter.

Because of the our limitation of time, this paper onlyconcentrate on delay adding. Actually, in order to draw abigger picture of P2P-TV behavior, we should have morestudies with different P2P applications. We can build morecolorful experiments by testing the P2P-TV behavior withother restrictions of network parameters such as bandwidth,drop probability or packet duplication. Moreover, we are ableto control traffic from or to some certain ISPs. Some databasesfrom the Internet can provide us programming libraries toconvert from IP to its ISP name.

As a perspective of our work, the prospective researchesabout P2P-TV in adverse environment will be not only provideus a deeper understanding but also improve video quality,optimize traffic distribution to reduce cost routing or shirkISP’s restrictions. It is really interesting.

REFERENCES

[1] SOPCast. [Online]. Available: http://www.sopcast.com.[2] PPLive. [Online]. Available: http://www.pplive.com.[3] PPStream. [Online]. Available: shttp://www.ppstream.com.[4] UUSee. [Online]. Available: http://www.uusee.com.[5] NISTNet. [Online]. Available: http://snad.ncsl.nist.gov/nistnet[6] Wireshark. [Online]. Available: http://www.wireshark.org[7] M. Wang, O. Fourmaux, Y. Nakamura, T. Miyoshi, “Network impact of

P2P zapping”, 2011.[8] T. Silverston, O. Fourmaux, K. Salamatian and Kenjiro Cho, “On

Fairness and Locality in P2P-TV through Large-Scale MeasurementExperiment”, IEEE Globecoms - Communications QoS, Reliability andModelling Symposium, December 2010.

[9] Y. Nakamura, T. Miyoshi, and O. Fourmaux, “Traffic analysis consid-ering channel zapping on p2p video delivery service”, IEICE, Tech.Rep. CQ2011-27, July 2011.

[10] A. Horvath, M. Teleeglia, D. Ciullo, M. A. Garcia, E. Leonardi andM. Mellia, “Network awareness of P2P live streaming applications”, inHOTP2P Workshop at IEEE IPDPS’09, Rome, May 2009.

[11] T. Silverton, O. Fourmaux, K. Salamatian, A. Dainotti, A. Botta,A. Pescape, and G. Ventre. “Traffic analysis of peer-to-peer IPTVcommunities”, Elsevier Computer Networks, vol. 53, no. 4, pp. 470–484,March 2009. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2008.09.024

[12] D. Rossi, E. Sottile and P. Veglia, “Black-box analysis of Internet P2Papplications, peer-to-peer networking and applications” 2010.

[13] M. Cha, P. Rodriquez, J. Crowcroft, S. Moon and X. Amatriain,“Watching television over an IP network”, in ACM/USENIX IMC’08,Athens, October 2008.

[14] ISO 3166 Country Codes. [Online]. Available: http://www.maxmind.com/app/iso3166

[15] GeoIP. [Online]. Available: http://geolite.maxmind.com/download/geoip/database