Abstract
In this work, we develop a general methodology to assess the level of network awareness and friendliness of P2P-TV applications. The methodology is based on a combination of active and passive measurement techniques and can be applied to any P2P-TV system since it is designed to work considering such systems as a black-boxes. As an interesting case study, we then apply this methodology to PPLive, one of the most popular P2P-TV systems nowadays. Focusing on the video content distribution, we consider several per-path and per-peer metrics, investigating which of them mostly biases PPLive download preferences. Furthermore, in order to refine the picture of PPLive peer selection policy, we not only study the impact of different metrics in isolation, but also assess the joint impact of different metrics at the same time. Our main finding is that PPLive seems mainly bandwidth greedy, but does not show any preference toward peer proximity based on RTT delay; at the same time, our results also suggest that this choice alone may provide a nonnegligible level of geographical clustering among peers as a beneficial side effect.
1. Introduction and Motivations
We agree with [1] that “the Obama inauguration marks a historic day in US politics and a remarkable day for the popularity of Internet streaming video. We look forward to watching more great things to come.” Live streaming of video content over the Internet is finally hitting the masses: it is not hype that P2P-TV systems are candidates for becoming the next Internet killer applications, as testified by the growing success of several commercial systems, among which PPLive [2] is perhaps the most popular.
Yet, despite valuable research already investigated such commercial applications [3–15] still little information is available about their internal algorithms, which are proprietary and closed. Specifically, a major concern is that, unless such systems are considerate of the underlying network, the very same potentialities of P2P-TV may constitute a worry for network carriers, especially in the case of HD streaming. Indeed, notice that while download rate is limited by the stream rate, the upload rate may grow much larger depending on the number of served peers [3]. Furthermore, a P2P application confining most of the generated traffic within the Autonomous System (AS) could noticeably reduce operators' transit costs on peering links [5].
In the last years, a significant research effort in P2P networking has been devoted to techniques for achieving a better mapping between the overlay topology and the underlying physical network [16–18]. This can be obtained by biasing the peer selection process, so to choose overlay neighbors based on their proximity on the underlying IP network, that is, in other words to make the overlay “aware” and “friendly” toward the underlay. Such network-aware techniques can be either enforced at the overlay level alone (by inferring peer proximity based on latency measurement, coordinates systems [16], Autonomous System information [17], etc.) or even by allowing ISPs to participate in this process [18]. At the same time, we point out that most of these techniques have been developed in the more general context of P2P applications and have only more recently been cast to P4P-TV [19–24] which can be explained by the fact that other classes P2P applications, such as file-sharing, can be more easily engineered since they lack the need to preserve the temporal coherence of the fetched content.
Although a number of relevant works [3, 4, 7, 10–13] recently targeted the study of popular Internet P2P-TV applications, still the question remains whether such systems are aware of (and behave friendly with respect to) the underlying IP network, which is precisely the aim of this work. From a high level perspective, we can define two categories of metrics that pertain to network awareness: pathwise metrics (such as RTT delay, available bandwidth, packet loss, etc.) are determined by the conditions on the end-to-end path between two peers in the overlay; conversely, peerwise metrics (such as Autonomous Systems, geographical location, /16 IP prefix, access capacity, etc.) only depend on properties of a single peer. Our methodology (i) exploits active techniques to artificially enforce pathwise metrics in a controlled testbed, while (ii) adopts a passive technique to infer preference of peerwise metrics from observation of the traffic, gathered from multiple active probes, in uncontrolled live experiments. We point out that we implemented a slightly modified version of the methodology presented in this work in [14], which is available as an open source software tool at [15].
We apply this methodology to the study of PPLive where the combination of both techniques allows us to draw conclusions that are otherwise precluded using either methodology alone. By means of active measurement, we find that PPLive is mainly bandwidth greedy, but does not show any preference concerning, for example, IP distance or RTT delay. As ISP friendly peer selection and, more generally, network awareness in P2P system has only recently become a topic of interest, it would have rather been surprising if PPLive already explicitly considered this. Yet, by means of passive measurement, we further observe that bandwidth preference alone may provide a nonnegligible level of geographical clustering among peers as a beneficial side effect. While this is an interesting and positive finding, the overall results suggest that supplementary effort is needed in order to further increase the level of network friendliness—which, as PPLive is continuously evolving [25], may very well happen in the near future.
Summarizing, the main contributions of this paper are as follows.
(i)First, we propose a black-box methodology, based on a combination of active and passive measurement techniques, to assess the level of network awareness and friendliness of currently deployed Internet P2P-TV applications. (ii)Second, we apply our methodology to the analysis of PPLive finding that geolocalization, while not explicitly enforced by the application, actually arises as beneficial side effect of bandwidth preference. (iii)Third, the methodology allows to investigate the relative preference of different metrics as well; in the case of PPLive, we find that the peer selection process is continuously updated, with a relative preference among pathwise properties that depends on the actual magnitude of the metrics.The reminder of this paper is organized as follows. After having overviewed related effort in Section 2, we describe the methodology and dataset in Section 3. We then apply the methodology to the analysis of PPLive reporting experimental results of active and passive techniques in Sections 4 and 5, respectively. Finally, Section 6 concludes the paper.
2. Related work
Recently, live streaming P2P-TV systems attracted the attention of the research community: as a result, a number of relevant works exist that exploit measurement techniques to study the behavior of such systems [3–13].
Many valuable work considers a single system, which is analyzed by active crawling as in the case of PPLive [3], CoolStreaming [4], and UUSee [5]. Other works instead focus on very specific aspects of a P2P streaming system, for example, node degree of popular versus unpopular channels [6] and node stability [7], while quality of service is of concern in [8, 9]. Finally, work also exists that attempts at comparing similarities and differences of the above systems as [10], which analyzes the traffic pattern generated by these applications from both a network as well as from a transport layer perspectives. Only very recently, work started to appear that focuses more closely on the study of P2P-TV network awareness [11–13]. Yet, although these works share some similarity in their aim with ours, as detailed in the following the adopted approaches are rather different.
For instance, authors in [11] exploit the application-layer logs of UUSee: interestingly, among their finding they observe a clustering phenomenon among peers in the same ISP, similar to the one pointed out in this paper. At the same time, we stress that our work differs from [11] concerning two important points. A first difference arises in the methodology employed, which in the case of [11] limits the applicability of the effort, indeed, authors not only have knowledge of the P2P-TV system inner workings, but also base their analysis on application-layer logs, which requires thus to instrument the application under analysis and is thus clearly not applicable in case of closed source proprietary systems. A second difference arises instead in the analysis of the results, and on the conclusions that can be gathered. The authors in [11] state that UUSee actually biases the selection of its neighbor peers via both (i) bottleneck bandwidth inference as well as (ii) RTT delay measurement. The authors further observe that a significant fraction of neighbor peers falls into the same ISP, despite that UUSee does not explicitly take into consideration ISP membership. These observations allows them to conclude that the reason behind the clustering is that “as connections between peers in the same ISPs have generally higher throughput and smaller delay than those across ISPs, they are more inclined to be chosen as active connections.” Interestingly, in our case we show that a similar geographical clustering can be observed in PPLive, which we also show not to be sensitive to RTT preference. To the best of our knowledge, this clustering effect solely induced by bandwidth preference has not been observed by other researchers to date.
A first step toward a methodology that can be applied to any system as a black-box is undertaken by both [12] (which, however, limitedly exploits an active measurement technique) and in our earlier work [13] (which instead only considers a passive measurement technique). In more detail, authors in [12], set up an active testbed to investigate the congestion control algorithms of different P2P-TV applications. Using active probes, authors enforce pathwise properties (such as artificial bandwidth limitations, packet loss, and delay) and examine P2P-TV reaction to adverse network conditions. Inspired by [12], we refine their setup, by (i) considering a more controlled setup and by (ii) jointly applying different impairments, so to assess the relative importance of multiple pathwise properties.
However, not all metrics potentially exploited by the overlay for neighbors selection and chunk scheduling can be artificially enforced via active measurement techniques—as, for instance, is the case of peer geographical and AS locations. In [13] we thus investigated such peerwise properties by means of a large pan-European measurement campaign, exploiting a purely passive measurement approach. In this work, we exploit the same dataset considered in [13] by performing a correlation-based analysis inspired by Principal Component Analysis (PCA) technique. Thus, although the dataset used in this work is the same as in [13], the analysis technique differs from the simpler one adopted in our earlier work [13], where we quantitatively weighted the relative amount of bytes exchanged with a peer that exhibits a specific peerwise property as an indication of P2P-TV system preference toward that property.
In this work, we define a methodology that jointly exploits active and passive measurements, encompassing thus and going beyond [12, 13]; by applying the methodology to the analysis of PPLive as a case study, we show that only the combination of both methodologies allows us to draw conclusions—such as the geographical clustering effect induced by bandwidth preference—that are otherwise precluded using either methodology alone.
3. Methodology
As previously outlined, our aim is to define a methodology able to tell whether a P2P-TV system has some level of knowledge of the underlying IP network, and whether it exploits this knowledge to bias the selection of the overlay neighborhood—especially for what concerns the chunk download preference. From a high level perspective, we can define two categories of metrics that pertain to network awareness.
(i)Pathwise metrics, such as IP path length (hops), loss rate, RTT delay, and available bandwidth,, are determined by the conditions on the end-to-end path between two peers in the overlay. (ii)Peerwise metrics, such as Autonomous Systems, geographical location, /16 or /24 IP prefix, access capacity, instead only depend on properties of a single peer.In this work, we use two separate sets of experiments to assess the awareness of a P2P-TV system with respect to metrics falling in either of the two above categories.
(i)On the one hand, we exploit an active measurement technique to enforce controlled artificial conditions (such as path length, delay, loss and bottleneck bandwidth) on a specific network path in an Internet-scale testbed. (ii)On the other hand, we adopt a live passive measurement approach, where we perform contemporary live measurement of unmodified peers from multiple vantage points, in order to investigate properties (such as AS or geographical location) belonging to real overlay peers.3.1. Pathwise: Controlled Testbed
For preference related to path metrics, we setup a controlled testbed to enforce artificial network conditions as in [12], from which our approach differs for two main reasons. First, we decide to completely control the path metrics. This means that, unlike [12] where impairments are additionally enforced beyond the actual network conditions, we know precisely the conditions of the different peers involved in the experiments. Second, we not only test the impact of each metric in isolation, but also investigate their combined effect as well.
The configuration used for all active experiments is shown in Figure 1. We use three modern desktop PCs equipped with dual-core processor running native installations of Windows XP and of the P2P-TV application, which in our case is PPLive 2.4. Two machines and are connected to a network switch through their 100 Mbps Ethernet interfaces. Traffic is observed at the probe PC , which is connected to the switch through a machine, referred to as in the picture, running a linux kernel 2.6 and acting as a bridge, firewall, and network emulator. Notice that a large population of users, as well as the primary source of the video itself, is reachable through the Internet.
At start-up, all machines , , and run undisturbed clients for 5 minutes. During this start-up period (where we verify that play-out starts and that the clients are visually synchronized within a 1-2 seconds range), naturally receives most of the traffic from Internet hosts. Then, at time minutes, firewall rules are established at to block traffic coming from the Internet toward , which can thus only receive traffic coming from either or . In this case, hosts and will still receive the video from the remote Internet peers, but our probe will be forced to receive the totality of the video from and .
We then introduce, starting at minutes, artificial network emulation rules (such as packet loss, RTT delay, bottleneck bandwidth limitation, etc.) on the path that joins our probe to the hosts and from which he is receiving the video content. We point out that our aim is to understand how the system biases its peer selection during normal operation; we verify that probe is correctly receiving the video stream. When a path metric is considered in isolation, we artificially worsen network conditions (e.g., increase packet loss rate, delay, etc.) solely on the path from machine to , by properly configuring the queueing discipline on . Rules on path from to are instead enforced only to investigate the relative importance of different metrics (e.g., delay on and loss on ). Finally, artificial network conditions are turned off at time m and firewall limitations are removed at m.
The above setup allows us to focus on the breakdown of the bit-rate received at between its contributors (i.e., , , and Internet hosts), and to express in a visually simple way the network awareness of the P2P-TV application. Consider indeed the period when artificial network emulation rules are applied on the path from to , for instance, clearly, in absence of bias with respect to a given metric , we expect the breakdown of the traffic received at to be unaffected from variations of . Conversely, a varying breakdown will reflect system awareness to , with the extent of the breakdown variation as rough indication of the system sensitivity to .
3.2. Peerwise: Multiple Live Measurement
The analysis of preference related to peer properties is instead based on a large testbed, setup in the context of the NAPAWINE project [26]. In this case, we mine the data gathered from the experiment in order to infer additional information concerning the P2P-TV system bias on peerwise properties.
The main idea is to use a correlation-based analysis of any given peerwise metric and the amount of bytes exchanged between contributor peers. As peerwise metrics , we will consider the Autonomous System (AS) and geographical Country (CC) properties. In this case, our aim is to test whether two peers that belong to the same AS/CC exchange more data than faraway peers, gauging the importance of in the peer selection process. Deferring further details on the quantification of this bias, along with considerations concerning the fallacies of correlation-based analysis to Section 5, we now briefly describe the Internet-scale experiment setup used to gather the passive measurement dataset.
More precisely, partners run PPLive clients on PCs connected either to the institution LAN, or to home networks having cable/DSL access. In more detail, as summarized in Table 1, the setup involves a total of 46 peers, including 37 PCs from 7 different industrial/academic sites, and 7 home PCs. Probes are distributed over four European countries and connected to 6 different Autonomous Systems, while home PCs are connected to 7 other ASs and ISPs. Therefore, the setup is representative of a significant number of different network environments. Several 1-hour long experiments were performed during April 2008, when partners watched the same channel at the same time and collected packet-level traces. Since P2P-TV applications are mostly popular in Asian countries [3], we tuned PPLive to CCTV-1, a popular channel, during China peak hours. Nominal stream rate is 384 kbps, Windows Media 9 Encoder is used, and the perceived video quality is similar for all partners. We point out that during the experiments, several of our peers act as amplifiers [3]; that is, they exhibit an upload/download ratio significantly larger than 1, which further justifies potential ISPs worries concerning P2P-TV systems.
Results reported in this paper refer to 44 hours of video, during which our probes exchanged about 70 GBytes of data in 157 million packets with nearly 1 million external peers. We stress once more that, despite the dataset reported in Table 1 is a subset of the one considered in [13], nevertheless the analysis of the dataset carried on in Section 5 differs from our earlier work [13].
4. Experimental Results: Pathwise Metric
Let us start by inspecting pathwise preference, by means of the controlled testbed depicted early in Figure 1. Initially, we study pathwise metrics in isolation, enforcing either (i) decreasing bottleneck bandwidth, (ii) increasing packet loss rate, (iii) increasing RTT delay, (iv) increasing IP hop count on the path from host to the probe .
We then inspect the relative importance of the above metrics in the peer selection process by jointly considering different metric combinations, applying one condition (e.g., bottleneck bandwidth) on the path from the host to the probe , and a different condition (e.g., packet loss rate or RTT delay) on the path.
4.1. Bottleneck Bandwidth
Results of the first experiment are reported in Figure 2(a). Time of the experiment runs on the -axis, while the firewall start and end times are reported on the top axis as a reference. A decreasing bandwidth profile is enforced starting at by means of a token bucket filter, with steps of Mbps every 2 minutes, as shown by the thick black line. Values of the bottleneck bandwidth are reported on the right -axis, and the bottleneck is removed at . The time evolution of the aggregated received rate at is reported in the top portion of the plot, averaged over 20 seconds intervals. It can be seen that, after an initial start-up phase in which the incoming rate peaks up to 1.2 Mbps, the aggregated received throughput at is steady around 400 Kbps, which account for both signaling and video traffic. Moreover, notice that the aggregate rate is undisturbed during the whole experiment, hinting to the fact that traffic shaping did not perturbed the perceived quality of service.
(a)
(b)
Bottom plot of the figure report the breakdown of the traffic incoming at with respect to the different hosts that sent the traffic to : host is depicted at the bottom with light (green) color, host with dark (red) color, and the remaining Internet hosts with a dashed pattern. It is easy to gather that, before firewall rules are in place , more than 80% of the incoming traffic is received through Internet hosts. As soon as firewall rules start at , is forced to receive traffic exclusively from hosts and ; since during , no bottleneck bandwidth is enforced yet, the traffic splits roughly equally between and , as the network condition and play-out time of hosts and are alike. Then, as soon as a 50 Mbps bottleneck bandwidth kicks in at , PPLive immediately starts preferring the unconstrained host , which then provides the most significant portion of the traffic to .
This observation is important as it means that (i) PPLive is extremely sensitive to the bandwidth and (ii) it may overreact or perform faulty bandwidth estimations. This behavior might be due to the token bucket shaper used to enforce bandwidth limitations, causing strange arrival patterns that mingle the bandwidth estimation algorithm. Moreover, packet time stamping may also bias the results (e.g., by poor timing due to clock drift, clock skews due to NTP synchronization, etc.). More likely, since packets of the same chunk are sent out in bursts [3], implementation of hardware card and drivers may play a very important role as well, especially due to interrupt coalescing. This feature, aimed at avoiding the overkill of raising an IRQ signal for every packet received, makes the cards wait during a short time-window for the arrival of other packets prior to notify the reception to the upper layers. Since packet time-stamping is then performed by the OS, this means that interrupt coalescing has a possibly very nasty impact on the bandwidth estimation as well, because two consecutive packets received by the card during the same interrupt coalescing window will then be sent to the upper layer almost at the same time. As a consequence, bandwidth and capacity estimation tools that are based on packet pair or packet dispersion will rather measure the PCI bus speed more than bottleneck in the network.
Finally, bottleneck limitations are removed at , which partly removes the breakdown bias toward host ; this holds until the firewall limitations are removed as well at , after which contributors are again to be found mainly among Internet hosts.
4.2. Packet Loss
We then conduct similar separate experiments for the other considered metrics, enforcing a single impairment at any time. Results for the packet loss rate experiments are reported in Figure 2(b) using the same similar visual presentation (i.e., aggregated rate, breakdown, and packet loss profile).
We notice again that the incoming traffic rate at is steady for any packet loss rate; indeed, since only the path is impaired, has still the possibility to receive the rest of the video from . In this experiment, starting at time , we increased packet loss rate experienced by host using the profile .
As the picture clearly shows, PPLive is not very sensitive to packet loss; noticeable changes in the breakdown happen only when packet loss percentage exceeds 10%—indeed when loss rate is 10%, still more than half of the data is downloaded from the impaired host . If we couple this observation to the fact that, despite packet loss increases considerably, the sent traffic rate (measured at and not shown in the picture) does not increases proportionally, we can conclude that PPLive seems to use an effective FEC techniques, as already observed in [12].
4.3. IP Distance
We then test whether PPLive is aware of the host proximity, which we measure in terms of the number of IP routers that packets cross on their path across the network. Applications using raw UDP sockets can infer IP proximity by means of the Time To Live (TTL) field of IP packet header, which is initially set to an OS-dependant value (namely, 60 or 64 for BSD and Linux, 128 for Windows) and then decremented by one unit at each hop in the network. We artificially increase the number of hops on the path from by subtracting the number of additional hops from the IP TTL header field at .
As before, a change in the hop profile is enforced every two minutes, and the results are shown in Figure 3(a). As there is no noticeable change in the breakdown irrespectively of the additional hops values, we can conclude that PPLive is either unaware the IP hop distance between two hosts, or that its inner algorithms do not rely on this piece of information.
(a)
(b)
4.4. RTT Delay
Finally, we verify whether PPLive does instead take latency measurement into account. We increase the delay on the path so that the Round Trip Time () equals s, and report the results in Figure 3(b).
The plot clearly asserts that PPLive is not very sensitive to the delay, as the breakdown does not show any noticeable change until the round trip delay grows very large ( s). We can thus conclude that PPLive peers do not bias their download policy in terms of nodes proximity, neither in terms of IP hop distance, nor in terms of delay. In other words, PPLive does not seem to implement proximity techniques such as [16–22].
Yet, another very important remark can be gathered from the picture. Indeed, when s, the breakdown drastically drops; this suggest that PPLive does actually measure , which is however not used afterward for the proximity-based video contributors selection. This behavior can be explained by recalling that one of the main aims of scheduling in P2P-TV streaming is to reduce as possible the play-out delay of the whole system. Therefore, despite that useful video content may be available at high peers, such peers are preferentially discarded as they may not timely contribute to the video content delivery, and as such they would increase the whole system play-out delay. In other words, it seems that PPLive, streaming to keep a low end-to-end play-out delay, uses as a “sanity-check” and disregard such peers on purpose to avoid the system pollution.
4.5. Combined Pathwise Metrics
In order to further refine the knowledge concerning PPLive network awareness, we investigate how PPLive reacts to different combination of impairments, so to sketch a relative order of importance of the above metrics. As we show that PPLive is not sensitive to IP hop count, we now limitedly consider packet loss, RTT delay and bottleneck bandwidth limitations, applying an impairment on the path, and another impairment on at the same time.
For the sake of readability, we consider only a couple of values for each metric (i.e., and ) and investigate PPLive behavior on the four different operational points resulting from their combination . Results are shown in Figure 4, which reports for the sake of readability the value of the impairment applied to a specific path directly on the plot. In this case, to avoid cluttering the pictures, we no longer report the aggregated received rate but limitedly depict its breakdown.
(a)
(b)
(c)
4.5.1. Delay versus Rate
Top plot of Figure 4 reports the case in which we apply a delay s on the path and enforce a rate limitation of Mbps on . It can be seen that preference goes toward bandwidth limited host and is mainly driven by the bottleneck bandwidth; indeed, almost all content is downloaded from when the rate limit is set to 1 Mbps, irrespectively on the delay toward . Once the bottleneck rate drops to Mbps, the number of video chunks downloaded from slightly increases (even though the rate limit would allow almost the whole content to be downloaded from ), but no noticeable effect of RTT variation is shown.
4.5.2. Rate versus Loss
Middle plot of Figure 4 refers to a rate limitation Mbps on and loss rate on . In this case, contrary to the previous experiment, we see that both metrics have an impact in determining the breakdown. When breakdown is roughly equal for and , with a slight bias toward when bandwidth toward drops at 0.4 Mbps. When losses instead grow to , the bandwidth limited host is always preferred, though the actual bandwidth limit still slightly influences the breakdown value.
4.5.3. Delay versus Loss
Finally, bottom plot of Figure 4 refers to a delay enforcement of s on and loss rate on Again, both metrics play an important role in determining the breakdown, depending on the impairment level. As expected, loss does not constitute a significant impairment, as such lossy path is preferred toward high path, when s, peer is almost completely ignored. Behavior changes completely as soon as losses grow to , in which case breakdown favors completely when s and is more fairly split when s.
The above observations allow us to conclude that the relative preference of pathwise metrics is weighted on the ground on the actual magnitude of the impairment. In principle, we point out that by exploring a wider number of impairment couples, it should be possible to get an even finer picture of the relative preference, but this falls outside the scope of this paper.
5. Experimental Results: Peerwise metric
In this section, we refine the picture of PPLive awareness by mining data gathered in the multiple-vantage point testbed. Following the methodology defined in [3], we extract from our traces about 16500 peers that contribute by providing video content. We focus on peers' Autonomous System () and geographical location, which we represent by Country Code () information. For each probe peer in the testbed, we analyze the and properties of all its contributors peers , gathered by whois and open IP databases queries. We point out that contributors in this case may be either probes taking part in the experiment, or external peer of real users. As such, we no longer control the properties related to their path, and we need to infer them from packet level traces in case of need.
As core tool in this case, we use a correlation-based analysis, inspired by Principal Component Analysis (PCA) technique. While PCA is often used for dimensionality reduction—that is, to transform a set of correlated variables into a smaller subset of uncorrelated variables, called principal components—in our case our aim is to gauge the extent of the correlation, so to show the existence of a dependence (if any) between these variables.
More precisely, let us consider a set of contributor peers observed during an experiment. By denoting with the value of property for peer and similarly with the value of property for the same peer, we measure the correlation between and over the whole experiment as
where and are the means of and over all samples, and are the sample standard deviations of and , respectively. Usually, (1) is referred to as the Pearson product-moment correlation coefficient which, dropping the sum bounds for the sake of readability, can be rewritten as
5.1. Autonomous System and Geolocation
We are interested in assessing if PPLive is - and -aware, and whether its video scheduling policy exploits such information; that is, if in other words our PPLive probes tend to download video content from contributors falling in the same or . By mining the experimental data, we find that, despite only of peers fall in the same of the probe, about the of bytes are downloaded from them to further quantify this evident degree of geolocalization among contributors, we evaluate the coefficient of correlation between the amount of bytes received from any given contributor and the fact that this contributor belongs to the same or . Considering all probes in the experiments, and by using the indicator function when both and belong to the same or , we obtain and , respectively, which accounts for modest (though not negligible) correlation.
This is however surprising, since the controlled testbed early suggested that PPLive peers are greedy in terms of bandwidth, but that are not sensitive otherwise to the fact that contributors are “close” in underlay terms (e.g., IP distance or latency).
5.2. Bandwidth
We are therefore interested in assessing if (and to what extent) the geolocation can be a (rather desirable) side effect of PPLive bandwidth sensitivity. Therefore, we further evaluate the bandwidth (BW) between probes and contributor by measuring the throughput of chunks, which are typically sent out in packet bursts, to further investigate the existence of correlation between peerwise metrics.
5.2.1. Bandwidth Estimation Techniques
Since we are unaware of the technique actually employed by PPLive to measure the available bandwidth, we adopt a hands-on approach; we estimate using multiple techniques and require an agreement of our observations over all techniques. Considering only the downstream traffic direction of a contributing peer toward one of our testbed probes, we evaluate the over windows of fixed length. We express the window length in terms of either (i) a number of consecutive packets or (ii) a temporal duration . Let us denote by and , respectively, the arrival time and size of the th packet downloaded by probe from contributor during the current observation window. In case of fixed-length packet trains, we estimate the bandwidth over the current window as the amount of bytes carried by the train of consecutive packets as In case of fixed-duration trains, we estimate the bandwidth as where is the number of packets received during .
As far as the window length and duration are concerned, we point out that their choice is made complex not only by the fact that we are unaware of the chunk size and chunk start time, but also from the fact that the estimation can be severely influenced by factors such as interrupt coalescing (which however affects both our estimates and PPLive methodology as well). We argue that choosing large values of and would yield less noisy results, but due to chunk scheduling policy, it may introduce a bias in the result. Intuitively, counting the number of packets over large time windows equals to count the number of chunk exchanged, rather than their actual transmission throughput. Using large windows, peers that more actively contributed to the transmission will thus appear as both preferred and high-bandwidth, introducing thus an artificial correlation between the two terms. To avoid this bias, shorter windows should be preferable. At the same time, too small values of and should be avoided, indeed, as packets are sent out in bursts, it may happen that interrupt coalescing (which we verified to be present in out traces) can squeeze the packet arrival pattern and increase the estimated .
In reason of the above observations, we select values of packets and ms. For every peer pair, we then construct a series of several samples gathered during the whole experiment, of which we then compute the mean and 99th percentile () values; we argue that both statistics are relevant, since the mean value is indicative of instantaneous network conditions, whereas may be more representative of peer access capacity. For lack of space, we will only report a subset of results, selecting packets and ms, since we verified that the same conclusions hold using the other parameters as well.
Scatter plot of the amount of received traffic versus mean bandwidth is depicted in Figure 5, using ms and log-log scale. Dark points represent exchanges between any two probes in the same LAN, white points are used for probes belonging to our testbed but belonging to different institutions, whereas any other contributor is represented with a small dot. First, hosts within our testbed, and especially hosts within the same LAN, achieve higher rates with respect to Internet hosts. Moreover, the estimated values are sound and consistent with our expectation.
5.2.2. Correlation-Based Analysis
Another interesting observation to gather from Figure 5 is that host achieving higher data rates also tend to contribute more data, and that this behavior is consistent across all three host groups.
To further quantify this behavior, we evaluate the coefficient of correlation between the amount of bytes received by a given probe and the bandwidth toward that contributor. For comparison purposes, we also evaluate the coefficient of correlation between the estimated bandwidth between two peers and the fact that they belong to the same or (using the indicator function as before). Though we are aware of the fallacies of correlation based analysis, we point out that we do not seek to prove directional cause-effect relationship between variables, but that we rather compare the magnitude of the correlation and relatively weight their impact.
Results are reported in Table 2 for different bandwidth estimation methods. In case of we also consider different peers subsets, namely, peers falling in the same LAN, peers that do not belong to the same LAN and all the peers altogether. As expected, we observe that irrespectively of the evaluation method considered, there is medium correlation between received bytes and bandwidth , which is clearly stronger for peers belonging to the same LAN. Moreover, notice that this correlation is stronger with respect to or reported earlier, even when all peers are considered. Also, notice that the correlation between bandwidth and geolocation (i.e., the fact that high bandwidth contributors can be found within the same ) is of the same order of magnitude of (i.e., the fact that video content is downloaded from contributors within the same ). Overall, these observations suggest that, even outside the LAN environment, peers are primarily looking for bandwidth and that the early noticed geolocalization may be a beneficial side effect of the enforced bandwidth preference alone. Finally, we point out that part of the correlation might be explained by means of (i) mutual dependency between and , as well as (ii) additional hidden factors which causes both and bandwidth preference. At the same time, such hidden factors (e.g., preference based on IP/16 address similarity) are likely to play only an additional role beside the one played by the bandwidth, to which we shown early PPLive being extremely sensitive to.
6. Conclusions
This work proposed a methodology, based on the joint use of active and passive measurement technique for the analysis of the network awareness of currently deployed Internet P2P-TV system. The technique has been designed so to consider P2P systems as a black-box and as such can be applied to future systems as well. As a case study, we applied the methodology to the analysis of PPLive a very popular system nowadays, gathering interesting results, that we briefly summarize here.
First of all, by means of active testbed methodology, we find PPLive to be extremely sensitive to bandwidth, only mildly sensitive to losses and mostly unaware of IP distance, expressed in terms of either delay or IP hop count, which is in agreement with [12]. Refining further this picture, we find that actually the peer selection process is continuously updated, with a relative preference among pathwise properties that depends on the actual magnitude of the impairment.
Interestingly, by the correlation analysis of peerwise preference gathered through the passive technique, we find that the very same bandwidth sensitivity of PPLive seems to induce a desirable side effect, namely, a moderate geoclusterization of peers within the same AS and CC. Yet, it seems that PPLive does not, for the time being, explicitly enforce AS-awareness, which remains thus a new exciting challenge for the next steps of its evolution.
Acknowledgments
This work was funded by EU under the FP7 Collaborative Project “Network-Aware P2P-TV Applications over Wise-Networks” (NAPAWINE). The authors wish to thank all the project partners for having taken part to the multiple live measurement experiment.