Reliable Monitoring of Network-related Performance ... - IEEE Xplore

Reliable Monitoring of Network-related Performance Parameters in Wireless Environments∗ Domenico Cotroneo1 , Armando Migliaccio1 , and Stefano Russo1,2 (1) Dipartimento di Informatica e Sistemistica Universit´a di Napoli Federico II Via Claudio, 21 80125 - Napoli, Italy (2) ITEM - Laboratorio nazionale per l’Informatica e la Telematica Multimediali Consorzio Interuniversitario Nazionale per l’Informatica Via Diocleziano 328, 80124 - Napoli, Italy (cotroneo, armiglia, sterusso)@unina.it

Abstract End-to-end delay estimation is a crucial issue in the design of network monitoring systems for wireless best-effort infrastructures. This work demonstrates that estimations based on one-way delay are the most suitable for evaluating the delay on wireless networks such as Wi-Fi LANs and Bluetooth piconets. To prevent delay measurement from being affected by clock synchronization issues, raw measures need to be corrected by estimating clock synchronism attributes such as clock skew and offset. However, due to network noise and clock adjustments, this estimation process may affect the reliability of network monitoring systems. In this paper we propose a trustworthy network performance monitor designed to support adaptive and/or soft real-time applications in wireless environments. The monitor corrects one-way delay measurements through an on-line algorithm for evaluating clock synchronism attributes. Simulation experiments show the effectiveness of our approach.

1 Rationale We are witnessing an increasing interest on the so-called next generation of distributed mobile applications, such as tele-conference, tele-presence, and tele-control. These applications are characterized by soft real-time requirements, and they are typically deployed over hybrid infrastructures, encompassing wired as well as wireless technologies (e.g. ∗ This work has been partially supported by the Italian Ministry for Education, University and Research (MIUR), within the framework of the FIRB Project “Middleware for advanced services over large-scale, wiredwireless distributed systems (WEB-MINDS), and by the Regione Campania, within the framework of the “Centro di Competenza Regionale ICT”.

Wi-Fi [3], Bluetooth [1], UMTS [2]). Due to the best effort policy of current wireless technologies, it is crucial to realize reliable monitoring systems in order to provide applications with feedback for adaptivity to network changes [8, 13]. To this aim, network monitoring systems must be accurate, since errors in the network performance estimation could lead the application to erroneous behaviors. A plenty of research studies has been conducted to estimate performance of Internet. The ITU-T [7] recommended network performance parameters (end-to-end delay, delay variation, and information loss) to be used for QoS estimation in IP-based networks. Several algorithms have been proposed for addressing issues in end-to-end delay estimation, the crucial parameter from which the other network performance indicators can be derived. Two are the most common metrics: i) the Round Trip Time (RTT); and ii) the One-way Transit Time (OTT). Asymmetric paths affect delay estimations based on RTT, whereas clocks synchronization affects delay estimations based on OTT. Although RTT is a good estimation of end-to-end delay in traditional LANs (such as IEEE 802.3x), we experience that it does not represent the favored choice for performance estimation of wireless environments, such as WLANs and Bluetooth piconets. As for the OTT, approaches for the correction of raw measures include those proposed in [12, 5, 14, 10, 16]. These post-facto approaches are mainly based on the following steps: i) estimation of clock synchronism attributes (i.e. skew, offset, drift); ii) removal of their effects from raw OTT measures; and iii) evaluation of the actual end-toend delay. Due to the great amount of data required for the clock attributes identification process, these approaches are not suitable in the context of real-time distributed systems. Moreover, they could suffer in presence of high network noise and/or clock adjustments [16].

Proceedings of the 10th IEEE International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS’05) 0-7695-2347-1/05 $20.00 © 2005

IEEE

The utilization of wireless network technologies may exacerbate the alternative among the different ways to estimate the end-to-end delay, due to significantly different behavior of wireless as compared to wired networks. In this paper, we present a trustworthy network performance monitor aimed to support adaptive and/or soft real-time applications in wireless environments. The monitor estimates performance parameters using an algorithm for on-line estimation of attributes for clock synchronism. In order to cope with network noise and/or clock adjustments, we propose the use of a threshold-based mechanism. Threshold-based mechanisms are able to discriminate among transient, intermittent and permanent changes of a phenomenon [4]. An accurate and low overhead algorithm for delay estimation allows the monitor to be an effective instrument for realtime mobile computing applications. The rest of the paper is organized as follows. Section 2 presents background concepts and related research. Section 3 describes the testbed and the experiments performed to assess algorithms for the end-to-end delay estimation in Wi-Fi and Bluetooth networks. Section 4 describes our approach in the design of the monitoring system. Section 5 asses the effectiveness of the approach, via simulation experiments. Section 6 concludes the paper with final remarks and directions of future work.

2 Background and related research We briefly define the basic terminology for describing the different clock attributes and network performance parameters. Let us refer to the true clock as the clock reporting the true time: • offset: difference between the local and the true clock; • frequency: the rate at which the clock progresses (first derivative of clock); • skew: difference between frequencies of the local and the true clock; • drift: first derivative of the skew, that is the skew variation with respect to time; • adjustment: an adjustment occurs when the time reported by the local clock is rapidly altered, due to a user or system action. Two clocks are synchronized at a particular moment, if both the offset and skew are zero, otherwise, time measured on one clock will not be consistent with the other clock. As for the network performance parameters, recommendations of the ITU-T [7] propose the following performance indicators to have an accurate estimation of network status:

• delay: it is the end-to-end delay; delay distribution consists of the sequence di (i = 0, 1, . . . , N), where di represents the delay in the i-th packet transmission; di is infinite when the packet is lost during its transmission; we can distinguish between the delay in the forward path and the delay in the backward path. Referring to delay without any other remark indicates the forward path delay. • delay variation: it consists of the difference between the i-th and (i-1)-th packet transmission delays. The delay variation distribution consists of the sequence dvi = di - di−1 (i = 1, . . . , N); • information loss: it represents how much information is lost for the application; information loss distribution consists of the sequence Ili (i = 0, 1, . . . , N), where Ili represents how many packets are delayed more than DM AX at the i-th packet transmission (in percentage). DM AX is the maximum delay that application can tolerate. It is defined as: i

Ili =

P lj

j=0 i

P lj =

1 0

A network monitor is a system that gathers data about the network status and produces a characterization of network performance in terms of a few selected parameters, provided to the application for adaptivity purposes. Since delay variation and information loss distributions are computed from the delay distribution, delay estimation is the crucial activity of the entire monitor. As for delay measurement, several methods are proposed in literature. RTT-based techniques require a simple and low-overhead algorithm, but they could be inadequate when the network traffic is asymmetric (e.g. when different QoS policies are enforced in uplink and downlink). In fact, the RTT does not give information about which path (forward or backward) is actually congested, potentially leading applications to erroneous behaviors. Methods based on OTT and Backward OTT (BOTT) estimate the traffic delay in only one network path; they are simple to compute, but they need clocks synchronization in order to prevent measures from being affected by skew, drift and adjustment [11]. Common methods to synchronize two or more clocks are those based on the Network Time Protocol (NTP [9]) or on the Global Positioning System (GPS [6]), and the so-called post-facto approaches. NTP is simple, but it adds an often non-negligible error to the delay measurement; GPS is accurate but limited to specific network environments, equipped with special devices; post-facto approaches proposed by Moon [10], Paxson [12], Gurewits [5], Takine [14], Wu [16], which aim to identify


IEEE

if dj > DM AX otherwise

Server Laptop

Technical features

Laptop 1 Server

2)

Server Laptop

Laptop 2

1)

PDA

Galileo

Intel PIII 850 Mhz, 256 MByte Ram, Linux Kernel 2.4.21

Pardesca

Intel PIV 1700 Mhz, 512 MByte Ram, Linux Kernel 2.4.21

Biondo


Toshiba


Aiacino

Intel Centrino 1200 Mhz, 512 MByte Ram, Linux Kernel 2.4.21

PDA

Intel StrongARM 206 Mhz, 64 MByte Ram, Linux Kernel 2.4.18

WAP

802.11b Wireless DSL/Cable Gateway Router

dongles

Bluetooth SIG specification 1.1, Radio Class 2

4)

3)

Figure 1. Wi-Fi testbeds: 1) nomadic computing; 2) ad-

Time [msec]

hoc computing. Bluetooth testbeds: 3) nomadic computing; 4) ad-hoc computing.

Time [msec]

a)

The testbeds used in our experimental investigation are depicted in Figure 1: Figures 1.1 and 1.3 depict two Nomadic Computing scenarios, while 1.2 and 1.4 depict two ad-hoc Computing scenarios. In the former cases, nodes involved in the experiments are fixed and mobile. In the latter cases both nodes are mobile, and they communicate without any fixed infrastructure. The traffic used for the estimation was a video stream with 2 Mbps average bit rate and 5 Mbps burst bit rate. The experiments are conducted under different network configurations and in both directions (from mobile to fixed infrastructure and vice versa). In particular, as for Bluetooth, the experiments were conducted in three different scenarios: • the piconet is connected to IEEE 802.3 infrastructure via a Bluetooth Access Point (BAP); furthermore, two other slaves are added to the piconet; we did such an experiment to analyze how delay changes as traffic and interferences increase (testbed 3);

Time [msec]

• the piconet is composed of one master (the server) and one slave (the PDA); Both master and slave transmit and receive in DH1 mode (testbed 4);

Time [msec]

b)

Figure 2. Nomadic computing Wi-Fi (testbed 1). Comparison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the BOTT. Traffic transmission from the server to the laptop.

• master transmits and receives in DH5 mode, whereas the slave operates in DH1 mode; this experiment aims to analyze how delay changes when an asymmetric traffic is forced between master and slaves (testbed 4). OTT and BOTT measures are corrected with the algorithm proposed by Paxson [11].

3.1 and estimate skew to correct raw data, are not suitable for the on-line delay estimation due to the great amount of data to collect. Even though the skew estimation proposed by Wang et. al. [15] is made through an on-line algorithm, it does not take into account drift and adjustment effects. Ultimately, accuracy in clock synchronism estimation of all these approaches may be affected by the presence of high network noise.

3 Preliminary experiments In this section we evaluate and compare the end-to-end delay on wireless networks by measuring both RTT, OTT, and BOTT. Once preserved the latter from synchronization issues, we are able to evaluate which of them is really effective for delay estimation in wireless environments. We experience that the RTT does not represent the favored choice for performance estimation for technologies like WiFi LANs or Bluetooth piconets/scatternets.

Wi-Fi experiments analysis

The standard IEEE 802.11x [3] has two function modes: DCF (Distributed Coordination Function), and PCF (Point Coordination Function). In the former mode, access to medium via the CSMA/CA protocol is controlled by each mobile station, while in the latter mode, access to medium is controlled by a base station (access point). Typically, when an ad-hoc network is established among mobile stations, they use the DCF mode to communicate to one another. Conversely, the PCF mode is used when a switch is connected to an Ethernet infrastructure bridging the standard 802.11x and the standard 802.3x. Figure 2 indicates the delay estimation through RTT and backward OTT (BOTT), when the video was transmitted from the server to the laptop. It is clear that the RTT is inadequate to represent the one-way delay in both direction in the highlighted window, that is the interval when the burst was transmitted. This conclusion is even more evident when the video was transmitted from the laptop to the server, as indicated in Figure 3. In this case, the delay estimation via RTT is more accurate in the forward path than backward path: in fact, when the


IEEE

Time [msec]

Time [msec]

a)

Time [sec]

b)

Time [sec]

a)

Time [msec]

Time [msec]

Time [sec]

Time [sec]

b)

Figure 3. Nomadic computing Wi-Fi (testbed 1). Comparison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the backward OTT. Traffic transmission from the laptop to the server.

Figure 4. Ad-hoc computing Wi-Fi (testbed 2). Compar-

video was transmitted from the laptop to the server, most of traffic was carried out by the forward path, while the backward path carried out only acknowledges. Therefore, the dominant component of RTT is the one-way transit time itself. Different trends of RTT depicted in Figures 2, and 3 may be due to different throughputs of IEEE 802.3x and IEEE802.11b and data link layers (IEEE 802.3x MAC layer does not have error control). Figure 4 indicates the end-toend delay estimation through RTT and OTT, when the video was transmitted from the laptop 1 (acting as server) to the laptop 2 (acting as client). It is clear that the RTT does not represent adequately the one-way delay in both direction; there is underestimation along the forward path and overestimation along the backward path.

mode (see Figure 6), the RTT will no longer be considered a good estimation of one way delay, due to different bandwidth division among the master and slave. It is worth noting, the delay reduction from the master to slave path cannot be considered the fifth part of the initial delay because DH5 packets are transmitted without any frequency hop, making it more sensitive to noise than a DH1 one. Figure 7 indicates the delay estimation when the piconet is interconnected to Ethernet via the Bluetooth Access Point, and two other devices are joined to it; even though the delay increases, it remains rather symmetric. The experiments demonstrate that a trustworthy network monitoring system can not use RTT for delay estimation, when the network infrastructure involves wireless technologies. These preliminary experiments lead us to the approach presented in the next section.

3.2

Bluetooth experiments analysis

Differently from Wi-Fi, Bluetooth [1] was though as short-range radio channel between embedded devices like mobile phone and headphones. To this aim, among the different design alternatives, Bluetooth SIG specification defined the access to the media layer takes places in time division multiplexing. In particular, the data link layer (L2CAP - Logical Link Control and Adaptation Layer Protocol) provides three different communication modes: DH1, DH3, DH5; they allow the transmitter to have respectively 1, 3, and 5 available slots for data transmission. The Figure 5 indicates the end-to-end delay estimation through the RTT and the OTT, when the video was transmitted from the server (the master) to the PDA (the slave). When master and slave use DH1 mode transmission, delay estimation through round trip time is accurate. If the master transmits in DH5

ison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the backward BOTT. Traffic transmission from the laptop 1 to the laptop 2.

4 The network monitoring system A network monitoring system compliant to the ITU-T recommendation [7] produces performance figures in terms of delay, delay variation and information loss. Once an application has specified the maximum delay it can tolerate, and the path of interest for the end-to-end delay estimation, the monitoring system may work in different modes: i) it returns network performance parameters when requested by the application (polling mode); ii) it will notify network performance changes with respect to conditions specified by the application (interrupt mode). In both operation modes, the monitoring system must have a trustworthy behavior: strategies for application reconfiguration/adaptation can not be affected by erroneous network status estimation


IEEE

Filter

Time [msec]

elaborate() correct()

MonitoringSystem

RawMeasures

Controller

Application getNPparam() subscribe()

a)

Time [msec]

addMeasure() getMeasure()

MeterClient

MeterServer

Time [msec]

estimateClockSynch()

measurement()

reply()

NET

b)

Time [msec]

Figure 8. Architecture of the monitoring system.

Figure 5. Ad-hoc computing Bluetooth (testbed 4). Com-

Time [msec]

Time [msec]

parison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the backward OTT. Traffic transmission from the server to the PDA.

Time [sec]

a)

Time [sec]

b)

Figure 6. Ad-hoc computing Bluetooth (testbed 4). Comparison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the BOTT. Traffic transmission from the server to the PDA, server in DH5 mode. 4-devices piconet

Time [msec]

Time [msec]

2-devices piconet

Time [sec]

a)

Time [msec]

Time [msec]

Time [sec]

Time [sec]

Time [sec]

Figure 7. Nomadic computing Bluetooth (testbed 3). Comparison between RTT (dashed) and OTT (solid); a) shows the forward OTT, b) shows the BOTT. Traffic transmission from the server to the laptop.

b)

and should be enforced in real-time. Since RTT cannot be trusted in case of wireless networks, the network monitor must estimate the end-to-end delay through the OTT. However, OTT needs to be corrected via the identification of clock synchronism attributes. In order to enable the use of the network monitoring system in the context of soft real-time applications, we adopt an online algorithm for clock synchronism attributes estimation. In particular, the skew estimation is based on Wang’s algorithm [15]. Since network noise and clock adjustments could affect one-way delay measures by errors in clock synchronism attributes identification, we use a thresholdbased mechanism for discriminating among apparent skew changes (i.e. estimation errors due to either network noise or clock adjustments) and actual skew changes (i.e. due to drift effects). Avoiding correction of OTT measures even when skew variations are due to estimation errors will give accuracy to our approach. As demonstrated by simulative experiments presented in the Section 5, our approach shows a better behavior as compared to the one by Wang [15]. The Figure 8 depicts the proposed network monitoring system. Basically, it is composed of three different blocks: Meter collects network information; Controller estimates clock synchronism attributes; Filter elaborates the collected data in order to provide network performance parameters. • Meter: the Meter is in charge of measuring network status and of providing the Filter with continuous data regarding the state of the communication channel. The Meter is composed of two layers: Server-side and Client-side; the Client takes care of the test packet generation. The Server has the only responsibility of test packet forwarding. Before explaining the test packet payload, let us define the following parameters: – tc0 : the reference time for the Client. Each further computation on packet delay is made from this time. As the Figure 9 indicates, tc0 is the time when the Client receives the SYNCH+ACK


IEEE

Rcvi = tCi* - tC0

S0 αT K

Sndi = tCi - tC0 Client

t

h i-t

t Server

On-line skew Estimation

Gsi

ω

1 z

et ck Pa

N

SY N

OTT

tCi*

t Ci

K AC

SY

AC K

t C0

tS0 Arri = tSi - tS0

tSi

Figure 9. Timing Chart packet from the Server, so that the monitoring can start. – ts0 : the reference time for the Server. Each further computation on packet delay is made from such an instant. As the Figure 9 indicates, ts0 is the time when the Server receives the ACK packet from the Client, so that the monitoring can start. – tci : the time when the Client starts sending the i-th packet; – tsi : the time when the Server ends to receive the i-th packet; – tci∗ : the time when the Client ends to receive the i-th packet. The packet payload consists of five fields: 1. Sndi = tci - tc0 : it is the time interval from the beginning of the measurement, until the beginning of the i-th packet transmission. 2. Arri = tsi - ts0 : it is the time elapsed from the beginning of measurement and the end of receiving the i-th packet; it also coincides with the beginning of the retransmission of the i-th packet for the forwarding. 3. Rcvi = tci∗ - tc0 : it is the return of the i-th packet to the Client. It is the time elapsed from the beginning of the measurement and the end of receiving the i-th packet.

To describe information contained in the Meter packet, let us refer to the timing chart in Figure 9. Once the

IEEE

Gsi*

Offset

Figure 10. Controller functional blocks. i-th packet is received on the Client-side, it is possible to obtain a raw estimation of the forward one-way transit time, OT Ti = Arri - Sndi , and of backward one-way transit time BOT Ti = Rcvi - Arri . The loss of a packet is identified returning the infinite values for each one of the three fields. • Filter: OTTs and BOTTs as collected by the Meter are affected by clocks synchronization issues. Such measures can not be considered accurate indicators of both forward and backward One-Way Delays (respectively OWD and BOWD), and they are corrected through the formula [12]: OW Di = OT Ti − Arri · G∗s + Of f set BOW Di = BOT Ti − Arri · G∗s + Of f set

The skew G∗s is estimated through the algorithm proposed in the Section 5 (based on Wang’s algorithm), while the offset Of f set is estimated through the formula: Of f set =

min(BOT Ti )−min(OT Ti ) 2

Once the data are corrected, the Filter provides average values of network performance parameters in order to improve the signal/noise ratio between the OWD and the measure error: OW DT =

1 N

·

N

OW Di

i=0 N

BOW DT =

1 N

·

BOW Di

i=0

OW DVT = OW DT − OW DT −1 BOW DVT = BOW DT − BOW DT −1

N

IlT =

P li

i=0 NT

P li =

1 0

if OW D i > DM AX otherwise

T indicates the particular request issued by the application, whereas N is the number of measures which the Meter has been collected until T.


α-count filter

On-line offset Estimation

4. The optional field can host different contents. For our purposes, it contains a sequence number for identifying packets lost during the transmission on unreliable transport layer and/or unreliable data link layer. 5. The stuffing field is filled with a sequence of random characters, in order to avoid that the measured delay be the result of compression techniques along the network path.

Gsi-1

α(L−1) + 1 α(0) = 0

8

1600

1400

1200

5 Experiments For the validation of the proposed approach, we have conducted several simulative experiments. Preliminary steps to these experiments are the following:

4

2

0

-2

-4

-6

1000 -8

800

a) 0

1000

2000

3000

4000

5000

6000

7000

8000

9000

-10

10000

0.8

if J (L) = 1

At each step L, the difference between two consecutive skew estimations is evaluated; if the difference is greater than a particular threshold S0 , then J(L)=1, otherwise J(L)=0. When the function α(L) is greater than a particular value αT , the controller assumes the change of the skew as permanent, and thus it adopts the last skew measure as the current estimation. J(L) provides the mechanism of discrimination between persistent and transient variations of the skew updating the α(L) filtering function. By using the α − count function, it is possible to avoid the modification of skew even when it changes due to the imprecision of the samples on which estimations have been made. The threshold αT represents the minimum number of consecutive changes sufficient to consider the skew significantly changed, while K sets the length of the temporal window in which the indicated errors are taken into account. This failure discrimination mechanism has two primary objectives which are contradictory to one another: i) a fast detection of intermittent failures or permanent failures of the component; ii) low percentage of false positive. As stated in [4], it is evident that high values of K cause a slow decrease of α − count, but a fast detection of the intermittent variations. However, such a choice often brings α − count to go above the threshold αT and consequently to assume significantly changed the skew even though it returns below the level S0 . A higher threshold requires a higher number of variations and therefore more time for the detection. From these simple considerations it is clear that for the best behavior of the α − count it is necessary a tuning phase based on the particular wireless technology being used.

Skew difference (∆Gs)

6 1800

c) 0

0.7

IEEE

200

300

400

500

600

700

800

7

0.6 6

0.5 0.4 0.3 0.2

4

3

2

0.1

1

0 -0.1

5

b) 0

50

100

150

200

250

0

d) 0

packet sent

100

200

300

400

500

600

700

800

packet sent

Figure 11. Simulation results; a) shows OTTs, with

weibull network delay (µ = 1000ms, σ = 100ms2 , γ = 2.34) and receiver clock’s skew Gs = 10−4 , d = 10−6 , A(t = 2500) = 1000, A(t = 5000) = −1000; b) shows the original skew, and skew identified via Wang’s algorithm (markers) and our algorithm (solid); c) shows the difference between two consecutive identified skew; d) shows the α − count.

• experimental evaluation of delay distribution: evaluating the probability distribution of network delay is a crucial step of the entire simulation process. By example, using a simple gaussian distribution to model real world network delay may not be a good solution for validating skew estimation algorithm. For this reason, we first collected network delay measures using wireless channels, and then we analyzed data in order to identify network delay probability distribution. In our analysis, we experienced an asymmetric delay distribution, which we reasonably modeled as a standard weibull distribution with shape factor γ ∈ (2.3, 2.6). • modeling skew trends: it is reasonable to model a skew trend as the following piecewise function: a (t) t + b (tj ) δ (t − tj ), where a (t) = ai ∀t ∈ (ti , ti+1 ) , i = {0, 1, ...} , b (tj ) = bj ∀tj ∈ (0, +∞). The linear component models drift effects, whereas the impulsive component models clock adjustments. For our experiments, we have modeled skew as follows: (1 + Gs ) + d · t + j A (tj ) · δ (t − tj ). After the above mentioned steps, we identified the skew trend by means of both Wang’s algorithm and our algorithm, using simulated raw OTT measures. Results are depicted in Figures 11 and 12. Figure 11.b and 11.c shows that Wang’s


100

8

Alpha-count(L)



10

2000

Skew (Gs)

α(L) =

2200

Time [msec]

• Controller: the Controller is in charge of estimating clock attributes. Figure 10 shows its functional blocks. As for skew estimation, the Controller works as follows: first, it estimates the skew through Wang’s algorithm, then, by using the α − count function it evaluates whether skew is actually changed or errors in the estimation occurred:   α(L−1) · K if J (L) = 0 0 < K < 1

900

Time [msec]

promising to achieve reliable monitoring in real-time wireless environments, even though a trade-off between timeliness and reliability has to be taken into consideration. Future work aims to investigate further solutions for end-toend delay estimation and to deploy our system in a realworld case of study.

References

packet sent

Figure 12. One-way delay compared to i) one-way delay estimated with Wang’s algorithm (dashed); and ii) ideal one-way delay (without network noise, black solid)

algorithm may be inaccurate in presence of clock adjustments. In fact, on the first adjustment, the algorithm experiences the biggest error in the skew estimation. The adoption of the α−count function improves the algorithm, leading it to follow the current skew value and making it less sensitive to clock adjustments and network noise. Figure 12 depicts the end-to-end delay estimated via our network monitoring system and via the Wang’s algorithm. Results are compared also with the end-to-end delay without network noise. The simulation results demonstrate the attractiveness of our approach as compared to the Wang’s approach. It should be noted that there exist some singular points where the estimation of end-to-end delay may be critical. In order to reduce such singularities, the controller should work on more collected data, increasing the intrusiveness and the overhead of the monitoring system. This represents a trade-off among timeliness and reliability.

6 Conclusions In this paper we proposed a network performance monitor suitable for real-time application in wireless environments such as Wi-Fi LANs, and Bluetooth piconets. An accurate and low overhead algorithm for delay estimation let the network monitoring system be an effective instrument for such systems. For these reasons, first we looked for the most suitable approach for end-to-end delay estimation in wireless environments, and then we tried to deal with arisen challenges proposing a solution based on the α − count function. Simulation experiments show that our approach is

[1] The Official Bluetooth Wireless Info Site. www.bluetooth.com, 2004. [2] UMTS Official web site. http://www.umts-forum.org, 2004. [3] Wi-Fi Alliance web site, 2004. [4] A. Bondavalli, S. Chiaradonna, and F. D. Giandomenico. Threshold-based mechanisms to discriminate transient from intermittent faults. IEEE Transaction on Computer, 2000. [5] O. Gurewitz and M. Sidi. Estimating One-Way delays from cyclic-path measurements. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 2001. [6] B. Hofmann-Wellenhof, H. Lichtenegger, and J. Collins. Global Positioning System. Springer Verlag Wien New York, 4th edition, 1997. [7] International Telecommunication Union. ITU-T Recommendations on Quality of Service in IP-based networks. http://www.itu.int/rec/rec.asp, 2004. [8] D. A. Kaff, C. Rodriguez, Y. Krishnamurthy, I. Pyarali, and D. C. Schmidt. Application of the QuO quality-ofservice framework to a distributed video application. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 2001. [9] D. Mills. Internet Time Synchronization: the Network Time Protocol. IEEE Computer Society Press, 1994. [10] S. B. Moon, P. Skelly, and D. Towsley. Estimation and Removal of Clock Skew from network delay measurements. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 1999. [11] V. Paxson. Measurements and Analysis of End-to-End Internet Dynamics. PhD thesis, University of California, Berkley, 1997. [12] V. Paxson. End-to-end Internet packet dynamics. IEEE/ACM Transactions on Networking, 7(3):277–292, 1999. [13] D. C. Schmidt and V. Kachroo. Developing next-generation distributed applications with QoS enabled DRE middleware. IEEE Communications Magazine, 2000. [14] M. Tsuru, T. Takine, and Y. Oie. Estimation of Clock Offset from one-way delay measurements on asymmetric paths. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 2002. [15] J. Wang, J. Yang, G. Xie, Z. Li, and M. Zhou. On-line estimation skew in one-way delay measurement. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 2003. [16] Q. Wu, J. Bi, and Z. Li. Relaible clock estimation algorithm for one-way measurements. In Proc. of 20th Int. Conf. on Computer Communications (INFOCOM’01), 2004.


IEEE