On the applicability of available bandwidth estimation ... - CiteSeerX

5 downloads 78627 Views 538KB Size Report
Aug 27, 2009 - Available Bandwidth Estimation Techniques and Tools (ABETTs) have recently ... nent in network management tools and platforms that monitor.
Computer Communications 33 (2010) 11–22

Contents lists available at ScienceDirect

Computer Communications journal homepage: www.elsevier.com/locate/comcom

On the applicability of available bandwidth estimation techniques and tools Cesar D. Guerrero 1, Miguel A. Labrador * Department of Computer Science & Engineering, University of South Florida, 4202 East Fowler Ave., ENB 118, Tampa, FL 33620, United States

a r t i c l e

i n f o

Article history: Available online 27 August 2009 Keywords: Available bandwidth estimation Performance evaluation Factorial design Active network measurement

a b s t r a c t Available Bandwidth Estimation Techniques and Tools (ABETTs) have recently been envisioned as a supporting mechanism in areas such as compliance of service level agreements, network management, traffic engineering and real-time resource provisioning, flow and congestion control, construction of overlay networks, fast detection of failures and network attacks, and admission control. However, it is unknown whether current ABETTs can run efficiently in any type of network, under different network conditions, and whether they can provide available bandwidth estimates at the timescales needed by these applications. This article includes a performance evaluation of Pathload, Pathchirp, Spruce, IGI, and Abing in a low cost and flexible test bed. The evaluation includes scenarios and conditions not evaluated before, such as varying the packet loss rate and the propagation delays of the links, the amount of cross-traffic, the capacity of the links, and the cross-traffic packet size. The results demonstrate that ABETTs are far from being ready to be applied in all these applications and scenarios. In addition, the article clearly indicates those aspects that need further research and which ABETTs are the best candidates for specific applications and environments. Ó 2009 Elsevier B.V. All rights reserved.

1. Introduction and motivation The available bandwidth of an end-to-end path is a time-varying metric, which is defined as the minimum of all non-utilized link capacities throughout the communication path. If a path composed of H hops is considered, the available bandwidth is given by Aðt; t þ sÞ ¼ mini¼1...H Ai ðt; t þ sÞ, where s is the period of time during which the estimation is averaged. The link with the minimum capacity is known as the narrow link and the link with the minimum available bandwidth is known as the tight link. The tight link is considered the bottleneck of the path and the link that determines the end-to-end available bandwidth. More details about these well-known definitions can be found in [1]. Recently, the estimation of the available bandwidth of an endto-end path has received considerable attention due to its applicability in many useful scenarios. For example, Available Bandwidth Estimation Techniques and Tools (ABETTs) are an essential component in network management tools and platforms that monitor large networked systems. However, ABETTs are also being envisioned as a supporting mechanism in many other networking applications and scenarios. For instance, ABETTs could be used to monitor and verify service level agreements, which would provide users and service providers with accurate information to manage

* Corresponding author. Tel.: +1 813 974 3260. E-mail addresses: [email protected] (C.D. Guerrero), [email protected] (M.A. Labrador). 1 In part supported by the Universidad Autonoma de Bucaramanga, Colombia. 0140-3664/$ - see front matter Ó 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2009.08.010

their contracts. Transport layer protocols might use ABETTs to change the transmission rate according to the amount of bandwidth available in the path, which would allow network resources to be used efficiently while avoiding congestion. Traffic engineering mechanisms would be able to perform real-time resource provisioning while balancing the load of the network. Overlay networks could use ABETTs to find the most appropriate topology. Call admission control mechanisms might take advantage of ABETTs to either admit or reject a new incoming connection, which would avoid network congestion and guarantee the quality of service for current and new connections. ABETTs could also be used in network security, as they could provide very valuable information to detect network failures and malicious attacks. Although the envisioned usefulness of ABETTs is not in question, legitimate questions arise: Can current ABETTs actually be used in all these envisioned applications? Can they provide estimates at the time scales required by all these applications? Can these techniques and tools be used regardless of whether the application is run over a low bandwidth wired network, or a wireless mobile ad hoc network, or a satellite network, or even a high bandwidth clean optical network? In this paper, a flexible and low cost testbed was built to evaluate and compare the performance of current ABETTs in a common and parameterizable environment and answer all these questions. The main results demonstrate that ABETTs are far from being ready to be used in all these envisioned applications. Nonetheless, the results and conclusions presented in the paper can be used by network managers and practitioners as a guide when choosing the most appropriate tool for their own

12

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

application, type of network, and network conditions. Similarly, network researchers will benefit when attempting to identify those areas where additional research is needed. The rest of the article is organized as follows. The next section includes a brief related work about past performance evaluations. The performance metrics that were used to determine the suitability of the estimators for different applications and networking environments are described next. A brief description of the techniques and tools that are currently available to estimate the available bandwidth of an end-to-end path is also included. The testbed and the methodology utilized in the experimental evaluation of the tools are detailed next. Finally, the results and analysis of the evaluation, along with the concluding remarks about the applicability of current ABETTs to different application domains, network types, and network conditions, are presented. 2. Related work Several papers have evaluated available bandwidth estimation tools using real networks. For example, Shriram et al. [2] evaluated Abing, Pathchirp, Pathload, and Spruce in a testbed with links of OC48 and 1 Gbps capacities using passive monitors to verify the actual load level of the generated traffic. The problem with these experiments is that they only provide a partial picture of the evaluation, as the researchers did not have the capability to change several network parameters. In [3], Lee et al. describe problems with several available bandwidth and capacity estimation tools when tested on the PlanetLab infrastructure. While Spruce was the most accurate tool, Pathload had run-time errors and IGI provided very inaccurate results. Among the available capacity estimation tools, Pathrate [4] was the only tool that run in a fairly consistent manner but still presented several accuracy issues, in particular when the tool interplayed with bandwidth limiting shapers. Also, the PlanetLab infrastructure introduced some issues itself. First, network paths connecting PlanetLab nodes were found to be highly heterogeneous in the capacity values and did not necessarily show capacity symmetry. Second, PlanetLab nodes may not represent the global Internet. In [5], Angrisani et al. evaluated IGI, Iperf, and Pathload over a local area network and used MGEN [6] as a traffic generator. This evaluation suffers similar flexibility problems like the ones found in [2]. Also, the authors do not measure the overhead generated by the tools. In [7], Sommers et al. compared a new tools called YAZ with Pathload and Spruce. Although the authors include several network scenarios, they are not able to tune the values of different network parameters. There are several differences between previous works and the work presented in this article. First, a very low cost and flexible testbed is used here. It is a controlled environment where the researcher has the capability to create many network scenarios changing network parameters such as the capacity of the links, propagation delays, packet loss rates, queue sizes and amount of cross-traffic. Second, we use a factorial design technique to determine from the complete set of possible network scenarios, those which have an impact in the performance of the tools under evaluation. The results presented here correspond to those important cases. Finally, this evaluation is the only one in the literature that utilizes the results of the performance evaluation to analyze the applicability of ABETs in different network applications, which is the main goal of the paper. 3. Current available bandwidth estimation techniques and tools The estimation of the available bandwidth in an end-to-end path has been performed based on two different models: the Probe Gap Model (PGM) and the Probe Rate Model (PRM). The Probe Gap

Model bases the estimation on the gap dispersion between two consecutive probing packets at the receiver, which has a strong correlation with the amount of cross-traffic in the tight link. Therefore, the available bandwidth is estimated by determining the amount of cross-traffic and subtracting it from the known capacity of the tight link. Assuming that the tight link and the narrow link are the same, the capacity can be calculated using well-known and accurate tools, like Pathrate [8]. Interested readers can find more information about capacity estimation tools and techniques in [9]. Examples of tools in this category are Initial Gap Increasing (IGI) [10], Spruce [11], Abing [12], and the estimator developed by Maryni and Davoli [13]. IGI finds an initial probing gap value that guarantees interactions between probing packets and cross-traffic in a non-empty narrow link queue. The authors find the Joint Queuing Region (JQR) where there is a proportional relation between the gap when probing packets leave the queue (output gap) and the cross-traffic. Therefore, the output gap value is used to estimate the amount of cross-traffic in the tight link and thus estimate the available bandwidth by subtracting that value from the bottleneck link capacity. In [10], the authors show that in the case of multiple hops and significant cross-traffic following the tight link, the accuracy of IGI suffers. Similar results are found when the tight link is not the narrow link. Other authors have found that IGI was unresponsive to variations in cross-traffic at Gbps speeds [2]. IGI sends fixed size probing packets of 500 bytes. Spruce sends a Poisson sample of 1500-byte UDP packet pairs with an intra-pair gap equal to the narrow link transmission time of a 1500-byte packet. This gap guarantees that the second packet arrives at the narrow link before the first packet leaves that queue. Using the dispersion of the probe packets measured at the receiver, Spruce calculates the average rate of the cross-traffic that arrives to the queue between the two probe packets. Again, the available bandwidth is determined by subtracting that cross-traffic rate from the capacity in the bottleneck link. Abing sends back-to-back 1500-byte long packet pairs with a known separation of 50 ms. The final time delay Td between packet pairs has the information of the amount of cross-traffic throughout different links with different capacities. The authors observed two components in Td. One component is common to all individual measurements and is caused by the narrow link; the other component reflects queuing changes. Therefore, the packet dispersion has a linear and a non-linear grow. Abing sends 40 probing packets per measurement to calculate a mean value for Td and then, the amount of cross-traffic and the available bandwidth in the path. Another tool that belongs to the PGM category is Delphi [14]. The Probe Rate Model is based on the idea of induced congestion, in which probe packets are sent at increasing rates. At the receiver, the delays of the probe packets are measured to determine the point at which they start increasing in a consistent basis. The available bandwidth is then estimated looking at the probe packet rate utilized when the turning point is found. Pathload [15], Pathchirp [16], PTR [10], and TOPP [17] are examples of tools utilizing this approach. Pathload uses the principle of Self-Loading Periodic Streams (SLoPS) [18]. SLoPS is based on the fact that the one-way delay of a periodic packet stream increases only when the rate of the probing traffic is higher than the available bandwidth in the path. A fleet of streams (of a fixed number of packets each) are sent at varying rates and the one-way delay trend of each stream is then characterized at the receiver. When the delay is in the grey region (not clearly increasing nor decreasing), the methodology presents a variation range of the available bandwidth for a user-specified resolution. Pathload sends periodic packet streams of UDP traffic and uses a TCP connection to send trend results back to the sender. Given a desired stream rate R, Pathload sets the packet inter-depar-

13

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

ture time T at 100 ls and calculates the necessary packet size L to satisfy R ¼ L=T. If L is less than 96 bytes, Pathload uses this minimum value and calculates T instead. Pathchirp uses the induced congestion principle too. Instead of sending packet trains at a specific rate, Pathchirp increases the probing rate within each chirp (having a variable number of packets) in an exponential manner. By doing that, Pathchirp captures delay correlation information using a smaller number of probing packets. Pathchirp also uses variable size probe packets of minimum 40 bytes. In this article, we evaluate and conclude about the applicability of five available bandwidth estimation tools that have been partially evaluated by other authors. The tools are Pathload, Pathchirp, Spruce, IGI, and Abing. These are the best performing tools found in the literature in each of the two models. 4. Performance metrics and applications needs Available bandwidth estimation tools have been evaluated based on three performance metrics: accuracy, overhead, and estimation time. The accuracy metric provides a quantitative value that compares the estimation of the end-to-end available bandwidth, which is provided by the tool under consideration, with the real value, which is supposed to be known to the evaluator. In this article, the accuracy is given by the estimation error, or how much the tool estimate deviates from the actual available bandwidth in percentage terms. The overhead is related to the amount of probe packets that the tools inject into the network to perform the estimations. Most ABETTs are active probing measurement mechanisms, therefore, they sample the system sending probe packets. For the purposes of this evaluation, the overhead is defined as the percentage of tool traffic with respect to the total capacity of the tight link. The estimation time is a measure of the time required by the tool to provide the estimate. Estimation time is measured in seconds. In addition to the three standard metrics, a fourth metric termed reliability is included in this evaluation. The reliability provides information about the robustness of the tool in providing estimations. The reliability is given by the percentage of times the tool succeeded in providing an estimate. It is calculated dividing the number of valid replications for a particular experiment by the final number of trials performed to reach that number. Thus, a 100% reliable tool would require exactly n trials to provide n valid estimations. According to these performance metrics an ideal tool should provide very accurate estimations, with very low or no overhead, in almost no time with 100% reliability. However, an ideal tool is very difficult to achieve as these are contradicting metrics. For example, highly accurate results are usually achieved increasing the number of samples. More importantly, not all applications require an ideal tool, and certain requirements could be relaxed or

C

strengthened according to the specific application and the current networking environment. For example, an application that monitors the compliance of SLAs in wired networks needs the ABETT to have high accuracy, medium overhead, medium or low estimation time, and medium reliability. Although these requirements might be different if the same ABETT is utilized in wireless networks, it can be said that one strong requirement is high accuracy. Inaccurate estimations cannot be afforded in this application. Similarly, if an ABETT is to be used to drive the flow and congestion control mechanisms of a transport layer protocol, it has to be fast and introduce almost no overhead. In this application, the estimation does not need to be very precise. A good estimation might be acceptable but it has to be fast. Fast estimations are required in order for the protocol to react on time to rapidly changing network conditions. In addition, the ABETT for this application must provide no overhead. Otherwise, the huge number of transport layer connections over the Internet will drive the ‘‘goodput” of the network to very low levels. As a final example, consider an ABETT to detect security attacks. In this application, the most important metrics are the estimation time and the reliability of the tool. This applicability to different network applications calls for a ‘‘parameterizable” ABETT that does not exist yet. 5. Methodology This section presents the network infrastructure utilized in the performance evaluation and describes the factorial design method used to select the most relevant set of factors, experiments and results. 5.1. Experimental testbed In order to experimentally evaluate the available bandwidth estimation tools, the testbed shown in Fig. 1 was built. This is a fully controlled environment with parameterizable links in terms of link capacities, packet loss rates, queues sizes, and propagation delays. In addition, the amount of cross-traffic and its statistical distribution can be controlled on a per link basis. The testbed has three main components: one client, four intermediate routers, and one server. They are six computers with AMD Athlon 64 3500+ processors, 1 GB RAM, and 80 GB hard drive capacity interconnected through two private networks. A 1 Gbps 192.168.X.X network is utilized to carry all the traffic related to the evaluation of the tools while a 100 Mbps 10.0.0.0 network is used to configure and run the experiments. These two networks were established to separate configuration data from evaluation data. The client and server are Linux-based machines running a 2.6.18.2 kernel with 10,000 Hz timer granularity. They host the available bandwidth estimation tools under investiga-

o m

[ Testbed control packets throughout a 10.0.0.0/24 network ]

Link A

Link B

Link C

192.168.3.0/24

192.168.2.0/24

192.168.1.0/24

Link D 192.168.0.0/24

192.168.4.0/24

Client

US

Colombia BET tool traffic

China Cross Traffic

Fig. 1. Testbed to evaluate bandwidth estimation tools.

Spain

Server

14

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

tion. Intermediate routers are implemented by four 6.2-RELEASEFreeBSD machines emulating a multi-hop network path. The kernel has been recompiled to host a packet shaper called Dummynet [19] and to run at the same end nodes granularity. Dummynet can change the capacity of each link from 0 to the physical capacity, and introduce packet losses and delays to emulate lossy and long links. Different queue sizes can also be established if so desired. The MGEN [6] traffic generator was used to generate cross-traffic. MGEN allows to choose the rate, packet size, and the statistical distribution of the cross-traffic. In order to have independent queues, the cross-traffic is introduced on a per link basis, i.e., enters at the input of each queue and leaves the network before the subsequent queue (see Fig. 1). The Dummynet-based testbed is accurate and introduces no significant errors in the results. Using netperf and iperf it was verified that TCP achieved a throughput of up to an average of 340 Mbps, and UDP 670 Mbps; using ping, the testbed emulated delays with 97.53% average precision; tcpdump traces verified that the testbed emulated packet loss rates with a 99.84% average precision; finally, tcpdump traces showed that MGEN generated traffic with 96.19% accuracy. Although the testbed interface cards were able to transmit packets at higher speeds, we limited the evaluation to link transmission rates of up to 200 Mbps considering that end hosts in a real network path are mostly general-purpose personal computers equipped with either 100 or 1000 Mbps NICs, and their effective transmission rates are considerably lower than that. For example, Zhou et al. [20] estimated the achievable throughput for six different operating systems installed on different computers and showed that NIC utilization is less than 80% for 100 Mbps cards and less than 40% for a 1 Gbps cards. 5.2. The 25 factorial design Given the number of factors and levels that should be considered in the evaluation of the tools, a factorial design was carried out to reduce the number of experiments and figure out which factors are important in the performance of the tools. As such, 32 sets of experiments were carried out to perform a 25 factorial design following standard statistical procedures found in the literature [21]. In a 25 factorial design, experiments are performed using two extreme values for each of the five factors to collect one sample of each performance metric for each tool. In order to have statistically confident results, we performed as many experiments as needed such that 10 valid results from each experiment were obtained. Then, 95% confidence intervals were calculated using the Student’s t-distribution. As a result, 1600 (32  10  5 tools) experiments were run in this phase. Table 1 shows the five factors (tight link capacity, link propagation delay, packet loss rate, percentage of tight link capacity used by cross-traffic, and cross-traffic packet size) and the low and high values selected for each factor. As stated before, we are interested in four performance metrics or response variables: the accuracy of the estimation, given by the percentage error of the estimate compared with the real value; the overhead, given by the percentage of the tight link capacity utilized by the probe traffic; the estimation time in seconds; and the reliability of the tool, given by 10 estimations divided by the total Table 1 Factors and levels utilized in the 25 factorial design. Factor

Level (1)

Level (+1)

Tight link capacity One-way propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

5 Mbps 10 ms 0.01 25% 512 bytes

100 Mbps 80 ms 0.07 75% 1408 bytes

number of times the tool had to be run to obtain those 10 values. In all these experiments and unless noticed otherwise, each output queue in the path had a buffer size equal to 50 slots and employed the Drop Tail queue management policy, the cross-traffic type used was Poisson sending 1408-byte long packets, and all the link capacities were set to 200 Mbps. From the 25 factorial design, we determined the main effects of varying each factor on the response variables, which are shown in Table 2. In addition, we also calculated the average interaction of two, three, four, and five factors, which are not included in this article.2 It is worth noticing that the factorial design help us determining what are the network parameters that have an influence or impact on the variation of a particular metric; however, these results do not say much about the absolute value of the metric. For example, in the case of Pathload, the effect of increasing the tight link capacity from 5 to 100 Mbps on the estimation error was found to be 21.86%. This result means that Pathload negatively varies its estimation error downwards with an average 21.86% as the capacity of the tight link increases, however, this result does not mean that the estimation error improved or declined by 21.85%. Using a graphical representation, Fig. 2 summarizes the main effect of varying each factor on each response variable for each of the tools, as having some impact, medium impact, and high impact. From the figure, the following main conclusions can be made:  The variation of any of the factors considerably impacts the estimation error variation for IGI, Abing, and Pathchirp. This is an indication of the inaccuracy of these tools. Therefore, the applicability of these tools may be limited to those applications that do not need to have very precise estimations. Spruce and Pathload are the least affected tools in the sense that their estimation errors do not vary much, independently of whether the estimates are accurate or not. The accuracy of Pathload is mainly affected by changes in the packet loss rate and the capacity of the tight link. Therefore, this tool might not be a good choice for those applications running over wireless networks, which usually have higher packet loss rates and low bandwidth channels. Spruce’s accuracy is impacted by the amount of cross-traffic (congestion) and the capacity of the tight link. Additional experiments need to be made to better analyze the accuracy of these tools. It is worth mentioning that ABETTs have not been analyzed under different packet loss rates before.  The overhead that the tools insert into the network to perform the estimations is almost unaffected by the variation of any of the factors, except for Abing, which seems to be affected by the capacity of the tight link. Therefore, only experiments with variations in the capacity of the tight link will be performed to observe the overhead shown by the tools in more detail. Recall that this conclusion does not mean that the tools do not insert a considerable amount of overhead but that the overhead that they introduce is fairly constant regardless of the factors.  With the exception of Pathload, the estimation time of the tools is barely affected by any of the factors, meaning that the tools take a similar amount of time to converge. This is a good feature, as it provides predictability in the estimation time. The estimation time of Pathload is shown to be affected by the capacity of the tight link, the propagation delay, the packet loss rate, and the amount of cross-traffic. Given these results, the applicability of Pathload may be limited to non-real-time applications, or applications that do not need to have a bounded response time.

2 All the numerical results can be seen at http://www.cse.usf.edu/~guerrerc/BET/ exp.htm.

15

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22 Table 2 Main effect in the performance metrics of Pathload, IGI, Spruce, Abing, and Pathchirp when varying one factor. Factor

Response variables Error (%)

Overhead (%)

Pathload Tight link capacity Propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

21.86 1.62 88.55 6.06 4.24

3.122 1.359 2.228 0.757 0.653

IGI Tight link capacity Propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

80.43 121.25 58.13 329.38 110.51

Spruce Tight link capacity Propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

Time (s)

Reliability (%)

29.2143 28.9783 31.9278 12.2796 8.3383

0.00 0.00 0.00 0.00 0.00

2.054 0.230 0.408 0.0004 0.036

1.7479 1.8841 5.2755 3.8677 1.4988

0.00 0.00 0.00 0.00 0.00

25.60 0.80 3.47 26.80 5.06

2.145 0.125 0.296 0.020 0.008

0.2870 0.6190 4.3325 0.2261 0.5007

7.33 1.13 26.12 0.05 0.91

Abing Tight link capacity Propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

636.00 325.84 64.18 744.01 311.76

14.722 2.048 0.829 0.014 0.046

0.0018 0.2870 0.0282 0.0100 0.0083

1.50 0.05 38.06 3.06 0.95

Pathchirp Tight link capacity Propagation delay Packet loss rate Percentage of cross-traffic Cross-traffic packet size

283.64 11.11 111.77 229.73 40.67

4.726 0.065 0.624 0.182 0.091

0.1625 0.0375 0.8750 1.3375 1.6625

0.00 0.00 0.00 0.00 0.00

Pathload will suffer from high variations in its response time when used over wireless and satellite networks, which have higher packet loss rates, low bandwidth, and long propagation delay links.  The packet loss rate is the only factor that affects the reliability of the tools, and only affects Spruce and Abing. More experiments are needed to determine the reliability level of the tools and the packet loss rate at which the reliability becomes critical.

 The accuracy of IGI, Abing, and Pathchirp is very sensitive to variations in the capacity of the tight link and the amount of cross-traffic in the network. More specifically, when these two factors are increased, a negative variation in the estimation error is obtained. A similar trend is observed when the packet loss rate and the amount of cross-traffic are increased.  The estimation time of Pathload is highly affected by variations in the capacity of the tight link, the packet loss rate, and the amount of cross-traffic.  When all factors are combined, IGI’s estimation error is the most affected but its overhead is the most stable. The estimation time of Abing shows the most stable behavior.

Similarly, we analyzed the average effect that the combination of two, three, four, and all five factors have in the performance metrics (results not shown here). Here are the main observations from that analysis:

Error

Time

Reliability Abing

Pathchirp

Spruce

IGI

Pathload

Abing

Pathchirp

IGI

Spruce

Pathload

Pathchirp

Abing

Spruce

IGI

Pathload

Abing

Pathchirp

Spruce

IGI

Pathload

Factors

Overhead

Capacity Delay PLR % of XT XT PSize

some impact

Medium impact 5

High impact

Fig. 2. Summary of the main effect of varying the factors of the 2 factorial design on the response variables of the ABETTs under evaluation.

16

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

6. Results and analysis Based on the results obtained from the factorial design just presented, this section presents additional evaluations to show the performance of the tools while varying those factors that affected them the most. In all experiments and unless noticed otherwise, each output queue in the path has a buffer size equal to 50 slots and employs the Drop Tail queue management policy, all link capacities are set to 200 Mbps, the one-way propagation delay is set to 10 ms, the packet loss rate is set to 1%, the cross-traffic type is Poisson sending 1408-byte long packets and loading the network at 20% and 75% of the tight link capacity. It is worth noticing that the results and trends obtained using Poisson traffic match previous results presented in the literature very closely, even in those cases where the evaluations utilized Internet traces. It is worth noticing that although the graphs do not include the 95% confidence intervals (for clarity), this information was indeed utilized to draw the conclusions. The estimations of the real value of the available bandwidth were obtained at each intermediate node using tcpdump with the e option to capture the packet size at the IP level; the estimations did not include the traffic injected by the tools. Pathload estimations were calculated and reported as in [15], i.e., plotting the central point of the range given by the tool. Similarly, Pathchirp measurements were calculated using the averages obtained from the output file generated by the tool. In those cases where the tools aborted the measurement and provided artificial results, these results were not included in the calculation of the averages and confidence intervals. However, they were considered in the computation of the reliability of the tool. Finally, it is important to mention that artificial packet losses were introduced by Dummynet, but additional losses happened due to network congestion.

6.1. Experiments with different tight link capacities The first set of experiments look at the performance metrics while varying the capacity of the tight link from 10 to 200 Mbps under low and high congestion. Regarding the estimation error, Fig. 3(a) and (b) shows that the tools go from overestimating to underestimating the available bandwidth as the capacity of the tight link increases. In low congested networks, the capacity of the tight link does not seem to have much effect on the accuracy of the tools, except in the case of IGI and Spruce, which present estimation problems in scenarios with low and high capacity links, respectively. Fig. 3(a) and (b) shows that the accuracy of the tools is mostly affected in highly congested scenarios where they present highly variable estimations. Regardless of the level of congestion, Pathload and Spruce (in that order) are the most accurate tools. Pathload tends to overestimate the available bandwidth in low congested scenarios and underestimate the bandwidth in highly congested ones. Spruce presents estimation problems when the link capacity goes beyond 100 Mbps. This behavior is mainly due to the timestamp resolution required for the probing packets in links with these speeds. On the other hand, IGI and Abing are shown to be highly inaccurate, especially in scenarios with high congestion and low capacity links (with estimation errors higher than 100%). Finally, Pathchirp is fairly accurate in low congested scenarios while it presents high estimation errors in highly congested ones, especially when low capacity links are used. Pathchirp estimation errors are usually less than 50% except in this case where the error can be as high as 150%. The results of this first set of experiments confirm what we already know about the accuracy of the tools from different authors [16,10,11,15] and validate our experiments and testbed. Now, considering the applicability of

the tools, if accuracy is important for the application at hand, Pathload and Spruce seem to be the best tools regardless of the link capacities and the amount of network congestion. The capacity of the tight link does not seem to have a strong impact on the estimation time of the tools. Only Pathload, under heavy congestion seems to be affected, increasing the estimation time with the capacity. This is due to its binary search algorithm, which is called to find greater rates in small ranges of available bandwidth. Other than that, all tools present fairly low variability as the capacity of the tight link is varied. It can be seen that the estimation time of the tools also shows a well-known trend. Pathload is the slowest tool to converge, followed by Pathchirp, Spruce, IGI, and Abing in that order. Another important aspect is that the estimation time of the tools does not seem to be affected by the level of congestion in an appreciable way. Regardless of the congestion level, Spruce, Pathchirp, and Abing show low variation and lower estimation time than Pathload. Pathchirp gives a mean estimation time of around 14 s. Spruce’s estimation time is around 12 s while Abing is the fastest tool with an almost constant 1 s estimation time. IGI is the second fastest tool but its estimation time depends on the congestion level. IGI’s estimation time is around 4 s in lightly loaded networks but it reaches 15 s (and with high variability) in heavily congested networks. This part of the evaluation clearly shows that, in general, current ABETTs are not able to converge in sub second or millisecond timeframes, limiting their applicability to non-real-time applications, or those applications that do not need to react or make decisions based on the available bandwidth estimates in millisecond ranges. The results show that the overhead of the tools decreases with the capacity of the tight link. This is a clear indication that the overhead introduced by the tools is rather constant, i.e., the tools need a similar amount of probe packets to make the estimation regardless of the level of congestion and the capacity of the network. Fig. 3(e) and (f) shows that Pathload and Abing are the most intrusive tools. Pathload’s probe packets take approximately 6% and 1.5% of the tight link capacity in scenarios with light and heavy congestion, respectively. Pathload is less intrusive in scenarios with high congestion because it works filling the available pipe capacity. However, as the capacity of the tight link is increased, the amount of overhead needed by the tool decreases, i.e., the tool is able to find the available bandwidth more efficiently when the available capacity is big. The other tool that uses the same induced congestion principle is Pathchirp; however, as it is argued in [16], Pathchirp needs less than 10% of the probing traffic that Pathload uses. Pathchirp sends the probe packets using a different gap distribution algorithm that makes the tool to converge faster with fewer probe packets. On the other hand, Abing utilizes a fixed and rather large amount of overhead to perform the estimations. This is why the overhead decreases with the capacity of the tight link and the level of congestion. IGI and Spruce are the tools that introduce the least amount of overhead (less than 0.5%). From this set of experiments, it is clear that those tools using the Probe Gap Model are better suited for those applications that run over networks with scarce capacity, such as wireless networks.

6.2. Experiments with different one-way propagation delays The second set of experiments look at the effect of the one-way propagation delay, which is varied from 10 to 80 ms. This is another scenario that has not been studied before and should provide information about the suitability of current ABETTs in networks with long delay links, such as networks with satellite connections. Fig. 4 shows the experimental results with low (5 Mbps) and high (100 Mbps) tight link capacities and heavy congestion (75% of cross-traffic). We only included the experiment results related to

17

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22 300

300

Estimation Error (%)

250 200 150 100 50 0

Pathload IGI Spruce Abing Pathchirp

250

Estimation Error (%)

Pathload IGI Spruce Abing Pathchirp

200 150 100 50 0

−50

−50

−100

−100 20

40

60

80

20

100 120 140 160 180 200

40

Tight Link Capacity (Mbps)

Estimation time (s)

20 15 10

Pathload IGI Spruce Abing Pathchirp

25 20 15 10 5

5 0

20

40

60

80

0

100 120 140 160 180 200

20

40

Tight Link Capacity (Mbps)

60

80

100 120 140 160 180 200

Tight Link Capacity (Mbps)

(c) Estimation time at 20% cross-traffic.

(d) Estimation time at 75% cross-traffic. 10

Pathload IGI Spruce Abing Pathchirp

9 8 7 6 5 4 3 2

% Tool Traffic in Tight Link

10

% Tool Traffic in Tight Link

100 120 140 160 180 200

30

Estimation time (s)

Pathload IGI Spruce Abing Pathchirp

25

80

(b) Estimation error at 75% cross-traffic.

(a) Estimation error at 20% cross-traffic. 30

60

Tight Link Capacity (Mbps)

Pathload IGI Spruce Abing Pathchirp

9 8 7 6 5 4 3 2 1

1

0

0 20

40

60

80

100 120 140 160 180 200

20

40

60

80

100 120 140 160 180 200

Tight Link Capacity (Mbps)

Tight Link Capacity (Mbps)

(e) Overhead at 20% cross-traffic.

(f)Overheadat 75% cross-traffic.

Fig. 3. Estimation error, estimation time, and overhead with variable capacity, 10 ms OWD, 1% PLR, and variable cross-traffic.

highly congested scenarios because they are the most challenging scenarios to the tools. With regard to the estimation error, Abing and Pathchirp are the most inaccurate tools with errors of more than 200%. This is why these results are not included in Fig. 4(a). In addition, Pathchirp’s error increases with the one-way propagation delay (not shown in the graph). That figure shows that Spruce and Pathload are the most accurate tools with less than 50% estimation error followed by IGI with an estimation error in the order of 100%. Although the increment in the one-way delay affected the accuracy of the tools compared to the results obtained in Fig. 3(b), most of the tools seem to be unaffected by additional increments. In general, we can say that all tools present overestimation problems. When the tight link is set to 100 Mbps, Fig. 4(b)

shows that the accuracy of the tools, with the exemption of IGI, improves compared with the 5 Mbps scenario, but the one-way propagation delay seems to have no major impact either. In general, only Pathload and Spruce seem to be adequate in these cases, as the estimation error of the rest of the tools is very high. Here, Spruce is even more accurate than Pathload with an estimation error of less than 15%. (Notice that the results of Spruce and Pathload are very consistent with the ones shown in Fig. 3(b) at 100 Mbps.) In terms of the estimation time, the tools do not seem to be affected by increases in the propagation delay. Fig. 4(c) shows that Pathload presents the worst estimation time, taking more than 100 s to converge compared with less than 15 s for the rest of the tools. Abing is definitively the fastest tool with an average

18

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22 250

250

200

Estimation Error (%)

Estimation Error (%)

200 Pathload IGI Spruce Abing Pathchirp

150 100 50

Pathload IGI Spruce Abing Pathchirp

150 100 50 0

0

−50

−50 10

20

30

40

50

60

70

10

80

One Way Propagation Delay (ms)

120

120

Estimation time (s)

Estimation time (s)

140

Pathload IGI Spruce Abing Pathchirp

60 40 20 0

40

50

60

70

80

(b) Estimation error at 100 Mbps.

140

80

30

One Way Propagation Delay (ms)

(a) Estimation error at 5 Mbps.

100

20

Pathload IGI Spruce Abing Pathchirp

100 80 60 40 20

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

One Way Propagation Delay (ms)

One Way Propagation Delay (ms)

(c) Estimation time at 5 Mbps.

(d) Estimation time at 100 Mbps.

80

Fig. 4. Estimation error and estimation time for variable one-way delay, 5 and 100 Mbps tight link capacities, 1% PLR, and 75% cross-traffic.

estimation time of 1 s. Similar trends were observed in the case of a 100 Mbps tight link. When the tight link is set to 100 Mbps, Fig. 4(d) shows that, although Pathload improves its estimation time, it still is the worst performing tool. This last figure shows how Pathload’s estimation time increases with the one-way propagation delay from 20 s to around 60 s. This behavior is expected since the tool adjusts the transmission rate according to the one-way delay variation shown by a probing packet train. Thus, the longer the propagation delay is, the slower the tool reacts. The other tools present steady convergence times regardless of the capacity of the tight link and the one-way propagation delay. Abing is definitively the fastest tool with an average 1 s estimation time while IGI, Pathchirp, and Spruce present convergence times of around 12 s or lower.

6.3. Experiments with different packet loss rates The third set of experiments is meant to study the performance of the tools in scenarios with different packet lost rates. These experiments are important to conclude about the utilization of current ABETTs in networks with lossy links, such as wireless networks, and to study the reliability of the tools. In this case, experiments were run using 100 Mbps tight link capacities and heavy congestion (75% of cross-traffic) while increasing the packet loss rate from 1% to 10%. Similar experiments were also run for low (5 Mbps) tight link capacities and low congestion; however, these results are not shown here because they also presented similar trends. With regard to the estimation error, Fig. 5(a) shows that the tools present different behaviors. For example, the estimation error is above 100% for Abing and IGI while it is below 50% (underesti-

mation) for Pathchirp and Pathload. In general, these results say that with the exemption of Spruce, which presents a steady and accurate estimation regardless of the packet loss rate, the rest of the tools are not suitable for applications running over networks with medium to high packet error rates, such as some wireless environments. Indeed, Pathload was not able to perform the estimation for a Dummynet-induced packet loss rate higher than 2%. The results depicted in Fig. 5(b) show that the estimation time of the tools is similar to previous scenarios, indicating that the packet loss rate does not affect the estimation time of the tools. As before, Pathload takes the longest time to converge, and Spruce and Pathchirp each takes around 12 s to converge. On the other hand, IGI’s estimation time tends to increase with the packet loss rate. As expected, Abing is the fastest tool with steady convergence times even lower than 1 s. The results of the reliability experiments are shown in Fig. 5(c). From the plot, it is clear that Pathload is the least reliable tool followed by Abing and Spruce. Pathload aborts the estimation and provides zero available bandwidth results. Spruce seems to have problems providing an estimate with Dummynet-induced packet loss rates of 1% and beyond 6% while Abing has problems regardless of the loss rate. The tools never failed in any of the rest of the experiments.

6.4. Experiments with different amounts of cross-traffic The next factor considered in the performance evaluation was the amount of cross-traffic in the tight link. Experiments were performed with 100 Mbps tight link capacities while varying the amount of cross-traffic (congestion) in the tight link from 10% to 80%. As before, experiments were also run with 5 Mbps tight link

19

300

35

250

30

200

Estimation time (s)

Estimation Error (%)

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

Pathload IGI Spruce Abing Pathchirp

150 100 50 0

20 15 10 5

−50 −100

Pathload IGI Spruce Abing Pathchirp

25

0 1

2

3

4

5

6

7

8

9

10

1

2

3

4

5

6

7

8

9

10

Packet Loss Rate (%)

Packet Loss Rate (%)

(b) Estimation time at 100 Mbps.

(a) Estimation error at 100 Mbps.

# of Valid Experiments / # Trials (%)

100 Pathload IGI Spruce Abing Pathchirp

90 80 70 60 50 40 30 20 10 0 1

2

3

4

5

6

7

8

9

10

Packet Loss Rate (%)

(c) Reliability at 100 Mbps. Fig. 5. Estimation error, estimation time, and tool reliability for variable packet loss rate, 100 Mbps tight link, and 10 ms Delay, and 75% cross-traffic.

capacities. From Fig. 6(b), it is clear that the estimation error of IGI, Abing and Pathchirp increases with the amount of cross-traffic. Pathload and Spruce, on the other hand, present fairly stable behavior regardless of the cross-traffic but with a tendency to underestimate the available bandwidth. In the 5 Mbps case, the tools present similar trends but they all tend to overestimate the available bandwidth. The estimation time results are very similar to those already presented and also consistent with the results shown in [2], where Pathload takes about 20 s to converge when the capacity of the tight link is high. The rest of the tools present stable behaviors regardless of the capacity of the tight link and the amount of cross-traffic. 6.5. Experiments with different cross-traffic packet sizes Finally, the effect of varying the cross-traffic packet size from 384 to 1408 bytes is considered. The results, shown in Fig. 7, say that the error is smaller and more stable in networks with low congestion, which is consistent with past results. Also, Pathchirp and Abing present estimation problems in the case of low capacity and congested tight links, which is also very consistent with other results presented thus far. 7. Applicability of ABETTs This section provides general conclusions meant to answer the original questions regarding the use of ABETTs in current and envisioned applications and summarize the results of the performance evaluation. The first conclusion, and perhaps the most important

one, is that we are still far from having appropriate available bandwidth estimation tools for many, if not most, of the envisioned applications and networking environments. For example, the tool with the best estimation time is Abing, which provides estimations in around 1 s. Simply put, an estimation time of 1 s may leave out many real-time applications that would need to have estimates in the order of milliseconds. One example of this case may be the flow control mechanism of an available bandwidth-based transport layer protocol. Second, none of the existing tools introduces low enough overhead to be used in those applications that will work on a per-connection basis. The example of the transport layer protocol comes to mind again; if TCP or any substitute transport layer protocol was to use an ABETT for flow control, the amount of overhead would be huge (prohibited) given the large number of connections that currently go through the Internet. For these applications, new methods have to be devised to use the data packets as probe packets, reducing the overhead to acceptable levels. Third, tools based on the PGM (e.g. IGI, Spruce, and Abing) are usually less intrusive but less accurate than the ones based on the PRM (e.g. Pathload and Pathchirp). Fourth, all tools present their worst behavior and performance in highly loaded scenarios. Finally, different applications have different requirements. This calls for a parameterizable ABETT that could be used by most applications by just passing the needed parameter values required by the application. It would be ideal to have a tool that provides available bandwidth estimates based on the accuracy, overhead and convergence time needed by the application. This is a hard problem and this tool does not exist thus far. From the results of the performance evaluation presented in Section 6, the following list summarizes the most important conclusions:

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22 300

300

250

250

Estimation Error (%)

Estimation Error (%)

20

Pathload IGI Spruce Abing Pathchirp

200 150 100 50

Pathload IGI Spruce Abing Pathchirp

200 150 100 50 0

0

−50

−50 10

20

30

40

50

60

70

10

80

30

40

50

60

70

80

(b) Estimation error at 100 Mbps link capacity.

(a) Estimation error at 5 Mbps link capacity.

30

50

40 35 30 25 20 15

Pathload IGI Spruce Abing Pathchirp

25

Estimation time (s)

Pathload IGI Spruce Abing Pathchirp

45

Estimation time (s)

20

% of Cross Traffic in the Tight Link

% of Cross Traffic in the Tight Link

10

20

15

10

5

5 0

0 10

20

30

40

50

60

70

10

80

% of Cross Traffic in the Tight Link

20

30

40

50

60

70

80

% of Cross Traffic in the Tight Link

(d) Estimation time at 100 Mbps link capacity.

(c) Estimation time at 5 Mbps link capacity.

250

250

200

200

Estimation Error (%)

Estimation Error (%)

Fig. 6. Estimation error and estimation time for variable % of cross-traffic, 5 and 100 Mbps tight link, 10 ms OWD, and 1% PLR.

150 100 50 0

Pathload IGI Spruce Abing Pathchirp

−50

150

Pathload IGI Spruce Abing Pathchirp

100 50 0 −50

400 500 600 700 800 900 1000 1100 1200 1300 1400

400 500 600 700 800 900 1000 1100 1200 1300 1400

Cross Traffic Packet Size (Bytes)

Cross Traffic Packet Size (Bytes)

(a) 5 Mbps - 75% cross-traffic.

(b) 100 Mbps - 75% cross-traffic.

Fig. 7. Estimation error for variable cross-traffic packet size, 5 and 100 Mbps tight link, 10 ms OWD, 1% PLR, and 75% of cross-traffic.

 In the analysis of the tools under different congestion levels, it is clear that regardless of the capacity of the tight link, the estimation error of the tools increases with the amount of cross-traffic and with a tendency to overestimate the real available bandwidth. It is also clear that the tools have more difficulty estimating the available bandwidth accurately in low capacity links.  Current ABETTs behave differently to variations of the end-toend propagation delays, but in general, further increases in the propagation delay have no major impact on the performance of the tools.

 Spruce is the most accurate tool when varying the packet loss rate. With the exemption of IGI and Pathchirp, all tools present reliability problems with high packet loss rates, being Pathload the worst followed by Abing and Spruce.  Our results show that the size of the cross-traffic packet has no major effect on the performance of the tools. Table 3 summarizes the performance results provided thus far and shows the best performing tools for each of the main factors (capacity of the tight link, propagation delay, packet loss rate,

21

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22 Table 3 Summary of best performing tools. Main factor

Secondary factor

Best performing tools Estim. error

Time

Overhead

Reliab.

Low Capacity

20% X-traffic 75% X-traffic

Pathchirp-Abing Pathload-Spruce

Abing Abing

Spruce Spruce

All All

High Capacity

20% X-traffic 75% X-traffic

IGI-Pathload Pathload-Pathchirp

Abing Abing

Spruce Spruce

All but Abing

Low Delay

5 Mbps capacity 100 Mbps capacity

Pathload-Spruce Spruce-Pathload

Abing Abing

Spruce Spruce

All All

High Delay

5 Mbps capacity 100 Mbps capacity

Pathload-Spruce Spruce-Pathload

Abing Abing

Spruce Spruce-IGI

All but Abing

Low Packet loss

5 Mbps capacity 100 Mbps capacity

Pathload-Spruce Spruce

Abing Abing

Spruce-Pathload IGI-Spruce

All All

High Packet loss

5 Mbps capacity 100 Mbps capacity

Pathload-Spruce Spruce

Abing Abing

IGI-Spruce IGI-Spruce

All but Abing

Low X-traffic

5 Mbps capacity 100 Mbps capacity

Spruce IGI-Pathload

Abing Abing

Spruce Spruce

All All

High X-traffic

5 Mbps capacity 100 Mbps capacity

Spruce Pathload-Spruce

Abing Abing

Spruce Spruce

All but Abing

Table 4 Qualitative assessment of application requirements and best tools for the set of representative applications. Application

Accuracy

Overhead

Time

Reliability

Best tools

Network management SLA compliance Transport protocols Traffic engineering Overlay networks Security Admission control

Medium High Medium Medium Medium Medium High

Medium Medium Low Low Low Medium Medium

High High Low Low Medium Low Low

Medium Medium High High High Medium High

Spruce/Pathload Spruce/Pathload None yet None yet None yet None yet None yet

and amount of cross-traffic), secondary factors (percentage of network congestion or cross-traffic and link capacities) and response variables (estimation error, convergence time, overhead, and reliability) studied. In terms of the applicability of the current ABETTs in the envisioned applications, Table 4 includes a qualitative assessment of their requirements and the best tools for each application. The assessment is qualified as low, medium, or high if the application needs low, medium, or high accuracy, overhead, estimation time, or reliability. From the table, it can be seen that despite the current efforts in the design and development of new methodologies and tools to estimate the end-to-end available bandwidth, most of the tools are not entirely suitable for most of the envisioned applications. Current ABETTs only find applicability in very relaxed scenarios where the overhead and the estimation time of the tools are not big issues. 8. Summary This article studies and evaluates the applicability of current methods and tools that estimate the end-to-end available bandwidth in current and envisioned scenarios and applications. After a brief survey and explanation of the most important methodologies and tools available, it describes the testbed and tools utilized in the performance evaluation. Experiments are run to assess the performance of Pathload, IGI, Spruce, Abing, and Pathchirp in different scenarios and under different network conditions. In particular, the accuracy, estimation time, overhead, and reliability of the tools are studied considering scenarios with different capacities of the tight link, amount of cross-traffic, propagation delays, packet loss rates, and cross-traffic packet sizes. The study clearly shows

which tools might be the best choices for particular applications, networks, and network conditions, and which aspects need further research. Perhaps the most important conclusion is that we are still far from having a tool that can be used in many of the envisioned available bandwidth-based applications. Further, a parameterizable tool that provides estimations according to input requirements from the application does not exist. Therefore, more research is needed in this field to develop new tools and techniques or modify existing ones to meet the requirements of the applications. The recent works by Dovrolis [22] and Man [23] are one step in this direction, as they provide available bandwidth estimates with zero overhead using data instead of probing packets. Acknowledgment This work was partially supported by Team TACLAN under Contract No. TACLAN-USF-07-16. References [1] R. Prasad, C. Dovrolis, M. Murray, K. Claffy, Bandwidth estimation: metrics, measurement techniques, and tools, IEEE Network 17 (6) (2003) 27–35. [2] A. Shriram, M. Murray, Y. Hyun, N. Brownlee, A. Broido, M. Fomenkov, K. Claffy, Comparison of public end-to-end bandwidth estimation tools on high-speed links, in: Proceedings of the 6th Passive and Active Measurements Workshop, 2005. [3] S.-J. Lee, P. Sharma, S. Banerjee, S. Basu, R. Fonseca, Measuring bandwidth between PlanetLab nodes, in: 6th Passive and Active Measurements Workshop, 2005. [4] C. Dovrolis, P. Ramanathan, D. Moore, What do packet dispersion techniques measure?, in: Proceedings of the IEEE Infocom, 2001. [5] L. Angrisani, S. DAntonio, M. Vadursi, G. Ventre, Performance comparison of different techniques for available bandwidth measurement in packet switched networks, in: VECIMS 2003 – International Symposium on Virtual Environments, Human–Computer Interfaces, and Measurement Systems, 2003.

22

C.D. Guerrero, M.A. Labrador / Computer Communications 33 (2010) 11–22

[6] MGEN: The Multi-Generator Toolset. Available from: http://tang.itd.nrl.navy. mil/5522/mgen/mgen4.html. [7] J. Sommers, P. Barford, W. Willinger, A proposed framework for calibration of available bandwidth estimation tools, Microprocessors and Microsystems 31 (2007) 222–235. [8] C. Dovrolis, P. Ramanathan, D. Moore, Packet-dispersion techniques and a capacity-estimation methodology, IEEE/ACM Transactions on Networking 12 (6) (2004) 963–977. [9] F. Michaut, F. Lepage, Application-oriented network metrology: metrics and active measurement tools, IEEE Communications Surveys and Tutorials 7 (2) (2005) 2–24. [10] N. Hu, P. Steenkiste, Evaluation and characterization of available bandwidth probing techniques, IEEE Journal on Selected Areas in Communications 21 (6) (2003) 879–894. [11] J. Strauss, D. Katabi, F. Kaashoek, A measurement study of available bandwidth estimation tools, in: Proceedings of the 3rd ACM SIGCOMM Conference on Internet Measurement, 2003, pp. 39–44. [12] J. Navratil, R. Cottrell, ABwE: a practical approach to available bandwidth estimation, in: Proceedings of the 4th Passive and Active Measurements Workshop, 2003. [13] P. Maryni, F. Davoli, Load estimation and control in best-effort network domains, Journal of Network and Systems Management 8 (4) (2000) 527–541. [14] V. Ribeiro, M. Coates, R. Riedi, S. Sarvotham, B. Hendricks, R. Baraniuk, Multifractal cross-traffic estimation, in: Proceedings of the ITC Conference on IP Traffic, Modeling and Management, 2002.

[15] M. Jain, C. Dovrolis, Pathload: a measurement tool for end-to-end available bandwidth, in: Proceedings of the 3rd Passive and Active Measurements Workshop, 2002. [16] V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, L. Cottrell, pathChirp: efficient available bandwidth estimation for network paths, in: Proceedings of the 4th Passive and Active Measurements Workshop, 2003. [17] B. Melander, M. Bjorkman, P. Gunningberg, A new end-to-end probing and analysis method for estimating bandwidth bottlenecks, in: Proceedings of the IEEE Globecom, 2000, pp. 415–420. [18] M. Jain, C. Dovrolis, End-to-end available bandwidth: measurement methodology, dynamics, and relation with TCP throughput, in: Proceedings of the ACM SIGCOMM, 2002, pp. 537–549. [19] L. Rizzo, Dummynet: a simple approach to the evaluation of network protocols, Computer Communications Review 27 (1) (1997) 31–41. [20] H. Zhou, Y. Wang, X. Wang, X. Huai, Difficulties in estimating available bandwidth, in: IEEE International Conference on Communications, vol. 2, 2006, pp. 704–709. [21] R. Jain, The Art of Computer Systems Performance Analysis, Wiley, 1991. [22] M. Jain, C. Dovrolis, Path selection using available bandwidth estimation in overlay-based video streaming, in: Proceedings of the Networking Lecture Notes in Computer Science, 2007, pp. 628–639. [23] C.L.T. Man, G. Hasegawa, M. Murata, ICIM: an inline network measurement mechanism for highspeed networks, in: Proceedings of the 4th IEEE/IFIP Workshop on End-to-End Monitoring Techniques and Services, 2006, pp. 66– 73.