Good enough Predictive QoS - ISYS

Good enough Predictive QoS Christian Spielvogel, László Böszörményi, Roland Tusch Institute of Information Technology (ITEC) Klagenfurt University Austria {cspielvo,laszlo,roland}@itec.uni-klu.ac.at

Abstract— We argue for the need of a tool that is able to provide QoS aware server applications with accurate information about current as well as predicted network characteristics. To address this issue, we present the design and evaluation of DANEF - a system that is able to estimate, process and forecast bottleneck bandwidth, available bandwidth, delay, jitter and loss of a certain path. Active measurements are performed by sending small ICMP packet trains and forecasts are performed by applying fast allgorithms that need only small initialization sets. The accuracy of the measurements is achieved by applying an efficient and innovative filtering mechanism, the correctness of the forecasts is achieved by dynamically selecting the best fitting forecast model and by considering the forecast error of previous samples. Our evaluation has shown that DANEF’s measurement results are significantly more precise than those yield by the 5 most widely used tools called Bprobe, Cprobe, Pathload, Pathchar and Network Weather Service.

I. I NTRODUCTION In order to stream a video over the internet, several links and network elements have to be passed. Each link has its own characteristics like available bandwidth, bottleneck bandwidth, rtt, jitter and loss (see Figure 1).

Fig. 1.

Network Structure

These characteristics depend on two main parameters, namely the physical characteristics

of the links as well as the amount of traffic sent over them. The links are shared between data streams from different sources. Most network elements apply the best effort strategy thus doing nothing to avoid irregular gaps between the packets (jitter). One possibility to get rid of this effect is to make use of reservation protocols. These protocols minimize jitter and loss, but they are too rigid and thus waste resources. Although the protocols are available, nowadays it is not very pratical to make use of them. For this reason we have selected the middle course between these two extremes by supporting QoS aware applications with measurements and predictions about the underlying network resource availabilities. Although we cannot guarantee a certain level of QoS, we can predict ”good enough” QoS with high confidence. We have developed a tool that estimates the network status of certain paths with the help of precise active network measurements and a mechanism that provides forcasts for future time periods. Although network characteristics change continuously, our evaluation has shown that our forecasting mechanism provides excellent support for path selection for soft realtime applications such as video delivery. In our sample scenario (see Figure 1) the alternative servers are Server1 and Server2 and measurement packets are sent from the Client. These measurement packets are Internet Control Message Protocol (ICMP) echo packets that are timestamped by their destination host and sent back to the measurement host the ICMP Protocol automatically. This means that no additional software has to be installed on the destination host. The measurement technique used is an improvement of the well known packet bunch

mode [13]. The core part of our development is the filtering mechanism that is applied to detect gaps that have been shortened or enlarged by other network traffic. As can be seen in the evaluation part of this paper, using this filtering mechanism, our measurement results are by far more stable than measurement results from other tools applied to the same paths. Measuring network characteristics is not a new task and therefore it is realized by tools like Bprobe [7], Cprobe [7], Pathchar [8], Pipechar [10], Pathload [9], Nettimer [11] only to mention a few of them. The largest disadvantage of these tools is that they only reflect the actual network status but they are not able to do forecasts and give information about the future. II. R ELATED W ORK A. Bprobe Bprobe [7] is a tool for measuring bottleneck bandwidth of a path based on the packet pair technique. It is realized by measuring the interarrival times of ICMP echo packets by sending 7 packet trains, each consisting of 10 packets. The problem is that in case of cross traffic, differencing the gaps between packet pairs, the estimated measurement result deviates from the real bandwidth of the path. Bprobe tries to avoid these failures by sending packets of different sizes (p1 , p2 , ..., pn ) and comparing the correlation of packets belonging to consecutive streams. Using this filtering approach, it is assumed that all cross traffic packets are of the same size x and that consecutive Bprobe packets are of different sizes. Comparing correlations this way, according to the authors of [7] it is possible to distinguish correct patterns like p1 −p1 and p2 −p2 from patterns like p1 - x - p1 or p2 - x - p2 . We argue that this assumption is wrong because there is no guarantee that cross traffic packets are of the same size and the same number every time. Additionally Bprobe ignores the fact that gaps can not only be enlarged but also shortened by other traffic, resulting in overestimations. The next issue is that context switches are not detected, leading to over or underestimations that occur during the sending or receiving period. The authors in [7] argue that larger packets yield more reliable results. In contrary to this it can be found in [12] that best measurement results are yield

by selecting a mean packet size. Large measurement packets have the disadvantage that their processing time is long and other packets intervene. Small packets with principahttp://www.google.at/lly short round trip times have the disadvantage that if they are queued behind large packets, this has a much severe impact than for larger packets that generally have longer round trip times. Bprobe assumes that the bottleneck element is the slowest element in both directions. This might be true at least for static bottlenecks but not for dynamic ones that are caused by heavy traffic at a single network element. An other shortcoming of bprobe we have identified by taking a look at the source code. It derives from the fact that the sending and receiving operation are performed by the same process. All measurement packets that return to the sender before the tail of the stream is sent, have to be buffered and the delays measured from the network are not reflected. B. Pathload A tool for measuring available bandwidth is Pathload [9]. Pathload is based on the idea of performing the estimation based on the trend behaviour that a packet stream shows. In case that interarrival gaps of successive packets show an increasing trend it is concluded that the sending rate was greater than the available bandwidth. Otherwise if no increasing trend can be detected at the receiver side, it is clear that the sending rate has been below the available bandwidth. After each measurement the sending rate is adjusted and from all streams, the highest sending rate that has been below the available bandwidth (Rmin ) as well as the lowest sending rate that has been above the available bandwidth (Rmax ) are stored. The measurement terminates if the difference between (Rmax − Rmin ) is smaller than a user defined value and the range [Rmin , Rmax ] is returned as a final bandwidth estimate. A negative aspect about Pathload is the assumption that the sequence of store and forward links is fixed and all packets take the same route. As a consequence, measurements performed with the Pathload tool are only representative for connection oriented network applications reflecting the actual network status. Principally a good thing about Pathload is that it has a mechanism for detecting context switches on the sender or the receiver side

to avoid that gaps are enlarged on the sender side or shortened on the receiver side. Nevertheless many context switches are undetected by Pathload because the designers have defined a static gap size that indicates the influence from a context switch, instead of considering dynamic process scheduling times that depend on the operating system.

terminates when all packets are received or a timer has expired. From all tools that work by sending ICMP echo packets, only Pipechar is aware of the fact that the train size needs to be determined based on the round trip time of a certain link. This is important because in case that the head of the train returns before the rest of the train has been sent, there is additional load on the network interface, C. Pathchar having a significant influence on the measurement Pathchar [8] is a sender based approach for esti- result. Concerning Pipechar we have identified two mating latency, bottleneck bandwidth and queuing disadvantages. The first one is that its designers try delays by measuring round trip times of consecutive to avoid context switches by increasing the priority packets, making use of the ICMP protocol. The of the measurement process compared to other protool estimates the characteristics of the end to end cesses by abandoning the processor several times. path as well as of all the intermediate links. The This handling requires support from the operating characteristics from each link (N) are estimated by system. Contrary to that in our tool we suggest calculating the difference to link N-1. The mea- a mechanism implemented at the user level. The surement terminates if the difference between the authors in [10] argue that longer packet trains yield smallest and the largest round trip time from each more reliable results. We argue that this assumption is only true in case of light cross traffic, under heavy series is less than 10 %. cross traffic the probability of inference increases D. Cprobe with the size of the packet train. Cprobe [7] is a tool for estimating the available bandwidth of a path by measuring the dispersion F. Network Weather Service The Network Weather Service (NWS) [14] is a between the first and the last packet of a train consisting of ICMP echo packets. Cprobe termi- distributed tool for providing dynamically changnates after sending 4 packet trains, each consisting ing performance characteristics and forecasts. NWS of 8 packets. Most libraries are shared with the consists of four main components connected by bprobe tool described in section II-A. In contrary to TCP/IP sockets, called persistent state process, bprobe, cprobe has a mechanism for handling con- name server process, sensor process and forecaster text switches that occur during sending or receiving. process. The persistent state process is a central This mechanism is very simple because it assumes component storing all measurement data received that the smallest and the largest round trip time are from the sensor processes located at remote sites the result from context switches and so these are which can be found by querying the name server the ones that are discarded from each measurement process. These sensors perform network measurements based on the TCP protocol by sending messeries. sages of different sizes and by timing their delay E. Pipechar times. Measurement results managed by the persisPipechar [10] is a tool for estimating bottleneck tent state process are used by the forecaster process and available bandwidth as well as round trip times to generate predictions for a specified period in the for a certain path. The bandwidth is calculated with future. a measurement technique called single packet with III. DANEF size differential calculus at the same node (SPSD). This technique works by sending two packets of DANEF (Distributed Active Network Estimation different sizes to the same node. Bandwidth is and Forecasting tool) is a CORBA-based measurecalculated by dividing the difference in packet size ment tool. The tool is organized in a 4 layer through the difference in travelling times. The algo- architecture including a Discovery Layer (section rithm works by sending the packet train once and III-A), a Data Collector Layer (section III-B), a

Forecast Layer (section III-C) and a Propagation Layer (section III-D).

Fig. 2.

Network Structure

A. The Discovery Layer The Discovery Layer has the task of discovering the path from the measurement host to a target host and providing this structure to the higher layers. The task is repeated every time before a new measurement is started, so route changes are captured. The discovery is performed using the UDP (User Datagram Protocol) as well as the ICMP (Internet Control Message Protocol). DANEF is a sender based measurement tool, thus it is not necessary to install any software at the target or at any intermediate host. The discovery process starts by sending UDP packets consecutively to each intermediate network element as well as to the target host. This is achieved by setting the IP header’s TTL field to expire when reaching the target host. The target host responds with an ICMP error message including its own IP address. With this mechanism, the measurement host learns about all intermediate layer3 network elements. When the complete path is discovered, it is divided into multiple subpaths called areas. An area is a network link bounded by two network elements. A network element can be a connecting element like a router as well as the source or destination host. It is possible to share measurement results between nearby hosts which reduces response times as well as unnecessary network traffic. B. The Data Collector Layer The Data Collector Layer has the task of measuring the characteristics like bottleneck bandwidth, available bandwidth, delay, jitter and loss of the

paths provided by the Discovery Layer. The bottleneck bandwidth measurement is based on a technique called packet bunch mode [13]. It differs from the original idea in the following: Consecutive packets are of different size and available bandwidth BA is calculated by dividing this difference (SN − SN −1 ) by the size of the interarrival gaps (T SRN −1 − T SRN ) − (T SSN −1 − T SSN ). T SSi and T SRi are the sending and receiving timestamps of packet i. S2 − S1 BWα = h ... |(T SR2 − T SR1 ) − (T SS2 − T SS1 )|

|(T SRN

BWA =

SN − SN −1 i − T SRN −1 ) − (T SSN − T SSN −1 | BWβ = sort(BWα )  BWβ N +1 , if N is odd 2

BWβ N +BWβ N



2 +1

2

2

, if N is even

BWα is a collection of N-1 bandwidth measurement samples resulting from the packet train. In order to determine the median value, the tuples have to be sorted (BWβ ) and depending on the number of samples the available bandwidth (BWA ) is determined. Using this approach, bottleneck bandwidth (BWB ) can be calculated from the same packet stream as well. BWB = min(BWβ ) Performing estimations this way, network bandwidth can be saved, all performed calculations are based on the same network status and additional error handling becomes unnecessary. Using active network measurements it has to be considered that packets from different streams are multiplexed onto the same link after passing a network element. Case A in Figure 3 represents the intersending state of two subsequent packets. As can be seen in case B of Figure 3, packets can intervene between the measurement packets or can surround them as in case C. Case B has the disadvantage that the gap between two measurement packets is enlarged resulting in underestimations. Case C has the disadvantage that gap is shortened leading to overestimations. In order to produce precise and accurate measurement results it is necessary to get rid

Producing forecasts is always a tradeoff between time and data required as well as accuracy achieved. In order to achieve good performance, the necessary data is retrieved from optimized database index structures, by performing range queries. Additionally all forecasting models are implemented as stored database procedures in C so that it is Fig. 3. Cross traffic behaviour not necessary to transfer the data. The models implemented in DANEF are simple and similar to those used by the Network Weather Service(NWS) of gaps enlarged or shortened by cross traffic. [14]. Shortened gaps are detected by comparing inter DANEF’s implementation differs from NWS in the arrival gaps to the dispersion introduced by way that an active error correction mechanism has the sender. Packets are only considered for the been added. Every forecast depends on a set of estimation if these inter-arrival gaps are larger than initialization values called hold out set. Different the original ones, otherwise they are discarded. hold out sets show different patterns, so every time After discarding these packets, the remaining a forecast is performed, the best fitting model needs set still contains enlarged gaps that lead to to be selected. It is found by applying the holdout underestimations. Detecting enlarged gaps is much set to all implemented models and by selecting the harder than detecting shortened ones but it can be one that yields the smallest forecast error. During managed by assuming that the pair showing the this test, every model learns from previous errors smallest dispersion is the one that was the least and increases its precision every time it is applied. influenced from any cross traffic. Additionally it In contrary to NWS the result of the forecast is not is necessary to explicitly care about: out-of-order a single value but a so called confidence interval delivery, context switches, lost packets, duplicated based on the forecasted value, the mean squared packets and delayed packets. In case of DANEF error (MSE) of the last forecast and the desired out-of-order delivery [13] is avoided and lost precision of the forecast. In case of DANEF the packets, duplicated packets and delayed packets desired precision is calculated dynamically based on are detected by assigning each packet an unique the standard deviation of the initialization set. identifier. This identifier is a combination of the stream and packet number. Context switches that D. The Propagation Layer occured during the sending process are detected by The Propagation Layer is responsible for collectcomparing adjacent interdelivery gaps. Taking into ing, storing and providing estimated and forecasted consideration that scheduling times vary between data to the applications. These applications interact operating systems, every gap that is more than with DANEF through an interface that is specified twice as large than the median gap is considered in CORBA IDL. to be enlarged by a context switch. In case of a IV. S YSTEM E VALUATION detected context switch, the stream is splitted and In this section we show the performance of the bandwidth calculation is performed for every DANEF compared to Bprobe, Pathchar, Cprobe, sub stream. Pipechar, Pathload and the Network Weather Service. The comparison is based on two statistical values called inaccuracy and precision. Precision C. The Forecast Layer has been defined by using the coefficient of variThe Forecast Layer is especially important for ance(CV): applications that depend on QoS assurances. It offers network support by producing precise forecasts coef f icient of variance = standard deviation mean for specifiable time periods, based on measurements captured in the past by the Data Collector Layer. precision = (1 − coef f icient of variance)∗100%

Good precision means that the measured values do not differ much from each other but it doesn’t mean that they are representative for the reference value the user is interested in. The difference between the estimated value and the reference value can be expressed with a characteristic called inaccuracy(I): n−1

1X |estimated valuei − ref erence valuei | I= n i=0 Parameter n is the number of samples belonging to the same measurement series considered for the calculation. Inaccuracy is the average difference between the estimated and the measured throughput. In order to provide a nearly equivalent network status to all tools tested in the same run, the comparison between the tools concerning standard deviation, precision and inaccuracy has been performed within our local testbed and can be found in IVA. In order to gain some initial experience of our tool’s behaviour over the Internet, we have tested it in a wide area network setting between Austria and Hungary (IV-B). A. Comparison of the tools in the local testbed The testbed consists of 4 computers (P1,P2,P3,P4) connected by a HUB. The tools have been compared in a round robin fashion with and without cross traffic. The measurements have always been performed between P1 and P2, the TCP cross traffic has been sent between P3 and P4. The reference application has been a client server application that sends a stream consisting of ten equally sized 750 byte data packets from the server to the client in best effort manner. Each test has been repeated 50 times. The first tool package that has been evaluated against DANEF is the Cprobe and Bprobe package. The original version is available from [2] but this version is only available for the SGI architecture. The evaluated version is a ported one from [1] that differs mainly in the replacement of C libraries to run the tools with the Linux operating system.

Metric Std.Dev. Prec. Inacc.

DANEF CPROBE 0.11 Mbit/sec 10.91 Mbit/sec 99.84% 83.36% 3.50 Mbit/sec 9.40 Mbit/sec

Figure 4: Comparison of DANEF and CProbe Concerning available bandwidth Cprobe and DANEF (Figure 4) have a precision of 83.36 and 99.84 percent. Concerning inaccuracy, on average Cprobe’s estimation is about 9.40 Mbit/sec above the reference value, DANEF’s value only 3.50 Mbit/sec. Next the behaviour of Cprobe and DANEF on inserting 30 Mbit/sec of TCP cross traffic has been tested (Figure 5).

Metric Std.Dev. Prec. InAcc.

DANEF CPROBE-CROSS 10.59 Mbit/sec 23.90 Mbit/sec 72.92% 52.74% 9.96 Mbit/sec 25.08 Mbit/sec

Figure 5: Comparison of DANEF and CProbe under generated cross traffic

Analyzing CPROBE’s and DANEF’s results, it can be seen that the precision has decreased to 52.74 and 72.92 percent. The average inaccuracy has increased to 25.08 Mbit/sec for Cprobe. Danef’s results deviate only about 9.96 Mbit/sec from the measured reference value. When measuring the bottleneck bandwidth of the testbed, the Bprobe tool is evaluated against the DANEF tool. Metric Std.Dev. Prec. Inacc.

DANEF BPROBE-CROSS 12.61 Mbit/sec 13.29 Mbit/sec 77.01% 75.04% 9.84 Mbit/sec 13.86 Mbit/sec

Figure7: Comparison of DANEF and BProbe under generated cross traffic


DANEF BPROBE 0.58 Mbit/sec 1.85 Mbit/sec 99.37% 98.19% 2.53 Mbit/sec 12.65 Mbit/sec

For both tools it can be seen (Figure 7) that due to an increased number of outliers, there is an increase in the standard deviation as well as in the inaccuracy. BPROBE’s precision has decreased to 75.04 and DANEF’s to 77.01 percent. On average BPROBE’s estimated value deviates from the reference value about 13.86 Mbit/sec, DANEF’s estimation deviates only about 9.84 Mbit/sec. The next tool that has been evaluated is Pathload available from [4].

Figure 6: Comparison of DANEF and BProbe Figure 6 shows that the BProbe’s precision is 98.19 and Danef’s is 99.37 percent. Even though both tools are nearly equivalent concerning precision, there is a large difference concerning inaccuracy. Bprobe’s estimated value differs about 12.65 Mbit/s but DANEF’s value only differs about 2.53 Mbit/sec from the reference value. Similar to testing Cprobe’s behaviour on inserting 30 Mbit/sec of TCP cross traffic, BProbe’s behaviour has been evaluated and compared to DANEF (Figure 7).


DANEF PATHLOAD 2.01 Mbit/sec 4.83 Mbit/sec 97.74% 94.80% 7.15 Mbit/sec 11.88 Mbit/sec

Figure 8: Comparison between DANEF and Pathload

As can be seen in Figure 8 the series measured by Pathload shows a precision of only 94.80 percent contrary to 97.74 percent of the DANEF tool. Concerning the inaccuracy, Pathload tool’s sampled values deviate about 11.88 Mbit/sec from the reference value. In contrary the values collected by DANEF only deviate about 7.15 Mbit/sec. Both tools tend to overestimate the reference UDP value, but Pathload’s error is about 4.73 Mbit/s larger. Similar to the other tools, pathload’s behaviour has been tested on inserting 30 Mbit/sec of TCP cross traffic.


DANEF PATHCHAR 0.50 Mbit/sec 3.09 Mbit/sec 99.46% 96.98% 8.77 Mbit/sec 16.19 Mbit/sec

Figure10: Comparison of DANEF and Pathchar As illustrated in Figure10, the Pchar and the DANEF tool have a precision of 96.98 and 99.46 percent. Concerning the inaccuracy, on average Pchar’s estimation is 16.19 Mbit/sec away from the reference value which is nearly twice worse than DANEF’s estimation which differs 8.77 Mbit/sec from the reference value. Again 30 Mbit/sec of TCP cross traffic has been inserted and the measurement has been repeated, yielding the following results: Metric Std.Dev. Prec. Inacc.

DANEF 0.68 Mbit/sec 98.58% 2.41 Mbit/sec

PATHLOAD-CROSS 4.21 Mbit/sec 95.23% 41.72 Mbit/sec

Figure9: Comparison of DANEF and Pathload under generated cross traffic As can be seen in Figure 9 Pathload’s precision has changed to 95.23 and DANEF’s to 98.58 percent which is nearly similar to the results measured without inserted cross traffic for both tools. Nevertheless Pathload completely ignores the 30 Mbit/sec of inserted cross traffic. So it’s estimated value deviates from the reference value about 41.72 Mbit/sec, contrary to that DANEF’s estimation only deviates about 2.41 Mbit/sec. The next tool being evaluated is Pchar, which is an open source version of Pathchar available from [5].


DANEF PATHCHAR-CROSS 8.73 Mbit/sec 4.80 Mbit/sec 82% 95% 14.84 Mbit/sec 67.33 Mbit/sec

Figure11: Comparison of DANEF and Pathchar under generated cross traffic

Increasing the cross traffic (Figure 11) increases the number of outliers which has a more severe effect for DANEF than for Pathchar. Pathchar yields a precision of 95 percent contrary to Danef that yields a precision of 82 percent. The reason fro Pathchar’s better precision can easily be seen in Figure11. The cross traffic inserted is detected by DANEF after the first 4 measurements and the bottleneck bandwidth value changes about 40 Mbit/sec. This is the reason for the huge standard deviation and the resulting lower precision. Pathchar is almost completely insensitive to the inserted cross traffic so it seems to have a better precision. This can be seen when analyzing Pathchar’s inaccuracy. On average the estimated value differs from the reference value about 67.33 Mbit/sec. Contrary to that DANEF’s value only differs about 14.84 Mbit/sec. The next tool being evaluated is the Network Weather Service available, from [3].



of inserted TCP cross traffic are illustrated in Figure13.



NWS-CROSS 7.54 Mbit/sec 98.54% 27.65 Mbit/sec

Figure13: Comparison of DANEF and NWS under generated cross traffic Analyzing the results it can be seen that neither NWS nor Danef’s precision is significantly influenced by the cross traffic. NWS yields a precision of 98.54 percent, Danef even yields a precision of 99.40 percent. Concerning inaccuracy, NWS is more than twice as inaccurate as Danef. On average NWS is 27.65 Mbit/sec away from the reference value, Danef is only 12.29 Mbit/sec away. The last tool being evaluated is Pipechar available, from [6].

NWS 5.19 Mbit/sec 92.96% 8.27 Mbit/sec

Figure12: Comparison of DANEF and NWS As can be seen in Figure12, the Network Weather Service and DANEF have a high precision of 92.96 and 99.42 percent. On average NWS’ estimation is about 8.27 Mbit/sec below the reference value. Although DANEF’s estimation is also below the reference value, the estimated value is only 5.79 Mbit/sec away. The results of repeating the test under 30 Mbit/sec



PIPECHAR 0.97 Mbit/sec 98.90% 10.10 Mbit/sec

Figure14: Comparison of DANEF and Pipechar As can be seen in Figure14, both Pipechar and DANEF have a high precision of 98.90 and 99.39

percent. Concerning inaccuracy it can be seen that pipechar is slightly better than Danef. On average Pipechar’s estimation is about 10.10 Mbit/sec below the reference value. Although DANEF’s estimation is also below the reference value, yielding 1.02 Mbit/sec (1.11 %) the error is 3.59 Mbit/sec less than Danef’s. The results of repeating the test under 30 Mbit/sec of inserted TCP cross traffic are illustrated in Figure15.

have been located at Klagenfurt, the UDP reference server has been located at Budapest. The measurement results can be found in Figure 16.



Figure 16: Evaluation of DANEF in a WAN setting Metric Std.Dev. Prec. Inacc.


PIPECHAR-CROSS 1.55 Mbit/sec 98.20% 32.35 Mbit/sec

Figure15: Comparison of DANEF and Pipechar under generated cross traffic Analyzing the results it can be seen that neither Pipechar’s nor Danef’s precision is influenced by the cross traffic. Pipechar yields a precision of 98.20 percent, Danef even yields a precision of 98.49 percent. As we have seen in Figure15 without crosstraffic Pipechar was more accurate that Danef, but under the influence of crosstraffic the result has changed significantly. On average Pipechar’s value is 32.35 Mbit/sec away from the reference value, contrary to Danef’s value that is only 14.11 Mbit/sec away. B. Tests in a wide area network setting We have evaluated our measurement tool in a wide area network setting by comparing it to a UDP Reference Stream. The measurement has been performed 50 times between Kagenfurt (Austria) and Budapest (Hungary). DANEF and the UDP reference client

By analyzing the measurement results from our wide area network evaluation, it can be seen that DANEF shows a precision of 68.09 %. Taking into consideration the small inaccuracy of only 0.49 Mbit/sec to the UDP reference application, it can be seen that both applications suffer from the natural non deterministic queuing effects of the Internet. C. Forecasting The most important aspect of our work is the fact that a level of QoS can be assured performing predictions of future network conditions by analyzing measurement results from the past. We show that our approach works by remeasuring the forecasted values at the given time. The first evaluation is based on an input set of 100 samples collected within a local testbed. Figure17 shows how the n + 1st value is calculated based on the previous n values corrected against the forecast errors. Concerning the accuracy of the forecast only 24 percent of the forecasted values exaggerate the upper bound of the confidence interval by 0.22 Mbit/sec and 13 percent exaggerate the lower bound by only 0.60 Mbit/sec.

Figure17: Forecast with DANEF Next the lower and upper bound of the calculated confidence interval have been applied to a set of 100 samples from the same local network, collected 24 hours later. The result is illustrated in Figure18.

Figure18: Forecast for the next day with DANEF 25 percent of the reference values exaggerate the forecasted upper bound by only 0.25 Mbit/sec and 17 percent of the reference values exaggerate the forecasted lower bound by not more than 0.55 Mbit/sec. V. C ONCLUSION AND FUTURE WORK In this work we have presented a new mechanism for assuring QoS without support from the network. All QoS characteristics an application needs are predicted with high confidency, based on precise and accurate measurements. These values are collected by performing active network measurements and by applying a fast forecasting mechanism. Our evaluation has shown that our measurement results are

more precise than the results from the most popular tools called Bprobe, Cprobe, Pathchar, Pathload and Network Weather Service. There was only one tool called Pipechar, that performed slightly better in our testbed. The inaccuracy to the reference value was about 3 Mbit/sec less than DANEF’s. On inserting 30 Mbit/sec of generated cross traffic the measurement results changed significantly. DANEF’s inaccuracy was about 20 Mbit/sec less than Pipechar’s. Our future work concerns the fact that results from one way measurements are less influenced by cross traffic and more precise than two way measurement results. The negative aspect about one way measurements is that the software has to be installed on the sending as well as on the receiving host. In order to get rid of this aspect we work on an implementation that is located only at the sending host but that forces the destination host to timestamp the received ICMP measurement packet before echoing it back. An other part of our further work concerns the extension of the tool with passive measurement techniques to protect the network from inserted test traffic. Contrary to the actual implementation, where forecasts are only made for UDP transfers, passive techiques have the possibility to cover all protocols without changing the measurement mechanism. The actual implementation shows only the basic idea of how to produce fast and accurate QoS assurances. At the moment only very simple forecasting scenarios are implemented. For example, to make an assurance for 9 o’clock the next day, only data from the previous day is used. Even though this yields good results, these scenarios should be extended by taking into consideration the Internet behaviour of certain users during working day, weekends or holidays. So to make a forecast for the 1st of november, not only the data from the 31st of october, but also the data from previous years should be considered and a mapping to the actual status of the network should be performed.

R EFERENCES [1] BPROBE - CPROBE Software Ported for Linux. http://piglet.uccs.edu/ chow. [2] BPROBE- CPROBE Software. [3] NWS Software. http://nws.cs.ucsb.edu/download. [4] Pathload Software. http://www.cc.gatech.edu. [5] PChar Software. http://www.employees.org. [6] Pipechar Software. http://www-didc.lbl.gov/NCS. [7] R. Carter and M. Crovella. Measuring Bottleneck Link Speed in Packet-Switched Networks. Performance Evaluation, 27,28:297–318, 1996. [8] Allen B. Downey. Using Pathchar to Estimate Internet Link Characteristics. In Measurement and Modeling of Computer Systems, pages 222–223, 1999. [9] M. Jain and C. Dovrolis. Pathload: A Measurement Tool for End-To-End Available Bandwidth. In In Proceedings of Passive and Active Measurements (PAM) Workshop, pages 14– 25, March 2002. [10] G. Jin, G. Yang, B. Crowley, and D. Agarwal. Network Characterization Service (NCS), 2001. [11] Kevin Lai and Mary Baker. Nettimer: A Tool for Measuring Bottleneck Link Bandwidth. pages 123–134. [12] Kevin Lai and Mary Baker. Measuring Link Bandwidths Using a Deterministic Model of Packet Delay. In SIGCOMM, pages 283–294, 2000. [13] Vern Paxson. End-to-End Internet Packet Dynamics. In Proceedings of the ACM SIGCOMM ’97 conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, volume 27,4 of Computer Communication Review, pages 139–154, Cannes, France, September 1997. ACM Press. [14] Richard Wolski. Dynamically Forecasting Network Performance Using the Network Weather Service. Cluster Computing, 1(1):119–132, 1998.